Jerry Garcia once said the Grateful Dead is like black licorice—you either love them or hate them. Well, I have finally been able to make a connection between the Dead and cybersecurity as it sure seems to me that “DevSecOps” is the Grateful Dead of cybersecurity—you either love it or hate it.
Steve Schmidt, AWS’s CISO and VP of Security, recently proclaimed his dislike for the term at AWS re:Inforce 2019 in Boston, stating that he is “no fan” of DevSecOps in his keynote followed by his take on why the practices of DevSecOps are so important. And therein lies the issue: We’re throwing the baby out with the bathwater by focusing on the term. Steve is dead on when he said that part of his issue with the term is that security is everyone’s responsibility. But it hasn’t been to date, and so we need a cultural shift around security akin to how DevOps broke down throw-it-over-the-wall organizational boundaries. That is, I fear throwing “DevSecOps” (the term) under the bus conflates the opportunity to treat security as an integral aspect of modern application development and delivery.
Part of the issue many have with DevSecOps is that some vendors have co-opted the term to be specific to their capabilities such as simply deploying an agent via script-based integrations with orchestration tools such as Chef, Puppet, AWS Code Deploy, etc. Others have connected DevSecOps with the notion of shifting left to automate code scanning. Both examples are legitimate DevSecOps use cases, but incomplete in and of themselves. With that context, I’ll try and limit my rant by offering three pillars to DevSecOps.
- DevSecOps means security is everyone’s responsibility. Treating security as a shared responsibility starts with agreeing on a risk-based approach to prioritize securing the most business-critical apps and data sets. Let’s not boil the ocean here, folks. Project teams should author user stories that get vetted by the scrum team to determine which will be implemented in the next sprint so everyone has a voice and a stake. Now if every security-related user story gets stuck in backlog then the team needs to take stock of their risk profile. Reviewing the status of these user stories at daily standups puts cybersecurity on the same drumbeat as architectural and functional related user stories so security is treated, minimally, as equal.
- DevSecOps must be repeatable to be scalable. One obstacle for automating security via continuous integration and continuous delivery (CI/CD) practices is not just the general shortage of cybersecurity skills, but a lack of specific cloud computing, scripting, and DevOps skills on the cybersecurity team, and a lack of cybersecurity skills on the DevOps team. As a result, cloud security architects often find themselves spread across too many project teams. A risk-based approach will provide focus and, along with an eye toward creating a library of re-usable practices and scripts that automate security (i.e., security-as-code), security can be repeatable in other projects, and thus scalable.
- DevSecOps must be continuous across stages. The call to “shift left” by integrating security into DevOps led to a limited scope of DevSecOps, one focused on just the development and build-time pre-deployment stages. For example, application security vendors rightfully cited shift left as a means to build more secure code. But DevSecOps can’t stop with static analysis and should be augmented with a shift right approach of automating the deployment of runtime controls, including those that perform dynamic analysis such as Runtime Application Self Protection (RASP). That is, the entire application lifecycle must be secured by integrated security at each stage of the dev-build-ship-run continuum.
While there are many DevSecOps use cases that result in security being truly integrated across the application lifecycle, these pillars represent a “first things first” approach to getting started. We shouldn’t need a term to make the case to integrate security at every step of CI/CD pipeline, but until we don’t, I’ll continue to like black licorice. What a long strange trip it’s been!
