Notifications
Clear all
Topic starter
18/08/2026 2:40 pm
TL;DR: SBOM programmes fail when they are treated as one-time compliance artefacts instead of living controls that track software change, ownership, coverage, and disclosure, according to FOSSA’s webinar recap. The operational lesson is that repeatable SBOM generation, consistent measurement, and VEX-based status handling matter more than choosing a format too early.
NHIMG editorial — based on content published by FOSSA: webinar guidance on standing up an SBOM programme
By the numbers:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- Only 5.7% of organisations have full visibility into their service accounts.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
Questions worth separating out
Q: How should organisations start an SBOM programme without overcomplicating it?
A: Start with why the SBOM exists, who owns it, and which systems matter most.
Q: When does an SBOM become useful for security teams?
A: An SBOM becomes useful when it drives workflow, not when it sits as a document.
Q: What do teams get wrong about SBOM data?
A: They often treat SBOM as proof of safety rather than a starting point for verification.
Practitioner guidance
- Define SBOM ownership and decision rights Assign clear ownership across product security, application security, and engineering so there is one accountable team for scope, cadence, and disclosures.
- Automate SBOM regeneration on software change Treat every material code or dependency change as a trigger for a fresh SBOM.
- Set scope before debating formats Start with the products, services, or regulated systems that matter most, then choose CycloneDX or SPDX as a downstream implementation decision.
What's in the full article
FOSSA's full article covers the operational detail this post intentionally leaves for the source:
- A practical four-stage SBOM operating model that maps directly to programme rollout decisions
- Examples of how to wire SBOM generation into build and release workflows without slowing delivery
- Guidance on using VEX to explain vulnerability relevance to auditors, customers, and internal stakeholders
- Discussion of disclosure boundaries, including what metadata should stay internal versus what can be shared externally
👉 Read FOSSA's webinar-based guidance on building and operating an SBOM programme →
SBOM lifecycle management: what teams need to get right first?
Explore further
18/08/2026 3:24 pm
SBOM maturity is really lifecycle governance. The article correctly shifts attention away from format debates and toward ownership, update cadence, scope, and sharing boundaries. That is the difference between a reporting exercise and a control that can survive release pressure. For practitioners, the lesson is to treat the SBOM as part of the software identity lifecycle, not as a one-off deliverable.
A question worth separating out:
Q: How should security teams handle SBOM sharing with customers and regulators?
A: Create disclosure rules before requests arrive. Decide which metadata is public, which stays internal, and how to produce a versioned, explainable package that supports customer and audit scrutiny without oversharing sensitive build details. That keeps transparency aligned with operational and legal boundaries.
👉 Read our full editorial: SBOM programs work when teams treat them as a living capability
