30+ open-source tools for building DevOps security. Part 1
Ivan Piskunov
Intro
The new security tools don’t have time to become part of a rapidly growing set of practices, which makes me want to set a certain checkpoint as a list of tools.
Practice means a set of measures that can be built into one of the stages of SDLC/DevOps (Threat modeling, SAST, DAST, SCA, Docker image scanning, Kubernetes scanning, AWS Audit and so on).
1.Threat Modeling
So, threat modeling in the context of Secure Development Lifecycle is a process of analyzing software architecture for potential software vulnerabilities and unsafe technologies. In order to reduce the cost of adding additional functionality from the security point of view, the solution may be to implement the process of security checks already at the architecture design stage. At the same stage, the requirements from AppSec expert are formed and will go into backlog. This approach is actually used in all DevSecOps practices and has received the stable expression “Shift security to the left”.
In order for this process to find its place in modern development at high release rates in a large IT company, the process of modeling threats must also be automated. Here is some pool of open-source tools that can help.
Quite a simple tool for self-modelling threats. The user draws the software architecture, indicating the threats that can follow the STRIDE methodology. No automation, but in the classic version, when the processes are debugged, can be useful. This tool is particularly used to model threats in GitHub.
Define your system in Python using the elements and properties described in the pytm framework. Based on your definition, pytm can generate, a Data Flow Diagram (DFD), a Sequence Diagram and most important of all, threats to your system.
Pytm is a framework on Python for creating data flow charts and a list of system threats. The Pytm user defines a model of component interaction in the architecture in code form, and then the tool generates the component interaction diagrams itself. It can be useful for collaboration and use in version tracking systems.
2. Static application analysis on vulnerabilities (SAST)
Let’s move on to the testing phase, namely static code analysis . There are a lot of code analyzers. Open-source tools, in turn, stand out because they are written for a particular language. A large number of tools can be found in the following collections:
But there are also some rather curious tools that can be used universally.
Salus (Security Automation as a Lightweight Universal Scanner), named after the Roman goddess of protection, is a tool for coordinating the execution of security scanners. You can run Salus on a repository via the Docker daemon and it will determine which scanners are relevant, run them and provide the output. Most scanners are other mature open source projects which we include directly in the container.
Salus is particularly useful for CI/CD pipelines because it becomes a centralized place to coordinate scanning across a large fleet of repositories. Typically, scanners are configured at the repository level for each project. This means that when making org wide changes to how the scanners are run, each repository must be updated. Instead, you can update Salus and all builds will instantly inherit the change.
An image of a container in which several static analyzers such as Bandit, Gosec, Brakeman and open-source components (Ruby, Node.js, Python, Go) are placed. At the output we get JSON/YAML report. On GitHub you can also find a description of the embedding in CircleCI.
The tool works similarly to Salus, but with support for more static analyzers. In repo you can see those static analyzers which were placed in the docker image (gosec, find-sec-bugs, psalm, bandit, …). Even terraform, bash, kubernetes manifest analyzers have been placed in the Docker image.
Gitlab is quite a popular DevOps platform, but what else it has is a free set of different open-source SASTs that can be connected from box to painting. Gitlab also has the ability to embed SCA, secret search, fuzzing and other DevSecOps practices, but centralized management of all tools will only be available in the Gold-version.
3. Check open-source component — SCA
Along with the code, which is developed inside the command, you should also check the open-source, which is connected to the project. Lack of process of analysis of third-party components for vulnerabilities may significantly affect the security of the product. The principles of work, comparison of popular SCA tools I gave in a separate article, and here we will talk about what tools exist.
Dependency Check is one of the most popular open-source solutions from OWASP for checking third-party components. There are a lot of ready-made integrations, ways to embed in the pipeline, but the tool has a lot to develop towards quality. It is recommended to implement for companies where Secure SDLC processes are in their initial stages and cyber security specialists have time to parse false positives. Dependency Check does not have a single platform where you can track results in retrospect, so if the processes of vulnerability management in the organization are not built, you should pay attention to Dependency Track.
Dependency Track is the second most popular solution from OWASP, which is a web platform that takes a software bill of materials (SBOM) input from another CycloneDx tool. The Dependency Track explores BOM and then accesses publicly available vulnerability databases such as NVDs. The tool also has the ability to integrate with Slack, Microsoft Teams, scan artifact repositories and check third-party components for license purity.
3.3 Sonatype Open-source
In addition to the NVD (the main source of information on vulnerabilities for most solutions), there is a Sonatype OSS database supported by Sonatype, which also has a commercial Nexus IQ solution. In our turn, we have adopted Nexus IQ as the main SCA tool for our customers. Sonatype OSS is a database of vulnerabilities that can be connected to Dependency Check and Dependency Track tools. In addition, Sonatype supports the following open-source SCA tools, which can be used to scan dependencies and take data from Sonatype OSS.
- AuditJS — JS scanner (NPM, Angular, yarn, bower)
- Nancy — Golang scanner
- Jake — Conda scanner
- Chelsea — Ruby scanner
- Cheque — C/C++ scanner (GCC)
- Ahab — scanner apt, apk, yum, dnf packages
- Pants — scanner Rust (Cargo)
- Sonatype Depshield — GitHub projects scanner
4. Searching for secrets
A project may contain not only vulnerabilities that were allowed in its own code and open-source components but also secrets like passwords, tokens, private keys. etc. Of course, if the code contains an open password from a critical database, it is not desirable to allow it in the repository. For this purpose, there are a number of tools that can help you find open secrets. We won’t stop here long, because the principle of operation is the same everywhere.
Prevents you from committing passwords and other sensitive information to a git repository.
Gitrob is a tool to help find potentially sensitive files pushed to public repositories on Github. Gitrob will clone repositories belonging to a user or organization down to a configurable depth and iterate through the commit history and flag files that match signatures for potentially sensitive files. The findings will be presented through a web interface for easy browsing and analysis.
Gitleaks is a SAST tool for detecting hardcoded secrets like passwords, api keys, and tokens in git repos. Gitleaks aims to be the easy-to-use, all-in-one solution for finding secrets, past or present, in your code.
Searches through git repositories for secrets, digging deep into commit history and branches. This is effective at finding secrets accidentally committed.
Tools for Automated Secrets Detection for Application Security
