Relationships for NTIA Minimum Elements in per-RPM SBOMs

[m10k]

Hey there,

I am working on AlmaLinux's SBOM generator, extending it so that our SBOMs contain NTIA's Minimum Elements. However, I've got a couple of questions regarding relationships in SPDX documents.

In AlmaLinux, there is one SBOM for each RPM package. Let's say there is a package foo-1.0 that depends on (but does not contain) another package bar-1.1. According to [1], an SPDX SBOM conforming to the NTIA Minimum Elements needs one (or more) DESCRIBES relationship and CONTAINS relationships for each transitive dependency that is included in any of the packages described by the SBOM. In this example, the dependency is not contained in the described package, so my understanding is that I do not need any CONTAINS relationships at all. Is that correct?

The official NTIA document on the Minimum Elements [2] also uses the word "includes", which seems to correspond to CONTAINS relationships. Don't I have to include information about dependencies that are not contained in the package, but are in a separate one, as in the example above?
I thought something like Relationship: SPDXRef-Package-foo-1.0 DEPENDS_ON SPDXRef-Package-bar-1.1 would be necessary for the NTIA Minimum Elements. Is my reasoning incorrect?

Finally, RPM packages sometimes depend on other packages without specifying an exact version (or a range like bar >= 1.0 and bar < 2.0), but packages are declared with exact versions in SPDX documents. How would I describe such a relationship in SPDX?

Thank you for your help!

[1] https://spdx.github.io/spdx-ntia-sbom-howto
[2] https://www.ntia.gov/sites/default/files/publications/sbom_minimum_elements_report_0.pdf

[goneall]

I have not personally been involved in the NTIA discussions on the minimum elements, but I can offer a couple of opinions on how to apply SPDX to the scenarios described above.

@kestewart @swinslow - Please feel free to disagree or add details

... In this example, the dependency is not contained in the described package, so my understanding is that I do not need any CONTAINS relationships at all. Is that correct?

Since the dependency is not included in the distribution artifact, I agree it should not use the CONTAINS relationship.

Don't I have to include information about dependencies that are not contained in the package, but are in a separate one, as in the example above?

It would be extremally beneficial to add the DEPENDS_ON relationship - but my interpretation of the NTIA minimum is that this is not actually required since the RPM package is not actually distributing the dependency. Ideally, there will be a separate SBOM for the package that actually distributes the dependency. My recommendation would be to include these DEPENDS_ON relationships since they are known.

Finally, RPM packages sometimes depend on other packages without specifying an exact version (or a range like bar >= 1.0 and bar < 2.0), but packages are declared with exact versions in SPDX documents. How would I describe such a relationship in SPDX?

There is a separate issue documenting this need: spdx/spdx-spec#14

Since the version is actually just a string without specific validation requirements, you could capture the range in the version string itself. In your example, use >= 1.0 and < 2.0 or bar >= 1.0 and bar < 2.0 for the version.

[swinslow]

@m10k @goneall I wasn't involved in the NTIA Minimum Elements process, so my writeup in the HOWTO is my secondhand understanding of what's required :)

But yes, from that perspective, I agree with both of your reading of the NTIA report. As defined in the actual report (particularly the definition in Appendix B), "dependency" for purposes of the NTIA Minimum Elements appears to refer to components that are actually included in the target software. I wholeheartedly agree that this is different from how we might think about "dependencies" in other contexts!

So I suppose for NTIA Minimum Elements purposes, the requirement appears to be to enumerate the included dependencies. For that purpose, the CONTAINS relationship would be appropriate.

But nothing stops you from including additional relationships for other kinds of dependencies, and the DEPENDS_ON relationship would seem to fit those other instances.

[goneall]

I'll move this issue over to the new "using" repo to track documenting some recommended practices.