Document canonical CycloneDX intoto predicate types

[sambhav]

Although in-toto/attestation#82 is still open, meanwhile we can document the canonical intoto predicate types in the cyclonedx website since there is no registration process for predicate types. (per https://github.com/in-toto/attestation/blob/main/spec/README.md#predicate)

This would allow tools like cosign, kyverno, syft, grype etc. to have a single canonical predicate type that they can use to identify cyclonedx BOMs.

The suggestion from in-toto/attestation#82 was to use https://cyclonedx.org/BOM or https://cyclonedx.org/bom (we should pick one given that these are case sensitive)

Separately, something to think about is how we can uniquely identify VEX from SBOMs for eg if everything is the same predicate type.

Kyverno for eg. allows users to filter on the predicate type https://kyverno.io/docs/writing-policies/verify-images/#verifying-image-attestations

Given that the SBOM would be mainly static and the VEX will be more dynamic, would we want an easy way to filter for one or the other through different predicate types i.e. - use

https://cyclonedx.org/bom for the generic case where all different kinds of BOMs are present in the same document, but separately allow something like https://cyclonedx.org/vex
or https://cyclonedx.org/sbom to filter out documents that only have a top level vulnerabilities or software components attribute defined?

Kyverno is also able to filter out the attestations further down the line using JMESPath expressions https://kyverno.io/docs/writing-policies/jmespath/ but it might be nice to have a top level predicate type filter for different BOM types.

Regardless of the outcome, we should at the very least document the canonical predicate type to be used since the usage for attestations is gaining traction and we should get ahead before there is a lot of disparity in the landscape on which predicate type to use for cyclonedx BOM documents.

More details around the valid values for a predicate type are defined at https://github.com/in-toto/attestation/blob/main/spec/field_types.md#TypeURI

[chipzoller]

+1 this is needed

[stevespringett]

I personally favor https://cyclonedx.org/bom as it closely aligns to the XSD and JSON Schema of the spec.

I am not in favor of predicates that define the content of the BOM. For example, a BOM may include software components, hardware components, services, vulnerabilities, and VEX. Future versions will include ML, LCAP, and configuration.

So I am not in favor of:

https://cyclonedx.org/hbom
https://cyclonedx.org/sbom
https://cyclonedx.org/saasbom
https://cyclonedx.org/obom
https://cyclonedx.org/advisory
https://cyclonedx.org/disclosure
https://cyclonedx.org/vex

Having a BOM with vulnerabilities also doesn't mean its a VEX. A VEX has a specific definition and structure which most security tools do not support today. It requires vulnerabilities to have an analysis with the required fields populated, and the affected component must be the end product, not individual components of the product.

I think CSAF is similar in that its an advisory format and it can optionally include VEX, but that data needs to be validated prior to confirming its actually a VEX.

@coderpatros @DarthHater Thoughts?

[stevespringett]

What might be interesting is if in-toto would adopt BOM predicates specific to lifecycle, similar to how the rest of the world works. For whatever reason, the software industry is backwards in terminology and lack of lifecycle context.

See https://medium.com/@steve_springett/sbom-should-not-exist-long-live-the-sbom-4554d5c31ff9

[lehors]

To be clear, the resolution is to use "https://cyclonedx.org/bom".
See in-toto/attestation#82 (comment)

[stevespringett]

Published to website:
https://cyclonedx.org/specification/overview/#recognized-predicate-type