You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/rfc/0006_multiscan.md
+32-34Lines changed: 32 additions & 34 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,17 +10,17 @@
10
10
11
11
[summary]: #summary
12
12
13
-
Support grype as additional tool to scan for SBOMs.
13
+
Support grype as an additional tool to scan for SBOMs.
14
14
15
15
# Motivation
16
16
17
17
[motivation]: #motivation
18
18
19
-
We want to add support for `grype` in order to enrich the vulnerability reports, making it more complete and accurate.
19
+
We want to add support for `grype` in order to enrich the vulnerability reports, making them more complete and accurate.
20
20
21
-
This will allow us to be vendorneutral, since we are currently relying only on `trivy` to generate SBOMs and scan for vulnerabilities.
21
+
This will allow us to be vendor-neutral, since we are currently relying only on `trivy` to generate SBOMs and scan for vulnerabilities.
22
22
23
-
Additionally, we discovered that `grype` is able to find more vulnerabilities than `trivy`. Below there's a recap about our research:
23
+
Additionally, we discovered that `grype` is able to find more vulnerabilities than `trivy`. Below is a recap of our research:
24
24
25
25
| image |`trivy`|`grype`|
26
26
|-------|---------|---------|
@@ -41,6 +41,23 @@ As a user, I want to make use of KEV and the EPSS score (which are currently pro
41
41
42
42
[design]: #detailed-design
43
43
44
+
For this new feature, we are providing a way to enable it when scanning.
45
+
46
+
This will impact the `ScanJob` CRD, adding a new boolean field called `multiScan`, set to `false` by default.
47
+
48
+
To enable it, the `ScanJob` should be set like this:
49
+
50
+
```yaml
51
+
apiVersion: sbomscanner.kubewarden.io/v1alpha1
52
+
kind: ScanJob
53
+
metadata:
54
+
name: scanjob-example
55
+
namespace: default
56
+
spec:
57
+
registry: example-registry
58
+
multiScan: true
59
+
```
60
+
44
61
## Scan
45
62
46
63
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:
49
66
50
67
* sbom scan
51
68
52
-
This will let grype generate its own report, so that we can then compare and merge with the one obtained with trivy.
53
-
54
-
We can run the tools sequentially (1st trivy, 2nd grype) and then apply the following flow to decide what to return:
69
+
This will let `grype` generate its own report, so that we can then compare and merge with the one obtained with trivy.
55
70
56
-
```
57
-
if trivy fails:
58
-
return error
59
-
if grype fails:
60
-
return trivy.result
61
-
if trivy succed && grype succed:
62
-
return trivy.result and grype.result
63
-
```
71
+
We can run the tools sequentially (1st trivy, 2nd grype) in case the `multiScan` field is set to `true` in the `ScanJob` CRD.
64
72
65
73
## Merge
66
74
67
-
The second phase, of the multiscan process, is about merging results.
75
+
The second phase of the multiscan process is about merging results.
68
76
69
-
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`:
77
+
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`:
70
78
71
79
* `kev` is a list of known exploits from the CISA KEV dataset.
72
80
@@ -76,15 +84,15 @@ We already have defined our own `VulnerabilityReport` format [here](./0004_vulne
76
84
77
85
* `licenses` is a list of the licenses used by all the components within the affected software.
78
86
79
-
In addition to that, we are going to optionally update/overwrite already existing fields retrivied from `trivy`, in case `grype` has better results:
87
+
In addition to that, we are going to optionally update/overwrite already existing fields retrievied from `trivy`, in case `grype` has better results:
80
88
81
89
* `cvss` version and scores.
82
90
83
91
* `references` with additional links.
84
92
85
93
* `description` if not provided by trivy.
86
94
87
-
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:
95
+
We cannot be sure that both tools will find the same results. For this reason, we have to adopt the following merging strategy:
88
96
89
97
```
90
98
vuln_report
@@ -95,7 +103,8 @@ for vuln in trivy.vulnerabilities:
95
103
vuln_report add grype.epss
96
104
...
97
105
for vuln in grype.vulnerabilities:
98
-
vuln_report add vuln
106
+
if vuln not in vuln_report:
107
+
vuln_report add vuln
99
108
```
100
109
101
110
# Drawbacks
@@ -111,20 +120,9 @@ Why should we **not** do this?
111
120
* will the solution be hard to maintain in the future?
112
121
--->
113
122
114
-
# Alternatives
115
-
116
-
[alternatives]: #alternatives
123
+
There are no specific concerns about this new feature.
117
124
118
-
<!---
119
-
- What other designs/options have been considered?
120
-
- What is the impact of not doing this?
121
-
--->
125
+
By default, the `multiScan` is not enabled, so the user will not hit performance issues.
122
126
123
-
# Unresolved questions
127
+
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.
0 commit comments