Import VEX from Files & Suppliers

Your suppliers already assess the vulnerabilities in the components you consume. Importing their VEX documents means you do not repeat that analysis — DevGuard turns every incoming statement into a VEX rule scoped to your repository.

Upload a VEX file

Use this for a one-off document, or for VEX your own build pipeline produces.

  1. Navigate to Dependency Risks → VEX Rules.
  2. Click Add a VEX-File or VEX-URL.
  3. Choose Upload a VEX File.
  4. Drop or select a single .json file.
  5. Click Upload VEX.

Add an upstream source URL

Use this when a supplier publishes VEX continuously. You configure the URL once and DevGuard re-syncs it.

  1. On the VEX Rules page, expand Upstream VEX sources and click Add source (or use Add a VEX-File or VEX-URLSupply a source URL).
  2. Pick the tab matching the document type:
    • CycloneDX VEX — e.g. https://supplier.example.com/vex.json
    • CSAF — e.g. https://supplier.example.com/csaf.json
  3. Click Add VEX source.

The source appears in the list with a type badge and its URL. Sync all sources triggers an immediate fetch of everything configured; otherwise DevGuard re-syncs on its own schedule as part of the repository's regular processing.

What DevGuard does with an incoming document

  1. Detects the format from the document's structure — CycloneDX, CSAF or OpenVEX.
  2. Identifies the affected products and reconstructs the dependency path each statement refers to. CSAF's product relationships yield an exact path; CycloneDX and OpenVEX statements produce a wildcard path ending in the affected component.
  3. Translates the status into a DevGuard decision:
FormatIncoming statusBecomes
CSAFknown_not_affectedFalse positive
CSAFknown_affected with a no_fix_planned remediationAccepted risk
CSAFknown_affected without that remediation, fixed, under_investigationignored
CycloneDXfalse_positive, not_affectedFalse positive
CycloneDXexploitable + response update, in_triage, will_not_fixignored
OpenVEXnot_affectedFalse positive
OpenVEXaffectedAccepted risk
OpenVEXfixed, under_investigationignored
  1. Creates one rule per statement, with the supplier's URL (or vex-upload) as the rule's source, and the supplier's textual justification as the rule's justification.
  2. Applies the rules to matching vulnerabilities and recalculates risk.

How re-syncing behaves

Each sync reconciles the rules for that specific source against the document as it stands now:

  • A statement that is unchanged produces no change — rule identity is derived from the expression, so imports are idempotent.
  • A new statement creates a new rule and is applied immediately.
  • A statement that disappears from the document causes its rule to be deleted. The vulnerabilities it handled revert — see Delete a rule.

Rules from other sources, and your own rules, are never touched by another source's sync.

Take ownership of a synced rule

Editing a synced rule converts it into your own rule, detaching it from the upstream source. Later syncs no longer overwrite or remove it. Use this when a supplier's assessment is right in substance but you want to record your own reasoning, or narrow the expression.

Paranoid Mode

If you do not fully trust an upstream supplier, enable Paranoid Mode in Repository Settings:

Do you trust your upstream supplier? If not, enable this mode so you need to accept the statement vulnerability assessment in the VEX reports from your supplier manually.

With Paranoid Mode on, rules created from uploads and upstream sources are stored inactive — they do not change any vulnerability's state until you approve them. Rules you write yourself are always active, regardless of the setting.

Working from the CLI

The DevGuard scanner can upload a VEX document from a pipeline:

Use --origin to label where the document came from, so its rules are distinguishable in the rules table. See the scanner VEX command reference for the full flag list and Upload VEX for the container-based invocation.

Have feedback? We want to hear from you!

Fields marked with * are required