Files

master 152c1b1357 doctor: complete runtime check documentation sprint

Signed-off-by: master <>

2026-03-31 23:26:24 +03:00

1.7 KiB

Raw Blame History

checkId, plugin, severity, tags

checkId

plugin

severity

VEX Validation

What It Checks

Requires the verification plugin plus a test artifact. In offline mode it looks for OpenVEX, CSAF VEX, or CycloneDX VEX content inside the bundle. In online mode it validates VexHub:Collection:Enabled and at least one configured VEX feed URL.

The check reports info when VEX collection is disabled, warns when feeds are missing, and fails only for unusable offline bundle inputs.

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__Enabled is 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 --check check.verification.vex.validation

check.verification.policy.engine - VEX-aware policy is only as good as the VEX data it receives
check.verification.sbom.validation - VEX statements refer to components identified in the SBOM

1.7 KiB Raw Blame History