docs(rfc): multiscan process

[alegrey91]

Description

Fix #583

Test

To test this pull request, you can run the following commands:

Additional Information

Tradeoff

Potential improvement

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 39.78%. Comparing base (11cffd9) to head (5058c4a).
⚠️ Report is 119 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #603      +/-   ##
==========================================
- Coverage   39.88%   39.78%   -0.10%     
==========================================
  Files          40       40              
  Lines        3019     3019              
==========================================
- Hits         1204     1201       -3     
- Misses       1624     1627       +3     
  Partials      191      191              

Flag	Coverage Δ
unit-tests	39.78% <ø> (-0.10%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[flavio]

I think it would be worth to mention that grype can also find vulnerabilities of Go binaries that are shipped without using a package manager.

It can find issues that affect the binary project itself, not just the dependency tree of that project. An example of that is the nginx-ingress controller cve-2025-1974 that trivy cannot find.

[alegrey91]

absolutely. that's a good point.

[flavio]

Note: that poses a question about which scanner is the default one when multiScan is disabled.

[alegrey91]

I assumed, when multiScan is not enabled, this will scan only with trivy as it currently does.
Sounds good to you?

[flavio]

yes, but let's clarify that inside of the RFC

[fabriziosestito]

I am not sure whether this setting belongs at the Registry level or at the Installation level, or if we should even add it in the first iteration.

I also don’t think a multiScan field is explicit enough.
It would be clearer to let users select the engines, for example:

scanEngines: [trivy, grype]

[alegrey91]

Personally, I don't like the idea of letting the user choose the scan engine to use.
I think the real advantage of using the multiscan is to have a richer and more exhaustive result by adding information to the vulnerability report. If we let the user decide which scan engine to use, we are just going to generate different vulnerability reports as you can already do manually.
In my opinion, the multiscan is something the user wants to activate for a deeper view of the cluster security posture, renouncing to the speed of scanning (since we are going to scan each image twice).

[fabriziosestito]

I think the real advantage of using the multiscan is to have a richer and more exhaustive result by adding information to the vulnerability report. If we let the user decide which scan engine to use, we are just going to generate different vulnerability reports as you can already do manually.

We are not going to generate different vulnerability reports, just one by merging the results.
However we are going to ask the user which "engines" he would like to use, without hiding them.
Why should trivy be the default?

[flavio]

I would add the multi-scan setting on a per-repository level. I would make it an parameter set at installation time.

I think we can start with a simple approach and make multiscan a boolean flag that can be enabled/disabled at installation time. We can then iterate from that based on user feedback.

Why should trivy be the default?

I think this should be the case since:

• As far as I remember, it provided richer metadata compared to grype
• It's the most popular image scanner, people are used to scan images with it. By using it, we reduce the chances of having different results that would confuse someone who is looking into SBOMscanner for the first time

[flavio]

I take it back, I changed my mind after the last call we had. I think we should make the names of the scanner to use explicit.

This also paves the way to introduce multiple scanners (like for licenses, secrets,...)

[fabriziosestito]

We are missing a few user stories here:

• As a user, I want image scans to include results from additional vulnerability data sources, providing broader CVE coverage.

• As a user, I want vulnerability findings from multiple scanners to be merged into a single unified report.

• As a user, I want to choose which scan engines are enabled when installing sbomscanner.

[fabriziosestito]

I am not sure whether this setting belongs at the Registry level or at the Installation level, or if we should even add it in the first iteration.

I also don’t think a multiScan field is explicit enough.
It would be clearer to let users select the engines, for example:

scanEngines: [trivy, grype]