DevSecOps’ Security Ownership Problem

Who’s responsible for security?

Milton Friedman once said “When everybody owns something, nobody owns it, and nobody has a direct interest in maintaining or improving its condition.” While that quote was about physical buildings 40 years ago, it’s still relevant to how we build software today. The technology required to shift security left exists but the organizational shifts are lagging behind. This presents an opportunity to create a new Product Security role with security accountability and ownership throughout the entire software development lifecycle.  

The debate over security accountability in DevSecOps generally comes down to two groups – developers and security teams. So who do they believe is responsible? GitLab asked that exact question in their 2020 Global DevSecOps Survey and the results highlighted the ownership problem:

1. Almost 33% of security respondents said they were responsible for security. 
2. 29% (of security) said everyone was responsible for security. 
3. 28% of developer respondents said that they are completely responsible for security in their organizations. 
4. 41% (of developers) said they were “responsible, but part of a bigger team.” 
5. 21% (of developers) said they do their part but “someone else” actually owns the security responsibility.

The survey results indicate that there’s security ownership confusion, but why is that necessarily a problem? Just like most things in security, it’s not a problem until something goes wrong. Builds fail in CI all the time, but when a build fails for security reasons, the resolution is usually more technically or organizationally complicated than simply sending the bug report back to the developer who pushed the code.

The ownership balancing act

If developers own the resolution, then technical difficulty comes from the fact that on top of writing scalable, performant code, the developer now has to be well versed in secure coding practices for every language they’re developing in, researching and implementing patches, and the security policies and regulatory frameworks with which the company must comply. The alternative is trying to figure out exactly why the build failed and project-managing the resolution with the corresponding security team. Suddenly you’re back to one of the core problems DevOps was created to solve, handoffs and silos. This is especially true if there’s a large, complex security team where vulnerabilities in the application layer are handled by one team and, at the infrastructure level, are handled by another. The only thing that makes this worse on developers is if they wind up chasing a red herring- according to GitLab “high false-positive rates are the top reason why developers struggle to tackle vulnerabilities while they build.”

If Security owns the resolution, then the technical challenges arise from a lack of context around the vulnerability and lack of access to the tools and environments required to implement and test the patch in CI. Security teams likely don’t know the functions and dependencies of the vulnerable components, nor do they know if the vulnerability exists in a file that will actually be used in production. On top of this, the average vulnerability analyst doesn’t have access to git repositories or the CI pipeline so they can identify a patch but can’t update the code or test it to ensure the vulnerability no longer exists. Organizationally, Security is outnumbered by developers anywhere from 10-100:1. At that ratio, it’s inevitable that Security will become a bottleneck without significant automation of existing processes, which they may lack the tools or knowledge to implement.

Where do we go from here?

With DevOps showing no signs of slowing down and new security issues cropping up every day, it may seem like the industry is at an impasse. We need to introduce a role that has the combination of engineering and security knowledge to understand a product down to the codebase, build security tests that are relevant without being overly restrictive, and manage relationships across security and engineering teams. This person also needs tools that span the full SDLC and cover the entire product stack from infrastructure to application in order to be effective. 

This is where the Product Security role comes into play. Product Security is integrated into the development of the product from the outset and has a two part mission to ensure the product is delivered effectively and securely at every stage of the product life cycle, from dev to production. The most important part of the Product Security role is ownership and accountability for security and a direct interest in continuously improving how risk is minimized throughout the life of a product.

This is an emerging role and there’s still some debate about where it fits within an organization. Given the depth of technical knowledge required and the fact that he or she must interact with engineers directly, some people feel this role needs to report up to the CTO. There’s another school of thought that dictates that Product Security is another security role and should report up to the CISO. Neither is inherently better or worse but the most important consideration is which reporting structure will introduce the least amount of friction to your continuous delivery processes. 

The key tools in the Product Security arsenal have to accomplish a number of goals: 

1. Integrate seamlessly into your CI/CD pipeline
2. Limit the amount of patching work and build failures to only what is absolutely necessary to reduce risk
3. Give package or file-level remediation instructions that developers will quickly understand
4. Understand the context of a vulnerability well enough to know if it will be exploitable in production
5. Cover the entire product from infrastructure to application in any deployment model

Rezilion meets all of these requirements and has been shown to speed up deployment velocity by up to 70% due to reduced patching work. It’s a key building block of a successful product security program and allows for total ownership of product security in CI/CD and production environments. Click here to learn more about the benefits of Rezilion for product security teams or any DevSecOps environment and schedule a demo.