Auditing Cross-Architecture Toolchain Provenance as a Supplier Control Requirement

Cross-architecture toolchain provenance must be part of supplier controls as well as build reporting. Platform teams should manage x86-64 and ARM toolchains through version-controlled, declarative environments with pinned compilers, runners, and build inputs, then generate a separate signed provenance record for each platform’s build. Attestations become credible evidence only when the toolchain behind them can be identified, reconstructed, and independently checked.

Why toolchain provenance is structurally different from artifact provenance

An SBOM describes what an artifact contains, while toolchain provenance establishes what built it. A signed SBOM certifies composition, and a provenance attestation claims how and by what means the artifact was built. The credibility of that claim depends on whether the build environment can itself be described and verified.

The AStRA model, which stands for Artifacts, Steps, Resources, PrincipAls, explains the causal relationship. The state of the toolchain is a Resource that shapes every Step that follows. Compilers, build systems, runners, and base images therefore belong at the start of the evidence chain. Their versions must be captured at the start of each build stage and written to a structured record included in the provenance attestation.

Uniformly applying SLSA attestations and signed SBOMs does not remove this dependency. Signing cannot compensate for an opaque build system. If its inputs are unversioned, its attestation remains an assertion about an environment that a reviewer cannot reconstruct. Toolchain provenance is therefore a prior requirement for assessing artifact provenance, rather than another field that can be inferred from the finished artifact.

How cross-architecture builds multiply the number of distinct provenance surfaces

A team with ARM64 laptops, x86-64 Linux CI runners, and production split between AMD64 and ARM64 instances has to account for the toolchain in each of those settings. Those contexts can diverge without an application-source change. Each build path has its own compiler configuration and runner environment, along with a base image lineage if it uses one. Evidence from the x86-64 Linux build does not establish which compiler or libraries produced the ARM64 output.

Cross-compilation builds executables for target operating systems and architectures from one CI environment, so teams have less need for a separate build machine for each platform. It does not automatically create provenance records for each platform. The shared runner can obscure the distinction because several outputs appear to come from one controlled build. Nevertheless, each target path needs its own attestation, including the compiler version and configuration used for that output.

When environments are maintained separately, service versions, configurations, and environment variables drift, so results from one environment cannot be assumed to hold for another. A build that succeeds on an ARM64 developer machine does not establish the state of the x86-64 CI toolchain. The runner is also a supplier artifact with its own support and EOL status. Architecture-specific failures are therefore more than a developer inconvenience when the evidence record cannot explain which environment produced the result.

What regulatory and contractual frameworks now require teams to document about their build toolchain

CISA’s updated SBOM guidance makes the document’s production context explicit through fields including SBOM Tool Name and Version and SBOM Generation Context. These identify the generator and the lifecycle phase in which the SBOM was produced. Component Hash Value and Hash Algorithm show which component the record describes, while SBOM Author Signature shows who attested it. Together, these fields connect composition records to evidence about their production.

The EU Cyber Resilience Act covers the product’s software components and requires at least top-level dependencies to be inventoried. It does not expressly address build-time dependencies such as compilers and build systems. That boundary should not be mistaken for complete toolchain coverage. Product-component obligations and toolchain supplier controls overlap, but they are not interchangeable.

US OMB M-26-05, issued on 23 January 2026, rescinded the government-wide CISA secure software attestation mandate. Attestation became an agency-level discretionary choice. Agencies may still ask for SBOMs or other artifacts based on the risks in each contract, so vendors must meet the evidence terms of each procurement.

Evidence availability is part of that obligation. In the CRA audit example, decisive evidence contained no release-binary signature or attestation, and container provenance could not be verified because the registry API returned a 403. The record failed at review time, irrespective of what evidence might have existed elsewhere.

Why attackers target the toolchain and build environment rather than source code directly

The 2026 incidents show why teams need to control build inputs as well as review the repository. In March 2026, malicious versions of axios reached npm consumers’ build pipelines before detection because enforcement happened after installation. Reviewing the application repository would not resolve that exposure.

In August 2026, a worm spread through keyv and dependent packages after an attacker compromised the maintainer’s GitHub account. Stolen npm publishing tokens enabled propagation across hundreds of packages. A single ecosystem actor’s credential compromise therefore reached downstream consumers through their dependencies, without requiring direct changes to each consumer’s repository.

The TrapDoor campaign targeted npm, PyPI, and Crates.io with execution paths tailored to each runtime, including postinstall hooks, import-time remote fetch, and malicious build.rs scripts. The entry points were different for each runtime. That distinction parallels the need for separate evidence for each architecture, because a control applied to one execution context cannot simply stand in for controls over another.

These incidents do not establish that every toolchain input is compromised. In the AStRA model’s terms, a poisoned Resource can corrupt the Artifacts it touches. Without a recorded toolchain baseline to compare against, a team cannot tell whether a build environment is as expected or has been compromised.

What a toolchain audit trail must actually contain to be useful at supplier review time

For supplier review, teams should record every significant build-time input’s identity, version, and support status at the moment each build stage executes. The record must be structured, machine-queryable, and separate for each architecture. It should include the compiler version and variant, the cross-compilation target where relevant, runner identity and version, base image digest and SBOM lineage, and significant build-time libraries. An inventory for the release alone cannot show the state of the toolchain at each stage.

CISA’s fields provide the vocabulary for connecting these records. SBOM Tool Name and Version identifies what generated the document, while SBOM Generation Context distinguishes source, build, and release production. Component Hash Value and Hash Algorithm must identify each architecture’s output, and SBOM Author Signature must establish who attested it.

A runner label alone is insufficient identification. The hosted label ubuntu-latest resolves to the OS version the CI provider designates current at build time. Two builds a week apart may thus use different versions of the kernel and libraries even though their attestations show the same label. Pinning a specific runner image digest makes that dependency concrete.

Reproducible builds provide the independent verification mechanism by producing bit-for-bit identical output from the same source and toolchain. To make these records useful in day-to-day work, teams should also attach an input-derived environment hash to the output and deployment record for each architecture. When a toolchain CVE appears, that association makes affected deployments queryable without grepping logs or rescanning every artifact.

How can platform teams standardize x86 and ARM toolchains with declarative, pinned environments?

Complete build-time records are sustainable only when environments are declared as code, pinned to specific inputs, and version-controlled. Otherwise, provenance documents whatever state the environment happened to have. The platform layer must create environments from a shared declarative configuration so developers are freed from bringing separately maintained installations into line. That moves environment parity from individual discipline into the build platform.

The declarative manifest, rather than the container image, is the appropriate unit of promotion across the SDLC. Atomic edits, pinned references, and generation-based rollbacks make earlier toolchain states reconstructible. Environment definitions must pass through review, test, and release steps just as application code does. Their history then becomes evidence rather than an informal account of infrastructure changes.

Platforms can share a definition and still have different binaries. Its input-derived hash can show which pinned environment definition the platforms share, while separate component hashes and attestations identify the outputs built for each architecture.

Platform engineers should distribute versioned, extensible base environments to development teams. A one-command activation can then instantiate the intended toolchain state rather than merely install a convenient collection of tools. This makes per-architecture provenance a platform output, including for new contributors, instead of an additional documentation task assigned to every developer.

How AI agent runtimes extend the toolchain provenance requirement into a new, largely unaddressed surface

AI agent runtimes and Model Context Protocol servers are toolchain inputs when they are used to develop, build, or run software. The same evidence boundary applies to them. An agent operating outside the pinned environment introduces tools and dependencies that the existing compiler and runner attestations do not describe. Treating agent infrastructure as invisible reproduces the original provenance gap.

In April 2026, OX Security disclosed a flaw in the architecture of MCP as a whole that left vulnerable instances exposed across a large package supply chain. MCP connects agents to external tools and data sources, but it is unopinionated about package management. Developers dynamically pull configurations through decentralized, unverified community registries to add capabilities. A compromised connector can then pivot across other tools and data sources wired into the same agent.

Teams should generate CycloneDX SBOMs for agent runtimes and resolve each MCP server and Python/npm dependency into a component graph. Components should be assessed against vulnerability and provenance signals before deployment or agent rollout. Unsigned dependencies should not pass, regardless of vulnerability count.

This makes provenance a release-blocking signal at the agent boundary. A low vulnerability count does not establish where a component came from or whether it is trustworthy. Coding agents must use the same declarative, pinned environment as human developers so their toolchain state is part of the same evidence chain that teams can reconstruct.

Translating cross-architecture toolchain provenance into a supplier control program

The program should start with an inventory of build-time inputs as supplier artifacts for each architecture. Compilers, runners, base images, and significant build-time dependencies need names, support and EOL status. Any input that cannot be pinned to a specific, verifiable version should be flagged. Without this inventory, the platform team cannot define the environment that subsequent attestations will claim to describe.

Once the inputs are known, the team should move each environment into a declarative configuration that is version-controlled, reviewed, and released with application code. Pinning establishes the baseline for reproducibility. Only then should the pipeline generate separate signed attestations for each architecture at build time, retaining the generator identity, lifecycle context, and output hashes. Recording these automatically frees developers from having to remember an extra task at release time.

The next step is to connect the evidence to deployments. Each deployed artifact should retain the input-derived hash of its producing environment, so a disclosed toolchain CVE can be traced to affected deployments. With that relationship established, the same SBOM and provenance gate should extend to agent runtimes, MCP servers, and agent dependencies. Unsigned components must block rollout before deployment.

Platform engineering is responsible for automating these steps so they can be repeated. Security and supplier review depend on the resulting evidence being available. For any deployed artifact, the record must trace its hash back to the specific, pinned, attested toolchain for its architecture. If that chain cannot be reconstructed on demand, the supplier control program is incomplete.