6 Tools and Methods to Secure DevOps Pipelines

Securing DevOps pipelines and the idea of DevSecOps in general has been one of the more popular topics in tech in recent years. However, with all the marketing speak and tools that do similar things, it can be difficult to separate substance from hype. This is particularly true if you're just getting started in the DevOps world.

To help you hit the ground running in your DevSecOps journey, here we will take a look at some of the most popular tools, methods, and practices used to secure DevOps pipelines. We have plenty of more tools in our DevOps courses, which will get you even more up-to-speed on DevSecOps.

Method #1: Shift Security "Left"

Traditionally, security has been a specific team's job. As a result, security was often an afterthought tacked on at the end of a development process. The practice of shifting security left means to make security part of the software development lifecycle (SDLC) from the beginning . As opposed to belonging to one specific team, security is everyone's responsibility.

The actual process of shifting security left involves doing a lot of other specific things. For example, adopting security as code, educating team members on security, and using many of the other tools and practices we'll discuss here.

Why security matters for DevSecOps: Integrating security from the start makes teams think, build, and deploy with security in mind. The result is usually more secure products and infrastructure.

Method #2: Trust Nothing, Question Everything

Zero Trust is an approach to security architecture where you trust nothing by default. A good way to understand Zero Trust is to contrast it with older "castle and moat" approaches to security. In those older designs, devices on a certain network or subnet were often implicitly trusted. That meant that access restrictions were usually lighter once you were on the "right" side of a firewall. Therefore, if a hacker got to the "right" side of a firewall, they could do a lot of damage fast.

Zero Trust takes a different approach. Nothing and no one should be trusted by default. Before accessing a network resource, trust must be explicitly established (via authentication, certificates, SSH keys, etc). Because Zero Trust is a model and not a specific technology, exactly how trust is established can vary. The important part is that you're never implicitly trusting any user, device, or service on a network. With this model, even if a hacker makes it onto the network or compromises an account, the amount of damage they can do should be limited compared to the castle and moat approach.

To implement a Zero Trust model, things like identity-based access policies (as opposed to simple network access control lists), multifactor authentication, IAM (identity and access management) tools, and proactive monitoring are used.

Why it matters for DevSecOps: ZTA means smaller overall attack surfaces for hackers to exploit.

Method #3: Develop a Red Team, Blue Team

You can think of red team/blue team testing as the infosec world's version of sparring. The red team's job is to act like the hackers that try to take down or compromise a network. The blue team's job is to defend against these attacks and keep the infrastructure safe.

The basic idea is simple: steel sharpens steel. Through red team versus blue team "sparring", organizations uncover security flaws and learn lessons they may have otherwise missed. This is because scanning and monitoring tools can't match all the tricks a real human hacker will try. However, a real human red team member can (or at least they can come close, there are often rules constraining what the red team can do).

Why it matters for DevSecOps: Red team vs blue team provides realistic testing of your security practices and drives improvement.

Method #4: Collect All the Data with a SIEM

Security information and event management (SIEM) tools collect data from various logs and analyze them to provide real-time information on security-related events. While the specific functionality SIEM tools offer will vary, the basic functions of a SIEM are:

• Centralized log/data collection for multiple devices

• Reporting and alerting when security incidents occur

The idea is that by centralizing and normalizing log data from all the different components of your infrastructure, you can better detect and analyze potentially malicious behavior. CBT Nuggets trainer Bob Salmans has a full rundown of how to select a SIEM and how they work in a recent blog post.

Examples of popular SIEM tools include:

• Splunk

• SolarWinds SIEM Security and Monitoring

• Rapid7

• Datadog

Why it matters for DevSecOps: You're able to get actionable security-related information from all your logs in real-time.

Method #5: Testing, Testing and More Testing

SAST (static application security testing), DAST (dynamic application security testing), and IAST (interactive application security testing) are three different — but related — ways of integrating security testing to a DevOps pipeline. Let's take a look at each separately and then tie it all together.

What is SAST?

SAST is a form of whitebox testing that checks for vulnerabilities in source code and compiled binaries. For example, sometimes SAST features are built into a developer's IDE (integrated development environment) and can flag security issues while code is still being written. Alternatively, a SAST tool can scan source code in a repository. For example, late last year several SAST tools were added to the GitHub marketplace.

SAST is useful for catching certain types of vulnerabilities (e.g. SQL injection flaws) early in the development cycle. This can make SAST tools an important part of "shifting left". However, since they're only scanning static code, they can't detect everything.

What is DAST?

DAST is a type of blackbox testing (i.e. it doesn't have access to the source code) that scans running applications for vulnerabilities. Other names for DAST tools include vulnerability scanners or web application vulnerability scanners. Many of the traditional security scanning tools you might think of (Nessus, Vega, Zed Attack Proxy, etc) fall into the DAST category.

DAST tools are useful for catching configuration issues and vulnerabilities that only show up during runtime. However, they can be a bit harder to set-up and scale than SAST tools.

What is IAST?

IAST tools are designed to run inside an application (e.g. using an agent) and combine the functionality of SAST and DAST into a single tool. IAST tools are often built with integration into CI/CD pipelines in mind.

Why it matters for DevSecOps: Integrating application security testing tools into a DevOps pipeline can help you catch vulnerabilities faster.

Method #6: Patches

Managing security patches for IT infrastructure can be a difficult juggling act. On the one hand, you want to make sure you apply all relevant security fixes. On the other hand, you want to make sure your infrastructure is stable, and an untested patch could create more problems than it solves. As your infrastructure scales, manually keeping up with all the patches, testing them, and deploying them can become a challenge.

There are many existing DevOps tools that can help streamline and automate the process of deploying and testing patches. For example, Ansible has modules for GNU updates, package managers like yum, and even Windows servers.

For cloud infrastructure, Microsoft's own Azure solution provides a real-world case study in patch management at scale.

Why it matters for DevSecOps: Unpatched infrastructure is low-hanging fruit for attackers. Effective patch management can help you strike a balance between stability and security.

Final Thoughts

These tools, methods, and practices can play an important part in securing your DevOps pipelines. However, it's important to remember to think about security holistically. A single tool or concept won't be the silver bullet that addresses all your security challenges. You'll need to effectively integrate the right tools to your pipeline, write good tests, and make security a shared responsibility across your team.