[New Material] What is a quality or complete SBOM for licensing or security use cases?

[shanecoughlan]

This comes out of the conclusion of this issue: https://github.com/OpenChain-Project/Security-Assurance-Specification/issues/31

The discussion is what is a quality or complete SBOM for licensing or security use cases.

From there, the discussion can progress to "should we include that in one or both of our specs?"

Our starting point can be to review the Telco spec, which is nearly ready, and which aims to outline certain requirements related to how an entity creates, delivers, and consumes Software Bill of Materials (SBOM): https://github.com/OpenChain-Project/Telco-WG/blob/main/OpenChain%20Telco%20SBOM%20Specification.md

It contains the following fields in Section 3.2:

3.2 SPDX Elements to be included in the Telco SBOM

The following elements are REQUIRED.

Document creation information

• SPDXVersion: mandatory in SPDX
• DataLicense: mandatory in SPDX
• SPDXID: mandatory in SPDX
• DocumentName: mandatory in SPDX
• DocumentNamespace: mandatory in SPDX
• Creator: mandatory in SPDX
• Created: mandatory in SPDX
• CreatorComment: to be able to put “SBOM Build information”

Package information

• PackageName: mandatory in SPDX
• SPDXID: mandatory in SPDX
• PackageVersion: needed by “NTIA SBOM Minimum elements”
• PackageSupplier: needed by “NTIA SBOM Minimum elements”
• PackageDownloadLocation: mandatory in SPDX
• FilesAnalyzed
• PackageChecksum: recommended by “NTIA SBOM Minimum elements”
• PackageLicenseConcluded: mandatory in SPDX
• PackageLicenseDeclared: mandatory in SPDX
• PackageCopyrightText: mandatory in SPDX

A package SHOULD be identified by a Package URL (PURL).

Relationships between SPDX elements

• Relationship: at least DESCRIBES and CONTAINS, needed by “NTIA SBOM Minimum elements”

[shanecoughlan]

Proposal:

Adjust to make Generic / Agnostic towards SBOM.

Example

Elements to be included in a quality SBOM

The following elements are REQUIRED.

Document creation information

SBOM Type: required for clarity SBOM Version: mandatory in SPDX DataLicense: mandatory in SPDX TBD Name ID: mandatory in SPDX as SPDXID DocumentName: mandatory in SPDX DocumentNamespace: mandatory in SPDX Creator: mandatory in SPDX Created: mandatory in SPDX CreatorComment: to be able to put “SBOM Build information”

Package information

PackageName: mandatory in SPDX TBD Name ID: mandatory in SPDX as SPDXID PackageVersion: needed by “NTIA SBOM Minimum elements” PackageSupplier: needed by “NTIA SBOM Minimum elements” PackageDownloadLocation: mandatory in SPDX FilesAnalyzed PackageChecksum: recommended by “NTIA SBOM Minimum elements” PackageLicenseConcluded: mandatory in SPDX PackageLicenseDeclared: mandatory in SPDX PackageCopyrightText: mandatory in SPDX A package SHOULD be identified by a Package URL (PURL).

Relationships between SBOM elements

Relationship: at least DESCRIBES and CONTAINS, needed by “NTIA SBOM Minimum elements”

NOTE: Important to review "TBD Name ID" to determine precise meaning of SPDXID and generic alternative.

[shanecoughlan]

A link flagged as potentially interesting on this topic: The distinctive qualities of Software Bill of Materials https://archive.fosdem.org/2022/schedule/event/security_sbom/

[shanecoughlan]

Our known next step inside the OpenChain community is:

To review what the SPDX Lite proposal from the OpenChain Japan community covers: https://github.com/OpenChain-Project/OpenChain-JWG/blob/master/subgroups/sbom-sg/meetings/spdx-asia-telco/SPDX-Asia-Telco-20230711.pptx (See slide 25 and 26)

They have already submitted SPDX Lite for the forthcoming SPDX 3.0 specification via this pull request at the SPDX Project: https://github.com/spdx/spdx-3-model/pull/350

Compare and contrast? @NorioKobota do you have any guidance?

[NorioKobota]

Thanks @shanecoughlan, We had a meeting with SPDX community and our proposal for the meeting was documented here: https://github.com/OpenChain-Project/OpenChain-JWG/blob/master/subgroups/sbom-sg/outcomes/SPDX-Lite/Proposal_v3.0/model/LiteProfile-Requirements.md

As a result of the discussion with the SPDX WG community, one specification was added to SPDX 3.0 so that we are able to propose the SPDX Lite more simply. The minutes are left here: https://spdx.swinslow.net/p/spdx-tech-minutes

In near future, we will create a document and promote it, so we would like to coordinate with the SBOM Guideline published by Telco wg, we would appreciate your cooperation.

[Dr-wood]

@NorioKobota @shanecoughlan I do not find a promoted document that directly proposes the issue in the Software Assurance Specification discussed here in Shanes proposal Proposal: Adjust to make Generic / Agnostic towards SBOM. Example

Elements to be included in a quality SBOM

The following elements are REQUIRED. Document creation information

SBOM Type: required for clarity SBOM Version: mandatory in SPDX DataLicense: mandatory in SPDX TBD Name ID: mandatory in SPDX as SPDXID DocumentName: mandatory in SPDX DocumentNamespace: mandatory in SPDX Creator: mandatory in SPDX Created: mandatory in SPDX CreatorComment: to be able to put “SBOM Build information” Package information

PackageName: mandatory in SPDX TBD Name ID: mandatory in SPDX as SPDXID PackageVersion: needed by “NTIA SBOM Minimum elements” PackageSupplier: needed by “NTIA SBOM Minimum elements” PackageDownloadLocation: mandatory in SPDX FilesAnalyzed PackageChecksum: recommended by “NTIA SBOM Minimum elements” PackageLicenseConcluded: mandatory in SPDX PackageLicenseDeclared: mandatory in SPDX PackageCopyrightText: mandatory in SPDX A package SHOULD be identified by a Package URL (PURL). Relationships between SBOM elements

Relationship: at least DESCRIBES and CONTAINS, needed by “NTIA SBOM Minimum elements”

NOTE: Important to review "TBD Name ID" to determine precise meaning of SPDXID and generic alternative.

[shanecoughlan]

@NorioKobota and @Dr-wood it seems that our next step here may be to take the material to the Telco Work Group for inclusion in their material, while also keeping a door open to talk with the SPDX community as SPDX Lite grows. Rationale: the proposed material in this issue is related to a combination of SPDX minimum fields + NTIA requirements, and thus is complementary to but not a direct 1-2-1 match with SPDX Lite. The only outstanding thread is whether the specific fields outlined above are missing anything critical from future versions of SPDX Lite that appear necessary to all industry verticals.

[NorioKobota]

@Dr-wood, @shanecoughlan
Thanks for the comment. The following three sections describe the SBOM in Security Assuarnce Specification:

2.14 SBOM
This section describes what SBOM is.

3.3 Open Source Software Content Review and Approval / 3.3.1 SBOM
This section defines the verification points to meet the specification of having an SBOM for all software used in the supply chain and how to achieve it clearly stated.

2.1 Conponent Records
The required elements are listed here and the proposal is relevant here.

Personally, I think there needs to be a discussion about whether to include each mandatory / recommended item in the OpenChain Security Assurance Specification. Because there is an increasing number of specifications that require mandatory elements in addition to the NTIA minimum, such as the FDA specification, and there are some things that do not suit to the OpenChain specification, which defines the general process, I feel.

On the other hand, as @shanecoughlan commented, we, OpenChain Japan Team, are promoting the Lite profile for SPDX v3.0.
We are currently discussing with SPDX community and updating the JSON schema for Lite profile with the SPDX3.0 jsonld specification.

IMHO, if the SPDX 3.0 Lite Profile + Security Profile specification allows to achieve the minimal set of elements that the OpenChain community considers necessary, I think it would be better for the OpenChain specification to create guidelines on how to use it without mentioning the detail required elements.

[shanecoughlan]

As per meeting 2024-04-02, it was noted that the discussion appears to have broken into two threads.

The primary thread is:

• Some parties may want to define a quality SBOM
• There is some work to create (as per 2024-04-02) a guide to determining a quality SBOM via the Telco Work Group
• The Telco Work Group focus is SPDX + NTIA requirements

• The Specification Work Group determined that it may be useful to ensure such a guide is generic rather than tied to SPDX to represent the diversity of the supply chain

  The secondary thread is:

  • SPDX Lite + the Security Profile appears to cover all items necessary for supporting open source security assurance

The secondary thread does not contradict the primary thread, but it is a slightly different topic. The primary thread is focused on providing some feedback to the Telco Work Group regarding their currently active work on determining SBOM quality. Given the concept of SBOM quality is not inherently tied to one implementation - and arguably should not be - the call 2024-04-02 determined that the feedback previously considered should be provided, and this issue closed.