Topic starter
20/08/2026 5:39 pm
TL;DR: Software Bill of Materials tools are now a compliance and supply chain security requirement, with the article arguing that the right choice depends on whether teams need generation, enrichment, governance, or all three, according to Xygeni. SBOMs that stop at inventory create governance blind spots; the operational test is whether they connect component data to exploitability, remediation, and audit evidence.
Editorial analysis by NHI Mgmt Group, based on content published by Xygeni: “Top 6 SBOM Tools in 2026”.
By the numbers:
- The Sonatype State of the Software Supply Chain report documented a 1,300 percent rise in malicious packages published to public registries in recent years.
Key questions
Q: What breaks when an SBOM is only an inventory file?
A: A static SBOM tells you what was present at generation time, but it does not tell you whether a component is exploitable, whether the data is current, or whether the evidence can support release and audit decisions.
Q: Why do SBOMs need vulnerability enrichment to be operationally useful?
A: Because the practical decision is not just what is included in software, but whether any included component creates real risk in the deployed context.
Q: What do security teams get wrong about SBOMs and open source governance?
A: Teams often treat SBOMs as the control itself rather than the inventory that supports control.
Practitioner guidance
- Standardise on a primary SBOM format strategy Choose SPDX, CycloneDX, or both based on whether your programme needs legal metadata depth, CI/CD speed, or broad ecosystem compatibility.
- Require enrichment before using SBOMs as release evidence Make exploitability, reachability, and known-vulnerability context mandatory so the SBOM can drive prioritisation instead of inventory alone.
- Tie SBOM generation to pipeline identity controls Review which build runners, dependency scanners, and export services can create or alter SBOM output, and narrow their permissions to the minimum required.
Bottom line: SBOM tooling has moved into the centre of compliance and software supply chain governance, not the edge of the development workflow.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:24 pm
SBOM maturity is now a governance test, not a formatting choice. Once SBOMs are tied to regulatory expectations and supplier assurance, the question is no longer whether teams can emit SPDX or CycloneDX. The harder question is whether the organisation can turn component data into risk decisions, evidence packs, and release gates. Practitioners should treat SBOM tooling as part of the control plane, not a documentation add-on.
A few things that frame the scale:
- The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
A question worth separating out:
Q: Should organisations prioritise SBOM signing or SBOM generation first?
A: They need both, but signing should be treated as the point where SBOMs become operationally useful. Generation creates the inventory, while signing makes it defensible. If a team can export SBOMs but cannot verify them later, it still lacks trusted release evidence.
👉 Read our full editorial: SBOM tools in 2026: compliance, risk enrichment, and workflow fit