Notifications
Clear all
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.
NHIMG editorial — based on content published by JupiterOne: Closing the Software Supply Chain Risk
Questions worth separating out
Q: How should security teams operationalise SBOMs in software delivery pipelines?
A: Security teams should generate SBOMs as part of build and registry workflows, then keep them searchable next to the images and components they describe.
Q: Why do transitive dependencies create more software supply chain risk than direct packages alone?
A: Transitive dependencies hide exposure inside nested libraries that are often missed by top-level package reviews.
Q: How do teams know if SBOM-based prioritisation is working?
A: It is working when remediation queues track exploit likelihood, ownership, and deployment reach rather than just raw severity counts.
Practitioner guidance
- Generate SBOMs at build and registry time Produce SBOMs where software is created or stored so the inventory reflects what is actually deployable, not a stale post-hoc snapshot.
- Track transitive dependencies as first-class risk items Do not limit review to direct packages.
- Prioritise by exploitability, not severity alone Use EPSS or a similar likelihood signal alongside SBOM findings to rank remediation by real-world attack pressure.
What's in the full article
JupiterOne's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step SBOM workflow examples for registry-scanned container images and connected GitHub sources
- Query logic for finding vulnerable components, affected images, owners, and environments in one pass
- Practical guidance on using EPSS data to rank remediation across crowded vulnerability queues
- Implementation guidance for keeping SBOMs current with every build instead of relying on manual refreshes
👉 Read JupiterOne's analysis of SBOM-driven software supply chain risk →
SBOM visibility in pipelines: what security teams need to know?
Explore further
11/07/2026 9:00 pm
Software supply chain visibility is now a governance problem, not just a DevSecOps concern. When teams cannot answer what is in a container image or which dependencies are deployed, they cannot govern exposure in a meaningful way. SBOMs become a control layer for accountability because they link software composition to operational ownership and remediation. Practitioners should treat inventory quality as part of risk governance, not as a compliance artefact.
A question worth separating out:
Q: Who should own remediation when a vulnerable package appears across multiple environments?
A: Ownership should follow the service or platform team that can actually change the affected component, with security coordinating the risk decision and verification. SBOMs help by linking the package to owners and environments, which reduces the time lost to internal handoffs and makes accountability clearer.
👉 Read our full editorial: Software supply chain risk needs SBOM visibility in modern pipelines
