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)
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)
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)

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)
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)

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)
Tools consume VEX to reduce noise but don't consolidate or surface provenance of merged statements; that often requires additional scripting or orchestration. (GitHub)

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)
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

Oligo Security identified as emerging runtime evidence competitor (call-stack exploitability proofs). Runtime-only; not an SBOM/VEX integrator. Added to competitive landscape.
Aqua VEX Hub noted as centralized VEX statement repository. Reduces alert noise but doesn't provide lattice logic or provenance. Added to competitive landscape.
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

6.4 KiB Raw Blame History