Proposing Trusted BOM (TBOM) profile for verifiable security-testing evidence

[n45os]

Hello,

I am writing on behalf of RESCALE (https://rescale-project.eu), an EU Horizon Europe project (GA 101120962) on securing software and hardware supply chains. CycloneDX has been the foundation of our data model since the project started, and before we finish in September 2026 I would like to put a concept in front of this community and find out whether it is of any interest.

What we built

RESCALE produces a Trusted Bill of Materials (TBOM): a CycloneDX 1.6 JSON document that binds an SBOM to structured, verifiable evidence of the security testing performed on the component it describes.

A TBOM consists of:

• the SBOM for the component, referenced by link and hash rather than embedded;
• a report of the static analysis performed on the source, structured rather than free-text;
• the equivalent for dynamic analysis and fuzzing, including hardware dynamic analysis where it applies;
• a bill of vulnerabilities, the known-vulnerability position at the time of issue, kept current by a continuous monitoring component.

Two properties matter beyond the composition. Storage is append-only, so a newer TBOM deprecates an older one without erasing history, which gives a component a security history rather than a snapshot. The document hashes are anchored to a permissioned ledger, so a consumer can verify integrity and provenance without trusting the producer's infrastructure. Only the hashes are stored on the ledger, never the TBOM itself, so nothing sensitive is exposed.

The model we are aiming at is "producer publishes, consumer verifies". Today security evidence does not travel with the component. Scan results, code review findings and test reports stay in the tools that produced them, in incompatible formats, and a downstream integrator has no practical way to verify the supplier's claims. An SBOM tells you what is in a component. It does not tell you what security testing was done on the component or what it found, or give you any way to verify either.

Where the existing types strain

The TBOM is based on CycloneDX 1.6 using existing types, to compile and be usable rather than wait on a schema conversation. Doing that surfaced three places where the existing types work but are a stretch. These are the concrete part of what we would like this community's view on.

1. The static and dynamic analysis report reference types. We carry the structured security-testing evidence as external references of type static-analysis-report and dynamic-analysis-report. Both fit in the sense that the evidence is a report about analysis. But the reference itself is only a URL, a hash and a comment: what was analysed, with which tool and version, against which ruleset, and with what result is structured inside our report, not in anything CycloneDX defines. Our specification notes the potential to align these types more closely with structured, tool-agnostic analysis evidence.

2. hashes cannot distinguish several different outputs of one component. In CycloneDX, the hashes array on a component or reference (not the ledger) is designed to hold several hashes of the same thing under different algorithms. Our trust assurance component produces several distinct outputs, and we need to record a hash of each. Today we differentiate them by writing which is which into a comment or description field, which is not machine-checkable and defeats the point of hashing them at all. A way to bind a hash to the specific output it covers would fix this cleanly, and we suspect we are not the only ones who hit it.

3. Version lineage between BOMs. The ledger is append-only: a new TBOM deprecates its predecessor rather than replacing it, so a component accumulates a security history rather than a snapshot. We express the link by storing the ledger hash of the previous version in a hash field, which works but is a convention we invented. CycloneDX has a pedigree field for lineage, but it models versions of a product rather than successive TBOMs for the same one.

None of these blocked us. All three are places where we wrote a convention into a description field and moved on, and a convention in a description field is a thing only our tooling can read.

Why we are raising it here

CycloneDX already hosts specialised BOM types for hardware, cryptography, SaaS and machine learning, and we think verifiable security-testing evidence may belong in the same family rather than in a project-specific format. We have built on CycloneDX for three years, and we believe it matters to bring what we learned back to the community that maintains the specification, and to hear your view before we settle our own conclusions.

We are not filing a deficiency report. The specification was sufficient to build on, which is why we built on it, and we would rather be told the three points above are solved problems we have missed than assume they are not.

What we are asking

1. Is a Trusted BOM, meaning a BOM type or a documented profile for verifiable security-testing evidence, of interest to this community?
2. On the three points above: are they real, are any already addressed by work we have not found, and are any worth raising as feature proposals?
3. If a profile is the answer, what is the right venue: an existing working group, a new Feature Working Group, or a guidance document rather than a specification change?
4. If the answer is that none of this belongs in CycloneDX, we would still value knowing why, and whether the evidence primitives we needed are better served elsewhere, the Transparency Exchange API in particular.

For context on the project's standardisation work, our white paper is at https://zenodo.org/records/17896135.

Thank you for reading.

[stevespringett]

• I think the concepts behind the trust that this proposal is advocating for are, is the direction that CycloneDX has been heading for a few years. The group, for example, is not a proponent of VEX in its current form, as VEX is designed around a one-way "trust me" conversation from vendor to consumer. This approach works well for suppressing false positives, but fails under the slightest scrutiny.
• Some of what you're proposing is currently being worked on. For example:
  • Vulnerability evidence allows us to represent whether a component is affected by a vulnerability and the tests that were performed to make that determination, to either confirm or refute a vulnerability claim. Multiple parties can make conflicting claims, allowing use cases such as a vendor claiming they are not affected and the tests they ran, and third parties providing the test evidence they've run and coming to a different conclusion. This capability is already designed and will be included in v2.0. v2.1 may include additional expansion if needed.
  • We have designed a way to extend hardened JSON, which by design is not extensible, but do so in a way that allows organizations or industries that have very specific types of data to overlay that data on top of CycloneDX 2.0 in a fully machine-readable way that doesn't violate the spec. We're doing this while keeping a hardened JSON schema and avoiding the pain and performance issues that plague JSON-LD.
  • Since CycloneDX v1.4, the specification has slowly started to introduce primitives that are unrelated to bills of materials. Starting with 2.0, the majority of the specification's capabilities have nothing to do with bills of materials. The specification has evolved from a full-stack BOM format into a "Transparency Expression Language". That language will underpin the upcoming "insights" capability of the Transparency Exchange API (TEA). So the spec delivers not only a file format everyone is familiar with today, but also an API specification that TEA will leverage.
• CycloneDX has a version field at the root, which is the version of the document. Each change should increment the version, allowing implementations to easily go back to any previous version of a CycloneDX document and perform a diff if needed. Multiple commercial and open-source TEA implementations have been interop tested, and many also support the CycloneDX version, which is core to a CycloneDX document's identity (serialNumber + version).

The team is currently buried in getting 2.0 released in November and can't take on new work until after its launch. However, I would like to continue this conversation and potentially stand up a new working group in Q1, after some of the existing working groups start spinning down with the 2.0 launch.