This is 4 parts tutorial on DevSecOps 101.
In part 1, we will learn how to detect and avoid vulnerable dependencies when developing applications.In the first step of DevSecOps, the first step towards building more secure apps is detecting and avoid
using dependencies that have known vulnerabilities. This process is
called Software Component Analysis or SCA.
There are a few commercial options like Snyk, but for this tutorial, we will use the open-source pip package safety.
$ pip install safety
$ safety check --full-report
The 2nd step is to integrate SCA into the CI/CD process by adding GitHub workflow to our repository.
Next, we will perform analysis on the source code to find security vulnerabilities. This process is known as Static Application Security Testing, and this has been part of the enterprise software development lifecycle (SDLC) for years.
Recently, there are opensource tools like pylint, eslint or semgrep.
semgrep is, as its names suggest, like grep, but for source code. It allows developers to automatically find patterns in their source code while taking into account semantics like variable renaming. You can find an example of semgrep finding XSS in Django code here.
Even better, semgrep supports a lot of languages, and the semgrep community already has written plenty of rulesets to detect bad practices and security flaws for those.
$ pip install semgrep
$ semgrep --config "p/ci" --exclude .venv --error
- --config "p/ci" means "use the community-written security rules for running in a ci environment"
- --exclude .venv means "do not search for vulnerable source code in the .venv folder" (otherwise it would return hundreds of alerts!)
- --error means return a non-zero error code if alerts are found. Useful for making the CI fail if insecure patterns are detected
Next, we need to add semgrep to the CI/CD to avoid ever doing the in the future. With this, we just installed a tool that scans all our python code to find insecure patterns, gives us recommendations on how to solve them, and integrates seamlessly into our CI/CD.
In part 3, we will be moving into Security Integration Testing (SIT) with automation.
To have an additional layer of security testing that is closer to the application's production context, security teams use specialized tools that will simulate attacks against the running application and report the successful ones.
This process is called Dynamic Application Security Testing (DAST).
Nuclei is an easy-to-use application security testing tool written in go-lang. It leverages the community to create new automated tests using simple YAML template files.
$ go install -v github.com/projectdiscovery/nuclei/v2/cmd/nuclei@latest
$ docker-compose up
$ nuclei -u http://localhost:8080
Next, we will be integrating Nuclei inside the CI/CD process. Again,, in only a few steps, we just install a tool that scans for vulnerabilitites directly inside CI/CD. We scannd our live running app using nuclei web-app security scanner.
In part 4, we will be learning how to scan Docker images using Trivy. This is an opensource security scanner to find mis-configuration and vulnerabilities.
Thanks to trivy, one can scan its docker images to know literally in seconds if they contain packages with known vulnerabilities. Even cooler, trivy is free, open-source, and well maintained.
$ curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin v0.21.0
$ docker build . --file Dockerfile.app -t dvpwa.app
$ trivy image dvpwa.app:latest
Lastly, we will be integrating trivy in GitHub Actions by following a template from AquaSec. So we just set up a tool that automatically detects vulnerable packages inside our docker images, directly in the CI/CD.
In fact trivy can scan way more than docker images: filesystems, requirements.txt, package.json, Dockerfiles and K8s configs.
$ trivy config .
This will scan Dockerfile.app and Docker.db automatic.
Links:
