From aaa616a00d3a584f9559ed2465119a6c83c9b0aa Mon Sep 17 00:00:00 2001 From: Alessio Greggi Date: Thu, 6 Nov 2025 19:47:06 +0100 Subject: [PATCH 1/3] docs(rfc): multiscan process Signed-off-by: Alessio Greggi --- docs/rfc/0006_multiscan.md | 97 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 97 insertions(+) create mode 100644 docs/rfc/0006_multiscan.md diff --git a/docs/rfc/0006_multiscan.md b/docs/rfc/0006_multiscan.md new file mode 100644 index 000000000..5249cc945 --- /dev/null +++ b/docs/rfc/0006_multiscan.md @@ -0,0 +1,97 @@ +| | | +| :----------- | :------------------------------ | +| Feature Name | Multi-Scan | +| Start Date | 6 November 2025 | +| Category | Architecture | +| RFC PR | [fill this in after opening PR] | +| State | **ACCEPTED** | + +# Summary + +[summary]: #summary + +Support multiple scanning tools. + +# Motivation + +[motivation]: #motivation + +We want to add support for multiple scanning tools (such as grype) in order to enrich the vulnerability reports, making it more complete and accurate. + +This will also allow us to be less vendor centric, since we are currently relying only on trivy to generate SBOMs and scan for vulnerabilities. + +## Examples / User Stories + +[examples]: #examples + +### User story 1 + +As a user, I want to make use of KEV and the EPSS score (which are currently provided by grype) to prioritize vulnerability remediation efforts. + +# Detailed design + +[design]: #detailed-design + +## Scan + +For the multiscan feature, we are going to double the following operations: + +* sbom generation + +* sbom scan + +This will let grype to generate its own report, so that we can then compare and merge with the one obtained with trivy. + +Since grype and trivy are different tools, we must to take care about their scan processes, synchronizing their flows, to be able to analyze and merge the results. + +This will require a synchronization mechanism to allow both of them to generate and scan SBOMs. To achieve this, we must set a timeout for their execution and define a default tool from which to take the results. In this case, we can adopt the following logic to avoid starvation: + +``` +if trivy fails: + return error +if grype fails: + return trivy.result +if trivy succed && grype succed: + return trivy.result and grype.result +``` + +## Merge + +The second phase, of the multiscan process, is about merging results. + +We already have defined our own `VulnerabilityReport` format [here](./0004_vulnerability_report.md). Starting from here, we are going to enrich the struct with information that are exclusively provided by `grype`: + +* `kev` is a list of known exploits from the CISA KEV dataset. + +* `epss` is a list of Exploit Prediction Scoring System (EPSS) scores for the vulnerability. + +# Drawbacks + +[drawbacks]: #drawbacks + + + +# Alternatives + +[alternatives]: #alternatives + + + +# Unresolved questions + +[unresolved]: #unresolved-questions + + From b1f99f9630f0660b847cf756f3cda136eab94728 Mon Sep 17 00:00:00 2001 From: Alessio Greggi Date: Fri, 7 Nov 2025 16:48:34 +0100 Subject: [PATCH 2/3] update rfc Signed-off-by: Alessio Greggi --- docs/rfc/0006_multiscan.md | 47 ++++++++++++++++++++++++++++++++------ 1 file changed, 40 insertions(+), 7 deletions(-) diff --git a/docs/rfc/0006_multiscan.md b/docs/rfc/0006_multiscan.md index 5249cc945..95c19a826 100644 --- a/docs/rfc/0006_multiscan.md +++ b/docs/rfc/0006_multiscan.md @@ -10,15 +10,24 @@ [summary]: #summary -Support multiple scanning tools. +Support grype as additional tool to scan for SBOMs. # Motivation [motivation]: #motivation -We want to add support for multiple scanning tools (such as grype) in order to enrich the vulnerability reports, making it more complete and accurate. +We want to add support for `grype` in order to enrich the vulnerability reports, making it more complete and accurate. -This will also allow us to be less vendor centric, since we are currently relying only on trivy to generate SBOMs and scan for vulnerabilities. +This will allow us to be vendor neutral, since we are currently relying only on `trivy` to generate SBOMs and scan for vulnerabilities. + +Additionally, we discovered that `grype` is able to find more vulnerabilities than `trivy`. Below there's a recap about our research: + +| image | `trivy` | `grype` | +|-------|---------|---------| +| `golang:1.12-alpine` | 45 | 210 | +| `nginx:1.21.0` | 396 | 522 | +| `redis:6.2.0-alpine` | 44 | 127 | +| `postgres:13.0-alpine` | 63 | 151 | ## Examples / User Stories @@ -40,11 +49,9 @@ For the multiscan feature, we are going to double the following operations: * sbom scan -This will let grype to generate its own report, so that we can then compare and merge with the one obtained with trivy. +This will let grype generate its own report, so that we can then compare and merge with the one obtained with trivy. -Since grype and trivy are different tools, we must to take care about their scan processes, synchronizing their flows, to be able to analyze and merge the results. - -This will require a synchronization mechanism to allow both of them to generate and scan SBOMs. To achieve this, we must set a timeout for their execution and define a default tool from which to take the results. In this case, we can adopt the following logic to avoid starvation: +We can run the tools sequentially (1st trivy, 2nd grype) and then apply the following flow to decide what to return: ``` if trivy fails: @@ -65,6 +72,32 @@ We already have defined our own `VulnerabilityReport` format [here](./0004_vulne * `epss` is a list of Exploit Prediction Scoring System (EPSS) scores for the vulnerability. +* `risk` is the score of the risk. + +* `licenses` is a list of the licenses used by all the components within the affected software. + +In addition to that, we are going to optionally update/overwrite already existing fields retrivied from `trivy`, in case `grype` has better results: + +* `cvss` version and scores. + +* `references` with additional links. + +* `description` if not provided by trivy. + +We cannot be sure that both the tools will find the exact same results, for this reason we have to adopt the following merging strategy: + +``` +vuln_report +for vuln in trivy.vulnerabilities: + vuln_report add vuln + if grype has vuln: + vuln_report add grype.kev + vuln_report add grype.epss + ... +for vuln in grype.vulnerabilities: + vuln_report add vuln +``` + # Drawbacks [drawbacks]: #drawbacks From 5058c4a7b96073e42579d6de96b9435fe70d360e Mon Sep 17 00:00:00 2001 From: Alessio Greggi Date: Mon, 10 Nov 2025 13:10:05 +0100 Subject: [PATCH 3/3] update doc Signed-off-by: Alessio Greggi --- docs/rfc/0006_multiscan.md | 66 ++++++++++++++++++-------------------- 1 file changed, 32 insertions(+), 34 deletions(-) diff --git a/docs/rfc/0006_multiscan.md b/docs/rfc/0006_multiscan.md index 95c19a826..9e9893544 100644 --- a/docs/rfc/0006_multiscan.md +++ b/docs/rfc/0006_multiscan.md @@ -10,17 +10,17 @@ [summary]: #summary -Support grype as additional tool to scan for SBOMs. +Support grype as an additional tool to scan for SBOMs. # Motivation [motivation]: #motivation -We want to add support for `grype` in order to enrich the vulnerability reports, making it more complete and accurate. +We want to add support for `grype` in order to enrich the vulnerability reports, making them more complete and accurate. -This will allow us to be vendor neutral, since we are currently relying only on `trivy` to generate SBOMs and scan for vulnerabilities. +This will allow us to be vendor-neutral, since we are currently relying only on `trivy` to generate SBOMs and scan for vulnerabilities. -Additionally, we discovered that `grype` is able to find more vulnerabilities than `trivy`. Below there's a recap about our research: +Additionally, we discovered that `grype` is able to find more vulnerabilities than `trivy`. Below is a recap of our research: | image | `trivy` | `grype` | |-------|---------|---------| @@ -41,6 +41,23 @@ As a user, I want to make use of KEV and the EPSS score (which are currently pro [design]: #detailed-design +For this new feature, we are providing a way to enable it when scanning. + +This will impact the `ScanJob` CRD, adding a new boolean field called `multiScan`, set to `false` by default. + +To enable it, the `ScanJob` should be set like this: + +```yaml +apiVersion: sbomscanner.kubewarden.io/v1alpha1 +kind: ScanJob +metadata: + name: scanjob-example + namespace: default +spec: + registry: example-registry + multiScan: true +``` + ## Scan For the multiscan feature, we are going to double the following operations: @@ -49,24 +66,15 @@ For the multiscan feature, we are going to double the following operations: * sbom scan -This will let grype generate its own report, so that we can then compare and merge with the one obtained with trivy. - -We can run the tools sequentially (1st trivy, 2nd grype) and then apply the following flow to decide what to return: +This will let `grype` generate its own report, so that we can then compare and merge with the one obtained with trivy. -``` -if trivy fails: - return error -if grype fails: - return trivy.result -if trivy succed && grype succed: - return trivy.result and grype.result -``` +We can run the tools sequentially (1st trivy, 2nd grype) in case the `multiScan` field is set to `true` in the `ScanJob` CRD. ## Merge -The second phase, of the multiscan process, is about merging results. +The second phase of the multiscan process is about merging results. -We already have defined our own `VulnerabilityReport` format [here](./0004_vulnerability_report.md). Starting from here, we are going to enrich the struct with information that are exclusively provided by `grype`: +If both the scans succeed, then we can merge them together. We already have defined our own `VulnerabilityReport` format [here](./0004_vulnerability_report.md). Starting from here, we are going to enrich the struct with information that is exclusively provided by `grype`: * `kev` is a list of known exploits from the CISA KEV dataset. @@ -76,7 +84,7 @@ We already have defined our own `VulnerabilityReport` format [here](./0004_vulne * `licenses` is a list of the licenses used by all the components within the affected software. -In addition to that, we are going to optionally update/overwrite already existing fields retrivied from `trivy`, in case `grype` has better results: +In addition to that, we are going to optionally update/overwrite already existing fields retrievied from `trivy`, in case `grype` has better results: * `cvss` version and scores. @@ -84,7 +92,7 @@ In addition to that, we are going to optionally update/overwrite already existin * `description` if not provided by trivy. -We cannot be sure that both the tools will find the exact same results, for this reason we have to adopt the following merging strategy: +We cannot be sure that both tools will find the same results. For this reason, we have to adopt the following merging strategy: ``` vuln_report @@ -95,7 +103,8 @@ for vuln in trivy.vulnerabilities: vuln_report add grype.epss ... for vuln in grype.vulnerabilities: - vuln_report add vuln + if vuln not in vuln_report: + vuln_report add vuln ``` # Drawbacks @@ -111,20 +120,9 @@ Why should we **not** do this? * will the solution be hard to maintain in the future? ---> -# Alternatives - -[alternatives]: #alternatives +There are no specific concerns about this new feature. - +By default, the `multiScan` is not enabled, so the user will not hit performance issues. -# Unresolved questions +When the feature is enabled, an additional scan will run, and consequently, its results will be merged. This shouldn't have a huge impact, but users should keep this in mind when enabling it. -[unresolved]: #unresolved-questions - -