Notifications
Clear all
Topic starter
02/08/2026 11:30 am
TL;DR: Software bills of materials are moving from static inventory exercises to operational security controls as teams try to track components, detect drift, and prioritise reachable vulnerabilities across modern software supply chains, according to OXSecurity. The governance challenge is no longer whether you can list dependencies, but whether you can keep that inventory aligned with what actually runs.
NHIMG editorial — based on content published by OXSecurity: What is an SBOM?
By the numbers:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities - 46% confirmed, 26% suspected.
Questions worth separating out
Q: How should security teams implement SBOM signing in CI/CD pipelines?
A: Treat SBOM signing as part of the build, not a separate compliance task.
Q: Why do SBOMs need runtime awareness instead of build-time inventories only?
A: Because software changes after it is built, and the security question is not just what was packaged but what is actually loaded and reachable in production.
Q: What do security teams get wrong about supplier SBOMs?
A: They often assume receipt equals assurance.
Practitioner guidance
- Embed SBOM generation into the delivery pipeline Generate SBOMs at build time and refresh them at deployment so package inventories stay tied to source control, container images, and release artifacts.
- Add drift detection to deployed software Compare declared SBOM content with runtime packages, images, and loaded libraries so teams can flag divergence before it becomes a blind spot.
- Prioritise reachable vulnerabilities first Use runtime and call-path data to focus on dependencies that are actually invoked, especially in internet-facing services and privileged workflows.
What's in the full article
OXSecurity's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step SBOM generation and drift detection workflow guidance across build and deployment stages
- Examples of SBOM software features for SPDX and CycloneDX export, runtime mapping, and prioritisation
- Practical discussion of SBOM SaaS versus on-prem deployment trade-offs for regulated environments
- How OXSecurity describes code-to-runtime mapping and integrated prioritisation across SAST, SCA, secrets, and API scanning
👉 Read OXSecurity's guide to SBOM governance, runtime drift, and AI-assisted prioritisation →
SBOM drift and runtime risk: what should security teams change now?
Explore further
02/08/2026 12:45 pm
SBOM governance has moved from inventory management to runtime exposure control. Build-time lists are necessary but no longer sufficient because modern software changes after compilation, deployment, and containerisation. A static SBOM can say what was intended, not what is reachable in production. Practitioners should treat runtime alignment as the real control objective.
A question worth separating out:
Q: How should organisations govern the non-human identities behind SBOM tooling?
A: Treat build systems, scanners, and signing services as privileged machine identities. Restrict their access, rotate their secrets, and monitor their behaviour because compromise of those accounts can undermine the integrity of the entire SBOM process.
👉 Read our full editorial: SBOM governance is shifting from inventory to runtime risk control
