RHEL Provider: Hydra and CSAF as data sources #772
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Will Murphy <[email protected]>
Signed-off-by: Will Murphy <[email protected]>
Signed-off-by: Will Murphy <[email protected]>
Signed-off-by: Will Murphy <[email protected]>
Signed-off-by: Will Murphy <[email protected]>
Signed-off-by: Will Murphy <[email protected]>
Signed-off-by: Will Murphy <[email protected]>
Signed-off-by: Will Murphy <[email protected]>
Signed-off-by: Will Murphy <[email protected]>
Signed-off-by: Will Murphy <[email protected]>
Signed-off-by: Will Murphy <[email protected]>
Signed-off-by: Will Murphy <[email protected]>
Signed-off-by: Will Murphy <[email protected]>
willmurphyscode
added
the
run-pr-quality-gate
|
This is the current qg output, which is honestly pretty good: The mariadb FPs are tricky - it's a CentOS image, and the version comparison comes down to the build numbers and digests on the end of the version, which are not really comparable between RHEL and RHEL clones. The only reason grype@latest doesn't report this vulnerability is that the modularity is wrong in the prod database for this particular vulnerability, so it's frustrating that the QG is failing because of a missed bug. Fixing the FPs is nice, but we should make sure we're actually fixing them and not like dropping the rows or something. Because this is a big change I'll also work up a diff in the data to figure out what rows are being changed at all, and how many there are. Some noise is sort of inevitable, but hopefully we'll be able to get it very close. |
Signed-off-by: Will Murphy <[email protected]>
Signed-off-by: Will Murphy <[email protected]>
Previously, both the module and package PURLs might match normalized package name, resulting in an incorrect version being returned. Instead, keep the remediation product ids in a list, not a set, so that they can be iterated in a deterministic sequence, and never return a module purl as though it were a package. Signed-off-by: Will Murphy <[email protected]>
Signed-off-by: Will Murphy <[email protected]>
Signed-off-by: Will Murphy <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR fixes #323 by introducing a configuration switch for where the RHEL provider gets fix data. In one position, it uses the OVAL XML as it previously did, and in the other, it uses the RedHat's CSAF advisories data from https://security.access.redhat.com/data/csaf/v2/advisories/ to establish fixed in data.
The original goal of this work (attempted in #758) was to drop use of the Hydra API in addition to dropping use of the OVAL XML, but that approach is blocked. In RedHat's CSAF vulnerability data, every package that incurred a version bump due a vulnerability is listed as
fixedby the corresponding Advisory. That means that some products are listed as "fixed at version 0:1.1.1" because version "0:1.1.0" was vulnerable, for example, and some are listed as "fixed at version 0:1.1.1" simply because version "0:1.1.0" was in a module that was rebuilt due to an unrelated vulnerability. In other words, a vulnerability scanner cannot assert that version "0:1.1.0" is vulnerable merely because the CSAF data say it was fixed. I have not found a way around this besides querying the old Hydra APIs and using them as guides for which products are vulnerable, and using that to choose the subset of patched packages from the RHSA that are vulnerable. This PR implements this tradeoff.It's still a draft PR because it lacks some new unit tests and other polish, but it's getting close and I wanted it available for CI runs and feedback.