---
checkId: check.verification.vex.validation
plugin: stellaops.doctor.verification
severity: fail
tags: [verification, vex, csaf, openvex]
---
# 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
```yaml
services:
  doctor-web:
    environment:
      VexHub__Collection__Enabled: "true"
      VexHub__Feeds__0__Url: https://vendor.example/vex.json
```

For offline mode:

```bash
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
```bash
stella doctor --check check.verification.vex.validation
```

## Related Checks
- `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