Today GitGuardian is happy to present its latest white paper: DevSecOps: Protecting the Modern Software Factory.

In this document, we go beyond traditional definitions of DevSecOps to present our vision of an emerging partnership between Developers, AppSec, and Ops teams: the AppSec Shared Responsibility Model.

To understand where this idea comes from, you should remember that one key finding of our 2022 State of Secrets Sprawl report is that most organizations have a 1:100 ratio of AppSec to software engineers. Therefore, as demonstrated in the report, a single AppSec engineer had to handle more than 3.4K secrets occurrences in 2021! And this is only considering one type of vulnerability…

This fact has large consequences for companies wanting to release secure applications at the DevOps velocity. It means that to embed security controls into their DevOps culture, processes, and tools, they need to reduce friction and break the security silo. This is why application security needs to evolve towards a new shared responsibility model.

Table of Content
Table of Content

Shared responsibility essentially means that security should be owned by various teams acting in collaboration to implement its various layers all along the SDLC.

Developers are provided with access to the right tools to set up their guardrails and remediate the security issues they’re the most familiar with, in context.

Security engineers are responsible for defining and implementing security policies as well as their controls. Sharing responsibility means they can dedicate more time investigating complex or low-assurance findings.

Ops can be tasked with ad-hoc responsibilities to make sure security CI/CD controls are correctly configured, or even to take ownership for certain types of vulnerabilities.

We are convinced that defining this new shared responsibility model is key to the success of DevSecOps initiatives. As a company deploying an enterprise-grade security platform, our experience has demonstrated that this is the only way to effectively scale the secure software development lifecycle as the development teams grow, compliance criteria change, and new threat signatures emerge.

The white paper also details what one should look for when considering a DevOps-ready security solution. Some key aspects can dramatically impact your DevSecOps adoption, such as enabling security automation across the SDLC and making teams work much more closely together. Propagation of security best practices across the organization is also a powerful side-effect that should be taken into account.

Multiple teams are bound to collaborate to produce software. The quick-release of secure applications is unlocked when teams start to collaborate on security. This can be hard to ignite but has proven to bring many benefits: less friction enhances communication and visibility, which leads to better automation processes and improved security overall. When it becomes a shared responsibility, security can finally benefit from the continuous improvement loops that made DevOps ubiquitous in the first place.