search

spack / spack-sbom

Generate a software bill of materials (SBOM) for a spack package
2 stars 2 forks source link

Support for NIST SWID Tagging or CPE designation #1

Open rmadamson opened 2 years ago

rmadamson commented 2 years ago

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 https://github.com/CycloneDX/cyclonedx-maven-plugin/issues/67

vsoch commented 2 years ago

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 commented 2 years ago

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 zlib@1.2.8 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 commented 2 years ago

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.