Support attestations as artifacts in SPDX 3.1

[kestewart]

There is a need to be able to attest to the transformation of SBOM information from one format to another, and carry this attestation with the SBOM generated (rather than as a side car/ encapulating envelope). There are a couple of mechanisms possible.

The SBOMit project is looking at options for this, and there was a talk at OpenSSFday 2023/12 Japan on this project.

There is now an issue in the SBOMit repository to track this issue, and some preliminary analysis has been done. In terms of what we can do in SPDX we need to discuss this as a community, so opening this issue to track it here, and draw the connections.

[kestewart]

Work may need to happen in 3.1; depending on alignment of schedules, but we should agree on way this can be done in 3.0 in a way that will not make future work a breaking change at a minimum.

[goneall]

@lumjjb - Was anything similar to this requirement discussed in the build profile?

[puerco]

I'm happy to make a proposal and put in the work to get attestation support in 3.0. I think it would be a good discussion for the next security meeting.

[mlieberman85]

There is a need to be able to attest to the transformation of SBOM information from one format to another, and carry this attestation with the SBOM generated (rather than as a side car/ encapulating envelope). There are a couple of mechanisms possible.

Is there any info on why including this in the generated SBOM is needed?

[kestewart]

@mlieberman85 - see attacks that that SBOMit project is trying to make visible https://github.com/SBOMit/specification/issues/20

[mlieberman85]

I know that, I'm a TAC sponsor of SBOMit. I am just curious if we have any documentation, reasoning, etc. as to which of the attacks in SBOMit are detected or mitigated by including the attestation or a reference to it in the SBOM?

• an attacker may possess cryptographic keys for any of the functionaries (the parties performing the software supply chain steps) in the system. \ Impact: Prevents modification of items not allowed by the in-toto layout. Provides traceability in all cases. No impact without the ability to interject this metadata into the supply chain.
• an attacker may tamper with one or more steps of the software supply chain. For example, the build process, testing, packaging, etc. \ Impact: Identical to the prior case.
• an attacker obtains a sub-layout key. Note that this also requires the ability to inject sublayout metadata into the supply chain such that other parties include it. _Impact:_The impact could be prevented depending on the restrictions placed upon the delegated sub-layout. However, traceability always exists. This is also similar to a functionary compromise.
• an attacker may become a man-in-the-middle between any steps of the system. _Impact:_Without further capabilities, this has no impact.
• an attacker may possess the key used to sign the SBOM resulting from the SBOMit process. \ Impact: Prevention for parties performing full SBOMit verification. Traceability otherwise.
• an attacker may compromise an SBOM mutator key or an SBOM mutator may act maliciously. \ Impact: Traceability in all cases. Depending on the changes made to the SBOM, this may be detected by review of the resulting SBOM. Changes that override in-toto derived information are specifically flagged and unlikely to be accepted.
• an attacker is able to compromise a SIT generator key or a SIT generator directly. \ Impact: Protection for clients who obtain the SBOMit document. Traceability for other clients. Note that the SIT will contain a reference to the SBOMit document, but this also may be modified in this case. However, the client should have the in-toto layout key and so will notice this action if retrieving the SBOMit document from the SIT.
• an attacker is able to compromise the in-toto layout key, which serves as the root-of-trust for the system. \ Impact: Traceability. Later analysis can show this was the cause, but users will trust a new, maliciously generated layout which replaces signing keys.

[kestewart]

@mlieberman85 - https://docs.google.com/document/d/1wGBiAMNkeE_R4NxzzWl1UBmTCfxDbpuzwz9qs2IJ63E/edit has been shared that I think gets into the some of what you were looking for. Working in airgapped environments is highlighted in the discussions.

[kestewart]

@lumjjb, @puerco - Is a proposal likely? If not, we'll move this to 3.1 release.

[goneall]

Moving this to 3.1 since we did not get any proposals before RC2