I’ve never really been sure how DevSecOps differs from plain-old DevOps, but over the past year I think I finally studied the topic enough to have a definition.
DevOps is the combination of cultural philosophies, practices, and tools that increase an organization’s ability to deliver applications and services at a high velocity. It allows to evolve and improve products at a faster pace than the use of traditional software development and infrastructure management processes. This is exactly the speed that enables organizations to better serve their customers and compete more effectively on the market.
DevSecOps stands for development, security, and operations. It’s an approach to culture, automation, and platform design that integrates security as a shared responsibility throughout the entire IT lifecycle.
The main difference between DevOps and DevSecOps is security automation, but the nuances and benefits are just as important. To be concise, the DevOps mindset improves software delivery by moving operations concerns closer to development with the help of a lot of automation and process change. What I think makes DevSecOps different, and at the same time, additive to DevOps are the three reasons below:
- A secure software supply chain
This is a fancy way of saying “we know all the components that went into building and deploying this software and we rely on those components.” It also includes the actual trusted CI/CD pipeline, that is resistant to third parties, including malicious code, as we have seen happening during the recent years.
- Improved culture and collaboration
DevSecOps increases the collaboration and understanding between developers and security staff. As with many governance practices, because of security, the developers and the security staff usually have an antagonistic relationship. Developers see the security staff as unstoppable masters of “no”, while security people see developers as mindless coders. Well, this relationship doesn’t help, but the good news is that DevSecOps assists in transforming this culture, as DevOps does.
- Automation and guardrails
Automation of the security policy enforcement, and provision of defaults and templates are also important DevSecOps tasks. They aim to make the writing of secure code and applications’ configuration as easy as possible for developers, from the start. Historically, verifying that developers are writing secure code has been a manual, error-prone process, but much of this can be now automated with the use of good platforms.
DevSecOps integrates a secure software supply chain into DevOps
During the recent years, the idea of a “secure software supply chain” became a fundamental part of DevSecOps. A secure software supply chain starts with a “supply chain,” which is, mostly, just another name for a “build pipeline.” A pipeline is filled with the activities that go into compiling, integrating, testing, and eventually releasing software. Let’s look at the three parts a secure software supply chain includes.
- Governing inputs and dependencies
First, you should think of a “software supply chain” as all the inputs that go into building and deploying an application. These inputs start with the code your developers write, the configuration used throughout the application lifecycle, third-party frameworks, libraries, and other services your application relies on (e.g., to send text messages), as well as any other ingredients that go into making that application. Developers depend on open source and third-party services more than ever, meaning that your supply chain also needs to verify and trust that third-party code.
Dependencies on third-party code bring in quickly the transitive dependency problem. For example, let’s say you’re using a PDF-generation library that needs a font-rendering library depending on a logging framework. If that logging framework has a security problem, you’re also having that security problem regardless of how secure, verified, and trusted the PDF-generation and font-rendering libraries are. This is exactly what happened recently with the Log4j security problem.
One of the major innovations in the DevOps-mindset is treating the configuration needed to deploy and run the application’s code as well. Since there are different groups involved in developing, testing, deploying, and even managing applications in production, it is easy to lose track of this configuration throughout the application lifecycle. This is the less cool part in the DevSecOps mindset: that configuration is a major input to be tracked and secured.
- Building
The second part of a software supply chain is the build process used to compile and verify your applications, known as continuous integration. This is a decades-old, well-established practice and set of tools. In the DevSecOps mindset, this build phase might enforce policies and swap out different components for the software. For example, when a security issue comes out, an advanced secure software supply chain can rebuild your applications with patches for operating systems and frameworks, without the need to trouble developers. This is exactly what Netflix and others (Amazon, etc) have been doing, which enables them to not only patch production quickly, but to rebuild production entirely several times a week to blow out any malware.
- Secure delivery
Third, a software supply chain usually consists of another part: continuous delivery. This means automating the releasing of the application builds to production.
The main part of a secure supply chain is ensuring that the inputs – code, configuration, and third-party frameworks and services – are protected and follow your guarded policy. This largely means tracking and verifying that those inputs are what you think they are, and that random people haven’t inserted malware into your applications.
Obviously, a secure software supply chain seeks to prevent these and other security problems.
Did you find this article useful? Stay tuned, because the other two reasons that state the differences between DevOps and DevSecOps are going to be developed in the next articles.