SBOM programs work when teams treat them as a living capability

At a glance

What this is: This is FOSSA’s webinar-based guidance on how to stand up and run an SBOM programme as a repeatable capability, with the key finding that process discipline matters more than format debates.

Why it matters: For IAM and security practitioners, SBOM maturity intersects with supply chain governance, third-party risk, and the identity of build and release systems that produce and share software metadata.

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.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.

👉 Read FOSSA's webinar-based guidance on building and operating an SBOM programme

Context

SBOM programmes are a governance problem before they are a tooling problem. Teams often start by debating file formats, but the harder issues are scope, ownership, update mechanics, and how the inventory will be used when software changes every day. In practice, that means the programme has to be designed as a living process, not a document factory, and the same principle applies to identity-managed build systems that generate software metadata.

The article’s main contribution is a practical sequencing model: get clear on why the SBOM exists, define who owns it, decide what must be covered first, then wire it into build and release workflows. That ordering matters because brittle controls break when they meet release pressure. The starting position described here is common among mature security teams, but many organisations still treat SBOMs as a reporting artefact rather than an operational control.

Where SBOMs intersect with identity security is in the trust placed on CI/CD systems, release automation, and external sharing. If those identities are not governed, the inventory they produce can be incomplete, stale, or overshared. That makes lifecycle control and access scope part of the SBOM conversation, not a separate one.

Key questions

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. Then automate generation from the build pipeline so the inventory updates when software changes. Early clarity on scope, ownership, and refresh rules prevents format debates from delaying actual risk reduction.

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. Teams get value once inventories feed vulnerability checks, risk acceptance decisions, and remediation tickets. The key signal is whether the programme changes what happens after a new dependency or issue appears.

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. A bill of materials shows what is present, but not whether dependencies are vulnerable, whether the build path was trusted, or whether secrets were exposed during delivery. Teams need SBOM plus context from pipeline and runtime controls to make it operationally useful.

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.

Technical breakdown

Why format choice is the wrong first decision

CycloneDX and SPDX are both SBOM formats, but format is only one layer of the problem. The more important questions are what scope you need, where the data comes from, how often it updates, and which lifecycle stage is authoritative. If a product changes, the SBOM should change too. That sounds simple, but in real environments it requires build automation, metadata consistency, and an explicit rule for when a software change invalidates the previous inventory.

Practical implication: define your SBOM operating model before standardising on a file format.

How SBOMs become operational rather than static

An SBOM becomes useful when it feeds workflows instead of sitting in a repository. That means generating inventories during builds, comparing them against vulnerability intelligence, and opening tickets when risk appears. The value is not in the document itself but in the feedback loop between source code, build output, and remediation. Consistency matters because different tools and lifecycle stages may produce slightly different views, so teams need a repeatable measurement approach and a rule for reconciling mismatches.

Practical implication: automate SBOM generation and link it to vulnerability triage, not just compliance reporting.

Why VEX changes the conversation

VEX, or Vulnerability Exploitability eXchange, adds a machine-readable way to explain whether a known vulnerability is actually relevant in a given component. That matters because SBOMs create scale, but scale also creates noise. VEX helps teams answer the auditor or customer question, 'does this issue matter here?', with evidence rather than guesswork. It also makes disclosure more structured when software is shared with regulators, customers, or partners, which is where many SBOM programmes become politically difficult.

Practical implication: pair SBOM production with VEX so risk decisions stay explainable as inventories grow.

NHI Mgmt Group analysis

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.

The governance gap is usually not absence of data, but absence of decision rules. Teams often can generate inventories, yet they do not define which system is authoritative when source, build, test, and production views differ. That creates ambiguity exactly where regulators, auditors, and customers expect precision. Practitioners should formalise how discrepancies are resolved before they promise scale.

SBOMs and NHI governance intersect through build and release identities. CI/CD systems, signing services, and release automation are non-human identities that control what enters the software supply chain. If those identities are overprivileged or poorly rotated, the inventory and attestations they produce inherit that weakness. Practitioners should include build-system identities in the same governance model as the software artefacts they emit.

VEX introduces the missing interpretation layer. SBOMs list components, but they do not explain exploitability or business relevance. VEX helps separate signal from noise, which is essential once inventories reach scale and stakeholders begin demanding rapid answers. The practical conclusion is that organisations need both artifact inventory and status governance, not one without the other.

Shared SBOM workflows will force more mature disclosure discipline. The article’s discussion of external sharing and tear sheets points to a broader market shift: teams will need finer-grained controls over what metadata leaves the organisation. That is a security, legal, and operating-model problem at once. Practitioners should build disclosure rules into the programme before customers or regulators ask for them.

What this signals

SBOM programmes will increasingly be judged on whether they can produce a trusted answer when software changes, not whether they can generate a static file. That pushes teams toward stronger release governance, better metadata hygiene, and clearer rules for what counts as authoritative across the build chain.

Software identity debt: when build, signing, and release identities are not governed tightly, the SBOM they produce can be stale or misleading. Practitioners should expect SBOM discipline to converge with CI/CD identity controls, especially where customers and regulators demand higher assurance.

As disclosure expectations mature, teams will need to separate internal operational metadata from what can safely be shared externally. That means SBOM governance will increasingly sit alongside third-party risk management, legal review, and identity-bound access controls for software delivery systems.

For practitioners

• 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. Tie escalation paths to the systems that generate the SBOM, not only to the software product.
• Automate SBOM regeneration on software change Treat every material code or dependency change as a trigger for a fresh SBOM. Wire generation into nightly builds and release pipelines so the inventory reflects the software that actually ships.
• 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. This reduces delay and keeps the programme anchored to audit and risk priorities.
• Pair inventories with VEX workflows Use VEX to explain when a listed vulnerability is exploitable, unaffected, or remediated so stakeholders get an actionable answer instead of a raw component list. That reduces noise when SBOMs begin flowing to customers and auditors.

Key takeaways

• SBOMs become valuable when they are managed as a living control, not as a document for auditors.
• The hardest SBOM decisions are governance decisions about scope, ownership, update triggers, and disclosure boundaries.
• VEX, automated regeneration, and clear identity control over build systems are what turn inventories into actionable security.

Key terms

• SBOM: A software bill of materials is an inventory of components, dependencies, and often transitive packages used in an application or build. It gives defenders visibility into what entered the software supply chain and helps spot risky or newly introduced dependencies.
• Vex: VEX, or Vulnerability Exploitability eXchange, is a way to state whether a known vulnerability is exploitable in a specific product, build, or deployment. It helps security teams avoid treating every matching CVE as equally urgent and improves prioritisation in software supply chains.
• Software Supply Chain: A software supply chain is the set of tools, identities, dependencies, and processes that turn source code into deployed software. Because it relies on automation and privileged machine identities, it becomes a governance problem when access, signing, and deployment controls are too broad.

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

👉 FOSSA's full post covers the practical rollout details, VEX handling, and disclosure considerations

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity lifecycle control to the broader security programmes their organisations depend on.