Should teams prioritise SBOMs or build provenance against AI-driven supply chain attacks?

Why build provenance should outrank SBOMs under active supply chain attack

When the threat is malicious code being introduced through compromised runners, tokens, or publishing identities, build provenance is the stronger first line of defence because it answers whether an artifact was produced in the expected way, by the expected process. SBOMs still matter for inventory, triage, and downstream response, but they are descriptive after the fact. Provenance helps decide whether the artifact should be trusted at all.

That distinction matters because AI-driven attacks often target the build and release path, not just the package contents. If an attacker can control the pipeline, they can publish a technically valid artifact that still should not be trusted. Provenance, isolation, and identity controls are designed to make that harder by binding the artifact to a known build context.

For supply-chain integrity, the practical question is not “what dependencies exist?” but “can we prove how this artifact was made and whether the publishing path was trustworthy?” That is why build provenance sits closer to prevention, while SBOMs sit closer to visibility and response. Use both, but do not treat them as interchangeable.

What SBOMs do well, and where they fall short

An SBOM is valuable when you need to inventory components, compare affected versions, scope exposure, or accelerate response after a compromise. It helps teams answer what was inside the artifact at a point in time. It does not, by itself, prove that the artifact was built from clean inputs, on a trusted runner, or by a legitimate publishing workflow.

That limitation is important in AI-assisted attack chains because the attacker’s goal may be to poison the release process rather than hide a vulnerable library. If a package is produced through a compromised account or an over-permissioned automation path, the SBOM can still look normal. The risk is not only what the software contains, but whether the software supply path can be trusted.

CI/CD Pipeline Identity Security Guide is relevant here because provenance only works when publishing identities, token scopes, and runner trust are controlled tightly enough to make the build statement meaningful.

What build provenance and identity controls add that SBOMs cannot

Build provenance adds verifiable evidence about source, build environment, and artifact generation. In practice, that means organizations can check whether a release was built in an approved pipeline, whether the build inputs were expected, and whether the artifact is tied to a specific trusted process. When provenance is paired with signing and short-lived credentials, it becomes much harder for a compromised token to silently mint a trusted release.

That is especially relevant when the compromise path includes CI tokens, publishing credentials, or compromised automation identities. Those identities are often the real control plane for the release process. If they are stolen or overprivileged, attackers can create or replace artifacts faster than human review can react. Provenance does not eliminate that risk, but it gives verifiers a way to reject artifacts that cannot prove trustworthy origin.

SLSA is the clearest external anchor for this position because it formalises build provenance as a supply-chain integrity control. NIST SSDF (SP 800-218) also supports the broader practice by pushing secure development and release discipline, while OpenSSF provides the ecosystem context for provenance, signing, and supply-chain hardening.

Risk and Threat Considerations

Active supply chain attacks tend to exploit the gap between “artifact exists” and “artifact is trustworthy.” If runners, tokens, publishing identities, or signing keys are compromised, an attacker can produce a release that looks legitimate enough for downstream systems to accept. SBOMs do little to stop that initial compromise path.

Failure mechanism: The release path is subverted, allowing an attacker to generate, sign, or publish a malicious artifact from an otherwise normal pipeline, while an SBOM still describes the package contents as if they were trustworthy.

Impact: Downstream teams may ingest a poisoned build, trust it because it came from the expected ecosystem, and only discover the issue after deployment, broad exposure, or incident response.

Practitioner Guidance

What to prioritise: Treat build provenance, runner isolation, token minimisation, and artifact signing as the primary controls when the threat is release-path compromise. Use SBOMs alongside them, but do not let inventory controls delay hardening the build and publish chain.

What to verify: Check that published artifacts can be tied to a known build identity, a constrained build environment, and a reproducible trust policy. If a package cannot prove where it came from, treat that as a trust failure, not a documentation gap.

Common mistake: Teams often collect SBOMs first because they are easier to generate, then assume they have addressed supply-chain risk. That sequence leaves the highest-risk problem, malicious artifact creation, largely untouched.

Practitioner takeaway: Use SBOMs for visibility, but use provenance to decide trust. In an active compromise scenario, the order of operations should be verify the build path first, then use the SBOM to scope what was shipped.

Related resources from NHI Mgmt Group

• How should security teams defend against software supply chain attacks that target build and signing infrastructure?
• How can teams tell whether zero trust is actually helping against AI-driven attacks?
• How should security teams secure machine-to-machine trust against AI-driven attacks?
• How should security teams evaluate identity controls against AI-driven attacks?