Scan git diff for vulnerabilities

[knqyf263]

Description

Trivy can be integrated into CI easily, but the vulnerability disclosure lifecycle is not synced with the development lifecycle. A job can fail due to newly disclosed vulnerabilities even though nothing has changed in the source code. The vulnerability could affect your production regardless of your job failure if your application is already deployed.

A job can fail on newly disclosed vulnerabilities currently, but it cannot prevent a vulnerable dependency from deploying since it is already in production. It doesn't make sense to stop your deployment.

I'd suggest the job should fail on vulnerabilities of newly added dependencies. Then, it can stop deploying the vulnerable dependency. For instance, if there is a change in package-lock.json, only the addition will be scanned. Only repository changes, not vulnerability disclosure, will fail CI jobs.

Obviously, people want to know newly disclosed vulnerabilities as well. They should be detected in a cron job, nightly, hourly, etc.

In short, users should have two scanning jobs.

1. Cron job
   • Scan for all vulnerabilities, including newly disclosed one
   • e.g. $ trivy fs --exit-code 1 ./package-lock.json
2. CI job
   • Scan only dependency differences for vulnerabilities
   • e.g. $ trivy fs --exit-code 1 --diff ./package-lock.json

I believe it would be useful, but we welcome any feedback👍

[github-actions[bot]]

This issue is stale because it has been labeled with inactivity.

[github-actions[bot]]

This issue is stale because it has been labeled with inactivity.

[phisco]

+1 we would be interested in doing the same for crossplane/crossplane. I think it could be hacked together, but it would be nice to have it directly supported.

[ngraef]

This would be nice as a built-in feature. I currently have it implemented as a PR check in a fairly simple pipeline using multiple scans:

1. Checkout base branch in ./base/
2. Checkout head branch in ./head/
3. Scan ./base/, output base.json
4. Scan ./head/, output head.json
5. Read the JSON results, calculate sets of findings added and removed by the head branch relative to the base

Because it scans both the base and head branches using the same database version, it achieves the goal of only alerting on findings caused by code changes, not newly disclosed vulnerabilities.

[liorsep]

@ngraef Thanks for sharing your workaround for this limitation, I am going to try it. +1 Would love to use this feature when its implemented