SBOM, VEX, and product security transparency

Simple definitions

SBOM — Software Bill of Materials

An SBOM is a machine-readable inventory of software components and dependencies. In plain language, it answers:

“What is inside this product?”

VEX — Vulnerability Exploitability eXchange

VEX is a machine-readable way to say whether a known vulnerability actually affects a product in its real context. In plain language, it answers:

“Does this vulnerability really matter for this product?”

That difference matters because scanner results alone often create noise without enough context.

Why scanner results alone are not enough

A customer or operator may see a vulnerability in a component and assume the whole product is exposed. But that is not always true.

The missing questions are often:

• is that component really present in the product?
• is the vulnerable functionality reachable?
• is the product configuration affected?
• is there already a mitigation in place?
• is the vulnerability relevant in this deployment context?

This is exactly why VEX has become important: it helps vendors communicate product-specific vulnerability relevance more clearly.

Does this apply to us?

• build or ship software products
• depend on third-party libraries, packages, containers, or frameworks
• receive customer questions about software composition or product security
• work in regulated or assurance-heavy environments
• expect stronger supplier or procurement scrutiny over time

What changes in practice

Teams exploring SBOM and VEX often need to think about:

• dependency visibility across products and builds
• who owns component transparency
• how vulnerability status is reviewed and communicated
• what format or standard makes sense
• how product, engineering, security, and support teams coordinate
• how much automation is realistic now versus later

This is not only a tooling decision. It is a product-security operating-model question.

Common misunderstandings

”SBOM and VEX are the same thing.”

No. SBOM describes product composition. VEX describes vulnerability relevance or status.

”If we generate an SBOM once, we are done.”

Usually not. Value depends on freshness, integration, and whether anyone can actually use the output.

”This is only for huge vendors.”

No. Larger organisations may feel pressure earlier, but smaller product teams also face customer and procurement questions.

”SBOM and VEX automatically solve code quality.”

No. They improve transparency and vulnerability communication — not general code quality or secure coding maturity.

Common gaps

Typical issues include:

• no clear dependency view across products
• too much faith in raw scanner output
• no clear answer for customers asking “are we affected by this CVE?”
• unclear ownership between engineering, security, and product teams
• confusion over standards, formats, and appropriate maturity levels
• overreacting to future trends without a practical phased plan

How WFH Labs helps

WFH Labs helps teams understand what SBOM and VEX are, where the pressure is coming from, and what level of maturity makes sense now. We connect software composition transparency to vulnerability handling, software supply chain thinking, and customer assurance.

Where relevant, we help decide what to pilot first, what to automate later, and what should not be overengineered too early.

FAQ

Is SBOM a legal requirement?

SBOM is an artefact type and practice area. Whether it is required depends on sector, customer pressure, procurement requirements, and specific regulations.

Is VEX a vendor excuse file?

No. Used properly, VEX is a structured way to communicate whether a known vulnerability actually affects a product in its specific context.

Do we need this if we already run dependency scanning?

Maybe. Dependency scanning helps internally, but SBOM and VEX address broader transparency and communication questions with external parties.

Is this mainly a US topic?

No. Important work started there, but the broader direction is international and increasingly relevant in Europe as well — especially with the Cyber Resilience Act.

---

Sources and official references are listed in the sidebar.