Add ability to document known NIST vulnerability information in SPDX documents

[kestewart]

Use Case: At a point in time, an auditor wants to be able to document what vulnerability and/or weakness information is known about a specific software deliverable (product, package, component, etc.) The NIST database is the standard here where the information is generally extracted from. It would be helpful to enable people to capture the relevant fields for accurate understanding.

IonChannel's SEVA has a version of this information included that we need to confirm with NIST is the relevant. Vulnerability Information from SEVA XML - Section 7

This information needs to be reviewed and a section created in SPDX document to track this.

[stevespringett]

Kate, here are some additional thoughts. This may be a lot more challenging than it seems if we want this to actually be useful to people.

• The majority of publicly disclosed vulnerabilities do not have CVEs in the NVD. They are disclosed by some other means: commit message, change log, social media, decentralized vulnerability intelligence source, etc
• Decentralized sources of vulnerability intelligence such as NPM Audit, .NET Retire, Retire.js and others are easy to link to, and often contain vulnerabilities not listed in the NVD.
• Major providers are in the process of making decentralized vulnerability intelligence more common place. Fast forward a few years, there will be even less incentive to publish to the NVD than there is today.
• Commercial sources of vulnerability intelligence, such as VulnDB, typically have thousands of vulnerabilities every year that are not published in the NVD. I believe in 2017 for example, their database added 6000 vulnerabilities in that timeframe that are not listed in the NVD. This information is licensed and inclusion may violate terms.

If SPDX adopts this feature, I believe the implementation would need to account for these things if we want it to be useful:

• Support for centralized and decentralized sources of vulnerability intelligence
• Support for public and private (licensed) vulnerability content

With regards to the statement of weakness information. This is a bit of an open-ended requirement. I've written a document for OWASP (currently draft) which outlines 10 unique risk factors that may affect a component. https://www.owasp.org/index.php/Component_Analysis. Some of these may apply to BOMs, others will not.

One final thought. Do we want this feature in a BOM or do we want to produce BOMs with highly accurate metadata that would facilitate the automated analysis of them in the future. For example, this is what organizations using CycloneDX BOMs with Dependency-Track are doing today:
https://www.youtube.com/watch?v=FWOCX7wEAzI
https://www.youtube.com/watch?v=nZakPU0wJMo

Dependency-Track also supports SPDX (tag/rdf). However, in order for SPDX to do what CycloneDX is doing today, it needs to support a large number of ecosystems, produce highly accurate metadata which can be analyzed, and support Package URL.

IMHO, if SPDX focused on high-quality implementations producing high-quality metadata useful in component analysis, and implemented #53, it will be a lot more useful to the auditor than attempting to include vulnerability and other weakness information in the BOM itself.

Apologies for being overly verbose.

[kestewart]

Based on discussion in weekly meeting, we're moving this into 3.0 so it aligns better with the base + security profile.

[kestewart]

@tsteenbe - see comments from Steve above.

[karsten-klein]

I had a look at the current security profile (google doc proposed by @tsteenbe on https://wiki.spdx.org/view/Technical_Team/Minutes/2020-05-26).

In fact it was not quite, what I expected. It took me a while to get my head around this, but I argue as follows:

• basically SPDX is a way to attribute software assets of different types. An asset has different attributes including license information (I'm not going into detail here, you all know that part than most people on this planet)
• a software asset (in its given version) may have vulnerabilities. But in contrast to licenses this is dynamic information. At release time the vulnerabilities may not be known. They are detected once the artifact is placed into production and inspected over time.
• me as a consumer of the artifact, I would like to query at any time the current vulnerabilities. Static information is nice, but does not cover the full story.
• me as consumer would like to make an exact query and assess the vulnerabilities in my usage context / business case. For this I would need the exact coordinates of the software artefact in the different vulnerability databases. This - for me - is the primary information. This would mean I would be grateful if the vendor or curator would attach the proper product enumerator to the artifact (e.g. one or more CPE for the NVD case). With this can access the secondary pieces of data: the vulnerabilities and then add the information I'm most interested in and need to anticipate in my business case: the vulnerability assessment.

Putting a long story short. I regard focussing on the vulnerability and weakness information is not sufficient. We need ways to attach CPEs (or the like) to assets, we need to aggregate CVEs (or the like) for an asset, we need to capture vulnerability assessment information, and we must understand how this data ends up in a consumer (and machine) readable and useful documentation (BOM, SBOM, Asset Annex, Compliance Artifact, whatever you want to call it)

Just 2 cents on friday evening. I'm happy to go into discussions and SPDX alignments here. We can also shows our current approach if there is interest.

Regards,
Karsten

[kestewart]

This has been handled in 2.3 as https://spdx.github.io/spdx-spec/v2.3-RC1/how-to-use/#k19-linking-to-an-sbom-vulnerability-report-for-a-software-product-per-nist-executive-order-14028.