TL;DR: An SBOM can turn software supply chain security into a fast inventory check, but only if it is derived from the binary you shipped rather than the manifest you intended, according to Finite State. Accuracy, not production, is the governance problem that decides whether SBOMs help during incidents, audits, and supplier disputes.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Finite State's blog post: SBOM governance's hard problem is not creating inventories but proving they match the software that actually shipped.
Why it matters: It matters to IAM and security practitioners because software supply chain assurance depends on trusted component inventories, which increasingly intersect with third-party access, NHI governance, and audit evidence.
Context
An SBOM is a machine-readable inventory of the components inside software, but an inventory only helps if it reflects what is actually running in production. In supply chain terms, the governance gap is between declared components and derived evidence, and that gap determines whether vulnerability response is precise or speculative. If your programme depends on software assurance, the question is not whether you can produce an SBOM, but whether you can defend it.
That problem matters because software supply chain risk often enters through third-party dependencies rather than direct compromise of the primary vendor. A reliable component inventory gives security, procurement, and PSIRT teams a shared reference point for exposure, remediation, and audit response. The same logic applies across identity-heavy environments where third-party software and delegated access can widen the blast radius.
Key questions
Q: How should security teams verify that an SBOM matches the software they actually shipped?
A: Teams should compare the vendor or build-generated SBOM with an independently derived view of the released binary or firmware. The goal is to catch statically linked code, vendored components, and version drift that never appear in manifests. If the two inventories disagree, treat that as a control failure and a supplier governance issue, not a paperwork mismatch.
Q: When should organisations prioritise derived SBOMs over declared SBOMs?
A: Prioritise derived SBOMs whenever the software is regulated, safety-critical, embedded, or distributed through multiple suppliers. In those cases, manifest-based inventories are too easy to drift from the shipped artifact. Declared SBOMs still help, but they should be treated as supporting evidence rather than the primary source of truth.
Q: What breaks when an SBOM is built from the wrong source artifact?
A: The inventory becomes incomplete, vulnerability matching gets noisy, and incident scoping slows down. Teams may miss vendored or patched code, misstate exposure to customers, and waste time reconciling false confidence with real production risk. In practice, the programme stops being a decision aid and becomes a document with limited evidentiary value.
Q: Should supplier-provided SBOMs be trusted without independent validation?
A: No. Supplier SBOMs are useful inputs, but they should be verified against the deployed artifact before they are used for compliance, triage, or procurement decisions. Independent validation gives you a defensible basis for incident response and reduces the chance that an incomplete declaration becomes your only evidence.
Technical breakdown
Declared SBOMs vs derived SBOMs
A declared SBOM is assembled from source manifests, lock files, and supplier attestations. A derived SBOM is inferred from the binary or firmware that was actually shipped. The difference matters because builds can statically link libraries, vendor code, or patch components after the manifest was written. When those changes occur, the declared inventory can look complete while missing the code that is really present. For security teams, this is a provenance problem, not a documentation problem. A binary-derived inventory is the evidence grade record, while a manifest-derived inventory is only the claim. See the Software Supply Chain Security Guide. See the Software Supply Chain Security Guide.
Practical implication: Validate high-risk software inventories against shipped binaries, not just build artifacts.
Why format is not the hard part
SPDX and CycloneDX are both viable SBOM formats, and mature programmes often support both. The real challenge is fidelity, not file syntax. Procurement teams tend to prefer SPDX because it is easier to read in legal and contractual workflows, while security teams often prefer CycloneDX because automation, vulnerability workflows, and VEX handling are stronger fits. Format conversion is usually solvable; inconsistent identifiers, missing fields, and stale inventories are not. In practice, teams fail when they treat format choice as the programme goal instead of a transport layer for trustworthy evidence. See the SBOM Guide. See the SBOM Guide.
Practical implication: Choose the format that fits the consumer, then invest more effort in inventory accuracy than in file standard debates.
The trust problem in third-party software evidence
Software supply chain security depends on being able to reconcile vendor-provided inventory with independent verification. That is especially important where third-party components, open source libraries, and transitive dependencies are involved, because the downstream customer inherits risk without inheriting visibility. In identity terms, the same governance pattern appears when a supplier or integration holds access that the buyer cannot independently observe. The article’s core insight is that trust must be earned with evidence, not assumed from a document alone. See the SaaS-to-SaaS and OAuth App Governance Guide. See the SaaS-to-SaaS and OAuth App Governance Guide.
Practical implication: Require independent verification for vendor inventories before you rely on them for incident scoping or compliance evidence.
Threat narrative
Attacker objective: Exploit hidden dependency exposure to reach many downstream environments before defenders can accurately scope affected products.
- Entry occurs through a widely used dependency or upstream component that enters many products through normal build and integration paths.
- Credential or inventory assumptions fail when the shipped binary contains components that the declared SBOM never listed.
- Impact follows when teams discover the gap only during a vulnerability event, forcing manual archaeology and slowing remediation and reporting.
Breaches seen in the wild
- LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
- Vercel Context.ai OAuth Supply Chain Breach: Shadow AI app Context.ai OAuth integration exposes Vercel customer data via unmanaged third-party token.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
SBOM governance has moved from documentation hygiene to evidence integrity. The central issue is not whether teams can generate a component list, but whether they can prove the list matches the shipped artifact. That shifts SBOM ownership toward security, product, and PSIRT workflows rather than leaving it as a release-note by-product. Practitioners should treat inventory fidelity as a control objective, not a reporting exercise.
Declared inventory alone creates a verification trust gap. When suppliers provide SBOMs from manifests or build metadata, buyers still need independent validation against the binary they deployed. This is where software assurance meets third-party governance, because downstream risk cannot be managed from declarations alone. The more regulated or critical the product, the more important this independent check becomes for audit and incident response.
Software supply chain risk becomes operational when provenance is weak. The article’s strongest point is that reachability, version matching, and component identity only work when the underlying artifact is trustworthy. Without that, SBOMs can become a noisy backlog rather than a decision tool. In NHI terms, the same lesson applies to delegated software access and supplier-held credentials: evidence must be tied to what actually executes.
Binary-derived inventories are the named concept that changes the category. This is the difference between a paper claim and a defensible security record. Binary-derived SBOMs are not a niche improvement, they are the governance threshold for teams that need to answer auditors, customers, and PSIRT questions with confidence. Practitioners should anchor their programme around evidence derivation, not document production.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Read next: Software Supply Chain Security Guide
What this signals
Binary provenance is becoming the real SBOM control. The market has largely accepted that inventories are necessary, but the next governance question is whether those inventories are derived from the shipped artifact or merely declared from the build chain. That distinction will increasingly shape procurement friction, audit outcomes, and how quickly PSIRT teams can act when a new vulnerability lands.
For identity and access programmes, the lesson is familiar: controls fail when the system of record is not the system of action. SBOMs only support secure operations when the evidence matches reality, which is why verification, not just generation, is where mature programmes will differentiate themselves. Teams that already manage third-party access and delegated trust should recognise the same pattern in their software supply chains.
For practitioners
- Derive SBOMs from shipped binaries Generate the inventory from the artifact you actually release, then compare it to supplier declarations to expose missing or mismatched components.
- Validate supplier SBOMs independently Request the SBOM for the exact deployed version, then run independent analysis so you can confirm the supplier inventory matches production reality.
- Automate SBOM generation in the build Wire inventory creation into CI/CD so every version and custom build produces a fresh SBOM without relying on manual updates.
- Pair inventory with reachability and VEX Use exploitability context to reduce noise, then publish machine-readable statements about vulnerabilities that are present but not reachable.
Key takeaways
- SBOM value comes from proving what shipped, not just listing what was intended to ship.
- Derived inventories close the gap between supplier declarations and the binaries teams actually deploy.
- Programmes that combine verification, automation, and exploitability context turn SBOMs into operational evidence instead of documentation overhead.
Related NHI Mgmt Group resources: Software Supply Chain Security Guide · CI/CD Pipeline Identity Security Guide · SaaS-to-SaaS and OAuth App Governance Guide · SBOM Guide
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 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Third-party software components and integrations are the article's main supply chain risk vector. |
| NHI-02 — Secret Leakage | The article stresses that shipped artifacts can contain unlisted components, which often co-travel with exposed secrets and hidden dependencies. | |
| Recommendation — Track third-party component exposure and verify supplier inventories before trusting them in production decisions. Scan shipped artifacts and build outputs for hidden components and exposed secrets before release. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | Supply chain compromise often enables hidden access and downstream data theft across many products. |
| Recommendation — Map component compromise to credential access and exfiltration paths in your detection and response plans. | ||
| NIST CSF 2.0 | PR.DS-10 — Data-in-Transit Is Protected | SBOM exchange and supplier validation rely on secure handling of product and supply-chain evidence. |
| Recommendation — Protect SBOM distribution and validation workflows with authenticated, integrity-checked transfer paths. | ||
| NIST SP 800-53 Rev 5 | SA-10 — Developer Configuration Management | The article focuses on controlling what actually ships through the build process and traceability. |
| Recommendation — Tie SBOM generation to developer configuration management and release traceability controls. | ||
Key terms
- Software Bill of Materials: A software bill of materials is an inventory of the components and dependencies used in an application. It helps teams identify what they shipped, but it becomes most useful when paired with source verification, signature checks, and policy enforcement for third-party code.
- Declared SBOM: A declared SBOM is generated from source repositories, manifests, lock files, or supplier attestations rather than from the shipped artifact itself. It is faster to produce, but it can miss statically linked, vendored, or patched components that only appear in the final binary.
- Derived SBOM: A derived SBOM is produced by analysing the binary, firmware, or executable that was actually released. It is more evidentiary than a declared inventory because it can surface components that were added, bundled, or altered during build and packaging.
- Vex: VEX, or Vulnerability Exploitability eXchange, is a way to state whether a known vulnerability is exploitable in a specific product, build, or deployment. It helps security teams avoid treating every matching CVE as equally urgent and improves prioritisation in software supply chains.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course.Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org