Should organisations prioritise SLSA over SBOMs for software trust?

Why SLSA and SBOMs Are Not Competing Controls

SLSA and SBOMs answer different trust questions. An SBOM is primarily a visibility and inventory artifact, it helps you see what components are present and where dependencies may sit. SLSA is a provenance and integrity control, it helps you assess whether the artifact was built in a trustworthy way. For software trust, provenance usually matters more than inventory alone because a complete bill of materials does not prove how the software was produced.

The practical distinction is important because the two controls support different decisions. SBOMs are useful when you need dependency awareness, vulnerability matching, or supply-chain triage. SLSA-style controls become more important when you need to trust the build pipeline, the artifact source, and the release path. A program can have a strong SBOM process and still ship a tampered or poorly attested build.

This is why mature software assurance programmes treat SBOMs and SLSA as complementary, not interchangeable. If the question is “what is inside this package?”, an SBOM is the right evidence. If the question is “can I trust this binary or image to be the output of a controlled build?”, provenance controls carry more weight. That distinction also explains why SLSA is commonly paired with signed builds, artifact attestation, and verified release processes.

When Provenance Should Take Priority Over Visibility

Prioritise SLSA first when your main concern is whether the artifact itself can be trusted. That is the case for release pipelines, build integrity, dependency tampering, and supply-chain compromise during artifact creation. Visibility alone cannot stop a compromised build system from producing an artifact that looks legitimate but was assembled under attacker influence.

SBOMs still matter in that environment, but they answer a later-stage question. They help teams locate affected packages, assess exposure, and support response once software exists. They do not by themselves establish build integrity, source traceability, or release authenticity. For that reason, provenance is the stronger control when trust in the shipped artifact is the business requirement.

For teams working across open-source and internal delivery chains, OpenSSF materials and SLSA guidance are useful because they reinforce the broader pattern: secure the pipeline, verify the artifact, then use the SBOM for downstream inventory and response.

What a Mature Programme Does With Both

The best operating model is layered. Use SBOMs to maintain component visibility, support vulnerability management, and answer consumer or regulator questions about software composition. Use SLSA-style provenance controls to protect the build path, reduce the chance of untrusted artifacts, and make releases more defensible. In other words, SBOMs improve observability, while SLSA improves trustworthiness.

In practice, the build side is where many teams underinvest. A complete component list is easy to report, but it can create a false sense of security if the pipeline still allows unpinned dependencies, weak publishing credentials, mutable build environments, or unsigned release artifacts. Controls that protect the CI/CD path are therefore central to software trust, which is why a CI/CD Pipeline Identity Security Guide is relevant to the same trust problem even when the question starts with SBOMs.

That split also helps with governance. Ask whether the control is needed to answer “what do we have?” or “can we trust how it was made?”. If you cannot clearly separate those two decisions, the programme usually ends up over-indexing on inventory and under-indexing on provenance.

Risk and Threat Considerations

The main risk is treating software composition as a proxy for software integrity. Attackers and compromised build dependencies can produce artifacts that are fully describable by an SBOM yet still untrustworthy, because the weakness lies in the build path, signing process, or publishing workflow rather than the inventory itself.

Failure mechanism: A malicious or compromised dependency, pipeline credential, or build step can alter the artifact before release, while the SBOM remains accurate about components but silent about provenance and tampering.

Impact: Teams may ship, accept, or repeatedly consume software that appears transparent on paper but cannot be relied on operationally. That increases the blast radius of supply-chain compromise and weakens downstream incident response, because visibility does not equal authenticity.

Practitioner Guidance

What to prioritise: If you are choosing sequencing, start with provenance for the software that matters most, then add SBOM coverage for inventory and response maturity. High-trust release paths, critical infrastructure, and externally distributed packages deserve the strongest build verification first.

What to verify: Confirm that the release process can prove who built the artifact, under what conditions, and with what controls around source, dependencies, and signing. If the team can only produce a component list but not a trustworthy build story, the programme is not ready to rely on SBOMs alone.

Practitioner takeaway: Prioritise the control that answers the real trust question, and use the other control to fill the gap, not to substitute for it.

Related resources from NHI Mgmt Group

• When should organisations prioritise Zero Standing Privilege for non-human identities?
• When should organisations prioritise Zero Trust over SASE?
• When should organisations prioritise access governance over software spend optimisation?
• When should organisations prioritise Zero Trust for OT over perimeter upgrades?