Different artifacts, connected decisions

QuestionSBOMVEX
What components are in this release?The inventory and graph address thisDoes not replace a full inventory.
Does a vulnerability affect this product?Provides components to investigateCommunicates a contextual status assertion.
Who made the statement?Inventory author and provenanceStatement author and provenance.
When should it change?Software changes or inventory correctionNew investigation results, fixes or changed conditions.

Source: CISA · Minimum Requirements for VEX.

Source: CycloneDX · VEX capability.

Status is not a blanket product guarantee

Common VEX concepts include affected, not affected, fixed and under investigation. Exact field names and enumerations depend on the chosen representation; use the format’s vocabulary and mapping rules rather than translating strings informally. A not-affected statement needs the applicable justification and context.

Source: OpenVEX · Specification.

A product release may be not affected by one vulnerability while remaining affected by another. A fixed status applies to an identified product version, not to every installation. Under investigation is an open question and should not silently suppress response.

Require an identifiable statement

  • Product and version scope that matches the receiving registry.
  • Vulnerability identifiers and relevant subcomponent context.
  • Author, issuance time and revision information.
  • Status, justification and supporting details as required by the representation.
  • Actions, update information or investigation path where relevant.
  • Authenticity and integrity evidence under the agreed delivery policy.

Missing version scope can cause an assertion about one release to be applied to all releases. Preserve the original statement and its interpretation, including any mapping from external product identifiers to internal records.

A safe consumption workflow

  1. Authenticate the statement source and preserve its original form.
  2. Check supported format/version and required content.
  3. Resolve the product, release and vulnerability.
  4. Review whether the justification fits the deployed configuration.
  5. Apply a documented trust policy and record the decision.
  6. Expire or reevaluate when software, configuration or evidence changes.

Use VEX to reduce noise without hiding uncertainty

Suppose a supplier explains that a vulnerable component’s affected function is excluded from a particular build. That may support a not-affected conclusion for that artifact, subject to evidence and trust policy. It does not establish that an optional plugin or a different build is safe.

Keep a decision trail showing the candidate match, statement revision, analyst or policy approval and reevaluation conditions. If a statement is withdrawn or superseded, reopen the affected analysis. Do not delete inventory components to make a vulnerability dashboard look clean.

Test end-to-end support

Ask a platform to ingest a statement, associate it with the right release, display the rationale, apply the chosen triage policy and export it. Test a revised statement, an untrusted author and a product-version mismatch. Generation, ingestion and policy use are separate functions.

CycloneDX includes VEX capabilities; OpenVEX provides another representation, and other advisory frameworks can carry related information. Agree on actual exchange formats and versions. A vendor saying “VEX support” is not a completed interoperability test.

Primary sources