In one sense, it seems crazy to add additional terms to the DevOps portmanteau. A proper DevOps solution should include security, but we don’t have “BusDevOps” to highlight the business part of DevOps, so why does DevSecOps even exist?
On the other hand, the security industry has mobilized around the term “DevSecOps” much more than they did DevOps, and that is helping to accelerate the integration of security best practices into continuous integration and delivery. It is also giving the security team an identity in the continuous world we now live in, and that is a positive development.
DevSecOps is the integration of security practices, principles, tooling, and knowledge into the software development, testing, and delivery process. Traditionally, security assurance of applications, environments, and production systems has typically been performed late in the software delivery lifecycle. With the trend toward a more continuous delivery and deployment process, late-lifecycle activities like security assurance present a significant hurdle to continuously delivering value to customers. DevSecOps addresses this challenge by shifting security assurance activities, personnel, and automation closer to development.
There are several competing DevSecOps manifestos out there that attempt to define DevSecOps values. Here are five of the themes I particularly like.
Security controls like authentication, authorization, and encryption can help secure applications, but fundamentally, software security is about the inherent quality of the design and software we produce. To build secure applications, it is not enough to just add security controls. Threat modeling, defensive design, secure coding, and risk-based security testing are necessary.
Security has the reputation of being a hurdle instead of an enabler. DevSecOps strives to push security practices into the entire software lifecycle so security is assured as we go instead of at the end.
While it is important to identify and stop security vulnerabilities from getting into production, security at the speed of continuous delivery will only happen if root causes of vulnerabilities are evaluated, teams learn from the mistakes they have made, and the results are incorporated back into the software development process to avoid making the same mistakes again.
It is as difficult to get security requirements right up front as it is for any other set of requirements. Therefore, a better approach is for security teams to be involved day to day in all activities associated with planning, implementation, and testing so that as requirements and needs change, security needs tune and adjust as well.
It’s an age-old security debate: Is it better to share knowledge of vulnerabilities and threats or hide them? Sharing allows others to proactively correct issues but gives hackers additional information to exploit those that don’t keep pace. However, hiding information prolongs the exposure window for vulnerabilities. DevSecOps rightly believes it’s better to share, learn, and improve security constantly to keep ahead of the bad guys.
