Skip to content
Declara
⌘K
engineer

Export a product's VEX

Was this page helpful?

When you assess an alert and decide it does not affect your product, your customers' scanners do not know that, and raise the same finding again. A VEX document tells them. Declara builds one per product from the decisions you have already made.

What goes in

  • An alert you decided not applicable becomes not_affected. If you answered that the component is not used in the shipped product, the justification is component_not_present; if the vulnerable code is not reachable, it is vulnerable_code_not_in_execute_path. Otherwise your rationale is the impact statement.
  • An alert you decided reportable becomes affected.
  • A statement you imported is used as it is, and wins over a triage decision for the same vulnerability.
  • Optionally, alerts still being assessed become under_investigation.

Product versions are named by pkg:generic package URLs Declara derives from the product name; matched components keep their own package URLs.

Exporting changes nothing about what suppresses a match or an alert.

Steps

  1. Open the product. In Exploitability statements, use OpenVEX, CycloneDX, or with open alerts as under investigation. The card appears once the product has an SBOM or a statement.

  2. Or fetch it in a pipeline with an API key carrying products:read:

    curl -H "Authorization: Bearer $DECLARA_API_KEY" \
  "https://your-declara-host/api/v1/products/$PRODUCT_ID/vex?format=openvex"

    format is openvex (the default) or cyclonedx; include_open=true adds alerts still being assessed.

What you should see

An OpenVEX 0.2.0 document, or a CycloneDX 1.6 document carrying only vulnerabilities and the components they affect. Both validate against their published schemas.

Related