Notifications
Clear all
Topic starter
02/08/2026 11:28 am
TL;DR: ENISA’s SBOM Adoption State of Play 2026 surveyed 334 organisations and found that 74% have at least partially automated SBOM generation, yet only 7% say they have closed the gap between creating SBOMs and actually using them for vulnerability and licence management, according to Aikido’s summary of the report. The real problem is not producing inventory, but operationalising it across suppliers, formats, and remediation workflows.
NHIMG editorial — based on content published by Aikido: SBOMs in 2026: Everyone's generating them, no one's using them
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.
Questions worth separating out
Q: What breaks when organisations generate SBOMs but do not consume them?
A: The SBOM becomes compliance evidence rather than a security control.
Q: Why do SBOM programmes fail even when generation is automated?
A: Automation solves only the creation step.
Q: What do security teams get wrong about supplier SBOMs?
A: They often assume receipt equals assurance.
Practitioner guidance
- 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.
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.
👉 Read Aikido's analysis of SBOM adoption gaps and CRA pressure →
SBOMs in 2026: where does the governance gap actually sit?
Explore further
02/08/2026 12:44 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: SBOM adoption is stalling at the point of use, not generation
