For most teams, signed provenance from a hosted build platform is enough. An in-toto layout is worth adding when your release passes through several steps and parties, such as separate build, test and packaging, and you want to verify the whole chain against a signed plan.
What a layout is
In the in-toto documentation, a layout is a signed plan for a software supply chain. It has these parts:
| Part | Meaning |
|---|---|
| Steps | Required tasks, each with a unique name |
| Functionaries | The parties authorised to perform a step, with their public keys in the layout |
| Artifact rules | MATCH, CREATE, ALLOW and DISALLOW rules on what a step may consume and produce |
| Inspections | Checks run during verification, such as unpacking the final archive and comparing contents |
| Owner signature | The project owner signs the layout, and verifiers use their public key |
Each step produces signed link metadata. A final verification checks the layout, its signature, the links and the inspections.
What provenance gives you
SLSA provenance records one build: who built it, with which parameters and inputs. A verifier compares it to expectations such as builder id, repository and build type. It is simple to consume because it is one signed statement per artifact.
Comparison
| Question | Provenance | Layout |
|---|---|---|
| Was this artifact built by a trusted platform? | Yes | Yes, as one step |
| Did a named person or system carry out the review step? | Not directly | Yes, through functionaries |
| Did the output of step A feed step B unchanged? | Not directly | Yes, through MATCH rules |
| Setup effort | Low on a platform that generates it | Higher, you design and sign a plan |
| Who maintains it | The build platform | The project owners |
When a layout earns its cost
- Releases with distinct stages run by different teams or tools.
- A need to show that a specific approval step happened before packaging.
- Environments where you do not trust any single builder to describe the whole process.
When provenance is enough
- A single hosted pipeline that builds and publishes.
- Consumers who only need to check source, builder and digest.
- Teams starting out. Provenance first, then add layout style checks if gaps show up.
A note on caution
The layout docs say verification generally warns rather than fails when the command run differs from the expected command, so do not treat expected commands as a hard control. They also recommend multiple project owners so one key compromise has less impact.
The two also combine. In-toto attestations are the shared format underneath SLSA provenance, so you can adopt one and grow into the other.
Where Safeguard fits
Safeguard's policy gates give you an enforced checkpoint in the pipeline, and its compliance and evidence automation helps record who approved what.
Quick check
Is in-toto the same as SLSA?
No. SLSA is a framework of levels. In-toto is a framework and attestation format. SLSA provenance is carried as an in-toto attestation.
Do I need functionary keys for provenance?
Not in the same way. Provenance is signed by the build platform, and you decide which builders to trust.
Sources
Last reviewed: 19 October 2026.
