The Definition of Done for DevSecOps

STPCon Spring Session

DevOps cannot be achieved without considering many different aspects of software quality, including security. The term DevSecOps was developed to highlight that security was being focused on as part of the pipeline, not a second-class citizen.

Fortunately, DevOps and continuous delivery practices give us opportunities to add different types of security testing to our pipeline so that security can be part of our definition of done. Continuous integration can invoke static analysis tools to test for simple security errors and check if components with known vulnerabilities are being used. Automated deployments and virtualization make dynamic environments available for testing in a production-like setting. Regression test suites can be used to drive traffic through proxies for security analysis. From the code to the systems where the software is being deployed, the process can make sure that security best practices are followed, and insecure software is not being produced.

I’ll talk about how to construct a definition of done that focuses on security along with other types of quality in a DevOps pipeline. We will discuss how to define security practices and criteria that are appropriate for our teams and our projects to be confident that we are doing DevSecOps, and how those practices and criteria might mature over time.