Switch from the "fixed + not affected" OVAL file to the "fixed + not … #635
Conversation
…affected + unfixed" See https://www.suse.com/support/security/oval/ for anchore#626 Signed-off-by: Marcus Meissner <[email protected]>
willmurphyscode
added
the
run-pr-quality-gate
|
Hi @msmeissn thanks very much for the PR! In order to merge this, we'll also need to improve Vunnel's parsing of the SUSE OVAL XML. Specifically, because the Vunnel provider was written to parse OVAL XML that only described fixed vulnerabilities, so Vunnel currently makes bad assumptions about the shape of the What I'd like to understand is this: do you all have limits on the shape of criteria trees that are emitted? The data structure looks like it can represent fairly arbitrary boolean conditions (SUSE enterprise more than 15 and (python < 3.12 or perl > 5.1)) or something. But I don't think that you actually write arbitrary boolean expression trees here. I think the data is structured like this: Is that right? For example, from the Suse 15 "affected" XML, I see: Are there other shapes we should plan to handle? |
Vulnerability criteria in the SLES parser that have an RPM version of "0:0-0" and an operator of "greater than" mean that any version of the package is vulnerable (because all packages have a version greater than zero). Therefore, emit a FixedIn with version of "None" in this case, to tell grype DB that there is no fix for this package yet. Signed-off-by: Will Murphy <[email protected]>
| @@ -142,6 +142,10 @@ def _get_name_and_version_from_test( | |||
|
|
|||
| name = name_obj.name | |||
| version = version_obj.value | |||
| if version_obj.operation == "greater than" and version_obj.value == "0:0-0": | |||
There was a problem hiding this comment.
The assumption here is this: That packages that are vulnerable in a given version of SLES, if they are affected and no patch is available, are considered vulnerable if present.
In other words, saying "PackageA is vulnerable" is always either: "All versions of PackagA are vulnerable" or saying, "PackageA is vulnerable until version 0:1.23", and we never say something like, "PackageA is vulnerable for versions greater than 0:1.23 and less than 0:2.0" or something.
Is this assumption valid @BenoitGui or @msmeissn ?
There was a problem hiding this comment.
It seems valid for me, but @msmeissn should confirm this assumption since he is the author of the code 👍
Signed-off-by: Will Murphy <[email protected]>
|
Note for next steps: This results in a fair number of new findings, so the next step is to label some vulnerabilities in vulnerability match labels, e.g.: (I plan to do this work - just writing down the next step for my own planning) |
|
@msmeissn I have some questions here: On a vulnerability listing like https://www.suse.com/security/cve/CVE-2019-20838.html, in the table "Status of this issue by product and package", I see that SUSE Linux Enterprise Server SP1 is "Released" while SUSE Linux Enterprise Server SP1-LTSS and SUSE Linux Enterprise Server SP1-BCL list "affected." I assume that means that a patch is released for SUSE Linux Enterprise Server SP1, but not for SP1-LTSS or SP1-BCL? If so, I have a question:
Knowing how to read these human-readable HTML documents will help me write tests for our parsing of the machine-readable OVAL XML, so I'd appreciate any help here. |
|
Currently the shape for the unfixed issues is in a way:
(btw, have you considered going to CSAF or so for a better standardized format which has no full logic?) |
|
Thanks @msmeissn - I was not aware that SUSE vulnerability feed was available in CSAF. |
|
https://ftp.suse.com/pub/projects/security/csaf/ indexed by patches (only released updates) |
so this is a bit challenging to understand I have to admit.
|
…affected + unfixed"
See https://www.suse.com/support/security/oval/