Best practices and Tools to master DevSecOps.

DevSecOps stands for Development, Security, and Operations. In the most basic meaning, it’s defined as an approach that promotes security in the SDLC (Software Development Life Cycle).

The primary goal is shift-to-left the responsibility. Security tools are integrated early in the development cycle, usually in CI/CD pipelines, to let Devs find vulnerabilities as early as possible, and fix them before reaching production environments.

I’m gonna explain what is DevSecOps, and which are the best practices to add security in the pipelines. Finally, I’ll show you some of the best open-source tools that you can use to automate vulnerability finding and compliance checks.

DevOps add a lot of value to the company, increasing agility and flexibility, and it helps Devs to deploy faster, more often, and less risky.

Thanks to DevOps culture, DevSecOps Engineers can achieve the same level of agility and automation, integrating Security controls and tools, inside the CI/CD pipelines, helping the company to find vulnerabilities faster and earlier.

The benefits for the company are obvious, production systems will be more secure, and it also implies fewer expenses because it’s harder to fix production issues when they are found late. Usually, it involves a lot of work with multiple teams to fix them, and the Engineer’s time costs money to the company because they can use that time to develop new features instead of fixing vulns.

Some time ago, when DevOps Engineers used to be SysAdmins, and Security was a police department inside the company, Security used to be reactive instead of proactive. Vulnerabilities were found and fixed usually with scanners in the live servers, or with pentesting. Today we continue doing that, but most security issues don’t see production, thanks to automated controls in the entire SDLC.

Nowadays, Security is a shared responsibility to the entire organization, and the DevSecOps term is another fancy word, to emphasize the importance of Security in the Software Lifecycle.

Maybe you heard it, maybe not, let me explain what it means.

Shifting security controls to left means putting the security tools more left in the pipelines, and by consequence, in the development process. The more left it’s, the better because remediation is easier and it’s done before reaching production.

Let’s see an example:

If you’re using your favorite IDE (My own is VS Code), and before you commit the changes an automated scan alerts you about an SQL injection you’re introducing in the project, it’d be easy for you to fix it because you’re with that piece of code right now. As a Dev, I don’t remember anything after I go to the bed and close my eyes, so if a security tool alerts me about a vulnerability when I’m coding, it’s really easy for me to change the code to avoid it.

Automate as much as you can: Automation is the key to successfully leveraging security in the pipelines.

Define must-checks to deploy: If you have some must-pass security checks, define them in the CI/CD pipelines, especially for production.

Encourage and training: Whenever is possible, promote security training to your Devs. They’ll be more motivated and with the knowledge to fix vulnerabilities, and avoid them in the future.

The advantages are pretty clear, automation is the key like it’s in common DevOps practices, and we benefit from it adding the compliance checks in our pipelines. Some of those checks will be mandatory, so you’re gonna put your barriers of trust in the automation, ensuring that nothing will go through those controls unless it has the level of trust you’ve defined.

For a better and smooth experience, you need to teach your staff what are the common vulnerabilities, which controls we’re doing, and how to fix them. Usually, at first you’ll need to do a lot of support to developers, to teach them how to avoid and fix issues, but once they learn, you’ll gain more time for you and your team, to put the efforts to solve bigger goals for the company.

Let's deep dive into the best tooling for integrating with CI/CD processes, and tackle the different sides of Security across the entire ecosystem.

One of the best open-source tools to analyze IaC is Kics. It’s a tool designed to find security vulnerabilities, compliance issues, and infrastructure misconfigurations.

It supports multiple platforms, such as Terraform, Kubernetes, Docker, Helm. It comes with a lot of predefined checks to assess your infrastructure, containers, and deployments.

One of the key benefits of this tool is that’s designed to let you expand the analyzing capabilities, using the extensible query configuration you can create your checks, adapted to your staff and environment, and disable the ones that are less important to the company.

You didn’t write all the code of your applications, nobody does it in WebApps today. You use libraries, and probably a lot of them. Like any piece of code, it has its vulnerabilities, and you should check them.

Dependency checking is the process of finding what vulnerable versions of third-party you’re using. Most tools do that by comparing the version with popular vuln databases, such as NIST and CVE.

RetireJs: As the name suggests, it only works with javascript based projects. But it does a really good job finding vulnerable packages, and it’s well integrated with most javascript frameworks out there.

Dependency-Check: OWASP tool for dependency scanning. It works with Ruby, Java, JavaScript, and .NET. It uses NIST Vuln Database to find vulnerable software in your libraries.

These tools are designed to scan your code to find flaws in your project. It could help to find SQL Injection, Buffer Overflows, Memory Leaks, XSS (Cross-Site-Scripting), and more…

SAST is known as white-box scanning because it works by analyzing your source code and finding vulnerabilities based on your implementation.

The downside is that they aren’t perfect, they have a lot of false positives, and the worst: false negatives. Despite its shortcomings, it’s another layer of defense to add to our pipelines.

Bandit: SAST tool for Python.

BrakeMan: SAST tool for Ruby on Rails.

DawnScanner: Another SAST tool for Ruby, but in this case with support for the most MVC frameworks, like Rails, Padrino, and Sinatra. It provides more than 150 security checks, with remediation suggestions.

FindSecBugs: SAST tool for Java code. Include 100 security checks and support all major Java frameworks.

HoruSec: It supports multiple languages, and it has an extension for VSCode. Very interesting tool. You must give it a shot.

In comparison with SAST, as its name suggests, it dynamically analyzes your live application and performs different types of attacks against it, to find vulnerabilities. It’s also known as black-box scanning, since it doesn’t analyze your code, it analyzes the live web server.

The best way to integrate these kinds of tools in pipelines is after deployment in lower environments, like Dev or Stage. After the deployment step in the CD process, you should have another step to perform the scanning, and if the results are not good enough, revert the deployment and flag the artifact as vulnerable to prevent production deployments.

ZedAttackProxy (ZAP): It’s a well-known tool to do pentesting, but it also has a lot of automated scanning capabilities to test your app. It could be deployed using GithubActions too.

Arachni: DAST tool with high performance and multiple types of integrations, including a WebServer where you can check scanning results.

This short tutorial should help you get started with DevSecOps, and comprehend the concepts behind it. DevSecOps is not hard if you know how to begin, follow the best practices, and use the right tools.

Also Published Here