Skip to content

Instantly share code, notes, and snippets.

@abhaybhargav
Created September 7, 2020 14:14
Show Gist options
  • Save abhaybhargav/685194c0b73a4b2433be5cfeb504314d to your computer and use it in GitHub Desktop.
Save abhaybhargav/685194c0b73a4b2433be5cfeb504314d to your computer and use it in GitHub Desktop.
Points on SCA and SBOM for Verification

Notes on CPE and SWID

  • CPE is being EOLd, resulting in SWID, which is a ISO-paywalled document (Question: Is this accurate? Because I haven't found any reference to an EOL date)
  • This has also resulted in the splintering of several Platform Vulnerability Databases:
    • Rust's DB
    • NPM for NodeJS
    • PyUP for Python

(Again, not sure if this is accurate)

CycloneDX SBOM Spec

  • Standardized SBOM spec that is platform agnostic
  • The PURL notation is meant to be a OSS replacement for CPE - meant to be simple and easy to work with
  • Currently supported by:
    • OWASP Dependency Track and other tools listed in the Tool Center
@stevespringett
Copy link

Yes, CPE is being deprecated, however, this will not happen over night. It will take time. Refer to NISTIR 8060 for some of the use cases the NVD envisions. The most obvious benefit is being able to create/register a SWID tagId before the software the SWID describes contains a vulnerability. Most often, software received a CPE only when the first vulnerability for that software is recorded. One of the benefits SWID aims to solve is this catch22 issue. SWID tags can be created/registered when the software is first published, long before the first vulnerability is discovered with the software.

NIST reps have stated on multiple occassions, publicaly, that CPE is deprecated and will be replaced by SWID. The last time I spoke with someone about a timeline, the response was 'something this summer'. That obviously has not happened, but I do think it will be something this year that a timeline will be announced by the NVD.

REST endpoint for publishing SWID tags to the NVD are already in place as well as some general tooling. Refer to https://github.com/usnistgov/swid-tools and https://pages.nist.gov/swid-tools/.

SWID is also paywalled, yes. This actually isn't a concern though. The C language spec is also an ISO standard and paywalled and it's doing just fine. The licensing concern with SWID is the distribution of the XSD to validate SWID documents. Two SWID versions exist, 2009 and 2015. The license for the 2009 version explicitly allows redistribution of the XSD as documented https://standards.iso.org/iso/19770/-2/2009/schema.xsd. The 2015 does not explicity state that redistribution is allowed as stated here https://standards.iso.org/iso/19770/-2/2015-current/schema.xsd. The NVD knows about this issue and has stated they are working with ISO for clarification. The NVD uses the 2015 version with custom schema extensions built on top of it.

The 'splintering' that you're referring to is part of a trend towards decentralized vulnerability databases. I'm not going to say whether or not that's a good idea or not, but CPE and the CNA's that registered software was centralized and designed at a time where software releases were not continuous. The NVD doesn't have the capacity to document known vulnerability in every piece of software. So NPM Audit, GitHub Advisories, etc, have all spring up to help allievate the burdon. Commercial sources such as VulnDB have been a viable alternative for years.

CPE however, cannot describe modules within a given piece of software. CPE only supports vendor, name, and version. And because CPE is centralized and created by humans the majority of the time, CPEs often do not reflect reality. See JBOSS RESTeasy for an example of that.

The advantage of PURL is that its decentralized. It can easily describe reality of software packages and do so without human intervention. It's also possible to describe non-packages. Being able to describe SWID tagIds is currently being proposed by the PURL working group.

PURL is not limited to CycloneDX. PURL is being adopted by basically everyone in the development and security space. Orgs and vendors not adopting PURL will likely not be relevant for too long. CycloneDX also supports SWID. Support for SWID in CycloneDX has a one-to-one mapping between the SWID element in CycloneDX to the SoftwareIdentity element in SWID. The tagID is one of the things that are mapped. From a licensing perspective, it is possible to use CycloneDX for vulnerability use cases using SWID tagIDs without actually having to adopt SWID. So for projects that do not want to take the changes with ISO licensing terms, CycloneDX offers an alternative way to support SWID vulnerability use cases. Complete inline SWID documents are also supported in CycloneDX similar to how license files can also optionally be embedded inline.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment