🎉 implement trivy scanner

[manuel-sommer]

CVE-2024-37891 --> #11891
CVE-2024-6484 --> https://github.com/DefectDojo/django-DefectDojo/actions/runs/13506024016/job/37735642044?pr=11892 --> components/yarn.lock (bootstrap 3.4.1)

[dryrunsecurity]

DryRun Security Summary

A new GitHub Actions workflow for Trivy vulnerability scanning is implemented, along with configuration files that include some security considerations around ignored vulnerabilities and excluded test directories.

Expand for full summary

The PR introduces a new GitHub Actions workflow for Trivy vulnerability scanning, adds a .trivyignore file, and creates a Trivy configuration file with comprehensive scanning settings.

Security Findings:

1. In .trivyignore: Deliberate acceptance of CVE-2024-6484, which represents a potential unaddressed security vulnerability without full context justification.
2. In trivy.yaml: Potential information disclosure risk due to excluding unittests/scans directory from vulnerability scanning, which might skip security-sensitive test code.

Code Analysis

We ran 9 analyzers against 3 files and 0 analyzers had findings. 9 analyzers had no findings.

View PR in the DryRun Dashboard.

[manuel-sommer]

Feedback welcome @valentijnscholten @Maffooch @mtesauro

[manuel-sommer]

Rebased because of #11891

[valentijnscholten]

I understand that it could be useful to scan applications with Trivy for vulnerabilities. What exact use case / process would we follow here and what goal do we want to achieve? Does it generate a report that is visible on the PR or Security Tab? Will it show a difference between existing vulnerabilities and new ones introduced by the PR? Or is it just a tool that generates some output that may or may not assist us in making decisions?

[manuel-sommer]

WIth this PR we can get feedback about new introduced vulnerabilities within the upgrade process. With some packages (.e.g yarn) we are behind. In case we once work on upgrading these, it would be nice to have feedback which vulnerabilities are introduced with new packages.
Furthermore, we get feedback about renovate and dependabot bumps, but I assume that renovate and dependabot upgrades are faster than the detection and reporting of vulnerabilities.
Furthermore, we get regularly feedback about packages with lacking release process, but new vulnerabilities are introduced.
Summarizing, it helps to get feedback about the packages used in DefectDojo. Then, we can decide to either accept the risk or go a different way. An example is this PR #11891
Regarding report: It returns a report in the pipeline, take a look here as an example: https://github.com/DefectDojo/django-DefectDojo/actions/runs/13506024016/job/37735642044?pr=11892

[mtesauro]

I wonder if this would be something better to run outside of PRs.

Here's why.

I'm a new contributor who writes a new parser for DefectDojo. It just so happens that libFoo.js has a vulnerability discovered right before I do my PR and it's used to create the charts in DefectDojo's metrics pages. I fail this test which has NOTHING to do with the code I'm trying to contribute.

I'm just worried we're going to cause pain to our community for things that didn't do and don't have control over.

Honestly, I'd rather write a cron job that pulls the containers we have in Docker Hub and runs Trivy and whatever else against those containers and pushes the results to a DefectDojo install. It might surprise you but DefectDojo Inc actually runs DefectDojo internally to manage our scan data. I'd be happy to add this to our automation and create PRs to update things that show up.

The key difference is I'm choosing to take on that effort vs it getting dropped in the lap of a community contributor.

Does that make sense?

[manuel-sommer]

Thank you for the clarification @mtesauro. It does not surprise me that you use also DefectDojo yourself.
I did not look into it, if this it technically possible, but would it make sense to run trivy ci checks only on PRs from renovate and dependabot to get instant feedback?

[Maffooch]

would it make sense to run trivy ci checks only on PRs from renovate and dependabot to get instant feedback?

Talking internally with Matt, we believe this would likely still be more churn than we would benefit from - even when running Trivy only on package updates from renovate/dependabot