checkId: check.verification.vex.validation plugin: stellaops.doctor.verification severity: fail tags: [verification, vex, csaf, openvex]
VEX Validation
Doctor check that confirms Stella Ops can collect and validate VEX (Vulnerability Exploitability eXchange) data for the artifacts it verifies. It is part of the artifact verification pipeline that release operators and DevOps engineers run before promoting a build.
This is the verification-pipeline smoke test. For deep VEX subsystem diagnostics (schema, signature, and queue health), see the VEX Document Validation check.
What It Checks
Requires the verification plugin plus a test artifact. In offline mode it actually parses the verification bundle for OpenVEX, CSAF VEX, or CycloneDX VEX content (a real, air-gap-safe probe). In online mode it confirms VexHub:Collection:Enabled and at least one configured VEX feed URL — but the out-of-process Doctor cannot fetch and validate the VEX document for the reference; that requires the runtime VexHub service.
Per ADR-026 D7 a check may never report a fabricated Pass: when only the online configuration is present (collection enabled + feeds configured) the check now returns an honest Skip (“not verified”) naming the unverified capability, instead of a Pass that would imply the VEX document was validated when it was not.
| Condition | Result |
|---|---|
| Offline bundle present but contains no usable VEX content | Fail |
| Offline bundle contains valid VEX (OpenVEX/CSAF/CycloneDX) | Pass (real probe) |
| Online, but no VEX feeds configured | Warn |
| VEX collection disabled | Info |
| Online, collection enabled with at least one feed (config present, VEX not fetched/validated) | Skip — “not verified; requires the runtime VexHub service” |
To get a verifiable green here in an air-gapped environment, supply an offline bundle (Doctor__Plugins__Verification__TestArtifact__OfflineBundlePath) so the real VEX-parse probe runs.
Why It Matters
VEX data is what allows policy to distinguish exploitable findings from known-not-affected cases. Without it, release gates become overly noisy or overly permissive.
Common Causes
VexHub__Collection__Enabledis false- Vendor or internal VEX feeds were never configured
- Offline bundles were exported without
--include-vex
How to Fix
Docker Compose
services:
doctor-web:
environment:
VexHub__Collection__Enabled: "true"
VexHub__Feeds__0__Url: https://vendor.example/vex.json
For offline mode:
stella verification bundle export --include-vex --output /var/lib/stella/verification/offline-bundle.json
Bare Metal / systemd
Keep VEX feeds in a controlled mirror if the environment cannot reach upstream vendors directly.
Kubernetes / Helm
Mount VEX feed configuration from the same source used by the running VexHub deployment.
Verification
stella doctor run --check check.verification.vex.validation
Related Checks
check.verification.policy.engine- VEX-aware policy is only as good as the VEX data it receivescheck.verification.sbom.validation- VEX statements refer to components identified in the SBOMcheck.vex.validation- end-to-end health of the VEX processing subsystem (schema, signature, pipeline)
