Support for common platform enumerations (CPEs) in SBOM files

[LesSyner]

Currently trivy doesn't include common platform enumerations (CPEs) info in the SBOM files generated [trivy only generates package urls (purls) for components]. This is an issue for some tools like Dependency-Track which use these fields to find vulnerabilities. As a result SBOM files uploaded to Dependency-Track result in no vulnerabilities found. By contrast other tools like syft include these fields and Dependency-Track can find vulnerabilities.

Do you have plans to include common platform enumerations (CPEs) in SBOM files generated by trivy?

Example:

trivy image -f cyclonedx ubuntu:22.04

 {
  "bom-ref": "pkg:deb/ubuntu/[email protected]?arch=amd64\u0026distro=ubuntu-22.04",
  "type": "library",
  "supplier": {
    "name": "Ubuntu Developers \[email protected]\u003e"
  },
  "name": "apt",
  "version": "2.4.10",
  "licenses": [
    {
      "license": {
        "name": "GPL-2.0"
      }
    }
  ],
  "purl": "pkg:deb/ubuntu/[email protected]?arch=amd64\u0026distro=ubuntu-22.04",
  "properties": [
    {
      "name": "aquasecurity:trivy:LayerDiffID",
      "value": "sha256:dc0585a4b8b71f7f4eb8f2e028067f88aec780d9ab40c948a8d431c1aeadeeb5"
    },
    {
      "name": "aquasecurity:trivy:PkgID",
      "value": "[email protected]"
    },
    {
      "name": "aquasecurity:trivy:PkgType",
      "value": "ubuntu"
    },
    {
      "name": "aquasecurity:trivy:SrcName",
      "value": "apt"
    },
    {
      "name": "aquasecurity:trivy:SrcVersion",
      "value": "2.4.10"
    }
  ]
},

syft -o cyclonedx-json ubuntu:22.04

{
  "bom-ref": "pkg:deb/ubuntu/[email protected]?arch=arm64&distro=ubuntu-22.04&package-id=7b1897f37c30c5a5",
  "type": "library",
  "publisher": "Ubuntu Developers <[email protected]>",
  "name": "apt",
  "version": "2.4.10",
  "licenses": [
    {
      "license": {
        "id": "GPL-2.0-only"
      }
    },
    {
      "license": {
        "name": "GPLv2+"
      }
    }
  ],
  "cpe": "cpe:2.3:a:apt:apt:2.4.10:*:*:*:*:*:*:*",
  "purl": "pkg:deb/ubuntu/[email protected]?arch=arm64&distro=ubuntu-22.04",
  "properties": [
    {
      "name": "syft:package:foundBy",
      "value": "dpkgdb-cataloger"
    },
    {
      "name": "syft:package:metadataType",
      "value": "DpkgMetadata"
    },
    {
      "name": "syft:package:type",
      "value": "deb"
    },
    {
      "name": "syft:location:0:layerID",
      "value": "sha256:61bbeda53374249345217a09cd78040f124ef8bc07a1612a1a186d2468f67d54"
    },
    {
      "name": "syft:location:0:path",
      "value": "/usr/share/doc/apt/copyright"
    },
    {
      "name": "syft:location:1:layerID",
      "value": "sha256:61bbeda53374249345217a09cd78040f124ef8bc07a1612a1a186d2468f67d54"
    },
    {
      "name": "syft:location:1:path",
      "value": "/var/lib/dpkg/info/apt.conffiles"
    },
    {
      "name": "syft:location:2:layerID",
      "value": "sha256:61bbeda53374249345217a09cd78040f124ef8bc07a1612a1a186d2468f67d54"
    },
    {
      "name": "syft:location:2:path",
      "value": "/var/lib/dpkg/info/apt.md5sums"
    },
    {
      "name": "syft:location:3:layerID",
      "value": "sha256:61bbeda53374249345217a09cd78040f124ef8bc07a1612a1a186d2468f67d54"
    },
    {
      "name": "syft:location:3:path",
      "value": "/var/lib/dpkg/status"
    },
    {
      "name": "syft:metadata:installedSize",
      "value": "3956"
    }
  ]
},

[knqyf263]

I don't think such CPE is defined.
https://nvd.nist.gov/products/cpe/search/results?namingFormat=2.3&keyword=cpe%3A2.3%3Aa%3Aapt

It just generates CPE-ish strings. We're not sure if it is useful to generate non-existent CPEs.

[LesSyner]

This was just an example so please treat it as such.
Main thing is that thanks to CPE fields other tools like Dependency-Track can find vulnerabilities. Currently SBOM generated by trivy using command "trivy image -f cyclonedx ubuntu:22.04" uploaded to Dependency-Track gives 0 vulnerabilities while SBOM with the same PURL fields but additionally with CPE fields results in ability to find them.

[LesSyner]

As you know CPE points to app/library and it's version. It's natural that if you have new version of the app/library it will be unknown to NVD if you don't add new entry in NVD for it. So in this case adding CPE to SBOM is one thing and it's in general independent of adding entry to NVD, IMO it's not valid argument that in the time of writing SBOM there is no such entry in NVD when in fact it's only matter of time (especially in case of new official Ubuntu packages, like in this example). As you can see yourself NVD CPE dictionary is changing very often: https://nvd.nist.gov/products/cpe/statistics .

[LesSyner]

@knqyf263 BTW it's just another bad luck for me to provide example with such package because in fact apt package has different CPEs defined. As you can see when we take CVE-2020-27350 as one of CVEs affecting apt, CPEs are defined as cpe:2.3:a:debian:advanced_package_tool for Debian and as cpe:2.3:o:canonical:ubuntu_linux for Ubuntu. But anyway in my opinion it's rather the choice of proper CPEs per package (with apt being unusual one) than general question if CPEs should be included. CycloneDX specification has definition of such property (https://cyclonedx.org/docs/1.5/json/#components_items_cpe).

[knqyf263]

You can read why CPE is challenging.
https://owasp.org/assets/files/posts/A%20Proposal%20to%20Operationalize%20Component%20Identification%20for%20Vulnerability%20Management.pdf

[LesSyner]

I get your point and totally understand it. PURLs are maybe better but suffer the same problem - they are constructed by end-user or tools so also may be constructed improperly resulting in false positives or negatives when it comes to vulnerabilities. Here is one of examples from DependencyTrack/dependency-track#1871 :
pkg:maven/org.apache.bcel/[email protected] is properly constructed purl but GHSA has pkg:maven/xalan/[email protected]. Therefore, it is Dependency-Track misses the CVEs related to this package.
Similarly my SBOM from trivy image -f cyclonedx ubuntu:22.04 has PURLs for all 102 packages and they are verified with Sonatype OSS Index and GitHub Vuln DB but with 0 CVEs as a result compared to standard scan where trivy and grype both find 21 vulnerabilities.

[LesSyner]

My point is that no mechanism is ideal so providing both purl and CPE would be better than providing only one and narrowing possibilities of usage of trivy-generated SBOM files in other tools (including Dependency-Track as popular and OWASP project)

[peterloron]

I am also running into this issue. The naming problem is very hard, but adding CPE to trivy would be helpful.

[wkoot]

Perhaps there could be an option to link CPE's without solving the naming problem within Trivy?
If the scan identifies vulnerabilities, can't the CVE be used to look up it's respective CPE? Maybe as a feature flag only?
This would be far from ideal, as it might offer a false sense of security, but may be addressed like composition.aggregate.

It is my understanding that having the CPE should aid in finding CVE's. However, there often is no unique CPE due to naming problem..
On top of that, I don't see any unified search option either. For example, the (partial) CPE cpe:/a:microsoft:internet_explorer yields:

• 55 CVE's on cve.mitre.org
• 109 records on nvd.nist.gov which all have their own lists of CVE's

Then, for instance, taking the first NVD resultset for cpe:2.3:a:microsoft:internet_explorer:-:*:*:*:*:*:*:* yields:

• 99 CVE's on nvd.nist.gov
• 0 CVE's on cve.mitre.org

Okay, so, the CVE.org FAQ page that referred me to the keyword search actually points out it searches Description fields ONLY.
Inspecting the resultset from CVE.org shows that they actually have nothing to do with Internet Explorer, probably fuzzy matching?

So how are we supposed to search by CPE exactly? And how can we know the answer is trustworthy and exhaustive?
This seems elusive, as it is not clear who is or should be authorative on this search as advertised (see also: NVD backlog).
Using the earlier cpe:2.3:a:microsoft:internet_explorer:-:*:*:*:*:*:*:* on some random google hits, I find:

• 6 CVE's on cvedetails.com
• a list plus "1784 more entries" on vuldb.com (manually fill in search string)
• a lot of websites that seem even more useless than these

But now I'm left wondering as to how I'm supposed to search CVE's by purl, which Trivy does return, instead?
I generally agree with the argument that purl is conceptually smarter than CPE, but this falls through when it isn't usable.
As a simple user, I can't even see the business case of a paid-for-service or product in this matter.
Is this discussion a point of interest for Aqua Security / Trivy? Or is there a better solution on the horizon?

[LesSyner]

Good idea @wkoot but please remember trivy can also produce SBOM with list of components without checking vulnerabilities so using only link between cpe and purl in each CVE can be only partial idea.
On the other hand as I have shown in the example in first post there are other apps like syft which create reports with both cpe and purl. And at least syft is open-source, So if there is a will to implement this there is a place to look at as a starter. Maybe their idea is ok, maybe needs some tweaking, maybe it will be good start to create something totally new. But you have some start option. I'm not a programmer so it's not option for me but I try to bring the issue to the front so others may step in or we can convince current developers to implement this.