git.stella-ops.org/docs/product-advisories/08-Dec-2025 - Designing UX for Signed Evidence Trails.md

I’m sharing this because I think your architecture‑moat ambitions for Stella Ops map really well onto what’s already emerging in SBOM/VEX + call‑graph / contextual‑analysis tooling — and you could use those ideas to shape Stella Ops’ “policy + proof‑market” features.

✅ What SBOM↔VEX + Reachability / Call‑Path Tools Already Offer

• The combination of Snyk’s “reachability analysis” and Vulnerability Exploitability eXchange (VEX) lets you label each reported vulnerability as REACHABLE / NO PATH FOUND / NOT APPLICABLE, based on static call‑graph (or AI‑enhanced analysis) of your actual application code rather than just “this library version has a CVE.” (Snyk User Docs)
• If reachable, Snyk even provides a “call‑path” view showing how your code leads to the vulnerable element — giving a human-readable trace from your own functions/modules into the vulnerable dependency. (Snyk User Docs)
• The VEX model (as defined e.g. in CycloneDX) is designed to let you embed exploitability/ context‑specific data alongside a standard SBOM. That way, you don’t just convey “what components are present,” but “which known vulnerabilities actually matter in this build or environment.” (CycloneDX)

In short: SBOM → alerts many potential CVEs. SBOM + VEX + Reachability/Call‑path → highlights only those with an actual path from your code — drastically reducing noise and focusing remediation where it matters.

🔧 What Artefact‑ or Container‑Level “Contextual Analysis” Adds (Triage + Proof Trail)

• JFrog Xray’s “Contextual Analysis” (when used on container images or binary artifacts) goes beyond “is the library present” — it tries to reason whether the vulnerable code is even invoked / relevant in this build. If not, it marks the CVE as “not exploitable / not applicable.” That dramatically reduces false positives: in one study JFrog found ~78% of reported CVEs in popular DockerHub images were not actually exploitable. (JFrog)
• Contextual Analysis includes a call‑graph view (direct vs transitive calls), highlights affected files/functions & line numbers, and lets you copy details for remediation or auditing. (JFrog)
• Combined with SBOM/VEX metadata, this enables a full proof trail: you can track from “component in SBOM” → “vulnerability discovered” → “reachable from my code or image” → “call‑path evidence” → “justified exploitability status.” That makes your SBOM/VEX data actionable and auditable without manual spreadsheets or email threads. (Endor Labs)

🎯 Why This Matters for Stella Ops’ Moats

Given your ambitious Stella Ops design — deterministic scans, reproducible proofs, cryptographically verifiable supply‑chain attestations — this established workflow model is a very powerful blueprint:

• You could integrate call‑graph reachability + artifact‑level contextual analysis directly into your “Proof‑of‑Integrity Graph,” giving customers a clear, machine‑readable + human‑auditable exploitability verdict per vulnerability.
• The “one‑click evidence” model (call‑path + signed SBOM/VEX + transparency‑log index) maps neatly onto your planned Proof‑Market Ledger / “trust‑credit” economy: consumers see not just “vulnerable component included,” but “here’s the exact evidence proving it is or isn’t reachable/exploitable.”
• It also supports tiered remediation prioritization (e.g. reachable + high severity + business‑critical vs unreachable / low‑impact), reducing burden on teams just like Snyk and JFrog do for their customers.

🧑‍💻 What’s Still Missing / What You Should Improve

• Reachability analysis — especially static — is not perfect: “NO PATH FOUND” doesn’t guarantee “never exploitable.” Reflection, dynamic loading, environment‑specific behavior can cause false negatives. (Snyk User Docs)
• VEX annotations often remain semi‑manual or vendor‑supplied — but for a fully trust‑worthy "Proof‑Market," you’ll need automated generation + strong signing + revocation / update mechanisms (which seems aligned with what you planned).
• For containerized builds, the contextual analysis must tie SBOM entries to actual runtime/packaged artifacts — your deterministic rebuild + binary lineage + transparency‑log approach could help guarantee that.

---

I think combining SBOM + VEX + reachability/call‑path + artifact‑level contextual analysis gives a real, operational model that matches what you envision for Stella Ops — but with some limitations that your added layers (cryptographic signing, replayability, trust‑market) can uniquely address.

If you like — I can sketch a minimal architecture (modules & data flow) that implements exactly that model in Stella Ops (call‑graph analyzer → VEX annotator → signed bundle → ledger entry).

Stella Ops’ big advantage can be: turn “security findings” into “verifiable claims with evidence”—portable across org boundaries, continuously updateable, and audit-friendly—by combining SBOM + VEX + reachability/call-path + signed provenance into one evidence graph.

Stella Ops advantages (what becomes uniquely hard to copy)

1) Actionable vulnerability truth, not CVE spam

SBOMs tell you what’s present; VEX tells you whether a known vuln matters in your specific context (affected vs not_affected vs fixed vs under_investigation), which is the difference between “alert fatigue” and prioritized remediation. (cyclonedx.org)

Stella Ops moat: VEX isn’t just a checkbox—it’s backed by machine-verifiable evidence (reachability traces, policy decisions, build lineage).

---

2) “Evidence bundles” that any downstream can verify

If every release ships with:

• SBOM (what’s in it)
• VEX (what matters + why)
• Provenance/attestations (how it was built)
• Signatures + transparency log inclusion

…then downstream teams can verify claims without trusting your internal tooling.

This mirrors best practices in the supply-chain world: SLSA recommends distributing provenance and using transparency logs as part of verification. (SLSA) Sigstore also standardizes “bundles” that can include DSSE-wrapped attestations plus transparency log material/timestamps. (Sigstore)

Stella Ops moat: “Proof packaging + verification UX” becomes a platform primitive, not an afterthought.

---

3) A unified Proof Graph (the missing layer in most tooling)

Most tools produce reports. Stella Ops can maintain a typed graph:

source commit → build step(s) → artifact digest → SBOM components → CVEs → reachability evidence → VEX statements → signers → log inclusion

That graph lets you answer hard questions fast:

• “Is CVE-XXXX exploitable in prod image sha256:…?”
• “Show the call-path evidence or runtime proof.”
• “Which policy or signer asserted not_affected, and when?”

SPDX 3.x explicitly aims to support vulnerability metadata (including VEX fields) in a way that can evolve as security knowledge changes. (spdx.dev)

Moat: graph-scale lineage + queryability + verification, not just scanning.

---

4) Reachability becomes a signed, reviewable artifact

Reachability analysis commonly produces statuses like “REACHABLE / NO PATH FOUND / NOT APPLICABLE.” (docs.snyk.io) Stella Ops can store:

• the reachability result,
• the methodology (static, runtime, hybrid),
• confidence/coverage,
• and the call-path (optionally redacted), then sign it and tie it to a specific artifact digest.

Moat: you’re not asking teams to trust a reachability claim—you’re giving them something they can verify and audit.

---

5) Continuous updates without chaos (versioned statements, not tribal knowledge)

VEX statements change over time (“under_investigation” → “not_affected” or “affected”). OpenVEX requires that “not_affected” includes a justification or an impact statement—so consumers can understand why it’s not affected. (GitHub) Stella Ops can make those transitions explicit and signed, with append-only history.

Moat: an operational truth system for vulnerability status, not a spreadsheet.

---

6) “Proof Market” (if you want the deep moat)

Once evidence is a first-class signed object, you can support multiple signers:

• vendor (you),
• third-party auditors,
• internal security team,
• trusted scanner services.

A “proof market” is essentially: policy chooses whose attestations count for which claims. (You can start simple—just “org signers”—and expand.)

Moat: trust-routing + signer reputation + network effects.

---

Developer guidelines (for teams adopting Stella Ops)

A. Build + identity: make artifacts verifiable

1. Anchor everything to an immutable subject Use the artifact digest (e.g., OCI image digest) as the primary key for SBOM, VEX, provenance, reachability results.

2. Aim for reproducible-ish builds Pin dependencies (lockfiles), pin toolchains, and record build inputs/params in provenance. The goal is: “same inputs → same digest,” or at least “digest ↔ exact inputs.” (Even partial determinism pays off.)

3. Use standard component identifiers Prefer PURLs for dependencies and keep them consistent across SBOM + VEX. (This avoids “can’t match vulnerability to component” pain.)

---

B. SBOM: generate it like you mean it

4. Generate SBOMs at the right layer(s)

• Source-level SBOM (dependency graph)
• Artifact/container SBOM (what actually shipped)

If they disagree, treat that as a signal—your build pipeline is mutating inputs.

5. Don’t weld vulnerability state into SBOM unless you must It’s often cleaner operationally to publish SBOM + separate VEX (since vuln knowledge changes faster). SPDX 3.x explicitly supports richer, evolving security/vulnerability info. (spdx.dev)

---

C. VEX: make statuses evidence-backed and automatable

6. Use the standard status set Common VEX implementations use:

• affected
• not_affected
• fixed
• under_investigation (Docker Documentation)

7. Require justification for not_affected OpenVEX requires a status justification or an impact statement for not_affected. (GitHub) Practical rule: no “not_affected” without one of:

• “vulnerable code not in execute path” (+ evidence)
• “component not present”
• “inline mitigations exist” …plus a link to the supporting artifact(s).

8. Version and timestamp VEX statements Treat VEX like a living contract. Consumers need to know what changed and when.

---

D. Reachability / contextual analysis: avoid false certainty

9. Treat reachability as “evidence with confidence,” not absolute truth Static reachability is great but imperfect (reflection, plugins, runtime dispatch). Operationally:

• REACHABLE → prioritize
• NO PATH FOUND → deprioritize, don’t ignore
• NOT APPLICABLE → fall back to other signals (docs.snyk.io)

10. Attach the “why”: call-path or runtime proof If you claim “reachable,” include the call path (or a redacted proof). If you claim “not_affected,” include the justification and a reachability artifact.

---

E. Signing + distribution: ship proofs the way you ship artifacts

11. Bundle evidence and sign it A practical Stella Ops “release bundle” looks like:

• sbom.(cdx|spdx).json
• vex.(openvex|cdx|spdx|csaf).json
• provenance.intoto.json
• reachability.json|sarif
• bundle.sigstore.json (or equivalent)

Sigstore’s bundle format supports DSSE envelopes over attestations and can include transparency log entry material/timestamps. (Sigstore)

12. Publish to an append-only transparency log Transparency logs are valuable because they’re auditable and append-only; monitors can check consistency/inclusion. (Sigstore)

---

F. Policy: gate on what matters, not what’s loud

13. Write policies in terms of (severity × exploitability × confidence) Example policy pattern:

• Block deploy if: affected AND reachable AND critical
• Warn if: affected AND no_path_found
• Allow with waiver if: under_investigation but time-boxed and signed

14. Make exceptions first-class and expiring Exceptions should be signed statements tied to artifact digests, with TTL and rationale.

---

Developer guidelines (for engineers building Stella Ops itself)

1. Everything is a signed claim about a subject Model each output as: subject digest + predicate + evidence + signer + time.

2. Support multiple VEX formats, but normalize internally There are multiple VEX implementations (e.g., CycloneDX, SPDX, OpenVEX, CSAF); normalize into a canonical internal model so policy doesn’t care about input format. (Open Source Security Foundation)

3. Expose uncertainty Store:

• analysis method (static/runtime/hybrid),
• coverage (entrypoints, languages supported),
• confidence score,
• and known limitations. This prevents “NO PATH FOUND” being treated as “impossible.”

4. Make verification fast and offline-friendly Cache transparency log checkpoints, ship inclusion proofs in bundles, and support air-gapped verification flows where possible.

5. Design for redaction Call-path evidence can leak internals. Provide:

• full evidence (internal),
• redacted evidence (external),
• plus hash-based linking so the two correspond.

6. Build plugin rails Reachability analyzers, SBOM generators, scanners, and policy engines will vary by ecosystem. A stable plugin interface is key for adoption.

---

If you want a crisp deliverable to hand to engineering, you can lift the above into a 1–2 page “Stella Ops Integration Guide” with: pipeline steps, required artifacts, recommended policy defaults, and a VEX decision checklist.