Support for NIST SWID Tagging or CPE designation

[rmadamson]

There are a couple of identifiers for software that would be nice to include in SBOM output somehow. This will help security teams link installed software to vulnerabilities that have been discovered in underlying libraries, etc.

Two identifiers come to mind, but there may be other, better options. The first option is to leverage Common Platform Enumerations (CPE) that are maintained by NIST. They take the form of something like: cpe:2.3:a:openssl:openssl:1.0.1m:*:*:*:*:*:*:* for openssl version 1.0.1m, and would probably need to be strictly defined in package.py metadata for each spack package since CPEs are not programmatically generated. I think the industry is moving away from these however, but a lot of security tooling in use today is still CPE focused.

The other option would be to create software id (SWID) tags which are more fully-featured xml objects with tagId fields. They look something like this, buried in SWID xml:

<Link
    rel="related"
    href="swid:com.acme.rms-ce-v4-1-5-0">

SWIDs aren't widely adopted yet, but I suspect they would be in the next few years.

Here are some additional references I found useful while thinking about this issue:
https://cpe.mitre.org/
https://csrc.nist.gov/Projects/Software-Identification-SWID/guidelines
CycloneDX/cyclonedx-maven-plugin#67

[vsoch]

hey @rmadamson ! If the CPE is going away, then probably it wouldn't be the top choice - however if you think it will remain to have an important focus I don't see why we couldn't look into a way to generate for spack. The SWID I do think will persist so this would be cool to add. I'm pinging @tgamblin to get his thoughts, and what that would mean practically (work to be done in spack) before we could just use it here.

[rmadamson]

Thanks @vsoch!

I've come across a good example vulnerability (using zlib, of course!):

https://nvd.nist.gov/vuln/detail/CVE-2016-9840

One of the common platforms affected by this vulnerability is cpe:2.3:a:gnu:zlib:1.2.8:*:*:*:*:*:*:*, which indicates that [email protected] is vulnerable. There are some obvious issues with this CPE scheme even though it is widely used: I don't think that zlib is actually part of the GNU suite of tools, and presumably one or more versions of zlib < 1.2.8 also had this same vulnerability apply to it.

[vsoch]

Interesting! So if this would be easy to add to spack (e.g., some property on a spec to generate the cpe and then swid) then I don't see why we couldn't include both. Let's wait for the grandmaster wisdom for some discussion around that.