in-toto Layout

Expanded Definition

An in-toto layout is the policy layer for a software supply chain: it declares which steps must occur, which keys or identities are trusted to perform each step, and what evidence each step must produce. In practice, it is used to make build and release provenance machine-verifiable rather than implied by process documentation.

Within NHI and CI/CD governance, the term sits between workflow design and cryptographic attestation. It is not the attestation itself, and it is not merely a pipeline definition. The layout describes the trusted sequence and the participants allowed to execute it, while tools and signing mechanisms prove the sequence was followed. That distinction matters when teams compare it with broader frameworks such as the NIST Cybersecurity Framework 2.0, which is outcome-oriented rather than supply-chain step specific.

Definitions vary across vendors on how much policy should live in the layout versus external pipeline controls, so implementations differ in strictness. The most common misapplication is treating an in-toto layout as a generic CI/CD template, which occurs when teams define build stages without binding them to approved identities and verifiable step attestations.

Examples and Use Cases

Implementing in-toto layouts rigorously often introduces operational friction, requiring organisations to weigh stronger provenance guarantees against the cost of tighter signing discipline and more controlled release paths.

• A build layout requires source checkout, dependency fetch, compile, and package steps to be performed only by approved service identities, so an untrusted runner cannot silently replace the artifact.
• A release layout requires security scanning and signing to occur in a specific order, ensuring a signed artifact cannot skip validation even if a pipeline is modified.
• A regulated software team uses a layout to prove that a production release passed through designated test and approval steps before publication, supporting audit evidence and incident review.
• A platform team pairs in-toto with a broader supply chain program to reduce the risk seen in incidents like the Schneider Electric credentials breach, where identity and process trust become intertwined.
• An open-source maintainer uses a layout so downstream consumers can verify that the published package came from the expected maintainer path and not from an altered build environment.

These use cases align with the supply-chain integrity model described by the NIST Cybersecurity Framework 2.0, especially where integrity and traceability are treated as control objectives rather than optional metadata.

Why It Matters in NHI Security

In NHI security, in-toto layouts matter because the security boundary often shifts from human approval to machine identity. If the wrong service account can execute a critical build step, the organisation may still receive a signed artifact that appears legitimate while having been assembled through an untrusted path. That is why layouts are a governance tool as much as a technical control.

This is especially relevant in environments where secrets, signing keys, and pipeline tokens are already exposed across CI/CD systems. NHIMG reports that 96% of organisations store secrets outside secrets managers in vulnerable locations, and 92% expose NHIs to third parties, conditions that make supply-chain identity binding a real control need rather than a theoretical best practice. An in-toto layout helps constrain which identities can act and what evidence must exist after they act.

Used well, the layout gives investigators a way to distinguish a valid release from a forged one, and it gives operators a basis for rejecting artifacts that do not match declared process. Organisations typically encounter the need for an in-toto layout only after a release is questioned or a signing path is compromised, at which point the term becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Right-to-left layout
• Deterministic Heap Layout