The Cloud Native Computing Foundation announced in-toto's graduation on April 23, 2025, moving the project from incubating to graduated status. Graduation is CNCF's signal that a project is production-ready and broadly adopted, and for in-toto it follows a five-year journey from a NYU research project to the substrate underneath SLSA, Sigstore Cosign attestations, and most of the modern supply-chain attestation ecosystem. Alongside graduation, the in-toto Attestation Framework v1 release introduced significant additions: an attestation bundle layer for grouping multiple attestations, a Resource Descriptor type for size-efficient artifact identification, and Protobuf definitions for language-independent attestation handling. For producers and consumers, the practical question is whether to migrate from individual signed attestations to bundles, and the answer is increasingly yes.
What is the attestation bundle layer?
A bundle is a collection of multiple in-toto attestations packaged in a single signed envelope. Before bundles, common practice was to emit each attestation (SLSA provenance, SBOM, vulnerability scan, test results) as a separate signed statement and either store them separately or chain them via OCI referrers. Bundles formalize the grouping: an artifact has one bundle, the bundle contains the statements describing its build, contents, security findings, and tests, and the bundle is signed as a unit. Consumers retrieve one document, verify one signature chain, and reason about a coherent attestation set. The bundle layer aligns with how Sigstore Cosign was already storing attestations in OCI registries — the v1 spec promotes that pattern into the in-toto framework itself.
What does the Resource Descriptor add?
A Resource Descriptor is a size-efficient way to identify any software artifact or resource referenced from an attestation. It supersedes the historical ad-hoc patterns where a predicate might reference a file by URI in one place and by digest in another. Resource Descriptors carry a name, optional URI, content digests (multiple algorithms supported), media type, and annotations. The benefit is that a complex bundle referring to dozens of components (an SBOM's transitive dependencies, for example) uses a consistent reference type, so a verifier can resolve and re-fetch referenced resources uniformly.
{
"_type": "https://in-toto.io/Statement/v1",
"subject": [
{
"name": "acme/api:v1.4.2",
"digest": { "sha256": "5e6f7a..." }
}
],
"predicateType": "https://slsa.dev/provenance/v1",
"predicate": {
"buildDefinition": {
"buildType": "https://slsa-framework.github.io/github-actions-buildtypes/workflow/v1",
"externalParameters": {
"workflow": {
"ref": "refs/heads/main",
"repository": "https://github.com/acme/api"
}
},
"resolvedDependencies": [
{
"name": "source",
"uri": "git+https://github.com/acme/api@refs/heads/main",
"digest": { "gitCommit": "9a8b7c..." }
}
]
}
}
}
How do bundles work with Protobuf definitions?
The v1 release added Protobuf schemas for the attestation Statement and select predicate types. Protobuf gives consumers language-independent strongly-typed deserialization, which matters when downstream verifiers are written in Go, Rust, Python, Java, and TypeScript. Before Protobuf, every language implementation re-derived its own JSON parser and validated against the spec by inspection. With Protobuf, the canonical types are defined once, and language bindings are generated. The JSON representation remains available — Protobuf does not replace it — but consumers who need performance or strict schema enforcement gain a real option.
What predicate types does in-toto define today?
Several predicate types live in the in-toto/attestation repository or are referenced as well-known external types. The most adopted: SLSA Provenance v1 (build provenance), SLSA Verification Summary Attestation (a higher-level "this artifact passed our policy" claim), SPDX (the SBOM format embedded as predicate), CycloneDX (similar), test-results, vulnerability scans, runtime-traces, and link (the original in-toto layout-based attestation). Producers do not need to invent new predicates; they generally compose existing ones into a bundle. v1 explicitly invites the community to contribute new predicates via the project's contribution guidelines.
How does in-toto interact with Sigstore?
In production, in-toto attestations are almost always signed using Sigstore (Fulcio for the certificate authority, Rekor for the transparency log, Cosign as the client). The two projects are complementary: in-toto defines the structure and semantics of the attestation, Sigstore provides the trust anchor and signature transparency. The 2025 Sigstore Rekor v2 general availability rolled out alongside in-toto's graduation, and both projects' clients (Cosign 2.6+, Go/Python/Java client libraries) interoperate on the new bundle structure. Producers using Cosign to sign attestations get a Sigstore-issued certificate bound to a workload identity (GitHub OIDC, GCP service account, etc.), the in-toto Statement is signed under that identity, and the resulting bundle is uploaded to Rekor for transparency. Consumers verify by checking the Rekor inclusion proof, validating the certificate against the expected workload identity, and parsing the in-toto Statement. The pattern is now mature enough that most consumers should default to it; alternative signing approaches (long-lived keys, custom CAs) remain valid but require more operational care.
What should producers do post-graduation?
Three actions. First, if you produce signed attestations today as individual envelopes, evaluate consolidating into bundles for new releases — the migration is incremental and consumers that only understand individual envelopes still work because a bundle's contents can be inspected as individual statements. Second, audit your predicate hygiene: many producers emit predicates without proper Resource Descriptor formatting, which makes downstream graph traversal harder; updating to the v1 Resource Descriptor type pays back at verification time. Third, watch the predicate registry — graduation makes in-toto a stable target for downstream projects, and new predicates (for AI model provenance, for hardware attestations, for compliance-mapped attestations) are landing rapidly. Consumers should plan for the predicate ecosystem to broaden, not narrow.
How do consumers handle attestation freshness?
A signed attestation is a point-in-time claim. A SLSA provenance signed in March is not invalidated automatically when April rolls around, but consumers reasonably want to know whether an artifact's attestations are recent enough to reflect current state. The in-toto v1 framework supports timestamps in Statement metadata, and consumers can build policy expressing freshness expectations ("provenance no older than 90 days for production deployment, vulnerability scan no older than 7 days"). The challenge in practice is that different attestation types have different reasonable freshness windows — build provenance is a record of how something was built and remains valid indefinitely for that build, while vulnerability scans degrade quickly as new CVEs are published against components. Mature consumers express freshness policy per predicate type, not as a single global rule, and re-run attestation generation on a cadence appropriate to the underlying signal rather than trying to keep every artifact's full bundle continuously refreshed.
How does graduation change the project's roadmap?
CNCF graduation does not give a project new resources directly but it does change the trajectory. Graduated projects can be referenced confidently by enterprise architecture teams without the "is this project mature enough?" objection. They become eligible for adoption in regulated environments where vendor-risk teams require a level of supply-side stability. They tend to attract more contributor diversity, because contributors are more willing to invest in a project with a stable governance model. For in-toto, the post-graduation roadmap visible in the project's working group materials focuses on: maintaining backward compatibility for the v1 framework while iterating on new predicate types, deepening the integration story with SLSA and Sigstore, expanding language-SDK coverage (the Protobuf bindings make this materially easier), and producing more end-to-end reference architectures for common use cases (Kubernetes deployments, AI model artifacts, OS package builds). The pace of change at the predicate level is faster than the framework level, which is the right model: the framework should be stable, and innovation should happen in the predicate ecosystem on top.
How Safeguard Helps
Safeguard's attestation pipeline natively produces and consumes in-toto v1 bundles. When building artifacts, the platform composes SLSA provenance, CycloneDX or SPDX SBOMs, vulnerability scan results, and test-result attestations into a single signed bundle stored in the OCI registry alongside the artifact. Resource Descriptors are populated with consistent digests, names, and annotations so that downstream verifiers can traverse the bundle without ambiguity. For consumers, Safeguard's verification engine evaluates bundles against policy in a single pass, returning structured pass/fail results per predicate and per overall artifact decision. Griffin AI explains verification failures with reference to the specific predicate, subject, and missing or invalid field. Policy gates accept bundle requirements as first-class inputs ("require SLSA v1 provenance, CycloneDX 1.7 SBOM, and vulnerability scan attestation within 7 days, all signed by tenant-trust-root identities"), making the post-graduation in-toto ecosystem usable as a policy substrate rather than just a signature format.