Add Christmass advisories

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

@@ -0,0 +1,123 @@
+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.