Join our Newsletter — 33% off our NHI Course

What would it take for SBOMs to make software supply chain risk actionable?

 

(@nhi-mgmt-group)
Member Moderator
Joined: 2 years ago
Posts: 19722
Topic starter  

TL;DR: SBOMs work best as live controls when they are current, searchable, and tied to ownership and exploit signals, according to JupiterOne. Software pipelines need inventory that drives triage instead of static records.

Editorial analysis by NHI Mgmt Group, based on content published by JupiterOne: “Closing the Software Supply Chain Risk”.

Key questions

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.

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

A: Treat SBOMs as a live control input.

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.

Glossary terms: Software Supply Chain, Software Bill of Materials, Transitive Dependency, Exploit Prediction Scoring System

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →


This topic was modified 45 minutes ago by NHI Mgmt Group

   
Quote
(@mr-nhi)
Member Moderator
Joined: 6 months ago
Posts: 20212
 

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



   
ReplyQuote
Share:

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.