NIST NVD for CPE identifier support for BOM

[swarkentin]

I ran into an issue with the pypi dependency, webargs==5.5.2 which has a CVE in NIST NVD but was not discovered in OWASP dependency track. OSS Sonatype Index does not contain this CVE. My thoughts were to augment the BOM generated by cylonedx-python to attempt to include CPE in addition to PURL, when possible, so that vulnerabilities like this are not missed.

• Packages are already generated with a unique PURL (Package URL)
• NIST publishes CVEs in the NVD (National Vulnerability Database) using CPE (Common Platform Enumeration). A CPE, like a PURL, is used to uniquely identify a dependency — but is intended for software/hardware and not really libraries.
• This change adds a new option, -c, to the CLI which will attempt to search the NIST National Vulnerability Database API for matching python dependencies. If one is found, the corresponding CPE is added to the resulting BOM.
  • This will work for package versions that are not present in the NVD
• The number of matches found will be limited, but can save significant time reporting CVEs that are only present in NVD when uploading the BOM to tools such as OWASP Dependency Track.

[swarkentin]

I have seen a false positive for this change for pypi:docker.

The NVD search (https://services.nvd.nist.gov/rest/json/cpes/1.0?cpeMatchString=cpe:2.3:a:*:docker) returns CPEs that are not relevant to the pypi docker library.

I considered looking at the refs bit of the response to provide a clue that the CPE refers to a python library. In some cases a ref to pypi.org would indicate a python dependency.

A docker search has no ref to pypi:

        "cpes": [
            {
                "deprecated": false,
                "cpe23Uri": "cpe:2.3:a:docker:docker:1.0.0:*:*:*:*:*:*:*",
                "lastModifiedDate": "2014-07-11T16:41Z",
                "titles": [
                    {
                        "title": "Docker 1.0.0",
                        "lang": "en_US"
                    }
                ],
                "refs": [
                    {
                        "ref": "https://www.docker.com/",
                        "type": "Vendor"
                    }
                ],
                "deprecatedBy": [],
                "vulnerabilities": []
            },

A search for ruamel_yaml does include a pypi clue in the ref.

{
                "deprecated": false,
                "cpe23Uri": "cpe:2.3:a:ruamel.yaml_project:ruamel.yaml:0.10:*:*:*:*:*:*:*",
                "lastModifiedDate": "2020-02-27T21:37Z",
                "titles": [
                    {
                        "title": "ruamel.yaml Project ruamel.yaml 0.10",
                        "lang": "en_US"
                    }
                ],
                "refs": [
                    {
                        "ref": "https://pypi.org/project/ruamel.yaml/#history",
                        "type": "Version"
                    }
                ],
                "deprecatedBy": [],
                "vulnerabilities": []
            }

But another python dependency, pyxdg, does not have any ref to pypi:

{
                "deprecated": false,
                "cpe23Uri": "cpe:2.3:a:python:pyxdg:0.26:*:*:*:*:*:*:*",
                "lastModifiedDate": "2019-06-07T16:23Z",
                "titles": [
                    {
                        "title": "Python PyXDG 0.26",
                        "lang": "en_US"
                    }
                ],
                "refs": [
                    {
                        "ref": "https://pyxdg.readthedocs.io/en/latest/",
                        "type": "Project"
                    }
                ],
                "deprecatedBy": [],
                "vulnerabilities": []
            }

I am happy to see that running this against OWASP dependency track correctly matched a few CVEs in NVD that were not present in OSS Sonatype. But this change is not deterministic. Are the potential false positives worth it? Maybe...

Is there a better way to handle this? I cannot find any deterministic mapping from a purl->cpe for python libraries.

[jkowalleck]

is this related to #300 ?

[jkowalleck]

no activity for years. will close this.