The solution for DevOps' security woes? DevSecOps! In its simplest overall description, DevSecOps helps you to embed security within DevOps practices. The purpose is to safely distribute security decisions, without sacrificing the safety required.
The adoption of DevOps throughout the world made all kinds of things possible: Cooperation blossomed, and teams felt more empowered, having more control over production environments. The increased use of (open source) third-party libraries and frameworks meant faster development of applications. The deployment frequency went up, as the lead time for changes decreased tremendously.
In other words, a faster development pipeline throughput.
Unfortunately, it wasn't all good news. The switch of control over production environments from the operational department to development teams meant that specific (security) knowledge got lost. The advent of more third-party software meant an increase in software supply chain risks. And lastly, the increased velocity also meant that software was being tested less rigorously.
Fortunately, the technological sector always tries fixing the problems it created itself. The solution for DevOps' security woes? DevSecOps!
In its simplest overall description, DevSecOps helps you to embed security within DevOps practices. The purpose is to safely distribute security decisions, without sacrificing the safety required. In other words, it gives you more security visibility - as well as more security control.
Analogous to the DevOps manifesto, there is a DevSecOps manifesto. It values data and security science for instance over Fear, Uncertainty and Doubt. It values open contribution and collaboration over security-only requirements. And it values business driven security scores over rubber stamp security.
Interestingly enough, it also values red and blue team exploit testing over relying on scans and theoretical vulnerabilities. Why interesting? Well, because in practice, the most widely used application of DevSecOps is actually automated security testing.
With automated security testing we mean the use of tools in continuous integration pipelines, that automatically test for security defects with each code push. Developers get almost instantaneous feedback on the negative - or positive - impact of their changes with regards to security.
With each integration, several tools will test for all kinds of vulnerabilities; For instance whether the code contains hard-coded secrets, or whether appropriate hardening has been applied. Furthermore some tools are able to create security metrics, and increase the visibility of security within the pipeline.
By using automated security testing, issues are therefore found earlier in the software development life cycle. This ultimately reduces the cost associated with fixing them.
Automated security testing also delivers continuous security. It doesn't become a one-time exercise like for instance penetration testing, but it becomes an integral part of the software development life cycle.
Another advantage is that security requirements can be treated as code. Test configurations and expected results can become part of the process, and not be seen as an after-thought.
In no particular order, this is a list of open-source tools that are often used in pipelines, for automated security testing.
- detect-secrets: There are numerous tools out there that can assist you in finding secrets within a code base. Over the years, this tool has proved itself one of the best out there. It's low on false positives and false negatives, and has a clever system which enables teams to gradually remove known secrets, instead of having to do all cleaning at once. If there's one tool you should use from this list, it's this one.
- Nikto: A web server scanning tool, which lends itself perfectly for automation in pipelines. Highly recommended for finding low-hanging fruit vulnerabilities in web applications.
- Zed Attack Proxy, or ZAP (formerly known as OWASP ZAP): Another web application scanner, which really shines in headless environments. Can be used as a dynamic application security testing tool.
- Dependency-Track: Although technically not a tool, and more somewhat of a platform, a centralized Software Bill Of Materials (SBOM) tool is nowadays indispensable. It works with several SBOM formats, and can automatically generate alerts based on new published vulnerabilities.
- Prettier: A language-dependent formatter - and yes, a code formatter can improve overall security. Code is often written just once, but read many times over. Readable, legible code is proven to be more secure than "spaghetti code". Use an (opinionated) code formatter to ensure some form of consistency, like for example Prettier. The tool itself doesn't matter that much, but consistency does.
Personally, I think that the biggest advantage of moving from DevOps to DevSecOps is the renewed awareness for security. Literally squeezing (the word) security into DevOps makes it clear that security should be taken into consideration throughout the whole process.
DevSecOps is the natural evolution of DevOps. It improves the security of applications, by injecting more security into pipelines - as well as enhance the overall security awareness of development teams.
There is so much more to say about DevSecOps. In case this piqued your interest, you might be interested in the following courses:
