Adding DevOps Security Tools to Your CI/CD Pipeline

As you travel down the DevOps path, one of the most avoided topics is often security or DevSecOps. Security is usually a touchy point because, more than likely, it will add work somewhere that someone didn’t want to do. But this doesn’t have to be the case. As we grow our systems, we’re adding more and more risk to potential threats. In this blog post, we’ll discuss the thought process you’ll need to have as you add security tools to your CICD pipelines.

A General Mental Framework

As you start to add security tools to your CICD pipelines, you want to ensure that you know what risks you’re trying to mitigate. Depending on the sector or line of business you’re in, there are vastly different risks you have to handle. This could include anything from sensitive customer data to critical business processes.

As your business grows, your toolset will need to grow as well. This is where you need to be on the lookout for where tools can be helpful. You’ll definitely have a “buy instead of build” mindset because you want to leverage things people have already paved the path for. Any tool should also add value, preferably quickly, to your environment. And any tool that immediately starts to drag on your processes should be reconsidered, if not outright replaced.

Let’s go through some of the broader areas you’ll probably be looking at for tools and what benefits they may bring to the table.

Container Scanning Tools

The first thing to probably start thinking about is what kind of tools or processes do you want to use to verify your container images are OK. These tools usually review everything that’s inside of the containers and can notify you of possible problems and remedies. What’s nice is that these tools can usually be inserted into almost any CICD pipeline. Also, depending on your desired outcomes, they can break the build before the container even goes into production.

Static Code Analysis Tools

Another good set of tools to have is tools that take a look at the code and figure out possible problems. These types of tools are usually called source code analysis tools, or Static Application Security Testing (SAST) tools. These tools look for known patterns of what may cause security holes and offer up solutions to resolve the issue. The downside to these tools is usually you would have to use a more popular language. The more people who use the language, the more experts there are on developing those patterns to watch out for. This also goes for frameworks. If you go off the beaten path, you may find yourself without many options.

Dependency Management

The next set of tools would be something that looks over your code dependencies. In an increasingly complex world, there are a lot of dependencies out there. Now, not keeping on top of your dependencies and known vulnerabilities is an OWASP Top 10 risk. This is why it’s important to, very early on, be able to manage, update, and keep in check what dependencies you have. There are a plethora of tools out there to help with this. And most platforms have many automated out-of-the-box solutions for you as well.

Security Policies

With all of these things, it’s also important to have policies on what to do when security issues are found, or even ways to report security problems. Having a security engineer, or even a group of security people, is almost necessary for every organization now. This group or person would help outline what happens if security problems arise. This includes determining what kind of communication needs to happen with stakeholders. They should also consider how quickly incidents need to be resolved.

Conclusion

Hopefully, this blog post has you thinking of what kind of tools and processes could be added to your workload to ensure that things are as secure as possible, as well as how to remedy issues as they come up. If this all sounds like this would be right up your alley, might I recommend taking the DevSecOps boot camp offered by Cprime?

Erik Lindblom