6.4 KiB
6.4 KiB
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