SBOM adoption is stalling at the point of use, not generation

At a glance

What this is: This is an analysis of ENISA’s 2026 SBOM adoption survey, and its key finding is that most organisations can generate SBOMs but struggle to use them operationally.

Why it matters: It matters to IAM and security practitioners because SBOM governance depends on reliable inventories, supplier accountability, and control over the software supply chain that underpins modern identity and application environments.

By the numbers:

• ENISA surveyed 334 organizations for its SBOM Adoption State of Play 2026 report.
• 74% have at least partially automated per-release generation.
• Only 7% have closed the gap between generating SBOMs and actually using them.
• 39% of organizations never receive SBOMs for the commercial software they buy.

👉 Read Aikido's analysis of SBOM adoption gaps and CRA pressure

Context

Software Bill of Materials governance is supposed to give teams a trustworthy inventory of what is inside the software they build, buy, and ship. In practice, the hard problem is not generation but consumption, because an SBOM has little security value if it never reaches vulnerability triage, licence review, supplier assurance, or build-time decision-making. That gap is where software supply chain risk becomes operational rather than theoretical.

The article’s focus is on SBOM adoption under the pressure of the Cyber Resilience Act, which makes completeness, machine readability, and supplier visibility a compliance and security issue at the same time. For identity and access programmes, the intersection is real: build systems, developer machines, service credentials, and supplier integrations all depend on the same trust chain, and weak SBOM governance often signals weak control over the surrounding non-human identities.

Key questions

Q: What breaks when organisations generate SBOMs but do not consume them?

A: The SBOM becomes compliance evidence rather than a security control. Vulnerabilities, licence issues, and supplier exposure remain hidden in plain sight because no workflow is consuming the inventory and turning it into action. That leaves teams with documentation but without decision-making, which is exactly where supply chain risk persists.

Q: Why do SBOM programmes fail even when generation is automated?

A: Automation solves only the creation step. Programmes still fail when component data is incomplete, identifiers are inaccurate, or vulnerability matching is too noisy to trust. In that state, teams cannot confidently triage exposure, so the SBOM never becomes a usable input to remediation or procurement decisions.

Q: What do security teams get wrong about supplier SBOMs?

A: They often assume receipt equals assurance. In reality, many organisations receive SBOMs rarely or not at all, and even when they do, the data may lack depth, freshness, or consistent machine-readable structure. Supplier transparency has to be enforced, verified, and operationalised, not simply requested.

Q: How should organisations use SBOMs to improve software supply chain governance?

A: Treat SBOMs as a live control input. Connect them to vulnerability management, licence review, build approvals, and supplier assurance so they drive action across the product lifecycle. That approach turns inventory into governance and exposes where third-party dependencies create unacceptable risk.

Technical breakdown

Why SBOM generation is not the same as SBOM use

An SBOM is an inventory file, not a control by itself. Its security value depends on whether component data is consumed by vulnerability management, licence review, procurement, and release governance. Many programmes stop at generation because the export looks like progress, but the actual work begins when component identifiers, version data, and transitive dependencies must be matched against exposure, policy, and business risk. If that matching layer is weak, the organisation has documentation without decision support.

Practical implication: wire SBOM output into remediation and supplier workflows, not just artifact storage.

Why completeness and identifier accuracy break the workflow

SBOM programmes fail when component data is incomplete, duplicated, or poorly normalised. Vulnerability matching depends on identifiers such as CPE and PURL, but real-world component metadata is often messy, especially across multi-language builds and transitive dependencies. If the underlying data quality is poor, teams spend more time resolving false positives than reducing risk. That is why completeness and accuracy are not reporting metrics alone. They determine whether the SBOM can support actual security decisions or only compliance evidence.

Practical implication: define minimum data quality thresholds before treating SBOMs as trusted security input.

How supplier SBOMs expose third-party trust gaps

Supplier-provided SBOMs extend visibility beyond internally built software into the commercial products and components that enterprises consume. That matters because many organisations do not receive SBOMs consistently, and even fewer can verify depth, format, or freshness. In identity terms, this is an assurance problem around third-party trust and delegated dependency chains. If supplier inventory is incomplete, the enterprise cannot reliably bound exposure in the software it inherits from others.

Practical implication: require SBOM depth, format, and delivery terms in supplier governance and contract language.

Threat narrative

Attacker objective: The attacker’s objective is to exploit blind spots in the software supply chain by hiding vulnerable or malicious components inside trusted build and supplier paths.

1. Entry occurs through unobserved or under-documented software components in the build and supplier chain, where missing SBOM data hides what is actually present.
2. Escalation follows when vulnerable transitive dependencies or unverified supplier packages remain in use because the organisation cannot match them reliably to known issues.
3. Impact is realised as exposure persists across releases, delaying remediation, weakening assurance, and leaving compliance evidence disconnected from real security posture.

NHI Mgmt Group analysis

SBOM generation fatigue is becoming a governance failure mode. Organisations are treating SBOM production as an endpoint, when the security outcome depends on consumption. That creates posture without protection, especially when vulnerability management, procurement, and release approvals remain disconnected. The discipline problem is not lack of files but lack of operational ownership. Practitioners should treat SBOM use as a control objective, not a documentation task.

Supplier transparency is now part of identity assurance. Software supply chain trust is increasingly mediated by non-human identities such as build tokens, repository credentials, signing keys, and package automation. If those identities are not tightly governed, the SBOM stream can be accurate on paper and unreliable in practice. This is where NHI governance intersects directly with software assurance: the trust chain is only as strong as the credentials and automation that produce it.

Completeness debt is the right named concept for this market. SBOM programmes accumulate risk when partial inventories, inconsistent formats, and missing supplier data prevent teams from acting with confidence. That debt is invisible until a vulnerability lands, but it steadily reduces the organisation’s ability to prove control. The practical conclusion is that completeness must be measured as a security control, not reported as an administrative metric.

CRA pressure is forcing the market away from symbolic transparency. The regulation is pushing organisations to move from generating artifacts to demonstrating usable inventory across the product lifecycle. That shift will expose weak data pipelines, weak supplier clauses, and weak remediation workflows faster than many teams expect. Practitioners should assume the next maturity step is not more SBOM volume, but better decision integration.

Build environment visibility is the missing complement to SBOMs. An SBOM tells you what went into the product, but not whether the machine building it was trustworthy. That leaves a blind spot around developer endpoints, CI runners, and pipeline credentials that supply chain attackers increasingly target. Teams that stop at artifact-level transparency will miss the environment-level assurance problem that governs whether the artifact can be trusted at all.

What this signals

Completeness debt is the operational risk that matters here. Once inventory data is partial, teams begin making decisions on assumptions rather than evidence, and that weakens both security posture and regulatory defensibility. The right response is to treat SBOM quality as a control objective tied to remediation speed, procurement gates, and supplier assurance.

The broader signal for practitioners is that software supply chain governance is becoming inseparable from identity governance. Build automation, signing flows, and package publishing all depend on non-human identities, and those identities need the same lifecycle discipline as any other privileged account. For further context on secret exposure patterns, see the State of Secrets Sprawl 2026 and the OWASP Non-Human Identity Top 10.

For practitioners

• Define SBOM consumption owners Assign explicit ownership for vulnerability matching, licence review, and release gating so SBOMs feed operational decisions instead of sitting in artifact storage.
• Set minimum SBOM quality thresholds Require completeness, identifier accuracy, and dependency depth before accepting supplier or internal SBOMs as trusted input to risk workflows.
• Embed supplier SBOM clauses in procurement Make SBOM format, delivery cadence, and update obligations part of supplier contracts so third-party software is governed like any other trusted dependency.
• Link build identity to software assurance Review the non-human identities used in CI pipelines, signing flows, and package publishing, because compromised build credentials can undermine every downstream inventory control.

Key takeaways

• Most organisations can generate SBOMs, but the security value appears only when those files are consumed by remediation, procurement, and release governance.
• Supplier incompleteness, identifier errors, and format fragmentation are the real blockers, because they prevent teams from trusting the inventory enough to act on it.
• The practical shift is from producing compliance artifacts to governing software supply chains through live inventory, supplier obligations, and build identity assurance.

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.
• SBOM consumption: SBOM consumption is the process of using component inventory data to drive security and compliance decisions. It only has value when the information is linked to vulnerability management, procurement, release governance, and supplier assurance rather than archived as static evidence.
• Transitive dependency: A transitive dependency is a component that is pulled in indirectly through another library or package rather than chosen directly by the developer. These dependencies often create hidden risk because they can introduce vulnerabilities or licensing issues that are not obvious from the top-level application code.
• Completeness debt: Completeness debt is the accumulated risk created when inventory data is partial, inconsistent, or missing across software supply chains. It reduces confidence in SBOM-driven decisions and slowly turns a compliance artefact into a weak, operationally unreliable control.

What's in the full article

Aikido's full blog covers the operational detail this post intentionally leaves for the source:

• A step-by-step explanation of how Aikido enriches SBOMs with license and copyright data after generation.
• A practical breakdown of how its CycloneDX export separates direct from transitive dependencies for CRA alignment.
• Details on importing supplier self-reported SBOMs into vulnerability monitoring workflows.
• Operational context on extending visibility into build servers and developer machines with Aikido Device Protection.

👉 Aikido's full blog covers SBOM consumption, supplier gaps, and build-environment visibility in more operational detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives practitioners a structured way to connect identity controls to the software supply chain and adjacent security programmes.