VEX Statement Authoring from CVE Triage Prompt
Turn manual CVE triage decisions into auditable OpenVEX statements with the correct machine-readable justification so scanners go quiet only when there is real evidence.
- Target user
- Security and platform engineers drowning in scanner noise who need defensible suppressions
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior product-security engineer who authors VEX (Vulnerability Exploitability eXchange) statements that auditors and downstream consumers trust. You convert triage reasoning into precise OpenVEX, never rubber-stamping a suppression. I will provide: - The product/artifact identity (image digest, package PURL, or component name) — [ARTIFACT IDENTITY] - One or more CVE IDs under triage and what we currently know — [CVE LIST + NOTES] - Evidence available (SBOM, call-graph/reachability output, build flags, runtime config) — [EVIDENCE] - Who authors statements and the publishing target (OCI attestation, advisory feed) — [AUTHOR + TARGET] Your job, step by step: 1. **Classify each CVE** into exactly one VEX status: `not_affected`, `affected`, `fixed`, or `under_investigation`. State the single deciding fact for each. 2. **Justify every `not_affected`** with one value from the fixed vocabulary only: `component_not_present`, `vulnerable_code_not_present`, `vulnerable_code_not_in_execute_path`, `vulnerable_code_cannot_be_controlled_by_adversary`, or `inline_mitigations_already_exist`. Reject any `not_affected` that cannot map to one — downgrade it to `under_investigation`. 3. **Flag weak claims** — call out reachability claims (`vulnerable_code_not_in_execute_path`) that depend on runtime assumptions likely to rot, and note what re-verification each needs and how often. 4. **Emit OpenVEX** — produce a complete, valid OpenVEX v0.2.0 JSON document for the set, with stable `@id`, timestamps, author, and per-statement `vulnerability`, `products`, `status`, and `justification`/`action_statement` as required. 5. **Action statements** — for any `affected`, write the user-facing `action_statement` (mitigation or upgrade path). 6. **Attach + verify** — give the exact commands to attach the VEX as an OCI attestation and to re-run the scanner with the VEX applied to confirm suppression behaves as intended. Output as: (a) a triage table (CVE, status, justification, deciding fact, re-verify cadence), (b) the OpenVEX JSON, (c) the attach + verify commands. Present everything as a proposal for human review — do not assume any suppression is approved until a reviewer signs off, and never invent a justification to silence a finding.
Why this prompt works
VEX only delivers value when a not_affected status is backed by a justification a reviewer can challenge and an auditor can replay. The most common failure mode is suppression by gut feeling, which produces no record of why and quietly poisons the whole program — when nine of ten criticals are silenced on vibes, the tenth real one gets the same treatment. This prompt forces the model into the spec’s fixed justification vocabulary and explicitly instructs it to downgrade any suppression it cannot map to a real justification, so the output stays defensible rather than convenient.
The framing as a senior product-security engineer matters because authoring VEX is an act of stating facts on the record, not closing tickets. By demanding the single deciding fact per CVE and a re-verification cadence for reachability claims, the prompt builds in the discipline that keeps VEX from rotting: vulnerable_code_not_in_execute_path is true until someone adds a call site, and the output names that fragility instead of hiding it.
Finally, the prompt closes the loop from reasoning to artifact to verification. It produces valid OpenVEX, the commands to attach it as an OCI attestation, and the scanner re-run that proves the suppression behaves as intended — and it ends every run as a proposal for human sign-off, because a security engineer, not an LLM, owns the decision to call a vulnerability irrelevant.