How to make security policies a team effort

Mark Bichon Technical Content Editor at Bearer with a background in software development and developer education. Twitter | LinkedIn

There are few things harder than inter-department cooperation. That’s why we have terms like DevOps, DevSecOps, DesignOps…the list goes on. All of these operations-focused concepts aim to bring two separate parts of an organization together. This is tough but becomes even harder when one team has to be the one that slows things down. For some businesses, this is legal. For others, it’s security.

So how do you keep development moving, while also ensuring that security checks the necessary boxes? You bring the people together. Instead of treating security and development as separate goals, you make sure everyone is working toward the same one—with as little friction as possible. In this article, we’ll look at ways to make security more of a team effort. All while ensuring that you’re still building with the cadence you expect from your product and development teams.

Make documentation “question-friendly”

We’ve all seen organizations with read-only policies. This stems from traditional corporate and legal culture but doesn’t translate well to involving the team. Make security policies and documentation welcoming. Whether it’s using tools like Notion or Google Docs, or even adding commenting to your internal knowledge base, ensure that there is some way for the team to ask questions and comment on policies.

Don’t understand something? Ask a question. Think there’s a hole in the policy? Leave a comment. Take it a step further and incorporate approval history, a changelog, and even context for decisions. This is a great way to make formal documents more approachable—especially for team members less versed in security jargon. You can even go a step further by having contextual explanations for the required legal language.

Augment your efforts with automation

Expecting every developer to stay on top of each new threat is unrealistic, but you can make their job easier by automating the low-hanging fruit. Tools like Bearer work by tracking changes and scanning your codebase for anything that conflicts with your security policy. Easy mistakes are solved by automation. Not every threat can be avoided this way, but the more policies and protections you can roll into your CI/CD pipelines, the better.

Other automated tooling, like dependency scanning and vulnerability notifications, even come as part of the many version control systems (VCS). For example, GitGuardian integrates natively with GitHub to scan every Pull Request’s commits for secrets and suggest remediation steps. This allows the individual developer to get notified when an incident is detected by GitGuardian, directly in the GitHub interface. Make sure these are enabled, and more importantly make sure you have a policy of assessing—and acting upon—vulnerability notifications as they arise.

Roll security policies into onboarding

The idea of “shifting left” in security is popular as it involves moving security teams early in the development cycle. But what about spreading security knowledge? The same idea applies. The best way to do this is to make security a part of the onboarding process. Just as new hires may pair with human resources to learn about benefits and policies, have them meet with security for a hands-on view of both the “people policies” and the engineering expectations.

Hold regular training sessions

You can take the onboarding approach a step further and hold regular security training. Traditional organizations may do this already but mostly focus on the basics. Strong passwords, general technical best practices, etc. For developers, you’ll want this training to go deeper and cover OWASP best practices for app and service development.

You can either let your security team structure and lead these sessions, or bring in an external company to run formal training. Many now offer remote, asynchronous, and instructor-led programs. Make sure to incentivize attendance, and find ways to tie learnings directly into whatever the team is currently building.

These types of sessions can even bring new perspectives to your existing policies. As more individuals gain a better sense of the expected policies, they can help improve your existing ones. This makes the need for those “question-friendly” docs mentioned earlier even greater.

Go to where your developers are

There’s a consistent disconnect between security and development. As much as every company tries to bring the two into the same process, it still isn’t perfect. The best thing you can do is bring security policies into their workflows in a non-intrusive manner. Just like with automated SAST and CI/CD integrations, embedding processes into a developer’s workflow means security is always a part of the process—rather than an afterthought.

GitGuardian’s CLI, ggshield, can be installed as a pre-commit hook on a developer’s workstation to act like a security seatbelt preventing any secret from being committed locally in the first place. If a developer chooses to bypass the guardrail and push a secret anyway, the event is reported in the GitGuardian dashboard. This allows security teams to have eyes on any possible policy issues as developers build—all without holding up their progress. These tools can detect risks, watch for vulnerabilities, and notify the right people in a non-intrusive way.

Have an ‘open door’ policy to concerns

Maybe you’ve heard of the concept of “HR-free Friday”. This is problematic in practice, but it generally comes from a place of good intentions. Use those good intentions to institute a time, place, or process for anyone within your company to raise concerns about security. This could be asking a question they’re afraid to otherwise ask in a public setting or even challenge an existing approach.

Ensure this is a safe place for anyone on the team to raise concerns or ask questions. In the event that asking the security team is difficult in your organization, it can even be helpful to appoint individuals in each team to field questions.

Don’t forget to check in with the team

All of this advice only works if your team is responding to it. With each change or addition, make sure you’re incorporating a feedback loop. Check-in after 30 days to see if a new policy or tool is well received. Send out surveys, collect anecdotal feedback, or even tie KPIs directly into each change to see if productivity has been affected.

There’s never a single solution for every team, but hopefully these suggestions can get you moving toward a more holistic approach to security within your organization.