# Advisory: VEX, Call-Stack Evidence, and Deterministic Audit in Public Tooling

**Date Received:** 2026-02-19
**Archived:** 2026-02-19
**Outcome:** No new implementation gaps. Validates existing positioning and active sprint coverage.

---

## Source Content

### VEX Integration & Limitations in Public Tools

- Tools like **Trivy** support CycloneDX and OpenVEX formats; users can supply a VEX for filtering scan results, but merging logic and edge-case support are known issues (e.g., suppressing duplicates or distinct PURLs isn't always consistent) — reported in community discussions. ([Trivy](https://trivy.dev/docs/v0.51/supply-chain/vex/))
- Centralized efforts like **Aqua's VEX Hub** improve how VEX statements are found and consumed — reducing alert noise by enriching scan results with exploitability context. ([Aqua](https://www.aquasec.com/blog/introducing-vex-hub-unified-repository-for-vex-statements/))
- SBOM/VEX workflows broadly aim to semantically tell tools *which vulnerabilities are exploitable* in context, but tooling support varies and is often manual (users generate SBOM -> generate VEX -> rescan). ([CycloneDX](https://cyclonedx.org/capabilities/vex/))

### Call-stack & Runtime Evidence

- Mainstream open-source scanners don't natively produce symbolized call stacks tying vulnerabilities to *actual code execution paths* — this kind of runtime evidence has to come from specialized runtime monitors. ([Oligo Security](https://www.oligo.security/blog/show-me-the-call-stack-proving-exploitability-with-runtime-evidence))
- Emerging products (e.g., runtime management tools) show call stacks where vulnerabilities actually executed, giving *actual exploitability proof* — very different from static package-level findings. ([Oligo Security](https://www.oligo.security/blog/show-me-the-call-stack-proving-exploitability-with-runtime-evidence))

### Explainability & Traceability in Scanners

- Most tools report vulnerabilities tied to packages or metadata — they don't explain *CFG reachability*, function-level paths, or *why* a vulnerability matters in context beyond "present/not_affected" states. ([wiz.io](https://www.wiz.io/academy/application-security/sbom-scanning))
- Tools consume VEX to reduce noise but *don't consolidate or surface provenance* of merged statements; that often requires additional scripting or orchestration. ([GitHub](https://github.com/aquasecurity/trivy/discussions/7885))

### Deterministic Evidence & Auditability

- Public scanners produce reports and formats (CycloneDX SBOM, JSON, etc.), and some support signing (e.g., Cosign attestation workflows) but *signed deterministic scoring envelopes with inclusion proofs* aren't standard outputs. ([OneUptime](https://oneuptime.com/blog/post/2026-01-30-trivy-sbom-generation/view))
- Rekor/attestation integration happens in ecosystems but isn't deeply embedded as a *first-class deterministic audit artifact* in core tooling docs.

### Where the Gaps Are for Competitors

- **Trivy, Grype (Anchore):** VEX support exists but merge semantics and deep provenance aren't central; outputs are package-centric.
- **General SCA/SAST Tools:** Focus on static findings without deep binary CFG or call-stack clarity.
- **Runtime Scanners (emerging):** Some provide call stack evidence but aren't positioned as SBOM/VEX integrators.

### Why This Matters for Messaging

The public documentation and community issues around these tools show that:

* **Deterministic merging with traceable provenance** (not silent overwrite) is rare.
* **Deep call stack symbolization linked to evidence** is mostly absent outside runtime observability products.
* **Signed, reproducible score artifacts anchored to a transparency log** are not a mainstream feature in typical scanners.

Framing Stella Ops around *replayable micro-witnesses*, *explainability beyond package lists*, and *deterministic audit evidence* highlights differentiation against the status-quo tooling in both product messaging and live demos.

### References

- [1] Trivy VEX docs: https://trivy.dev/docs/v0.51/supply-chain/vex/
- [2] Aqua VEX Hub: https://www.aquasec.com/blog/introducing-vex-hub-unified-repository-for-vex-statements/
- [3] CycloneDX VEX: https://cyclonedx.org/capabilities/vex/
- [4] Oligo Security call-stack evidence: https://www.oligo.security/blog/show-me-the-call-stack-proving-exploitability-with-runtime-evidence
- [5] Wiz SBOM scanning: https://www.wiz.io/academy/application-security/sbom-scanning
- [6] Trivy VEX suppression issue: https://github.com/aquasecurity/trivy/discussions/7885
- [7] OneUptime Trivy SBOM: https://oneuptime.com/blog/post/2026-01-30-trivy-sbom-generation/view

---

## Analysis

### Verification Summary

| Advisory Topic | Stella Ops Status | Claim IDs |
|---|---|---|
| VEX merge semantics & provenance | **Production** (VexLens consensus, Concelier AOC) | VEX-001/002/003, COMP-TRIVY-001 |
| Call-stack & runtime evidence | **Production** (PathWitness, RuntimeWitness, DSSE-signed) | REACH-001/002/005/006 |
| CFG reachability explainability | **Production** (ReachGraph edge types, SARIF integration) | REACH-001/002 |
| Signed deterministic scoring | **Production** (DSSE, Rekor v2, proof spine, Merkle roots) | DET-001/004, ATT-001/005, PROOF-001/003 |
| Replayable micro-witnesses | **In progress** (SPRINT_20260219_012) | Contract: `triage-suppress-v1.md` |

### New Competitive Intelligence

1. **Oligo Security** identified as emerging runtime evidence competitor (call-stack exploitability proofs). Runtime-only; not an SBOM/VEX integrator. Added to competitive landscape.
2. **Aqua VEX Hub** noted as centralized VEX statement repository. Reduces alert noise but doesn't provide lattice logic or provenance. Added to competitive landscape.
3. **Trivy community issue #7885** confirms VEX suppression limitations with distinct PURLs — validates COMP-TRIVY-001.

### Documentation Updates Applied

- Added Oligo Security to `docs/product/competitive-landscape.md` (emerging competitor section)
- Updated Aqua/Trivy section in competitive landscape with VEX Hub mention
- No new claims-citation-index entries needed (all advisory points map to existing claims)

### Decision

**Archive without new sprint tasks.** The advisory:
- Validates existing moat positioning (all 5 one-liners remain accurate)
- Confirms active sprint coverage for remaining gaps (009-012)
- Introduces no capabilities we haven't already architected or implemented
- Provides useful external references for competitive claims verification