The security community talks a lot about DevSecOps — look at any vendor's marketing materials. But very few are suggesting any significant changes to the way that security is practiced. DevOps is a fundamental shift in the way we think about building software and is intended to dramatically improve speed and quality. At its core, DevOps prescribes the following:
The exact problems that used to plague software are still major problems for security. Most organizations only do security on a subset of their code, such as the "critical" or "externally facing" applications and APIs, leaving the vulnerability backlog rampant across the portfolio and the attack visibility practically zero. The truth is, there are a few DevOps myths that are making the problem worse. Here are six:
Myth 1: "DevOps Is All About Automation." The automation is often the most visible part of DevOps, and it may be all that security folks perceive. The reality is that automation can also help to explain how your software factory actually works to the security team. Challenge security to experiment with applying the DevOps techniques to their own work and help them get started on their own DevOps journey.
Myth 2: "We Need to Shift Security Left." "Shift left" is a catchy phrase, but don't just push legacy security tools onto developers who don't have the background to use them. Instead, help developers find modern security tools that integrate into the DevOps pipeline, produce accurate and usable results, and aren't just DevOps lipstick on traditional security tools. Hopefully, your security team will come to realize that security can achieve the same kind of DevOps transformation and benefits as development.
Myth 3: "Increasing Velocity Reduces Security." Security doesn't actually have anything to do with velocity. But often the same automation and processes that lead to high-quality software can be leveraged by security to deliver assurance much faster and more reliably. DevOps actually establishes the infrastructure that security has been lacking for so long. By turning security into code, organizations can dramatically increase the speed, coverage, and accuracy of their security efforts.
Myth 4: "DevOps Makes Security Harder." Many security folks are already overwhelmed with the scale and complexity of their challenge, and they may view DevOps as making their job harder. They may unwittingly slow, derail, or undermine your DevOps transformation, so bring them along on the journey. Include the security team in your planning. Have them read "The Phoenix Project" and have regular interaction with development teams.
Myth 5: "Developers Don't Care about Security." This is one of the most pernicious myths in DevOps. After teaching application security to thousands of developers, my impression is that developers are smart, interested, and curious about security. They want to learn to do things right and avoid security vulnerabilities. Consider that in many organizations, security is poorly defined, a moving target, and full of landmines that can derail projects or careers. Consider becoming part of a development team for a time and working to make security explicit and fully automated so that anytime applications are "clean" they can go into production at whatever velocity the project wants.
DevOps has been widely adopted and has achieved impressive results across a wide array of organizations. It's time to move past trivial "shift left" conceptions of DevSecOps and take a hard look at how security work actually gets accomplished. You'll find massive bottlenecks, wasted effort, duplicated work, feedback loops of weeks, months, or years, and many other problems. Let's call an end to security exceptionalism — there's nothing that special here. The vast majority of security is working on well-understood problems such as injection, path traversal, cross-site scripting, etc. Let's unleash the power of DevOps and radically improve security.