No FIXED-IN values for CVE findings #236
Comments
|
We can double-check this, but I believe the issue is the upstream NVD data itself. In GitHub’s data, they declare explicitly what the “FixedIn” version is for a reported vulnerability if there is one. The NVD data doesn’t do this. Through CPEs, they describe what versions are vulnerable, but they don’t explicitly list versions that are fixed. (And it wouldn’t be safe for grype to assume versions after the listed vulnerable versions have been patched.) However, one thing we find is that even though there’s no explicit field in the NVD data, the Description field (a string, usually several sentences) sometimes includes phrases like “This is fixed as of version 2.5.10". So, one option for a future feature would be to make a best-effort attempt to parse out “fixed in” data from the description string. This would be non-authoritative, and we’d need to represent it as such, but it could be useful for grype users in certain contexts. Notes for developersIn considering this strategy, it's useful to look at the JSON output from the Feeds service for NVD data. Here's an example command that returns an array of Description strings that contain "fixed in", just to help explore what kind of data we might be able to harvest: Looking at this output, you'll notice that some phrases seem very helpful:
While other phrases seem more difficult for extracting "fixed in" data:
There are also instances of the phrase "fixed in" being used to describe related software, but not the matched artifact itself (e.g. a VS Code extension that uses a binary that's vulnerable). We'd want to be careful not to include these kinds of instances, which may be hard to do. |
|
@hotpheex looks like this issue has been addressed and I'll be closing it for now - if you have other questions feel free to respond here and I'll reopen or answer. Thanks! |
|
Could this issue be reopened please? It's related to #1178 (old, fixed, vulnerabilities are passing). When comparing trivy to grype we noticed that trivy is able to report 'fixed in' versions for java archive CVEs, while grype only reported the fixed in versions for the Grype Trivy: Test image: As it turns out CVE-2020-9547 is also tracked under GHSA-q93h-jc49-78gg, so the same vulnerability is included twice in the output of grype (once with a fixed version, and once without). I think in this case it would be better to report these vulnerabilities once (like trivy does) with the fixed version filled. EDIT: using the |
ghost
mentioned this issue
|
I think this issue is worth re-opening for discussion! @jneate's comment is correct: if you look at NVD's raw data, contrary to what I said a few years back, there is machine-readable version range data in the CPE configurations worth re-examining. IIRC, back in the day we were squeamish about using the word "fixed" with NVD data, since the literal word "fixed" didn't appear in the data fields. On top of this, some version ranges were inconclusive! For example, we saw affected ranges like However, NVD also has more definitive version ranges, such as So my current thinking is that the case for not using these exclusive range ends as the |
|
Reopening this now - we have a good foundation for a way forward to possibly get more information into the database via vunnel in schema v6. I'll follow up with a more detailed comment outlining this approach in the future - thanks for the heads up on reopening this! |
|
I think inferring fixed-in information from NVD data is still problematic, not because we're squeamish about the lack of the word "fix", but because the data doesn't seem to use "cpeMatch": [
{
"vulnerable": true,
"criteria": "cpe:2.3:a:oracle:openjdk:*:*:*:*:*:*:*:*",
"versionEndExcluding": "8",
"matchCriteriaId": "111E81BB-7D96-44EB-ACFA-415C3F3EA62A"
},
... snip ...
{
"vulnerable": true,
"criteria": "cpe:2.3:a:oracle:openjdk:8:-:*:*:*:*:*:*",
"matchCriteriaId": "70892D06-6E75-4425-BBF0-4B684EC62A1C"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:oracle:openjdk:8:milestone1:*:*:*:*:*:*",
"matchCriteriaId": "7A165D71-71CC-4E6A-AA4F-FF8DB5B9A5AB"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:oracle:openjdk:8:milestone2:*:*:*:*:*:*",
"matchCriteriaId": "7417B2BB-9AC2-4AF4-A828-C89A0735AD92"
},This has a CPE match with Maybe it's possible to do clever parsing here, but we see a lot of inconsistency in how NVD represents things, so I don't think we'd be able to consistently make correct inferences. That said, now that Grype uses GHSA by default for ecosystems GHSA supports, maybe this issue is less important? |
|
This CPE data says that version 8 is vulnerable, so I wouldn't think we'd want logic that suggests that version 8 is a fixed version here, regardless. You're definitely right that there's a range of how definitive CPE data is. My suggestion would be to focus on the more definitive cases (i.e. not this one), so that we can have an incremental improvement for users, even if we won't solve the problem for every CVE.
I could missing something, but I don't think anyone is asking for changes in matching behavior here — I think this is just about the data being surfaced in existing NVD-based matches. So since matching behavior wouldn't be altered, there wouldn't be a risk of new false negatives. For example, if there were a single CPE version range of "< 8", then version 8 in an installed package shouldn't be matched to this CVE regardless of what "fix" information is being inferred. |
What happened:
Grype scan outputs contain no values in the
FIXED-INcolumn forCVE-...vulnerabilities.Is this a limitation of the tool or an upcoming feature?
What you expected to happen:
FIXED-INcolumn to output versions that remediate the vulnerability.How to reproduce it (as minimally and precisely as possible):
grype scan an image that has CVE and GHSA findings
Anything else we need to know?:
We are using the scan output and failing builds with Critical vulnerabilities, if there is a
FIXED-INvalue.Due to
CVEfindings not publishing known fixed-in values builds with many old critical vulnerabilities are passing.Environment:
The text was updated successfully, but these errors were encountered: