Question: Support of multiple SBOM formats.

[dn-scribe]

Hi,
I'm new to the conversation, hope not repeating a closed issue (didn't find such):
The current SPDX predicate is SPDX specific. This does not comply to the "separating statement from predicate" goal; suppose one wishes to use CycloneDX; she would need to define a new predicate "cyclonedx". Thus a policy engine cannot query "was an SBOM attestation created?", without parsing the actual sbom object.

An alternative would be:
predicate type: sbom
predicate {
sbom_type: <spdx, cyclonedx,...>
sbom body :
}

What am I missing?

[dn-scribe]

Sorry for the confusion, what I meant was : Thus a policy engine cannot query "was an SBOM attestation created?" without caring about the SBOM format.

[MarkLodato]

What you are suggesting is a trade-off: add complexity in the general use case (having to check two separate type fields every single time you use the attestation) in order to make one particular check easier (predicateType == "sbom" vs predicateType in ["spdx", "cyclonedx", "swid"]).

I don't know enough about the SBOM ecosystem to know whether that trade-off is valuable, but my guess would be that it is not worth the complexity. Having to check three possible types instead of one doesn't seem particularly onerous to me. Would that work for you?

Happy to hear feedback from other SBOM users as well.

[dn-scribe]

Of course checking three possibilities is not an issue; but since the SBOM ecosystem is young, suppose someone comes up with a forth possibility; even the simple policy "Is there an SBOM" will have to be modified.

In similar cases it would be a more serious problem. Suppose an attestation regarding a source control platform. In this case we would have an attestation for GitHub, CircleCI, TravisCI and it is obvious that in the future there will be other vendors. Again, it would be convenient to test that there exists an authorized attestation while decoupling the specific platform.
As I understand, the ability to do such attestations without any knowledge about the predicate's content is the main idea behind separating statement from predicates (https://github.com/in-toto/attestation/blob/main/README.md#reasoning).
So I do suggest to modify the SBOM attestation format while it is still young.

[MarkLodato]

Again, this adds complexity. It's not free. Could you expand on why someone will want to check that an SBOM exists, even in a format they don't recognize? Wouldn't they also need to check that it meets some sort of minimum criteria, in which case they need to parse it?

Note that this sounds somewhat similar to #2, which talks about a generic "inheritance" or "subtype" model.

Regarding source control platform attestations, I'm failing to understand the relation to this issue. That sound sound to have anything to do with SBOM. Plus, our intent is to create a standard, vendor-neutral predicate type (#47).

[dn-scribe]

Regarding the spdx vs sbom:
I'm following the logic in the reasoning section of the in-toto attestations - mentioned there is a generic requirement to test validity of attestations (i.e. that the attestation exists and was signed by an authorized entity), without knowing the predicate structure.

I think this logic is fine an recommend not to shortcut it.
So why not assume there may be a similar need for SBOMs.

A concrete example would be compliance to government regulations that will require SBOMs. As a software producer I would check that I have produced the valid SBOM attestation. It is the responsibility of the government agency to actually do something with the SBOM.

Another example would be SLSA compliance - the provenance requirements section. Most requirements are existence requirements.

A separate use of the type would be indexing for later use - again - it would be better to index by an abstract type (sbom) and not by a specific sbom-format.

Regarding source control - this was an example. I was trying to make an analogy between "spdx, spdx-lite, cycloneDX..." and "GitHub, CircleCI, TravisCI ...". Being vendor neutral is closely related (in some aspects) to being, format neutral.

Hope I made myself clear

[dn-scribe]

A note to what I've written above: Although the SLSA example is of provenance and not SBOM, the same logic applies - we see that requiring an attestation without verifying it's content is common.

[marcelamelara]

Closing, since we now have predicates defined for both SPDX and CycloneDX.