With the increased interest in DevSecOps, the Cloud Security Alliance (CSA) and Software Assurance Forum for Excellence in Code (SAFECode) brought together a DevSecOps Working Group to identify and share best practices for the development and maintenance of a DevSecOps program. This working group identified and defined six focus areas critical to integrating DevSecOps into an organization; this article will focus on pillar one—collective responsibility
The Context of Security
When we look at security historically, we find that it has often been relegated as a secondary objective when compared to other primary objectives like releasing features to market quickly. The rationale is that if we don’t release fast, our competitors will get ahead of us. Unfortunately, that mindset is fraught with security risk as evidenced by the rising number of vulnerabilities in our software. Malicious actors can take advantage of these vulnerabilities to breach critical systems and exfiltrate sensitive data.
Let’s not be too hard on ourselves, however. Security in a DevOps world is not an easy problem to solve. As we continue patching vulnerable code, new flaws emerge just as quickly. In essence, the security landscape is dynamic and continues to evolve. Solving a complex problem like this requires diversity of thought. In other words, we need to include people with different perspectives in the security conversation. Essentially, we need to build a collective mindset rooted in security culture. Security then becomes a collective responsibility rather than the responsibility of a few people.
Now that we’ve agreed on the importance of collective responsibility, the logical question that emerges is, “How do I operationalize collective responsibility?” Pillar one addresses this question. We need to bring together our security and DevOps cultures. No longer can we talk about security or DevOps. It has to be both. This means security must be considered and addressed at every point in the software development and operations life cycles. Extending this further beyond the technical domain, security is fundamentally tied to business objectives, not left as an afterthought or considered a mere cost drain.
Building a security-supportive culture involves three broad phases:
- Phase One: Gain executive support and engagement
- Phase Two: Design an effective program
- Phase Three: Sustain the program
What Does Pillar One Mean for DevSecOps Practices?
Pillar one reinforces the idea that security responsibility cannot be limited to a few people. Just as software development is no longer an exclusively technical activity, security is no longer a compliance activity. This has a profound impact on DevSecOps practices. Here are just a few areas that are impacted by this shift in mindset and responsibility:
- People across software development and operations activities must now consider security requirements
- Security tools can no longer run separately from DevOps pipelines
- DevOps teams need to understand security and how it applies to their roles
- Security teams need to translate high-level policies into clear, atomic security requirements that can be implemented and tested
How is Pillar One implemented?
Implementation of pillar one touches on structural issues aimed at removing silos. There are many possible ways to build cross-functional teams. One approach is to have security embedded inside DevOps teams. Another approach is to integrate security as a support structure for DevOps teams. In either case, given the limited number of security professionals, a security champion can help bridge the gap between DevOps teams and security teams. A security champion ensures that the software being built and deployed takes security into account. To achieve this, it is important to set up a security champion for success:
- Security must be their primary responsibility
- They must be viewed as the security expert in engineering teams
- They are responsible for mentoring and training developers
- They can own threat and privacy models
- They must have clear goals that are aligned with the business
Setting up a security champions program without a clear sense of direction can lead to a lot of wasted time and effort. Collective responsibility rests on teams being able to communicate across functional silos and a security champion is an exemplar of that mindset.
Speed Versus Security
We live in a world where the rate of software development and deployment outpaces traditional security practices. This has come at a cost. Balancing both speed and security is the new norm. The right balance is dependent on each organization. One thing remains the same, however, and that is culture. We need a culture that is supportive of security and views it as a collective responsibility. This takes intentionality. Organizations need to get their executives involved and make sure the program has relevant elements to drive a security culture and has a clear path to business value.