4 Keys to Bridging the Gap Between Security and Developers

Security and development sometimes don't have the best of relationships. It's no one's fault; it's just the nature of what they do. Security's top concern is protecting the organization from the risks of application security issues. Developers are trying to hit tight timelines and deliver features as fast as possible to address customer needs. Unfortunately, because both developers and security teams often operate in silos, those priorities are sometimes in competition with each other, creating friction between the two teams.

This friction can create a culture of fear among developers, who have become accustomed to security teams scolding them for mistakes. That doesn't make developers any better at their jobs or help them avoid security risks when they build. We need to move away from a culture of fear to one of shared responsibility where you can quickly react to security issues and fix them. As Cisco's Wendy Nather puts it, "Security should be designed to be adopted rather than just engineered to be enforced."

Instead of measuring how many gaps or errors developers have left in the application architecture, measure how quickly those issues were found and fixed. Everyone wants the application to be secure; we just need to integrate the security and development processes into one seamless workflow.

That starts with how security teams work with developers. Among teams that have broken down the silos and eliminated friction, security guidance tends to have four attributes that streamline workflows and align security and developers.

Security That's Accessible
There are few things more frustrating for a developer than receiving a 25-page Word document from a security colleague listing all the security considerations for the particular application they're working on. These documents are often difficult to understand and slow workflows to a halt because they're written in a language that makes sense to security, not developers.

If security teams recommend that developers "protect authenticators from unauthorized disclosure or modification," for example, most developers will have no idea what that means. Even though that's an important security consideration, it'll never be implemented if developers don't know what security is talking about. If security can deliver guidance that's more accessible for developers, written in language they understand, developers are much more likely to address them.

Security That's Actionable
Clear and easy-to-understand security guidance is just the start. Security can make developers' lives a lot easier and get their recommendations implemented a lot faster if they go beyond just explaining what needs to be fixed and tell developers how to fix it. Few developers are well-versed in security, and even if security recommendations are accessible, developers will likely have to do more work to figure out how to fix what's broken.

To help them get there, just cut to the chase. Developers don't need all the gory details of why there is a problem, and forcing them to do research on how to fix it won't win you any friends. All developers want to know is what you want them to do. Get them to the green check box as fast as possible by providing actionable guidance.

Security That's Automated
You've explained what needs to be fixed in accessible language, and you've told developers how to fix it with actionable guidance, but can you go a step further and solve the problem for them automatically?

Part of the friction between security and development stems from the abundance of automation and speed among developers, and the lack of it for security. Instead of Word docs, how could security use automation to move at the speed of development? This part of the process requires time and effort up front. Automation should be baked into the security process to scan for potential security issues both pre- and post-deployment.

When security adopts the same kinds of automation as development teams, they can fit into their workflows more seamlessly.

Security at the Right Time
Security should be engaged early in the process and fit into the existing development life cycle and workflows. Developers shouldn't have to wait until the next sprint or next month to get security guidance.

If you engage at the right time, developers can fix security issues and design gaps while the application is being designed, not after they've already implemented it.

This "shift left" reduces risks and streamlines workflows for both developers and security teams.

Stop the Culture of Fear
Making these changes requires a cultural shift. We need to move away from the siloed culture of fear and toward integrated, modernized, automated workflows where security and development take a shared responsibility.

It requires measuring successes — like how quickly issues are resolved — instead of shortcomings. This kind of cultural transformation positions security as a trusted adviser to developers and creates the kind of awareness and collaboration that ensures every application is secure by design.