[Discussion] Documenting SIT specification to SBOM generated fields for tracibility

[idunbarh]

This issue is to document our discussion today (Dec 13th 2023) at the SBOMit community meeting.

We discussed what properties are required in an SBOM format to allow it to meet SBOMit phase 1 and phase 2 verification. A SBOMit compatible SBOM format is referred to as a SIT.

• SIT: refers to an SBOM (Software Bill of Materials) that has been derived from an SBOMit document. It can be formatted in any SBOM style and references the originating SBOMit document used for its creation.

SIT Required Fields

• Identifiers
  • Component/Packages must of a digest field which supports the same digests as outlined in the in-toto DigestSet field
• In-toto Attestation Storage
  • Attestations can be stored directly within an SBOM
  • Attestations can be stored externally to the SBOM and referenced by URL
• In-toto Layout Storage
  • Layouts can be stored directly within an SBOM
  • Layouts can be stored externally to the SBOM and referenced by URL
• Component/Package to Attestation References
  • Each component/package has a reference to one or more attestation(s)
  • References should be able to support URLs for externally stored attestations and within the same document

We want to explicitly call out many to many relationships are required between components/packages and attestations.

• Multiple attestations could reference the same materials/products.
• Multiple materials/products may be reference in the same attestation

Planned Fields For Common SBOM Formats

SPDX

• targeted Version: TBD
• (2.3+) Package checksum field
• (2.3 +) External reference field

Needed Fields

• We need a method to store in-toto attestation json files directly within the SPDX formation. We could overload annotations but it doesn't seem like an ideal solution.

CycloneDX

• targeted Version: 1.6
• (1.2 +) hashes
• (1.6 +) Evidence is being added as part of Standards and Attestation support.
  • Evidence supports base64 encoded data to be stored directly within the SBOM using the evidence.data.contents.attachment field.
  • Evidence supports url reference to external resources using the evidence.data.contents.url
• (1.5 +) External Reference of attestation Type
  • A bomlink can be used for an internal reference to a component of data type
    • references
      • https://cyclonedx.org/guides/sbom/data_components/
      • https://cyclonedx.org/guides/sbom/external-references/
      • https://cyclonedx.org/guides/sbom/linking/

Needed Fields

• N/A

[kestewart]

Have added an issue in the SPDX spec repository to track this issue, and get input from the rest of the SPDX community.

[idunbarh]

Phase 1 trade off for attestation location.

• https://docs.google.com/document/d/1wGBiAMNkeE_R4NxzzWl1UBmTCfxDbpuzwz9qs2IJ63E/edit

[idunbarh]

#24 documents the decision of what to do for SBOMit Phase 1 while storage mechanisms for Phase 2. Big thanks to @yzhang71 for documenting the decision. Lets keep this issue open to document progress in Phase 2.

Phase 2 still requires storing the attestations within an SBOM.

I'll update the options here with @stevespringett recommendation of using a bomlink to a separate component of data type.