MileciaCybersecurity is a big concern for many companies. With data breaches happening more and more as attacks increase in sophistication, teams are looking at all of the options they have to prevent them. Since DevOps has taken root as the standard way to deploy applications to production, it's worth figuring out how to include security in your CI/CD pipelines.
Background on DevSecOps
There's already a field dedicated to adding security to your existing DevOps flow called DevSecOps. Instead of waiting until the end of the process to run security checks, like in the Waterfall method, you include them throughout the different run stages. In DevSecOps, this is referred to as "shifting to the left".
It's called this because you move things that are traditionally at the end of the deployment cycle to happen earlier in the process. You're able to use multiple automated tools to run checks for cross-site scripting, SQL injection, and to check for any other of the OWASP Top 10 security risks.
You still need security experts to interpret the results and ensure there are not many false positives, but adding security in your CI/CD pipeline helps automate a lot of processes that were manual before. This saves time on getting deployments out to customers because you don't have to wait until the end to learn about security risks. That means the code won't need to be updated at the last minute, which always causes delays.
A number of tools are available to help you do security checks at every phase of your CI/CD run. A basic CI/CD pipeline will include a build phase, testing phase, delivery phase, and finally a deploy phase. The goal with DevSecOps is to shift security to the left or to move the checks to earlier parts of the process.
We'll go over a 15 of the top DevSecOps tools and which phases they help find vulnerabilities at.
Tools
Build
This is usually where your code gets compiled and your dependencies get installed. You'll want to run security checks in this phase because it can catch any static page vulnerabilities before the deploy artifact gets created. Doing these kind of checks at this phase can help developers learn what changes need to be made before the pipeline really starts running.
Arachni
OWASP Zed
Burp
SQLMap
Gauntlt
Test
This is where your unit tests will run and catch any other risks in the application code. Things like package vulnerabilities and system patches might be found here.
OWASP Dependency Check
Retire.js
Sonatype Nexus
Veracode
Delivery
In this phase, you're deploying to pre-production environments. You might need to do a few manual checks here to make sure things are in compliance with any regulations your applications fall under, like HIPAA. This is also a good phase to start running integration tests to make sure that your application and services are working together like you expect.
DevOps Audit Defense Toolkit
Chef InSpec
Deploy
Now that your application is being deployed to production, the only tests left are going to happen on production. Those tests are usually conducted by a team of pen-testers and the automated tools aren't typically run here.
HackerOne
BugCrowd
Signal Sciences
ThreatStack
Other thoughts
There are a number of things that make it harder for teams to include security checks in their pipeline processes. Most pipeline tools use YAML config files, like CircleCI or TravisCI, which teams don't work with often and they aren't easily testable files. Another thing is that when a complex pipeline is running, it can be hard to track any issues through the DAG visualizations.
When you can write your pipeline as code that can have its own unit tests, you can get through audits and other compliance checks with more confidence that your deploys are going as expected. One option is Conducto which lets you write your pipelines in Python and it follows a tree system instead of a DAG so your run steps are shown like files in a folder.
These are some of the most commonly used security tools in DevSecOps, but there are dozens more out there to fit particular languages, like Ruby, or to run more targeted tests. The main thing you need to do to get things going is set up a threat model. This will help guide the tools you need because you'll know exactly what vulnerabilities you're checking for.
Make sure you follow me on Twitter because I post about stuff like this and other tech topics all the time!
If you’re wondering which tool you should check out first, try Conducto for your CI/CD pipeline. It’s pretty easy to get up and running and it’s even easier to debug while it’s running live.
