For years, DevSecOps was supposed to usher in a world in which applications would be secure by design.

Earlier development approaches such as Waterfall, Agile, DevOps, and Shift-left tacked on security relatively late – almost as an afterthought. Dev teams focused on churning out code as quickly as possible – any vulnerabilities would get caught later, even if that meant after the software was released.

But DevSecOps pointed toward a different way forward. No longer would a particular team “own” security. Now, all the relevant stakeholders in the organization would take collective responsibility, introducing security much earlier into the life cycle of the application development process. No more separate silos where the development team would oversee creating an application, an infrastructure team would be in charge of operating it, and a maintenance team would be in charge of reliability.

Henceforward, developers, security teams, and operations teams would all approach their jobs by elevating security as a priority. This was the ballyhooed “shift-left” where you build security into active development instead of addressing the issue only after the code work is complete. The result: both a reduction in costs and more secure apps.

And everyone lived happily ever after.

Well, not quite.

While DevSecOps has gained increasing traction, many organizations haven’t yet figured out how to make this work. In a recent survey of IT and security professions polled by the Cloud Security Alliance, only 30% of respondents described the working relationship between the application development teams and the cybersecurity teams as good. That wasn’t all. Consider the following:

• 38% of respondents estimated that 21% to 40% of their code contained vulnerabilities. That wasn’t the worst of it:
• Another 19% estimated that 41% to 60% of their code contained vulnerabilities.
• An additional 13% estimated there were vulnerabilities contained in 61% to 80% of their code.

Numbers like that are nothing to brag about. So why is the promising future of DevSecOps still just that – a promising future?

It’s not for lack of trying. CISOs have chipped away at the long-running rifts between the Dev and Security teams. And after years of trying, there is some evidence of growing acceptance around shared security responsibility.

Unfortunately, too many development stakeholders continue to view security as an impediment to speed-to-market to the point where they’re willing to sacrifice cybersecurity for speed. Many developers view code creation as their primary responsibility. Current incentives reinforce that belief as they are rewarded for how quickly they code.

All too often vulnerabilities get discovered by the security team after code is merged into a test environment.

The obvious question is why? Security ought to be the responsibility of everyone in an organization – particularly in an era defined by rolling releases and agile development practices. New features and code now get added at a furious clip. So, if one part of the organization still believes that security’s the other guy’s job, that’s hardly an encouraging harbinger.

Shedding Old Mindsets

CISO’s can’t solve this by themselves. The only way to get the Dev and Security teams onto the same page is by getting the C-Suite involved in knocking down organizational silos, communicating the strategic importance of DevSecOps to all stakeholders, and essentially changing the culture

Ending the friction between cross-functional teams and getting them to function as one team won’t happen overnight. Dev and Security teams work in different silos where they are tasked with goals that often put them at loggerheads. This is stuff that ought to be second nature for C-Suite veterans.

• While you may not be able to force them to be friends overnight, work on mitigating the tension and preach the value of common goals and practices.
• Establish the strategic importance of DevSecOps. Articulate the urgency behind formalizing a process that guarantees more secure products by removing most known vulnerabilities at the source. Promote the idea that it’s incumbent on all hands to embed security into software development workflows.
• Bridging the knowledge gap will take time. Hold regular brown bag presentations for the rank and file to make sure that all parts of the organization have – at a minimum – an adequate working knowledge of DevSecOps practices.
• Peg the compensation of development teams to their willingness to prioritize vulnerability remediation as part of their jobs. Offer incentives that reward them for the security of their code.
• Rinse. Repeat. Until DevSecOps is second nature and organizations are no longer their own worst enemies when it comes to generating secure and timely applications.

Otherwise, we’ll be talking about the same thing a year from now.