How to track CPEs in ORT?

[sschuberth]

In addition to PURLs, from time to time there are inquiries to also track CPEs in ORT's data model, e.g. in order to let the advisor query vulnerability providers that only understand CPEs.

Open questions:

• Should we track CPEs at all?
• Should a CPE be a top-level Package-property like purl? Or should both be merged into an "external reference" concept similar to SpdxExternalReference?
• Should the analyzer instead try to convert CPEs given in package metadata to PURL, e.g. via VulnerableCode like @pombredanne has mentioned?

[heliocastro]

As middle of 2019, UE instituted a regulation for automotive industry related to cibersecurity. https://unece.org/sustainable-development/press/un-regulations-cybersecurity-and-software-updates-pave-way-mass-roll

Because of that, we need to track it down security related issues in our software anyway, and we are relying on CPE strins to track CVE advisories, as nothing else exists right now, and i don't see alternative initiatives.

So, even not tracking now, this questions will bite back again and again as Ort usage is increasing tenfold lately.

[oheger-bosch]

Some thoughts:

I like the idea of having external references, this seems to be pretty flexible. I assume we would then have an enumeration like ReferenceType, and packages would contain a Map from ReferenceType to String, correct?

If a package manager can provide the CPE directly (as may be the case for SPDX), it should do so. It would be possible to have a post-processing step to generate/retrieve missing CPEs using an external source. As this may slow down the analyzer step, this should probably be an optional step that can be enabled if this information is needed.

[pombredanne]

Some comments:

1. in general and IMHO tracking CPE is a good thing. For instance we track these as references in VulnerableCode. They are far from great as identifiers especially for open source packages, but they have the merit to exist.
2. VulnerableCode was started in part because CPEs are weak when it comes to open source packages
3. Package URLs are an effective (emerging) alternative for open source packages packages adopted in many places such as OWASP including more recently in the OSSF OSV schema and the CSAF Vex schema. So they are always a good choice IMHO.
4. VulnerableCode ends up being also a CPE<-> purl translator since we track both; we have a script that can effectively dump a translation between the two. You can see an example run in https://raw.githubusercontent.com/sbs2001/purl2cpe/master/2020.json

[oheger-bosch]

So from the comments on this ticket, the tendency seems to go into the direction of adding support for CPEs to ORT's data model. Shall I create a proposal PR how this could look like?

[sschuberth]

Shall I create a proposal PR how this could look like?

I would be fine with this, yes. Maybe we could start together.

[dineshr93]

HI @heliocastro @sschuberth is there any standard way for computing cpe id's. I personally feel each company is creating their own standard for computing the cpe id's

for example https://github.com/oss-review-toolkit/ort/blob/e1932bac862adae31868069b2b5dd6b48c660d48/plugins/package-managers/spdx/src/funTest/assets/projects/synthetic/libs/zlib/package.spdx.yml#L19 above zlib cpe is coming from compress but the url shows it is taken from standard site https://github.com/oss-review-toolkit/ort/blob/e1932bac862adae31868069b2b5dd6b48c660d48/plugins/package-managers/spdx/src/funTest/assets/projects/synthetic/libs/zlib/package.spdx.yml#L16

for which the actual cpe id computed from official nvd cpe site is cpe:/a:zlib:zlib:1.2.11

In official-cpe-dictionary_v2.2.xml below we can see the actual

  <cpe-item name="cpe:/a:zlib:zlib:1.2.11">
    <title xml:lang="en-US">zlib 1.2.11</title>
    <references>
      <reference href="https://github.com/madler/zlib">Version</reference>
      <reference href="http://www.zlib.net/">Product</reference>
      <reference href="http://www.zlib.net/ChangeLog.txt">Version</reference>
    </references>
    <meta:item-metadata nvd-id="396307" status="FINAL" modification-date="2022-06-22T16:40:44.440Z"/>
  </cpe-item>

So that means the wrong cpe id will not show any vulnerabilities when compared with the nvd database. is there any standard/automated way to compute the cpe id (from pkg managers if available) for it to be really beneficial ?

Thanks

[sschuberth]

That's the problem with CPEs, there is no common standard to compute them. Actually, CPEs have to be registered, similar to license plates for vehicles. Which means you first have to look up whether there is an official CPE registered for the software product you want to query vulnerabilities for. Which in turn means you cannot look up vulnerabilities for a product which doesn't have a CPE... quite pointless if you ask me.