Hi Gary, On 15.05.2026 13:44, Gary Gregory wrote: > Today, we provide CycloneDX and SPDX SBOMs. We are talking about > adding a _third_ "thing". > > Is it desirable or possible to provide one thing to rule them all? I > don't need to link to the xkcd about standards... > > Is it desirable or possible to lump this new information into the > SBOMs we already provide?
It is technically possible. CycloneDX documents can carry this kind of information in two ways: 1. The Provenance use case (https://cyclonedx.org/use-cases/provenance/). 2. The newer `formulation` field, which describes how an artifact was built. But I don't think we should take that route, for two reasons. It muddles the semantics of the SBOM. An SBOM is a list of components. Once we start packing provenance into it, it stops being that, and downstream tooling looking for provenance information won't think to look inside an SBOM. The SBOMs we publish today are, in practice, not consumed for security. Library SBOMs have narrow real-world utility: - License management: potentially useful, since our dependencies' licenses rarely change between versions. - Compliance: some users are told they need an SBOM per component, tick the box, and never open the file. - Vulnerability management: not useful. The dependency versions resolved by an application using Commons differ from the versions we use at build time, so our SBOM doesn't describe what the consumer actually ships. - Tooling adoption: effectively zero. I had an illuminating conversation with an OSS Review Toolkit maintainer about why ORT doesn't even support importing SBOMs published by upstream dependencies. The short version: the metadata quality from upstream SBOMs isn't good enough for what ORT users need. In contrast, the in-toto attestation has a concrete consumer from day one (Ampel, with a policy users can apply directly) and a clearly separate purpose (verifying *how* an artifact was built, not what's in it). Keeping them as distinct artifacts means each can evolve on its own terms, and consumers who only want one don't have to parse the other. Piotr --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
