Integrate Trivy for vulnerability scanning

[michaelsauter]

Trivy is a popular vulnerability and misconfiguration scanner.

ODS Pipeline supports vulnerability scanning via the Aqua scanner right now, which is a commercial offering. In contrast, trivy is a free offering, but it can be integrated with an Aqua server via the Aqua plugin.

Migrating from the Aqua scanner to trivy will be a great step forward for ODS Pipeline, because:

• the trivy binary is freely available so can be baked into the container image stored on GitHub
• scanning will be available regardless of the existence of an Aqua server
• in addition to vulnerabilities, misconfiguration and licenses can be scanned too
• SBOM generation as mentioned in opendevstack/ods-pipeline#592 can be done via trivy

[michaelsauter]

@gerardcl @henrjk What are your thoughts on dropping Aqua completely? I think Aqua should run vulnerability checks every day. During CI, it probably does not need to do anything. Instead it may be enough to run Trivy, and allow users to fail if Trivy detects vulnerabilities (of some severity).

[henrjk]

If I am not mistaken currently ods-pipeline creates an SBOM using Trivy but does not yet use it for vulnerability scanning. If we used Trivy also for scanning, caches Trivy creates could be reused. Also in general it makes sense to me to use a single tool for both.

Assuming that there is also external scanning happening the need to support other scanning tools for ods-pipeline might be less. On the other hand it might be cool if we could make it pluggable so that other scanners could be supported without requiring this to be built into ods-pipeline.

There are many candidates that may makes sense to use, without a lot of research osv-scanner, grype, syft (see https://github.com/opendevstack/ods-pipeline/issues/592#issuecomment-1445914949) and perhaps other related tools such as Docker Bench come to mind.

[gerardcl]

Hi!

I like a lot the approach! I was thinking in the same way for ods-jenkins-shared-lib indeed! Must be aligned with IT.

Nevertheless, I would try to keep the PR decoration.

Also, I suggest on having scans on different stages and with different puroposes:

• before building images

1) fs: scan vulns repo before any test/build (so one can also check vulns on tests/build deps. Etc)

2) config: to detect any missconfiguration, passwords in plain text, terraform...

3) licenses check

• after building images:

1) image vulns

Then compile and report/decorate?

What do you think?

[michaelsauter]

Thanks for the comments!

I lean towards the following now:

• Don't make any change until we split out the tasks into separate repos
• Once the tasks are in their own repos, remove vulnerability scanning from the package-image task
• Create a new vulnerability scanning task which uses trivy, consuming the SBOMs generated in the the package-image task. No connection / configuration of Aqua remains.
• Allow users to enable license and config scan via a parameter of the scan task (exact parameters of the task tbd)
• Remove the PR report / commit insight from the task itself, and instead save a file to disk, e.g. .ods/insights/trivy-scans/vulnerabilities. This file (and other similar ones) would be a JSON structure which will be sent to Bitbucket in the finish task. That way the scan task does not need to interact with Bitbucket and it becomes very easy for any task to generate Bitbucket insights.

In regards to some other aspects you mentioned:

• I do not see a compelling reason to make fs part of the offering - if need be users can configure this themselves in their own tasks
• The above proposal would make it much easier to swap trivy with other scanners. It depends a bit on how well the SBOM generated by Trivy can be consumed by other tools though.

[michaelsauter]

I do not see a compelling reason to make fs part of the offering - if need be users can configure this themselves in their own tasks

Actually, this may be interesting for repos not building container images. Not sure how to deal with this yet.

[michaelsauter]

Transferring as a consequence of https://github.com/opendevstack/ods-pipeline/pull/722.