Use of clair report from OCI and CVE leeway #1180
Conversation
|
Created as draft to get early feedback. Currently missing:
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1180 +/- ##
==========================================
Coverage 100.00% 100.00%
==========================================
Files 120 120
Lines 6254 6409 +155
==========================================
+ Hits 6254 6409 +155
|
zregvart
force-pushed
the
issue/EC-838
branch
3 times, most recently
from
bdafcbc to
8679082
Compare
|
This is now ready for review. I think the descriptions/messages could use a bit of finessing. The logic is bit hard (at least for me) to follow, the main idea is not to report any blocking (deny) violations caused by a vulnerability that was made public (issued date) after the effective date - leeway for the severity, and the same should be reported as a warning. |
zregvart
force-pushed
the
issue/EC-838
branch
from
8679082 to
27ad2ce
Compare
policy/release/cve.rego
Outdated
| report_blob := object.union(input_image, {"digest": layer.digest}) | ||
| report_blob_ref := image.str(report_blob) | ||
|
|
||
| report := json.unmarshal(ec.oci.blob(report_blob_ref)) |
There was a problem hiding this comment.
We should probably have some data validation on the report itself. Maybe as a follow up?
There was a problem hiding this comment.
Yeah, I don't want to make this bigger, but I might, let's see how enthusiastic I'll end up being...
There was a problem hiding this comment.
Created #1199 for the follwup.
If present the Clair report attached to the image will be used and consulted instead of the aggregate present in `SCAN_OUTPUT` Task result. This allows us to filter out the vulnerabilities that are made public within X number of leeway days. Reference: https://issues.redhat.com/browse/EC-838
zregvart
force-pushed
the
issue/EC-838
branch
from
27ad2ce to
7c0a915
Compare
Sets the `effective_on` when vulnerabilities are not reported as blocking violations due to the leeway policy. Now the evaluation considers a period instead of the leeway cut-off date, so the functions/expressions can be reused between the different rules. This makes the violations resulting from vulnerabilities found within the leeway period effectively a warning. The zero period refers to the period with no leeway, i.e. from beginning of (Unix) time till the current effective date; and the configured period includes the time up to the leeway cut-off date, i.e. from beginning of (Unix) time up to the leeway cut-off date. Reference: https://issues.redhat.com/browse/EC-838
zregvart
force-pushed
the
issue/EC-838
branch
from
7c0a915 to
b00d1c0
Compare
|
I'm very close to merging this, I think everything is addressed in the latest version and there is one approving review albeit for the older version. |
If present the Clair report attached to the image will be used and consulted instead of the aggregate present in
SCAN_OUTPUTTask result.This allows us to filter out the vulnerabilities that are made public within X number of leeway days.
Reference: https://issues.redhat.com/browse/EC-838