Devops came about because of the cultural, functional, and technical walls between development teams that want to release frequently and operations teams that need to preserve reliability and stability. Devops culture addresses the mindset, collaboration, and practices to achieve both objectives, and devops practices—including continuous integration and delivery (CI/CD), infrastructure as code (IaC), and AIOps, which leverages machine learning in application monitoring, enable the implementation.
As more people and organizations adopted devops, it became clear that the term “devops” fell short of describing the full breadth of the movement, its practices, and requirements. I once called out the need for DevQaOps, and I have recommended shift-left testing practices where feasible.
But equally important, if not more important, is the need to make everyone responsible for security. Shifting security into development and operations, or DevSecOps, helps you achieve this.
Software security starts with developers
Before devops, development teams often implemented security practices in the final stages of an application release process, usually as a required step by a change advisory board (CAB). Because security teams were brought in late in the process, they had limited time to learn business requirements, understand technical changes, evaluate risks, and run security tests. When security teams escalated issues, there was limited time to remediate the problems without impacting timelines, and issues that required substantive code changes left development teams with hard choices.