<aside> 💡 For a list of accepted CVEs in Sourcegraph releases, see Accepted CVEs in Sourcegraph Releases
</aside>
We use Trivy to scan our container images for security vulnerabilities. It breaks down a container image into components and alerts on components with CVEs. We scan our container images for Critical and High severity CVEs.
We currently run Trivy daily as a CronJob in the security-tooling kubernetes cluster. This daily scan is meant to catch new CVEs in our existing components. It also sends Slack alerts to the security team on new vulnerabilities. The results are sent to a GCP bucket and stored for compliance purposes, and can be viewed in Elastic.
We can run the same image as the CronJob locally and have results uploaded to the GCP bucket. Authentication to GCP is necessary. Run the image with:
docker run -it -v ~/.config/gcloud:/.config/gcloud us.gcr.io/sourcegraph-security-logging/trivy-sg:latest
You can also install Trivy and scan specific images. Trivy can be installed with homebrew:
brew install aquasecurity/trivy/trivy
Once Trivy is installed running scans on images is easy:
trivy image --severity "HIGH,CRITICAL" <IMAGE>:insiders
This scans an image for High/Critical CVEs. The -f json flag can be used to output data in JSON format, which includes a lot more information on the vulnerable components and versions.
The steps above can become a bit tedious if you need to scan all images during a release cut. We've written a script that you can find in the infrastructure repo. You can run the script as follows:
$ python3 trivy-diff.py --last-release 4.1.0 --threads 10
The command above will fetch the accepted vulnerabilities from the markdown table in our handbook. You need to specify the release using the --release option. It then uses 10 threads to scan the container images. When the scan is done it will output vulnerabilities that are not on the handbook page, and those that are on the handbook page but not found by Trivy. Keep in mind that you should not put tags in the container justification document. This confuses the tool, and is unnecessary as the title of the justification page already indicates the version.
trivy-diff also supports result caching with --cache and you can point it to the markdown file you are updating with --local-table. This makes it easier to check if the justification table is complete when you are updating it. If you use the latest version of trivy-diff when you use the --local-table option, it will now create a new file in the directory where you run it. That file contains an updated table with newly detected issues and without the resolved vulnerabilities.