DevOps took the software scene by storm in 2008, with the promise to reduce the time between changing a software system and that change being rolled out in a production environment – without compromising on quality. Basically, it was supposed to “turn the IT business model on its head with shorter cycle times, automation, and deep cross-functional integration to deliver the next great idea,” wrote cloud expert James D. Brown in 2013.
And this is exactly what it did. Yet from the get-go, DevOps was viewed by security teams as a risk. The increased velocity of software releases – the raison d’etre of DevOps – was perceived as a threat to security, governance and regulatory controls. And the security teams had a point. Because no matter what the development paradigm, if anything goes wrong, it’s security managers that gets blamed for not having adequate controls and processes in place.
On the flip side, DevOps saw security as a drag on time-to-market. And they were right, too. Rapid development cycles strain traditional security processes and controls, which really can’t keep up with the pace of change.
To overcome these challenges, organizations realized that the solution was to give security personnel a seat at the DevOps table. This means not only making standard security processes part of the software development lifecycle, but also instilling basic security principles and sensibilities in the collective consciousness of development teams – from product designers to release managers, customer service reps, and everyone in between.
And thus, DevSecOps was born.
According to the DevSecOps manifesto, DevSecOps should be dedicated to “…developing security as code” and should “…strive to create awesome products and services, provide insights directly to developers, and generally favor iteration over trying to always come up with the best answer before a deployment.”
The Benefits of DevSecOps
The DevSecOps paradigm helps identify security issues early in the development process – instead of after a product is released. This can reduce costs associated with fixing security flaws by building security into every stage of development – from the requirement stage onwards.
What does DevSecOps offer organizations, specifically?
- Better visibility
The DevSecOps paradigm offers full visibility into application activity. This enables earlier detection of threats and vulnerabilities – often at pre-production stages – and more effective information sharing across teams. From an organizational culture perspective, DevSecOps fosters a culture of transparency and openness from the earliest stages of development through to production. With DevSecOps, everyone is responsible for security – and everyone can see the results of each team member’s positive contribution.
After deployment, DevSecOps remains relevant and vigilant, and visibility continues. Well-engineered DevSecOps processes have a closed feedback loop from production, to handle security issues. Production dynamic application security testing (DAST) can help identify configuration drift from pre-production, while runtime application self-protection (RASP) can catch vulnerabilities that may have slipped by pre-production checks. Also, DevSecOps processes tightly control the production environment’s bill of materials, to watch for zero-day vulnerabilities in open-source software, and make it easier for incident-response teams to react faster to new threats.
- Shift left
“Shift Left” refers to the refocusing of efforts towards finding security vulnerabilities during the earlier phases of the development cycle – instead of after rollout. By addressing these flaws during the planning, design and coding phases, organizations are able to more effectively manage risk and create better threat models that can be applied to production versions. Moreover, by better educating and guiding developers on security coding practices, while helping them test for security during the coding, DevSecOps enables true continuous security throughout every stage of development.
Shifting left empowers software development teams to detect operational breaches throughout the software supply chain, from design to deployment. This fosters a collaborative spirit between development and IT security teams, and helps mitigate the natural skepticism that exists between developers and security professionals, not to mention their notably divergent attitudes towards security vulnerabilities. Since DevSecOps empowers developers to be able to test their own code, it creates an atmosphere of understanding which inspires collaborative effort.
- More speed, less risk
With DevSecOps, organizations can achieve speed without risking stability and governance. With tight controls baked in all the way through to production, DevSecOps creates an effective security layer for applications – that translates into a solid foundation for ensuring security and compliance in the long run. The paradigm also facilitates cost reductions by enabling detection and remediation of security issues during development – which also, of course, increases the speed of delivery. If there is a security incident, DevSecOps enables faster speed of recovery.
That said, sometime DevSecOps offerings are just DevOps with a veneer of traditional security – which relies on the tenet that better security comes from robust human gating. It’s important to realize that a true DevSecOps model can safely deploy orders of magnitude faster than human gating, and adopt tools that work well with rapid-cycle CI/CD pipelines.
The Bottom Line
DevSecOps is changing the way companies look at both development and security, and offers numerous advantages over existing paradigms. With DevSecOps, organizations no longer rely solely on reports and scanners to improve code. Rather, the paradigm encourages proactive searching for vulnerabilities, loopholes, weaknesses – and correspondingly empowers developers to remediate more seamlessly, with less risk.
Organizations should not take a reactive stance of expecting or fearing that they will fall victim to attackers. As the DevSecOps manifesto states, they no longer need to “…settle for finding what is already known; instead…[they can]…look for anomalies yet to be detected.”
So is ‘traditional’ DevOps dead? No, but like systems and methodologies everywhere – it has significantly evolved.
