Lion Cipher Lab
Consume CSAF 2.0 VEX advisories to cut vulnerability noise (build the producer AND the consumer)
- Threat Intel Analyst
- Advanced
- ~75 min
- Free · no account required
Why it matters
Every organisation that runs a software-composition scanner has the same experience: the scanner walks the bill of materials, sees that a shipped product bundles log4j-core 2.14.1, and reports a CVSS 10.0 finding on every host. The vendor of that product already knows the vulnerable code path is unreachable in their build — but historically that knowledge lived in a PDF, or a support-portal post, or a sentence in a sales call, and your scanner could not read any of it. CSAF 2.0 is the OASIS standard that fixes the transport: a strict JSON schema for machine-readable security advisories. Its…
What you'll learn
- CSAF 2.0 document structure
- VEX profile and the four product_status buckets
- product_tree modelling (branches, full_product_name, product_id)
- purl and CPE product identification
- machine-readable not-affected justifications (flags)
- advisory provenance and issuer-trust policy
- automated finding suppression with an audit trail
- product-matching failure modes
Steps in this lab
- CSAF is the envelope; VEX is the claim inside it
- Where this sits next to KEV, EPSS and SSVC — a different question entirely
- Set up: confirm Python and make a working folder
- Stage 1 — build the CSAF producer: product_tree, product_status, flags
- Run the producer and watch the validator quarantine a bad advisory
- Stage 2 — generate the estate: 142 SBOM-derived scanner findings
- Stage 3 — write the consumer (both engines in one file)
- Run the naive consumer: 142 findings become 28, and it feels like a triumph
- Run the strict consumer: deny by default on trust, fail open on suppression
- The diff: 47 findings the naive engine silently killed, and the four reasons
- Do it better: earn the suppression back with an attested curated overlay
- The judgment: what VEX can and cannot do for you