Security Essentials Every CI Pipeline Must Have!

There’s a ton of security tools that are available in the industry today. Many offer simple and effective targeted solutions, while others offer more generic, yet complex configurations to solve problems. At times, it’s hard to know what to pick.

A good continuous integration (hereafter referred to as CI) pipeline needs some core security essentials covered. What are the essential tool types?

• Static Application Security Testing (SAST)
• Software Composition Analysis (SCA)
• Automated dependency management
• Secret scanning

Have no fear, Liatrio is here! Our DevSecOps engineers have worked on compiling a list of those very core CI security essentials that are easily integrated into your GitHub workflows; shifting security left and helping improve your security posture!

Disclaimer: None of these tools are sponsored. We just like and use them!

SAST and SCA Tooling, a CI Security Must!

First let’s define what SAST & SCA are and why they’re essential to improving your CI pipeline.​​

Static Application Security Testing (SAST) involves examining the source code of an application without actually executing it. This static analysis identifies possible security issues like injection flaws, cross-site scripting (XSS), and insecure data handling within your code. Doing this upfront helps developers spot and remediate vulnerabilities prior to getting their code into production and significantly reduces the risk of security breaches in the final product.

Software Composition Analysis (SCA) focuses on analyzing the components and dependencies of a software application, such as open-source libraries, third-party packages, and proprietary code. It identifies known vulnerabilities, license compliance issues, and outdated dependencies within the software's components. Leveraging SCA scans early in the SDLC helps developers effectively manage their application components preventing vulnerable dependencies from creating security threats and incidents.

Snyk, a Developers Integrated Security Tool of Choice!

Snyk is our go-to choice for SAST & SCA scanning, particularly when it comes to the developer experience. Check out our recap of migrating from Veracode to Snyk in a Dojo to improve security!

Snyk does an exceptional job at identifying vulnerabilities in your source code and provides easy to read recommendations for remediation. It automatically monitors/scans repositories daily for both SCA / SAST and can provide pull requests for SCA fixes. The scan can be done in the pipeline via a GitHub action, locally via the command line, locally prior to commit via a pre-commit hook, or our favorite, directly in your integrated development environment (IDE). Having Snyk actively monitor your code directly in your IDE is key to preventing issues from being created in the first place and shifting security left.

Snyk scans all dependencies including transient dependencies but also provides a dependency path view. Snyk can set policies at a group level or organization level and provides the ability to set custom policies based on project attributes like Business Criticality, Environment (On-Prem, Internal, External, SaaS etc.), Lifecycle (Production, Development). It also offers data and analytics across all of your projects, displaying historical and aggregated data about projects, issues, dependencies, and licenses.

There’s one main downside with Snyk, it’s not cheap and the free version has a limit. Realistically though, succumbing to security vulnerabilities, spending extra unneeded development cycles to remediate the unknown, or using tools with lackluster, non-actionable information is even more expensive! Coupled with the unparalleled developer experience, using Snyk, either paid or free, is a no-brainer for any organization or developer.

Runner Up: CodeSec

CodeSec is a SAST/SCA tool created by Contrast Security, a new and upcoming security company providing free and paid tooling. Contrast Security boasts on their website 10x faster scan times, 200% more accurate results, and 45x faster time to fixing defects. Though, we’re not sure how accurate that is in comparison to Snyk, or how those numbers were actually calculated.

For auditing (SCA), CodeSec supports Java, Javascript, Python, Ruby, Go, PHP, and .NET. For SAST, CodeSec supports Java, Javascript, .NET, React, Angular, and jQuery. For AWS Lambda functions, CodeSec supports Java and Python.

Unfortunately, it lacks support for other languages that Snyk does support. Regardless, CodeSec from Contrast Security is definitely something to keep your eyes on as the company grows and iterates through their tool stack. They’re hyper focused on making products that are easy to use for developers while shifting security left. Their Chief Technology Officer and Co-Founder, Jeff Williams, is the founder of OWASP and has been helping drive the conversation and technology around Software Bills of Materials (SBOMS).

Definitely keep your  👀on Contrast Security!

Automated Dependency Management Helps Shift Security Left!

New Log4J CVE released; are you ready? No one enjoys manually bumping versions, so let automation take care of that for you! In fact, automated dependency management is essential to the security health of an organization, ensuring that your software is always built with the most up-to-date and secure dependency versions. Leveraging automation reduces the risk of vulnerabilities caused by outdated or compromised libraries and minimizes human error, saving valuable developer time! When dev time is saved, that means you’re allowed to focus more time on writing secure code and solving problems.

GitHub makes this super easy with two excellent applications that are available. Renovatebot and Dependabot.

Dependabot

Dependabot is free for everyone. It started off as Bump from a project over at GoCardless and made its way over to GitHub. GitHub further maintains it and puts the GitHub UI in front, making it easy to see what’s going on. It’s really easy to use, just add a dependabot.yml file to your repo and Dependabot will begin opening a pull request to update outdated dependencies. It’s a good idea to double check  and make sure all your package ecosystem files are added and supported.

Renovatebot

Just like Dependabot, Renovatebot is an open source tool that’s completely free and provided by Mend which was formerly known as WhiteSource. It’s been endorsed by OpenSSF & Google as the “industry standard tool for dependency updates.” You can read the white paper here. It’s super easy to get started too! On GitHub all you have to do is Install the GitHub App, at which time the GitHub hosted Renovate will automatically open a pull request to your repo(s) with the configuration. From there, you can adjust the config file per the configuration documentation (which is extremely verbose and robust). Getting started is easy though as it’s not necessary to adjust the configuration. The basic configuration allows for Renovate to begin opening pull requests immediately upon merge. Below is a sample snippet for a configuration file with some core attributes we like to leverage, but the sky really is the limit here.

A basic renovate configuration with core security attributes we like to leverage:

A default renovate configuration that Renovate adds when onboarding a repository. A default renovate.json file will look like this:

We like to add some basic configurations to auto-merge Minor and Patch updates, add labels for security, and require major updates to be manually reviewed.

One of the big sellers for Renovate is that they provide multiple ways to use it and support for the following platforms:

• GitHub (.com and Enterprise Server)
• GitLab (.com and CE/EE)
• Bitbucket Cloud
• Bitbucket Server
• Azure DevOps
• Gitea

Both are well designed and are very effective at automating dependency management. If you’re running on GitHub then either is a solid choice, though we have a slight preference for Renovatebot. This slight preference for Renovate is due to its customization, stability, and breadth of default support across multiple platforms. It’s made our lives much easier on client sites, helping keep a lot of custom DevSecOps platform tooling and libraries up-to-date automatically.

Secret Protection and Leak Detection

Protecting your secrets from being exposed to the outside world is critical. Well, gone are the days where you accidentally commit a secret and go back to remove it from history, only to still have to rotate your secret.

GitHub Secret Scanning

We would be remiss to not mention GitHub secret scanning. It’s so simple to get configured and works very effectively. It provides the inherent ability to protect you from pushing your code with said secret, without the need to set up a pre-commit hook and allows you to easily define your own custom patterns. In fact, it’s so simple, easy, and effective there’s not much more to say; just use it!

If you want more information, checkout Calvin’s in-depth review of GitHub Secret Scanning.

GitLeaks

GitLeaks is an open source SAST tool built by the user zricethezav on GitHub with a current number of about 120 contributors. What it does is scan your repo for hardcoded passwords or other types of known secrets prior to you committing (through a pre-commit hook) and directly in your CI. It can be run locally, through the published action, or as a pre-commit hook. It’s written in Go and includes a python script for the pre-commit hook.

Gitleaks is pretty easy to use and the documentation, found in the form of a README.md, is pretty good. In fact, on MacOS, the documentation took me less than 5 minutes to get setup locally, and get an action put in my repo. This is with no advanced configuration. It’s installable through homebrew locally, or you can use docker. It is easy to integrate with Github through their published action. And they immediately tell you how to set up a pre-commit hook through the pre-commit tool, which is also easily installable. From there, I only had to read a tiny bit farther to figure out what the intended basic commands do. This tool is very well documented and the documentation itself is simple and readable.

What if your secret isn’t in a well known secret format? No problem, GitLeaks provides an easy way to extend the program by making your own customizations. This can be particularly useful if the code base is diverging from a paradigm.

Since GitLeaks is open source, you’re able to skim the code to see how it works. It does of course have some limitations as it’s completely based on regex and conventions. Which definitely makes sense and is arguably the right way to build out this tool. It just means it’s not all encompassing out of the gate.

The regexes are maintained in varying functions within the go files that make up the tool. They’re called “rules.” The rules can be found within this directory  in the repository. An example rule that many may be familiar with is the GitHub PAT rule where the regex basically looks for a 36 character string after ghp_. When using the pre-commit hook, GitLeaks would run prior to making the commit and figure out whether or not you have a GitHub PAT listed in any of the files within your repo and of course, stop you from committing (presuming you don’t run –no-verify or have the secret ignored via the test secret option) if a string was found matching that regex. The other rules function similarly. The readme for the project documents options for custom rule extensions in the event you want to look for a type of secret that isn’t supported out of the gate.

Here’s what running git commit looks like when GitLeaks is installed as a pre-commit hook and a secret exists.

If I had one thing to nitpick, it’s how licensing works for the GitHub Action and that it’s owned by a single user. Granted, licensing for enterprises is insanely cheap and is only needed by GitHub enterprises using the GitHub action.The funny thing is though, it’d be really easy to make your own GitHub action or something else to use on another platform. Additionally, there’s a couple security implications in the repo that I immediately caught on to, so if you’re an enterprise, please vet the application before using it, or just default to the tried and true GitHub Secret Scanning.

There are some security considerations with using the tool. The following is a list of things I noticed during my investigation of the tool.

1. GitLeaks doesn’t do any apparent security scanning of its source code.

1. It DOES run the GitLeaks action against itself
2. It does have GHAS security vulnerability publishing.
3. There are no dependabot updates
4. There are no actions for other SAST tools
5. There is no GoSec action

1. GoSec throws 11 issues, 3 criticals and 8 moderates

1. Most can be safely ignored via comments
2. But there are some other areas that could be improved

1. There’s no SECURITY.md file explaining how to report vulnerabilities.
2. It’s hosted under a user on GitHub instead of an org. Not really a big deal, but something to consider if that matters to you.

Fin

The digital landscape is an ever-evolving battleground, where securing your applications through the entire Software Development Life Cycle (SDLC) is no longer just a luxury — it's a necessity. By embracing DevSecOps and equipping your CI pipeline with security tool essentials, you can efficiently weave security into the very fabric of your application development process. Leveraging Renovate, Snyk, and GitLeaks can help you to begin to transform your SDLC into a formidable bastion of cybersecurity prowess