git.stella-ops.org/docs/marketing/evidence-linked-vex.md

# Evidence-Linked VEX — Proof-Backed Vulnerability Decisions

> Status: Marketing Bridge Document · December 2025
> Audience: Technical buyers, security architects, compliance teams

<!-- TODO: Review for separate approval - new marketing bridge doc -->

## Executive Summary

Stella Ops isn't just another scanner—it's a different product category: **deterministic, evidence-linked vulnerability decisions** that survive auditors, regulators, and supply-chain propagation.

**Evidence-Linked VEX** is how those decisions are structured: every vulnerability status assertion includes pointers to the underlying proof. Unlike traditional VEX that simply states "not_affected" without explanation, Stella Ops provides a complete evidence graph connecting the decision to its inputs.

**Key message**: "VEX you can prove."

---

## What is Evidence-Linked VEX?

Every VEX decision in Stella Ops links to an **evidence graph** containing:

| Evidence Type | Description | Link Format |
|---------------|-------------|-------------|
| **SBOM match** | Component identity confirmation | `sbom_hash`, `purl` |
| **Vuln snapshot** | Exact advisory data at decision time | `advisory_snapshot_id` |
| **Reachability proof** | Static/runtime analysis artifacts | `reach_decision_id`, `graph_hash` |
| **Runtime observation** | Process traces, method hits | `runtime_trace_id` |
| **Mitigation evidence** | WAF rules, config flags, patches | `mitigation_id` |

```
┌────────────────────────────────────────────────────────────┐
│              VEX Decision: NOT_AFFECTED                     │
├────────────────────────────────────────────────────────────┤
│                                                              │
│  "CVE-2025-1234 does not affect pkg:nuget/Example@1.2.3"   │
│                                                              │
│  Evidence Graph:                                             │
│  ┌─────────────┐    ┌─────────────┐    ┌─────────────┐     │
│  │ SBOM Match  │───▶│ Vuln Record │───▶│ Reach Proof │     │
│  │ sha256:abc  │    │ nvd-snap-01 │    │ graph:xyz   │     │
│  └─────────────┘    └─────────────┘    └─────────────┘     │
│                                              │               │
│                                              ▼               │
│                                        ┌─────────────┐      │
│                                        │ Runtime Obs │      │
│                                        │ trace:456   │      │
│                                        └─────────────┘      │
└────────────────────────────────────────────────────────────┘
```

---

## Why Evidence-Linked VEX Matters

### The Problem with Traditional VEX

Traditional VEX statements are **assertions without proof**:

```json
{
  "vulnerability": "CVE-2025-1234",
  "status": "not_affected",
  "justification": "vulnerable_code_not_present"
}
```

Questions this doesn't answer:
- How do you know the vulnerable code isn't present?
- What analysis was performed?
- Can this decision be independently verified?
- What happens when the advisory changes?

### The Evidence-Linked Solution

Stella Ops VEX includes **proof pointers**:

```json
{
  "vulnerability": "CVE-2025-1234",
  "status": "not_affected",
  "justification": "vulnerable_code_not_present",
  "evidence_refs": {
    "sbom": "sha256:abc123...",
    "advisory_snapshot": "nvd-2025-12-01",
    "reachability": {
      "decision_id": "reach:xyz789",
      "graph_hash": "blake3:...",
      "score": 22,
      "state": "POSSIBLE"
    },
    "mitigations": ["mit:waf-rule-123"]
  },
  "replay_bundle": "capsule:2025-12-11-abc"
}
```

This enables:
- **Independent verification**: Anyone can follow the proof chain
- **Deterministic replay**: Re-run the exact analysis
- **Audit compliance**: Evidence meets regulatory requirements

---

## Explicit "Unknown" State Handling

A key differentiator: Stella Ops explicitly handles **incomplete data**.

| Traditional Approach | Stella Ops Approach |
|---------------------|---------------------|
| Binary: affected/not_affected | Three states: affected/not_affected/under_investigation |
| Missing data → assume safe | Missing data → mark "Unknown" |
| False negatives possible | Incomplete data surfaced explicitly |

**Why this matters**: Incomplete data never leads to false safety. If reachability analysis is inconclusive, the decision stays `under_investigation` until sufficient evidence is gathered.

---

## Competitive Differentiation

| Capability | Stella Ops | Competitors |
|------------|------------|-------------|
| **VEX output** | Evidence-linked with proof graph | Simple VEX statements |
| **Verification** | Independent proof chain verification | Trust the vendor |
| **Unknown handling** | Explicit `under_investigation` state | Binary yes/no |
| **Replay** | Bit-for-bit from Decision Capsules | Not possible |

**Battlecard one-liner**: "Competitors export VEX formats; Stella provides VEX you can prove."

---

## Evidence Graph Structure

### Full Evidence Chain

```
Component (PURL)
    │
    ├──▶ SBOM Document
    │       └── digest: sha256:...
    │
    ├──▶ Vulnerability Record
    │       ├── source: NVD
    │       ├── snapshot_id: nvd-2025-12-01
    │       └── digest: sha256:...
    │
    ├──▶ Reachability Analysis
    │       ├── static_graph: blake3:...
    │       ├── runtime_traces: [trace:001, trace:002]
    │       ├── score: 22 (POSSIBLE)
    │       └── evidence: [edge:abc, edge:def]
    │
    ├──▶ Mitigations
    │       ├── waf_rule: rule:xyz
    │       └── config_flag: flag:disabled
    │
    └──▶ Policy Decision
            ├── version: corp-policy@2025-12-01
            ├── digest: sha256:...
            └── threshold: score < 25 → not_affected
```

### Evidence Types

| Evidence Kind | Confidence Impact | Source |
|---------------|-------------------|--------|
| `StaticCallEdge` | +30 base score | IL/bytecode analysis |
| `RuntimeMethodHit` | +60 base score | EventPipe/JFR |
| `UserInputSource` | +80 base score | Taint analysis |
| `WafRulePresent` | -20 mitigation | WAF connector |
| `PatchLevel` | -40 mitigation | Patch diff |

---

## VEX Propagation

Evidence-Linked VEX enables **scalable supply chain sharing**:

1. **Generate**: Create evidence-linked VEX from scan results
2. **Sign**: Apply DSSE signatures with your trust root
3. **Share**: Propagate to downstream consumers
4. **Verify**: Consumers verify independently using proof pointers

```bash
# Generate evidence-linked VEX
stella vex generate --scan scan-123 --format openvex --include-evidence

# Export for downstream
stella vex export --decisions "decision:abc123" --bundle evidence-bundle.tar

# Downstream verification
stella vex verify evidence-bundle.tar --trust-root downstream-ca
```

---

## Integration with Four Capabilities

Evidence-Linked VEX connects to the four capabilities:

1. **Signed Reachability** → Reachability proof in evidence graph
2. **Deterministic Replay** → Evidence reproducible via Decision Capsules
3. **Explainable Policy** → Policy version and thresholds traced
4. **Sovereign Offline** → Evidence verifiable without network

---

## Customer Scenarios

### Scenario 1: Vendor VEX Verification
"The vendor says this CVE doesn't affect us—can we trust it?"
→ Check their evidence graph; verify the reachability analysis matches your deployment.

### Scenario 2: Compliance Audit
"Prove this CVE was properly analyzed."
→ Show the evidence chain from SBOM → advisory → reachability → decision.

### Scenario 3: Supply Chain Propagation
"Pass our VEX decisions to downstream consumers."
→ Export evidence-linked VEX; consumers can independently verify.

---

## Related Documentation

- `docs/vex/consensus-overview.md` — VEX consensus engine
- `docs/reachability/lattice.md` — Reachability scoring model
- `docs/marketing/decision-capsules.md` — Decision Capsules overview
- `docs/marketing/hybrid-reachability.md` — Hybrid analysis