Pipeline hardening usually comes first because a complete SBOM still does not protect a build system that can be tampered with. The strongest position is to treat both as linked controls, but to secure the build path before relying on the inventory it produces.
Why the build path usually deserves attention before the inventory
SBOMs and pipeline hardening solve different problems. An SBOM helps you understand what went into a release, but a compromised build system can still produce a trustworthy-looking inventory for a tampered artifact. That is why the first priority is usually to protect the build path, then use the SBOM as evidence that the path is producing something you can trust.
The practical distinction is between visibility and control. SBOMs improve software transparency, dependency review, and downstream response, while pipeline hardening reduces the chance that the build, signing, or publishing stages are altered before the artifact is released. If the pipeline is weak, the SBOM can become a record of a bad build rather than a safeguard against one.
In other words, the question is not whether SBOMs matter. It is whether the organisation can rely on the process that generates them. For release integrity, provenance and environment control are the foundation; the inventory becomes more useful once the path that emits it is already constrained and monitored. See the broader supply-chain perspective in AI Supply Chain Security and AI-BOM Guide, which also treats inventory as one part of a larger integrity problem.
Where SBOMs help, and where they do not
SBOMs are strongest when the question is, “What components, versions, and dependencies were included?” That helps with vulnerability triage, license review, impact analysis, and post-release response. It does not, by itself, answer whether the build environment was trusted, whether artifacts were injected, or whether a dependency was swapped during compilation or packaging.
That limitation matters in real incidents. If attackers can reach source control, CI/CD tokens, runners, artifact storage, or signing steps, they may be able to change output without changing the SBOM logic around it. The resulting bill of materials may still look consistent with the pipeline’s declared inputs, even though the pipeline itself has been subverted. Campaigns like Shai Hulud npm malware campaign show why exposed build-time secrets and compromised tooling turn supply-chain metadata into only partial assurance.
That is why SBOM adoption should be paired with provenance, signing, controlled dependencies, protected runners, and access restrictions on build and release paths. If those controls are missing, the SBOM tells you more about intent than integrity.
How to sequence the work without treating it as an either-or choice
The sensible sequence is to stabilise the build path first, then use SBOMs to deepen visibility and response. Pipeline hardening reduces the blast radius of compromise by narrowing who and what can alter the build. SBOMs then improve what defenders can inspect, compare, and prioritise after the build system is already less exposed.
That sequence does not mean delaying SBOMs indefinitely. A basic SBOM process can be introduced early, but it should not be treated as the primary integrity control. The highest-value early work is usually around build access, secret handling, artifact integrity, approval gates, reproducible build practices where feasible, and logging that lets teams prove what happened during release. reviewdog Action compromise 2025 and ArtiPACKED 2024 are useful reminders that leaked CI/CD tokens and exposed artifacts can undermine release trust long before an inventory is consulted.
A good decision rule is simple: if a compromised build could publish or sign something your teams would accept as legitimate, harden the pipeline before you rely on the SBOM as evidence of trust.
Risk and Threat Considerations
The main risk is false confidence. Organisations can end up with an accurate list of components for an artifact that should never have been trusted in the first place. The second risk is that attackers target the pipeline because it offers leverage over many releases at once, especially when secrets, signing keys, runners, or publishing permissions are too broad.
Failure mechanism: An attacker or insider tampers with source, build steps, dependencies, secrets, or signing flows, then uses the resulting pipeline output to produce an artifact and SBOM that appear legitimate.
Impact: Defenders may trust, deploy, or redistribute a compromised release, and downstream response may be delayed because the inventory data looks consistent even though the production path was not trustworthy.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while SLSA and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Leaked build secrets can compromise pipelines and invalidate release trust. |
| NHI-07 — Long-Lived Secrets | CI/CD tokens and release credentials often persist too long in build systems. | |
| Recommendation — Rotate exposed build secrets and limit their scope to reduce pipeline tampering risk. Replace long-lived build credentials with short-lived, tightly scoped access. | ||
| SLSA | Supply-chain integrity | The question is about build provenance and release trust, which SLSA directly addresses. |
| Recommendation — Adopt stronger provenance and integrity requirements for build and release paths. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Pipeline hardening depends on secure build configurations and reduced tampering surface. |
| CIS-5 — Account Management | Build systems rely on tightly governed accounts and tokens that affect release integrity. | |
| Recommendation — Harden build and CI/CD configurations to reduce unauthorized change paths. Restrict and review accounts that can change, sign, or publish software artifacts. | ||
Practitioner Guidance
What to prioritise: Treat build-system access, secret handling, and artifact integrity as the first control layer. If those are weak, an SBOM mainly improves post-incident analysis, not release assurance.
What to verify: Check whether the pipeline can be altered by broad human access, long-lived credentials, unprotected runners, or unreviewed third-party actions. If yes, the inventory cannot be treated as strong proof of integrity.
What good looks like: A release path where build inputs are controlled, signing is tightly constrained, and the SBOM is generated by a process that already has meaningful barriers against tampering.
Practitioner takeaway: Use SBOMs to make software more explainable, but harden the pipeline first so the thing being explained is actually trustworthy.
Related resources from NHI Mgmt Group
- What should organisations prioritise first: takeover response or inbox hardening?
- Should organisations prioritise secret scanning or pipeline policy enforcement first?
- Should organisations prioritise supplier access review or perimeter hardening first?
- Should organisations prioritise patching or identity hardening first after active exploitation is detected?