git.stella-ops.org/docs/product-advisories/25-Dec-2025 - Implementing Diff‑Aware Release Gates.md

Here’s a simple, practical way to make release gates that auto‑decide if a build is “routine” or “risky” by comparing the semantic delta across SBOMs, VEX data, and dependency graphs—so product managers can approve (or defer) with evidence, not guesswork.

What this means (quick background)

• SBOM: a bill of materials for your build (what components you ship).
• VEX: vendor statements about whether known CVEs actually affect a product/version.
• Dependency graph: how components link together at build/runtime.
• Semantic delta: not just “files changed,” but “risk‑relevant meaning changed” (e.g., new reachable vuln path, new privileged capability, downgraded VEX confidence).

---

The gate’s core signal (one line)

Risk Verdict = f(ΔSBOM, ΔReachability, ΔVEX, ΔConfig/Capabilities, ΔExploitability) → Routine | Review | Block

---

Minimal data you need per release

• SBOM (CycloneDX/SPDX) for previous vs current release.
• Reachability subgraph: which vulnerable symbols/paths are actually callable (source, package, binary, or eBPF/runtime).
• VEX claims merged from vendors/distros/internal (with trust scores).
• Policy knobs: env tier (prod vs dev), allowed unknowns, max risk budget, critical assets list.
• Exploit context: EPSS/CISA KEV or your internal exploit sighting, if available.

---

How to compute the semantic delta (fast path)

1. Component delta: new/removed/updated packages → tag each change with severity (critical/security‑relevant vs cosmetic).

2. Vulnerability delta:

   • New CVEs introduced?
   • Old CVEs now mitigated (patch/backport) or declared not‑affected via VEX?
   • Any VEX status regressions (e.g., “not‑affected” → “under‑investigation”)?

3. Reachability delta:

   • Any new call‑paths to vulnerable functions?
   • Any risk removed (path eliminated via config/feature‑flag/off by default)?

4. Config/capabilities delta:

   • New container perms (NET_ADMIN, SYS_ADMIN), new open ports, new outbound calls.
   • New data flows to sensitive stores.

5. Exploitability delta:

   • EPSS/KEV jumps; active exploitation signals.

---

A tiny, useful scoring rubric (defaults you can ship)

• Start at 0. Add:

  • +6 if any reachable critical vuln (no valid VEX “not‑affected”).
  • +4 if any reachable high vuln.
  • +3 if new sensitive capability added (e.g., NET_ADMIN) or new public port opened.
  • +2 if VEX status regressed (NA→U/I or Affected).
  • +1 per unknown package origin or unsigned artifact (cap at +5).

• Subtract:

  • −3 per proven mitigation (valid VEX NA with trusted source + reachability proof).
  • −2 if vulnerable path is demonstrably gated off in target env (feature flag off + policy evidence).

• Verdict:

  • 0–3 → Routine (auto‑approve)
  • 4–7 → Review (PM/Eng sign‑off)
  • ≥8 → Block (require remediation/exception)

(Tune thresholds per env: e.g., prod stricter than staging.)

---

What PMs see (clean UI)

• Badge: Routine / Review / Block.

• Why (3–5 bullets):

  • “Added libpng 1.6.43 (new), CVE‑XXXX reachable via DecodePng()”
  • “Vendor VEX for libssl says not‑affected (function not built)”
  • “Container gained CAP_NET_RAW”

• Evidence buttons:

  • “Show reachability slice” (mini graph)
  • “Show VEX sources + trust”
  • “Show SBOM diff”

• Call to action:

  • “Auto‑remediate to 1.6.44” / “Mark exception” / “Open fix PR”

---

Exception workflow (auditable)

• Exception must include: scope, expiry, compensating controls, owner, and linked evidence (reachability/VEX).
• Gate re‑evaluates each release; expired exceptions auto‑fail the gate.

---

How to wire it into CI/CD (quick recipe)

1. Generate SBOM + reachability slice for prev and curr.
2. Merge VEX from vendor/distro/internal with trust scoring.
3. Run Delta Evaluator → score + verdict + evidence bundle (JSON + attestation).
4. Gate policy checks score vs environment thresholds.
5. Publish an OCI‑attached attestation (DSSE/in‑toto) so auditors can replay: same inputs → same verdict.

---

Starter policy you can copy

• Prod: block on any reachable Critical; review on any reachable High; unknowns ≤ 2; no new privileged caps without exception.
• Pre‑prod: review on reachable High/Critical; unknowns ≤ 5.
• Dev: allow but flag; collect evidence.

---

Why this helps immediately

• PMs get evidence‑backed green/yellow/red, not CVE walls.
• Engineers get actionable deltas (what changed that matters).
• Auditors get replayable proofs (deterministic verdicts + inputs).

If you want, I can turn this into a ready‑to‑drop spec for Stella Ops (modules, JSON schemas, attestation format, and a tiny React panel mock) so your team can implement the gate this sprint.