Conversation
|
Skipping CI for Draft Pull Request. |
|
Images are ready for the commit at 61310af. To use with deploy scripts, first |
2f92d1b to
8376959
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #12452 +/- ##
==========================================
- Coverage 48.23% 48.21% -0.03%
==========================================
Files 2441 2441
Lines 175609 175659 +50
==========================================
- Hits 84709 84693 -16
- Misses 84077 84146 +69
+ Partials 6823 6820 -3
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
79fd823 to
f8f8308
Compare
0da9b59 to
f87eaa0
Compare
102c0c9 to
aba8105
Compare
57a4a25 to
f6f54c7
Compare
898b93e to
1551f3f
Compare
jvdm
left a comment
There was a problem hiding this comment.
What is your plan regarding the vulnerability bundle version?
This will break 4.[45] now that we use v1 for everything from what I understand.
@daynewlee we'd still need both of them:
|
@jvdm this is the case I brought up offline before, but I completely forgot about it until you mentioned it. I believe this will merit a bump to |
There was a problem hiding this comment.
Just to confirm: Is CSAF/VEX unaffected by that weird OpenShift 4.x CPE version matching expansion?
I am actually curious if older Scanner V4s will handle getting VEX data, so I will test that before making a v2. Thanks for bringing it up!
I think bumping the bundle version is the way to go here; I don't think the DB will support filtering updates for "disabled updaters", need to check though.
@jvdm I spent some time thinking about it, and I probably could just test it to be absolutely sure, but I think it may be best to be safe, and I'll make a |
652847b to
0c62e00
Compare
f8dc642 to
448b56a
Compare
jvdm
left a comment
There was a problem hiding this comment.
One question/clarification on the changelog entry, otherwise all good.
From testing instructions @RTann:
Install StackRox 4.5.2. I used an SSD for the Scanner V4 DB PVC to speed up DB initialization
The vulnerability URL is pointing to dev
Curious: The old RHEL updater data, does it get cleaned-up by the garbage collector? Since the updater was disabled, I was wondering...
@jvdm Claircore added a migration to remove all the OVAL data: https://github.com/quay/claircore/blob/v1.5.31/datastore/postgres/migrations/matcher/13-delete-rhel-oval.sql. We also clean up references to the old updater timestamp in |
9b89a13 to
29278a7
Compare
8251514 to
61310af
Compare
|
@RTann: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
Description
Claircore has replaced Red Hat OVAL data with VEX. This change ports that over and makes whatever related changes are required.
User-facing documentation
Testing and quality
Automated testing
How I validated my change
For each installation, I used Helm for the fresh installs, and for any updates, I did
oc editon the affected deployments/config maps. Steps for installing StackRox is left as an exercise for the reader.These tests were conducted Tuesday, September 17, 2024. This is important to note because Prod Sec made an update to VEX files on September 11 (https://access.redhat.com/articles/5554431). This took some time to propagate, and it was found that most, if not all, VEX files were changed due to this. So, the number of changes to the files after the compressed vulnerability file was created is rather massive. This is clear due to the fact it took around 40+ minutes to generate the vulnerability bundle.
CI
Some tests added/modified. Also, we can see we were able to build the new vulnerability data due to the
pr-update-scanner-vulnslabel.Fresh Install
registry.redhat.io/advanced-cluster-security/rhacs-scanner-v4-db-rhel8:4.4.0to compare it with the results from https://catalog.redhat.com/software/containers/advanced-cluster-security/rhacs-scanner-v4-db-rhel8/65e5dfed037ec9102313821b?q=rhacs-scanner-db&image=66056246959cc751326e3ee2&container-tabs=securityDifferences:
advanced-cluster-security/rhacs-scanner-v4-db-rhel8perl-*componentsSo, the results match for the most part. Aside from the 3 vulnerability discrepancies (the ones affecting
advanced-cluster-security/rhacs-scanner-v4-db-rhel8look ok to me), the results look fine to me. If there is an issue, then it's due to how ClairCore handles the VEX/RHEL data, so I think it's ok to proceed (messaging interested parties offline, though).Upgrade from 4.5.2
From inside Scanner V4 DB, you can see there are no more RHSAs (aside from the ones from the container-first updater):
I didn't comb through every single vulnerability, but I scanned
registry.redhat.io/advanced-cluster-security/rhacs-scanner-v4-db-rhel8:4.4.0, and I found the same number of vulns (fixable and unfixable) and the same number of vulns with each severity, so I'm going to say they matchI also tested what happens when I defer an RHSA and a mark an RHSA as a false positive and then upgrade. It seems like nothing crashes, but now there are no referenced vulns anymore on the exception management page.