Implementing SBOMit specification by integrating with in-toto/witness

[Vyom-Yadav]

Hey Folks,

We are working on improving the accuracy of SBOMs being produced by extending/verifying them using in-toto attestations. The SBOMit project defines the guidelines:

The SBOMit specification is a SBOM format independent method for attesting components with additional verification information. These attestation are generated at the time the supply chain was generated.

The SBOMit specification mentions the complete idea but to briefly describe it, instead on just relying on lock files for generating SBOMs or relying on any sort of file analysis to guess the components, SBOMit specification proposes recording and signing the metadata during the build (the time the supply chain was executing) using the in-toto bundle format. Then various other tools can process that in-toto attestation to enrich the lockfile SBOM being produced and even embed the attestation inside the SBOM.

SBOMit is just the specification and the recording and signing of the metadata during the build is done using in-toto/witness currently.

Enriching the lock file SBOMs using in-toto attestations (witness format) increases the accuracy of the generated SBOM. Both in-toto/witness and SBOMit are completely open source and under CNCF and OpenSSF respectively. We are currently working on doing phase-1 of this project where we're building the relevant libraries and tooling as an intermediate solution, but in long term, we'd like projects like Trivy, Syft to be able to enrich the SBOMs using the SBOMit specification (maybe something like --witness-attestation flag).

Is that something that aligns with the goals of the Trivy project? We don't want to build another tool and fragment this ecosystem more, so we're looking for ways to add this support to existing SBOM generators. Thanks!

cc @absol27 @stupendoussuperpowers @JustinCappos @jkjell @SantiagoTorres

[knqyf263]

Thanks for bringing this up!

Let me confirm my understanding: users would run witness during their build process to generate attestations, and then pass those attestations to Trivy at scan time (e.g., trivy fs . --witness-attestation attestation.json). Is this correct?

If so, and if it can improve SBOM accuracy, this sounds like a great addition.

However, I have a question about the practical workflow: where are these attestations expected to be stored, and how would users retrieve them at scan time?

We've added several SBOM and attestation discovery features to Trivy in the past, but from what we've seen, users often struggle to take full advantage of them because there's no standardized location for storing these artifacts. I'd like to understand the expected workflow to ensure this feature can be practically useful.

[Vyom-Yadav]

I completely forgot to reply on this. My apologies.

However, I have a question about the practical workflow: where are these attestations expected to be stored, and how would users retrieve them at scan time?

That is a valid concern. https://github.com/in-toto/archivista is one place to store and visualize attestations, but I don't recall seeing anything around standardizing distribution and storage of in-toto attestations across the ecosystem (source, release artifacts, OCI registries, etc.). I'll talk to the team to see how we can improve upon this. Thanks for raising this.

[JustinCappos]

There is a push for this to be centrally collected in big open source foundations (most notably, the Linux Foundation). Separately, a bunch of the in-toto maintainers are putting out an informational standards document that explains the footguns and how to do this right, whether you centrally collect these or just pass them along the pipeline. More to come on this, but I think it's safe to assume there will either be a central registry that clients will get this information or the in-toto attestations will be bundled into the software you are distributing. In the case of SBOMit, I would recommend storage on a separate server and then having the URL listed in the SBOM be the place where the client can retrieve it.

…

On Thu, Mar 26, 2026 at 7:20 AM Vyom Yadav ***@***.***> wrote: I completely forgot to reply on this. My apologies. However, I have a question about the practical workflow: where are these attestations expected to be stored, and how would users retrieve them at scan time? That is a valid concern. https://github.com/in-toto/archivista is one place to store and visualize attestations, but I don't recall seeing anything around standardizing distribution and storage of in-toto attestations across the ecosystem (source, release artifacts, OCI registries, etc.). I'll talk to the team to see how we can improve upon this. Thanks for raising this. — Reply to this email directly, view it on GitHub <#10117?email_source=notifications&email_token=AAGROD67ESOXQO5ERHWE3UT4SUHBFA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNRTGI2TKMRYUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-16325528>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGRODZJUFI5ZO3KPZNB3Q34SUHBFAVCNFSM6AAAAACTU2YT4GVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMMZSGU2TEOA> . You are receiving this because you were mentioned.Message ID: ***@***.***>