Your critical system IS (NOT?) vulnerable: CSAF, VEX, SBOM and the future of advisories

The talk opens with a common problem: when a vulnerability makes headlines, organisations struggle to answer whether their own products or systems are affected. The speakers note that CVE identifiers give everyone a shared name for a flaw, but they say nothing about what to do, and many fixes never receive a CVE. They explain a software bill of materials as a dependency graph listing each component, its supplier, version and identifiers, and stress that this data must be machine readable.

The middle of the talk focuses on VEX, a way for a supplier to state that a product is not affected by a particular vulnerability. Reasons can include the vulnerable code being absent or unreachable. The speakers describe the current advisory process as manual and inconsistent, with advisories in mixed formats and scattered across portals, which overloads the teams that must read and prioritise them. They present CSAF, a JSON-based standard for advisories, with VEX defined as a profile within it, so tooling can match an SBOM against published statements.

The closing section covers the chicken-and-egg problem: vendors are slow to publish machine-readable data unless customers ask for it, and customers cannot ask until it exists. The speakers point to government procurement requirements and European legislation as drivers, and to open-source CSAF tools for creating and validating documents as early but still rough. Practitioners are encouraged to adopt the format, build tooling, and treat publishing not-affected statements as a way to cut support calls and free experts for decisions that need judgement.