Blog → The in-toto attestations and your supply chain security → v1.1.0

The in-toto attestations and your supply chain security

January 13, 2026 Supply Chain Security By Laurent Crisci
in-toto-attestation-framework

Supply chain security is something that is gaining momentum inside the software community. In this article, my goal is to explain to you what in-toto attestations are, what they can do for you and why you should really start integrating them within your own supply chain security approach. I will also cover what I have been working on as part of a contract for the last two years and how it is making a difference for the customer.

There is a lot to write about attestations and I will try to give you a brief introduction to them within this article. I’m planning on writing more about this topic in follow-up articles. Your feedback will help me decide what to prioritise writing about next.

First, let’s list the past 5 years of supply chain security attacks that attestations would potentially have been helpful to mitigate:

  • Sep 2025 - Shai‑Hulud (npm ecosystem compromise): A self-replicating worm compromised hundreds of npm packages, impacting a large portion of the JavaScript/Node.js ecosystem.
  • Aug 2025 - Drift / Salesloft supply-chain attack: Compromise of the Drift application cascaded through customer integrations, showing how SaaS supply-chain risks propagate.
  • Mar 2025 - CI/CD workflow platform compromise: Supply-chain attack on CI tooling (e.g., GitHub Actions related), underscoring that attackers increasingly target build/CI infrastructure beyond packages.
  • Apr 2024 - xz‑utils compromise attempt: Escalation in open-source supply-chain threats against foundational dependencies shared across many projects.
  • 2023 (multiple): Okta (Oct), JetBrains (Sep/Oct), MOVEit (June), 3CX (March) — spanning identity, developer tools, file transfer, and communications software, highlighting supply-chain risk across categories.
  • Feb 2023 - transitive dependency issues: Research and industry reports flagged deep, implicit dependencies as a growing attack vector.
  • 2022 - malicious dependency insertions: Multiple incidents across smaller OSS libraries, accelerating demand for SBOMs and provenance tracking.
  • 2020–2021 - SolarWinds Orion (“Sunburst”): Attackers injected malicious code into a legitimate update, compromising thousands of organisations globally.

It is in everybody’s interest to dig deeper into how their third-party dependencies handle supply chain security before they import a piece of software that could cause real damage to their operations and reputation.

How do you currently handle supply chain security?

1. The world before attestations

Software trust relied on:

  • source control access controls
  • release managers
  • checksums published on websites / repositories

No information about how the software was built, from where, who approved its release, etc.

2. Enterprise controls as paper theater

In regulated environments (SOX, PCI, ISO), trust is enforced via:

  • tickets
  • screenshots
  • approvals
  • separation-of-duties policies

This relies on manual steps and having different conversations with different centralised authorities. There is little room for automation and self-service and self-accountability or ownership.

in-toto does not stop compromised systems or malicious actors by itself. What it does is surface various claims / data from different processes that are deemed to be done in a certain way by your internal security controls.

Meet the in-toto Attestation Framework

The in-toto Attestation Framework aims to provide a specification for generating verifiable claims about any aspect of how a piece of software is produced.

Anatomy of an attestation

https://github.com/in-toto/attestation/blob/main/spec/README.md#in-toto-attestation-framework-spec

Attestation envelope relationships diagram showing payload, payload type, and signatures

An in-toto attestation is a signed statement ( payload ) and is composed of the following:

  • An envelope built using DSSE containing the following fields:
    • A payload ( an in-toto statement )
      • The payload contains:
        • The type of statement
  • A list of subjects being attested, usually a single container image’s name and digest, but you could technically have multiple ( multiple platforms, etc ) - The predicate type that indicates the type of attestation being created - In the picture above, that would be an SPDX document - The predicate data, which is the data being attested - In the picture above, that would be the SPDX document
    • A payload type
    • A list of signatures

You can capture specific data about a build, SBOM, CVE scan, or any other control that relates to an image inside an attestation. The producer signs it with a private key and the consumers verify it with the public key. Consumers can then parse the predicate data and apply logic to allow or deny an image based on what is present or missing in the attestation.

Attestations are usually stored as OCI artifacts next to the images that they cover. That keeps verification simple throughout the CI/CD process:

  • Retrieve the image’s digest
  • Fetch its attestations from the same registry
  • Verify the attestations’ signature(s)
    • You are also advised to verify the expected claims contained within the attestations’ predicate data

This approach is a simple but powerful way to enforce security controls and remains auditable for internal and external reviewers.

Before attestations, data might be generated and forgotten or not saved, buried in logs, or saved into databases. Semi-automated or manual steps produced documents with CVE scan results, and people assembled those to decide whether an image could be deployed to production or another critical environment.

With attestations, the process becomes automated and, most importantly, decentralised. Once trusted entities (a tool, a team, or even a person) generate and sign data with keys whose public counterparts are available to consumers, those consumers can:

  • Verify the attestation was produced by the expected source by checking its signature(s)
  • Parse the data and decide:
    • Is the image from an approved source?
    • Does it contain critical CVEs?
    • When was it last scanned?
    • Was it tested and promoted through prior environments?
    • Who approved the deployment(s)?

As you can see, you can pretty much create an attestation for every single event on the CI/CD pipeline. The in-toto Attestation Framework project has a few existing ones to reuse.

CI/CD flow overview

Below is an example of possible attestations to be created within each CICD step:

flowchart LR
    build[Build Image] --> sbom[SBOM] 
    sbom --> tests[Tests]
    tests --> cve[CVE scans]
    cve --> deployDev[Deploy to dev] 
    deployDev --> promote[Promote from dev to prod]
    promote --> deployProd[Deploy to prod]

By the time your pipeline has reached the step to deploy to production, you would be expected to have the following attestations for your container image:

If any of these attestations are missing at any of these pipeline steps, you know that an expected process has not been followed. You are now free to deny the image from proceeding to the next steps until the expected attestation(s) exist.

It doesn’t have to be all on the same pipeline. You could have a dev pipeline and prod pipeline as some heavily regulated organisations have and you would still be able to follow the above logic. Even copying an artifact from a dev registry to a prod registry would retain all this information as long as you copy the attestations alongside the artifact because the digest of the container image would be the same on both registries and so the attestations would still be valid.

Attestations storage

OCI v1.1 and the Referrers API

A new mechanism makes it easier to attach data to a container image within an OCI registry. That data is stored within an OCI artifact and represented through a manifest. The key addition is a subject field that points to the related container image. You can have one image with multiple OCI artifacts stored alongside it in the same registry.

You fetch the image, take its digest, and call the Referrers API. It returns an index manifest that lists all artifacts attached to that digest. This is ideal for storing and retrieving attestations from OCI artifacts. Previously, you often had to fall back to tagging an OCI artifact with the digest of the related image.

Please read this article to find out more about it. More details can be found within the official spec.

Currently the following OCI registries support it:

My recent project

Over the past two years, I have been part of a team working on a project at a leading UK bank to provide evidence that every container image passed the mandatory internal security controls set for container images within the bank. Each image had to be built internally or imported through approved paths, scanned for CVEs, have an SBOM generated, etc.

The tooling to scan and import images already existed, but how do you prove that the exact image running in production went through these controls? You might already have an existing system in place but how complicated / manual / tedious is it? What if we pushed more automation into this process and reduced the amount of back and forth communication and searching for the right document/proof? What if all this information was self-contained inside a bundle living alongside the image?

Attestations solve this problem in that no one should be able to move along on the CICD flow if key attestations are missing at key steps:

  • A container image missing a CVE scan result attestation or SBOM attestation or build / import attestation should not be allowed to be deployed within an environment.
  • A container image missing an attestation documenting its Dev deployment or a provenance attestation should not be allowed to be deployed in production

Let’s visualise the internal flow:

                 ┌─────────────────────────────────────────────────┐
                 │         SECURITY / GRC (Control Owners)         │
                 │  "What must be true" (policy, standards, SOC2)  │
                 └───────────────┬─────────────────────────────────┘
                                 │ defines / mandates
                                 v
          ┌─────────────────────────────────────────────────────────────┐
          │                      SECURITY CONTROLS                      │
          │  C-01: Only signed builds may be deployed                   │
          │  C-02: Dependencies must be scanned for known CVEs          │
          │  C-03: Dependencies must be scanned for known CVEs          │
          │  C-04: Promotions require approval + traceability           │
          └───────────────┬─────────────────────────────────────────────┘
                          │ mapped to "required process steps"
                          v
       ┌────────────────────────────────────────────────────────────────────┐
       │         ENGINEERING PROCESS / CI-CD (Control Implementers)         │
       │  Build → Test → Scan → Deploy → Promote                            │
       └───────────────┬────────────────────────────────────────────────────┘
                       │ emits evidence ("prove it happened")
                       v
   ┌────────────────────────────────────────────────────────────────────────────┐
   │                           ATTESTATIONS (Evidence)                          │
   │  A-01 Build Provenance  (who/what/when: repo, commit, builder, materials)  │
   │  A-02 SBOM              (what went in: components, versions)               │
   │  A-03 CVE Scan Result   (what was found: findings, policy pass/fail        │
   │  A-04 Deploy/Promote    (where/why: env, approver, change ticket)          │
   └───────────────┬────────────────────────────────────────────────────────────┘
                   │ verified by policy engine / auditor
                   v
        ┌───────────────────────────────────────────────────────────────┐
        │             AUDIT / COMPLIANCE ASSERTION (Outcome)            │
        │  "Control C-01..C-04 satisfied"                               │
        │  because attestations A-01..A-04 exist and are verified       │
        └───────────────────────────────────────────────────────────────┘


  Dependency chain (left-to-right logic):
  Controls (requirements) ──► Process (implementation) ──► Attestations (evidence) ──► Audit conclusion

A tool was developed to create, sign and verify attestations. It was integrated in numerous existing processes as an extra step and work is still being done to integrate it within key security processes within the bank.

What attestations are and are not

  • Attestations are not equivalent to artifact signatures. Instead, what is being signed here is that a specific process around the container image has happened and the data to document it.
  • Attestations are a snapshot of a state at a specific time. That situation could have changed in the meantime ( for example CVE Scans Results might give you different results over time ).
  • Attestations are making it easier to push for more self-service, decentralisation and ownership/accountability. All the information is self-contained and it is no longer required to reach out to different people / APIs / etc to ensure that a process has been followed. The evidence exists or doesn’t exist and is usually stored alongside the image, ready to be verified.
  • Attestations are not a replacement for SBOMs, CVEs scanning results, etc
    • They simply prove that these processes did happen from the expected sources of trust. If the attestation is missing for an SBOM, the SBOM might not have been generated by the team whom you trust to handle this process.

Who needs attestations?

  • You are maintaining a piece of software and want to give your consumers as much data as they need ( Build Provenance, SBOM, tests, etc ) before they can integrate it into their internal stack and satisfy the internally mandated security controls.
  • You are working in a place where there is a lot of bureaucracy and manual / human steps to verify that a piece of software is allowed to proceed past various steps until it gets deployed and run in production.
  • If you need to simplify the collection of evidence and reduce the amount of different steps to do so. Instead of calling different endpoints at various stages, you collect the signed evidence only once and have it progress alongside the image.
  • You have to deal with auditors who require concrete proofs that processes and controls are being followed.

Do not trust them blindly

in-toto attestations ultimately rely on the trust that you give to the entities delivering them. You have to trust them to manage their key pair in a secure way, to not add false claims to their attestations, to manage their internal processes in a secure way, etc.

The attestations carry the evidence that you might require, but remember that ultimately this evidence is generated by processes that may end up being compromised.

They are not a silver bullet when it comes to the security processes. What they are effective at is to document the existing processes that have interacted with the software artifact for the consumers to be able to take the appropriate decisions with regard to their current security controls requirements.

Who is currently using in-toto attestations?

Useful resources

There is a before-and-after moment happening when you finally realise what in-toto attestations can do for you and how much it can simplify your internal security procedures that aim at auditing and verifying that security controls and processes are being followed to the letter by all the teams within your organisation.

Please feel free to contact me should you need a better understanding or help deploying this approach within your current stack.

v1.1.0 Last updated: January 13, 2026
Version History
v1.1.0 January 13, 2026
  • Minor updates / corrections
v1.0.0 January 13, 2026
  • Initial version