cve-bin-tool
cve-bin-tool copied to clipboard
intel
Name collision with "docutils"
I'm testing the new cve-bin-tool action on a personal repo and got a warning about https://nvd.nist.gov/vuln/detail/CVE-2022-23602 which is claimed was from Sphinx.
It is true that Sphinx uses a package called docutils, but that CVE is for a docutils written in an entirely different language (nim). In this case, we're getting Sphinx out of a requirements.txt file so we know it's a python dependency, so we could avoid a false positive and skip this CVE. Sphinx is a very popular python library used for building docs for Read The Docs so I expect a lot of python open source projects would encounter this bug, so I'd rather we fix it in cve-bin-tool rather than recommend people do a workaround with triage (although obviously that'll work short-term)
We've talked a lot about using metadata and de-duplicating results from NVD, but I don't think we've built any of that framework yet. Now might be a good time to figure out how to store and use at least a rudimentary de-duplication table so we can fix this one false positive.
I don't know if I should file a separate bug but I see a lot of collisions in sboms I have because composer have hierarchy in package names. e.g. the CDX sbom has something like this:
{
"bom-ref": "data-values/common-1.1.0.0",
"type": "library",
"name": "common",
"version": "1.1.0",
"group": "data-values",
"description": "Contains common implementations of the interfaces defined by DataValuesInterfaces",
"author": "Jeroen De Dauw",
"licenses": [
{
"license": {
"id": "GPL-2.0-or-later"
}
}
],
"purl": "pkg:composer/data-values/[email protected]",
"externalReferences": [
{
"type": "distribution",
"url": "https://api.github.com/repos/DataValues/Common/zipball/9f5e6216ec66ac8f2281351b110bad0eded43e65",
"comment": "dist reference: 9f5e6216ec66ac8f2281351b110bad0eded43e65"
},
{
"type": "vcs",
"url": "https://github.com/DataValues/Common.git",
"comment": "source reference: 9f5e6216ec66ac8f2281351b110bad0eded43e65"
},
{
"type": "website",
"url": "https://github.com/DataValues/Common",
"comment": "as detected from Composer manifest 'homepage'"
},
{
"type": "chat",
"url": "irc://irc.freenode.net/wikidata",
"comment": "as detected from Composer manifest 'support.irc'"
},
{
"type": "issue-tracker",
"url": "https://github.com/DataValues/Common/issues",
"comment": "as detected from Composer manifest 'support.issues'"
},
{
"type": "vcs",
"url": "https://github.com/DataValues/Common/tree/1.1.0",
"comment": "as detected from Composer manifest 'support.source'"
}
],
"properties": [
{
"name": "cdx:composer:package:distReference",
"value": "9f5e6216ec66ac8f2281351b110bad0eded43e65"
},
{
"name": "cdx:composer:package:sourceReference",
"value": "9f5e6216ec66ac8f2281351b110bad0eded43e65"
},
{
"name": "cdx:composer:package:type",
"value": "library"
}
]
}
It's a php library unfortunately called "common" but it's part of a very distinct group (it's quite common to have library like this in php and npm). That leads to CVE tool responding with this:
[15:13:03] DEBUG cve_bin_tool.CVEDB - Multiple vendors found for common cvedb.py:499
DEBUG cve_bin_tool.CVEDB - common - doctrine-project cvedb.py:501
DEBUG cve_bin_tool.CVEDB - common - phpoffice_project cvedb.py:501
DEBUG cve_bin_tool.CVEDB - common - nimble-project cvedb.py:501
[15:13:04] DEBUG cve_bin_tool.CVEDB - Multiple vendors found for time cvedb.py:499
DEBUG cve_bin_tool.CVEDB - time - time_project cvedb.py:501
DEBUG cve_bin_tool.CVEDB - time - ruby-lang cvedb.py:501
DEBUG cve_bin_tool.CVEDB - Multiple vendors found for elasticsearch cvedb.py:499
DEBUG cve_bin_tool.CVEDB - elasticsearch - elasticsearch cvedb.py:501
DEBUG cve_bin_tool.CVEDB - elasticsearch - elastic cvedb.py:501
DEBUG cve_bin_tool.CVEDB - elasticsearch - anynines cvedb.py:501
(and many more)
And now I'm drowned in CVEs:
╭─────────────╮
│ CVE SUMMARY │
╰─────────────╯
┏━━━━━━━━━━┳━━━━━━━┓
┃ Severity ┃ Count ┃
┡━━━━━━━━━━╇━━━━━━━┩
│ CRITICAL │ 204 │
│ HIGH │ 320 │
│ MEDIUM │ 41 │
│ LOW │ 18 │
│ UNKNOWN │ 2 │
└──────────┴───────┘
Yeah, we're working on that in #3771
You can work around it for now by putting in a PURL identifier in to the common entry so it bypasses the "search for any product with the same name" search and directly looks for the relevant package. But it's definitely on the roadmap to fix.
Hm, wait, I see you already have a purl in there. That's supposed to over-ride, I wonder if it doesn't because it doesn't find a match? We might need a better work-around.
Let me know if I can or should provide more context to allow reproducing the issue.
@Ladsgroup thanks! I think we've got a good idea of what's happening here, it's jsut going to require a whole de-dupe database to fix and that requires some architecture work.
Should be resolved by #4164
Output for running the tool against requirement.txt having only one entry: sphinx:
