Topic starter
11/07/2026 8:30 pm
TL;DR: SBOMs are becoming operational controls rather than compliance artefacts, according to JupiterOne, because deep dependency visibility, in-place scanning, and EPSS-based prioritisation can cut investigation time from hours to seconds when packages like log4j-core appear in production. The real shift is that software supply chain governance now depends on searchable, current inventory, not static documentation.
Editorial analysis by NHI Mgmt Group, based on content published by JupiterOne: “Closing the Software Supply Chain Risk”.
Key questions
Q: How should organisations use SBOMs to improve software supply chain governance?
A: Treat SBOMs as a live control input.
Q: Why do transitive dependencies create more exposure than top-level package scans show?
A: Transitive dependencies often carry the vulnerable code that defenders do not see in a simple package list.
Q: What are the signs that SBOM data is too stale to support response?
A: The warning signs are manual lookup, unclear ownership, and long delays when a vulnerability appears in a commonly used component.
Practitioner guidance
- Implement SBOM generation in CI/CD Generate SBOMs as part of the build so every release produces an updated inventory of images, packages, and transitive dependencies.
- Scan registry images in place Point scanning to connected registries and inspect images where they already live, rather than exporting artefacts into separate analysis workflows.
- Map transitive dependencies to owners Link code modules and container images to the teams and environments that run them so response does not stall at discovery.
Bottom line: Software supply chain risk becomes harder to control when teams cannot see transitive dependencies inside the images and packages they deploy.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/07/2026 9:00 pm
SBOM visibility is now a control problem, not a documentation problem. The important question is no longer whether teams can generate a list of components, but whether that list stays connected to live registries, build outputs, and ownership data. Static inventories do not support fast decisions when a dependency vulnerability drops into production. Practitioners should treat SBOM data as a governed operational asset, not a compliance attachment.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Should organisations prioritise EPSS or CVSS when fixing supply chain vulnerabilities?
A: They should use both, but not as equals. CVSS tells you how severe a flaw may be, while EPSS helps identify what is most likely to be exploited soon. In a crowded dependency estate, exploit likelihood is often the better trigger for first-line remediation, especially when exposure spans multiple images and modules.
👉 Read our full editorial: Software supply chain risk needs SBOM visibility in modern pipelines