archive audit attempts

docs-archived/product/advisories/19-Feb-2026 - SBOM Evidence Verification and Auditability Pipeline.md

@@ -0,0 +1,119 @@
+# Advisory: SBOM Evidence Verification and Auditability Pipeline
+
+**Date:** 2026-02-19
+**Status:** ARCHIVED (translated to sprint tasks)
+**Reviewed:** 2026-02-19
+
+## Review Outcome
+
+Advisory reviewed against current codebase. ~85% of proposed capabilities already exist in Stella Ops across Scanner, Signer, Attestor, Excititor, VexLens, Signals, EvidenceLocker, and ReachGraph modules.
+
+### Capabilities Confirmed (no action needed)
+- CycloneDX v1.7 SBOM generation (Scanner.Emit)
+- DSSE/in-toto attestation with 10+ predicate types (Attestor.Envelope)
+- Cosign-compatible signing via Signer (keyless Fulcio + keyful KMS/HSM)
+- Rekor v2 anchoring with RFC 6962 tile verification and offline mode (Attestor)
+- Deterministic VEX ingestion with AOC enforcement (Excititor + VexLens)
+- eBPF micro-witness collection with cross-distro replay (Signals + Scanner)
+- Evidence bundle storage with Merkle roots and portable audit packs (EvidenceLocker)
+- Offline verification for air-gapped deployments
+
+### Gaps Identified → Sprint Tasks Created
+1. **Unified canonical_id contract** → SPRINT_20260219_009 (CID-01, CID-02)
+2. **Artifact Canonical Record** → SPRINT_20260219_009 (CID-03, CID-04)
+3. **Predicate Schema Registry** → SPRINT_20260219_010 (PSR-01, PSR-02)
+4. **CI Assertion Pack** → SPRINT_20260219_011 (CIAP-01 through CIAP-04)
+5. **Micro-witness → VEX Auto-Suppress workflow** → SPRINT_20260219_012 (MWS-01 through MWS-03)
+
+### Proposals Explicitly Rejected
+- Replacing Signer with raw cosign CLI (Signer adds PoE, quotas, DPoP/mTLS)
+- Simplifying VEX handling (Excititor+VexLens+AOC is more sophisticated)
+- Adopting advisory's simplified schema URIs (keep existing Stella URIs, add to registry)
+- `replay_token` pointing to external S3 (keep CAS with BLAKE3 digests)
+
+---
+
+## Original Advisory Content
+
+(Inline advisory provided by user — full text preserved below for audit trail.)
+
+---
+
+# Why this matters (quick primer)
+
+* **SBOM** (software bill of materials) says what's inside an artifact.
+* **DSSE / in-toto** wraps evidence in a tamper-evident envelope.
+* **cosign** signs/verifies those envelopes.
+* **Rekor (transparency log)** proves *when/what* was published.
+* **VEX** states whether known CVEs affect your artifact.
+* **Micro-witnesses** are runtime breadcrumbs you can join back to SBOM/VEX for triage.
+
+---
+
+# NOW (MVP you can ship immediately)
+
+**Goal:** Minimal, reproducible spine with canonical SBOMs, signed attestations, Rekor v2 anchoring, and deterministic VEX ingestion.
+
+### Canonical SBOM & ID
+
+1. Emit CycloneDX v1.7 JSON.
+2. Canonicalize via JSON-JCS -> `canonical_id := sha256(JCS(sbom.json))`.
+
+### DSSE attestation (SBOM predicate)
+
+* Wrap CycloneDX content (or pointer) in an **in-toto Statement**.
+* `subject[0].digest.sha256 == canonical_id`.
+* Sign with cosign (**DSSE mode**).
+* Capture Rekor v2 tile pointer / entry id and embed it in predicate metadata.
+
+### Rekor v2 anchoring
+
+* cosign publish creates the log entry.
+* Store the **tile URL** and **entry id** in your artifact record.
+
+### Deterministic VEX ingestion (OpenVEX & CycloneDX VEX)
+
+* Ingest OpenVEX or CycloneDX VEX, map to a **canonical CycloneDX VEX** form.
+* Apply strict merge rules (source priority, timestamp, exact `canonical_id` target).
+
+### CI assertions (must-pass)
+
+* **Unit:** `cyclonedx-cli validate ./bom.json && jcs_canonicalize ./bom.json | sha256sum` -> equals expected `canonical_id`.
+* **Integration:**
+  `cosign attest --predicate predicate.json --key cosign.key <subject-ref>`
+  `cosign verify-attestation --key <pubkey> --type in-toto <subject-ref>`
+  Rekor proof: `rekor-cli tile get --entry <entry_id>` -> inclusion proof valid.
+* **VEX mapping:** jsonschema validate; assert `vulnerabilities[].analysis.state` and target match `canonical_id`.
+
+---
+
+# LATER (scale/hardening)
+
+* Rekor v2 **tile batching** & multi-tile reconciliation.
+* **Signed micro-witness aggregation** service.
+* **Deterministic replay** harness (nightly) for large volumes.
+* Predicate **schema registry** (stable `predicateType` URIs, semver).
+
+---
+
+# Flow A: Build-time SBOM + Attestation Anchor (end-to-end)
+
+1. **Producer:** CycloneDX v1.7 -> validate -> JCS canonicalize -> `canonical_id = sha256(canonical_bytes)`.
+2. **Predicate:** in-toto Statement with CycloneDX JCS content.
+3. **Sign & anchor:** cosign attest -> capture Rekor tile URL and entry_id.
+4. **Verify:** Fetch referrers, extract DSSE, cosign verify-attestation, recompute canonical_id, validate Rekor inclusion proof.
+
+# Flow B: VEX -> Apply -> Runtime Micro-witness Join
+
+1. **VEX provider:** Publish OpenVEX or CycloneDX VEX; DSSE-sign; optionally anchor in Rekor.
+2. **Ingest & map:** OpenVEX -> canonical CycloneDX VEX; store DSSE + rekor_tile + provenance.
+3. **Runtime micro-witness:** Emit DSSE micro-witness predicate referencing canonical_id.
+4. **Correlate:** Join micro-witness DSSE with VEX; if not_affected -> auto-suppress; else surface audit pack.
+
+---
+
+# Failure modes
+
+* Payload > Rekor limit: Put artifact in immutable store; Rekor entry contains digest + pointer.
+* Missing symbol bundle: Emit unknown_state micro-witness entry.
+* Digest mismatch anywhere: fail the build.

docs-archived/product/advisories/19-Feb-2026 - Supply Chain Security Tool Matrix.md

@@ -0,0 +1,112 @@
+# Supply Chain Security Tool Matrix (evidence from public docs)
+
+**Advisory date:** 2026-02-19
+**Archived:** 2026-02-19
+**Disposition:** Archived -- claims verified against codebase; two caveats noted below.
+
+---
+
+## SBOM support
+
+* **Stella Ops:** *YES* -- internal canonical CycloneDX JCS and SBOM ingest contracts (internal spec).
+* **Trivy:** *YES* -- generates and consumes CycloneDX/SPDX SBOM formats.
+* **Grype:** *YES* -- scans container images and SBOMs, accepts SBOM input.
+* **Snyk:** *YES* -- SBOM security checks and scanning/analysis.
+* **JFrog Xray:** *YES* -- scans artifacts and imports/analyses SBOMs (enterprise).
+* **Docker Scout:** *YES* -- generates/consumes SBOM attestations; Docker SBOM tooling exists.
+
+## VEX ingestion (OpenVEX / VEX docs)
+
+* **Stella Ops:** *YES* -- design includes deterministic VEX ingest (internal).
+* **Trivy:** *YES/PARTIAL* -- Rekor SBOM attestation scan supports VEX attestation via experimental plugins.
+* **Grype:** *YES/PARTIAL* -- supports OpenVEX ingestion for filtering/enrichment.
+* **Snyk:** *UNKNOWN* -- primary docs do not explicitly surface OpenVEX ingestion.
+* **JFrog Xray:** *YES/PARTIAL* -- evidence collection and enriched vulnerability annotations.
+* **Docker Scout:** *YES* -- Docker's VEX concepts documented for integration.
+
+## In-toto / DSSE / attestation ingestion
+
+* **Stella Ops:** *YES* -- DSSE/in-toto + articulated provenance anchors (internal).
+* **Trivy:** *PARTIAL* -- has experimental attestation retrieval via Rekor/Cosign.
+* **Grype:** *PARTIAL* -- linked tooling uses Cosign attestations via Syft workflows (public examples).
+* **Snyk:** *UNKNOWN/PARTIAL* -- primary docs focus on SBOM/scan; attestation ingestion not prominent.
+* **JFrog Xray:** *YES/PARTIAL* -- enterprise attestation/evidence documented.
+* **Docker Scout:** *YES* -- Docker Docs show attestation commands and retrieval.
+
+## Explainability depth (beyond package level)
+
+* **Stella Ops:** *DEEP (function-level shipped; line-level CFG partial)* -- function-level call-path witnesses with file/line/column context shipped; dedicated line-level CFG export not yet a shipped feature. **[CAVEAT: advisory originally said "function->line"; qualified to "function-level with line context".]**
+* **Trivy:** *PARTIAL/NO* -- reports package/component level; no public deep binary CFG explainability.
+* **Grype:** *PARTIAL* -- deep vulnerability metadata but not low-level CFG.
+* **Snyk:** *PARTIAL* -- contextual dev-focused explainability; no binary CFG.
+* **JFrog Xray:** *PARTIAL* -- rich reports but not per-frame CFG.
+* **Docker Scout:** *PARTIAL* -- good image composition context; no granular call-path explainability.
+
+## Smart diffing (semantic/structured)
+
+* **Stella Ops:** *YES* -- signed semantic diff predicates (internal).
+* **Trivy:** *PARTIAL* -- experimental compare features.
+* **Grype:** *PARTIAL* -- package diff workflows exist; not signed diff predicates.
+* **Snyk:** *PARTIAL* -- snapshot & delta tooling (e.g., snyk-delta).
+* **JFrog Xray:** *PARTIAL* -- enriched scan comparisons possible but not canonical diff predicates.
+* **Docker Scout:** *PARTIAL* -- `docker scout compare` CLI; not structured diff predicates.
+
+## Binary provenance
+
+* **Stella Ops:** *YES* -- symbol bundle + pinned build ID mappings.
+* **Trivy:** *PARTIAL/UNKNOWN* -- Rekor/SBOM attestations hint at provenance but not symbol bundle marketplace.
+* **Grype:** *PARTIAL/UNKNOWN* -- attestation via Syft/Cosign workflows but no signed symbol pack docs.
+* **Snyk:** *UNKNOWN* -- no primary proof of signed symbol handling.
+* **JFrog Xray:** *PARTIAL* -- evidence collection; no explicit signed symbol bundle.
+* **Docker Scout:** *PARTIAL* -- Docker Hardened Images provenance; not general marketplace.
+
+## Call-stack/micro-witness replay
+
+* **Stella Ops:** *YES* -- micro-witness replay design (internal).
+* **Others:** *NO/UNKNOWN* -- public docs do not show deterministic replayable micro-witness stack artifacts.
+
+## Deterministic signed scoring
+
+* **Stella Ops:** *YES* -- deterministic signed scores anchored to Rekor (internal).
+* **Competitors:** *NO/UNKNOWN* -- focus on heuristic scores; no published deterministic signed envelopes.
+
+## Explicit UNKNOWN-state handling
+
+* **Stella Ops:** *YES* -- canonical unknown state predicates.
+* **Competitors:** *PARTIAL/UNKNOWN* -- systems have 'not applicable' or suppressed states but no signed unknown predicate standard documents.
+
+## Reachability analysis (binary)
+
+* **Stella Ops:** *YES* -- integrated analysis by design.
+* **Competitors:** *NO/UNKNOWN* -- not visible in primary docs.
+
+## UI/UX evidence surfacing
+
+* **Stella Ops:** *YES* -- evidence ribbons & signed pointers (internal).
+* **Trivy:** *PARTIAL* -- CLI focus; some partner UIs exist.
+* **Grype:** *PARTIAL* -- CLI and partner UI capabilities.
+* **Snyk:** *YES/PARTIAL* -- strong developer UI; no DSSE/Rekor badges documented.
+* **JFrog Xray:** *YES/PARTIAL* -- enterprise UI for enriched evidence.
+* **Docker Scout:** *YES* -- CLI/UI attest list and VEX visibility.
+
+## CI/test parity
+
+* **Stella Ops:** *YES (gate engine shipped; CI automation integration in progress)* -- PolicyGateEvaluator with staged gates shipped; GitOps loop wiring under active development. **[CAVEAT: advisory originally said "two-tier gating (fast signed + deep)"; qualified to note CI automation integration is in progress.]**
+* **Trivy:** *YES/PARTIAL* -- CI integrations documented.
+* **Grype:** *YES/PARTIAL* -- CI workflows via Syft/Grype.
+* **Snyk:** *YES* -- solid CI/PR checks.
+* **JFrog Xray:** *PARTIAL* -- CI/CD integrations exist.
+* **Docker Scout:** *PARTIAL* -- CI CLI commands; no signed-score parity.
+
+---
+
+## Archive review notes
+
+**Reviewed:** 2026-02-19 by Product Manager role.
+
+**Outcome:** All Stella Ops claims verified against codebase. No new sprint tasks required. Two qualification caveats applied inline (marked with **[CAVEAT]**):
+
+1. **Explainability depth** -- function-level call-path witnesses shipped; line-level CFG export is architecturally supported but not a shipped feature. Softened from "function->line" to "function-level with line context."
+2. **CI/test parity** -- gate engine (`PolicyGateEvaluator`) and CVE-aware gates shipped; CI/CD automation integration loop under active development. Qualified accordingly.
+
+**Competitive claims:** Sourced from public vendor documentation. Not independently re-verified (web-tool policy). Cited sources appear credible.

docs-archived/product/advisories/2026-02-19-competitive-gap-attestation-symbol-score-replay.md

@@ -0,0 +1,51 @@
+# Advisory: Competitive Gap Brief -- Attestation / Symbol / Score / Replay / Audit
+
+**Received:** 2026-02-19
+**Source:** External LLM-generated competitive analysis (ChatGPT)
+**Status:** Reviewed -- No gaps. Pending archive.
+
+## Summary
+
+Advisory proposes five capabilities to "win enterprise RFPs" based on competitive analysis of Docker Scout, Trivy, and JFrog:
+
+1. Attestation Gateway (DSSE ingest + Rekor anchoring with size-aware pointer)
+2. Symbol Pack Referrer & Lookup (OCI referrer + build-ID endpoint)
+3. Deterministic Signed Score + Replay (seeded, signed DSSE with transforms)
+4. Micro-witness Tiles (call-stack replay with symbolized frames)
+5. Evidence Ribbon & Offline Audit-Pack (UI + export bundle)
+
+## Review Outcome
+
+**All five capabilities already exist in Stella Ops.**
+
+| # | Proposal | Existing Module(s) | Status |
+|---|----------|-------------------|--------|
+| 1 | Attestation Gateway | Attestor (DSSE, Rekor v2, detached payloads), Signer (DSSE generation) | Operational |
+| 2 | Symbol Pack Referrer | Symbols (REST API, build-ID lookup), BinaryIndex (fingerprints), Scanner (DWARF/PDB/Mach-O) | Operational |
+| 3 | Deterministic Signed Score | Policy Engine (stella-dsl@1, seeded eval), Replay (manifest v2), Signer (PolicyEvaluation@1 predicate) | Operational |
+| 4 | Micro-witness Tiles | ReachGraph (CAS subgraphs, edge-bundle DSSE, replay endpoint), Scanner (graph-level DSSE) | Operational |
+| 5 | Evidence Ribbon & Audit-Pack | Export Center (profiles), Evidence Locker (sealed bundles), Offline Kit, UI v2 (Sprint 20260219-005) | Operational / UI in progress |
+
+## Risks if Implemented As-Written
+
+- Endpoint duplication with existing Attestor, Symbols, Policy Engine APIs
+- Contract conflicts with frozen DSSE predicate schemas
+- Vocabulary confusion ("micro-witness" vs established "edge-bundle DSSE")
+
+## Minor Observations (Not Actionable)
+
+- `symbol_coverage_%` metric useful for dashboards; already implied by SBOM completeness/entropy scoring
+- Proposed SLO targets (2s ingest, 60s verify, 120s score) are reasonable; existing perf targets are comparable
+
+## Decision
+
+Archive. No sprint tasks required. Stella's implementation exceeds what the advisory proposes across all five areas.
+
+## Documentation Updates (2026-02-19)
+
+Although no implementation gaps were found, the advisory surfaced competitors (Docker Scout, JFrog) and differentiation angles that were underrepresented in competitive docs. The following documents were updated:
+
+- **`docs/product/competitive-landscape.md`**: Added Docker Scout and JFrog to snapshot table and origin taxonomy; added 3 new specific gap entries (symbolized call-stacks, deterministic scoring, Rekor size-aware strategy); updated verification date
+- **`docs/product/claims-citation-index.md`**: Added claims REACH-005, REACH-006 (symbolized call-stacks, OCI symbol packs), ATT-005 (Rekor pointer strategy), COMP-SCOUT-001/002 (Docker Scout), COMP-JFROG-001/002 (JFrog)
+- **`docs/product/moat-strategy-summary.md`**: Added Docker Scout and JFrog to competitor positioning table; expanded "Where We're Ahead" with 3 new entries; updated verified gaps with evidence from this advisory
+- **`docs/modules/platform/moat-gap-analysis.md`**: Updated implementation percentages to reflect Feb 2026 state; added 3 new feature rows (symbolized call-stacks, deterministic scoring, Rekor pointer); added Docker Scout/JFrog to "Avoid Head-On Fights"

docs-archived/product/advisories/2026-02-19-debug-symbol-ecosystem-landscape.md

@@ -0,0 +1,78 @@
+# Advisory: Debug Symbol Ecosystem Landscape
+
+**Date**: 2026-02-19
+**Status**: ARCHIVED (no new gaps)
+**Disposition**: Validates existing architecture; no sprint tasks required.
+
+---
+
+## Advisory Content
+
+The modern **debug symbol ecosystem** is quietly coalescing around a few open standards and patterns that matter deeply if you're building debuginfo/symbol retrieval tooling, mirrors, or secure redistribution systems — and the vendor landscape + formats/licensing are more fragmented than you might expect.
+
+`debuginfod` from **elfutils** has emerged as the de-facto HTTP API for build-id → debuginfo/executable/source retrieval, with clients caching aggressively and servers typically exposing endpoints like:
+
+* `GET /buildid/<hash>/debuginfo`
+* `GET /buildid/<hash>/executable`
+* and related source or section paths
+  over simple HTTP/HTTPS, indexed by build IDs embedded in ELF/DWARF objects.
+
+Most Linux distros now offer or federate debuginfod servers (e.g., Fedora, Debian, Ubuntu, openSUSE) that tools like GDB/LLDB, `debuginfod-find` and libdebuginfod can consume by setting `DEBUGINFOD_URLS`.
+
+**BTFHub** fills another niche for kernel toolchains: it's a canonical **Apache-2.0-licensed archive of BPF Type Format (BTF) files** for many published Linux kernels, allowing eBPF runtimes and tools to retrieve BTF when the kernel doesn't embed it.
+
+Symbol server and debug symbol trends across ecosystems are heterogeneous:
+
+* **Microsoft's Public Symbol Server** exposes Windows symbols for automated debugger consumption (e.g., Windbg) via symbol path mechanisms, but its license explicitly restricts **redistribution** outside tooling/contract terms.
+
+* **Mozilla's Firefox Symbol Server** hosts debug symbols (PDB-like or similar) for nightly and release builds and uses upload jobs to populate symbols; integration is similar in concept to MS's servers but with its own workflows and policies.
+
+These vendor servers predate debuginfod and aren't directly redistributable without respecting their respective **license terms / upload policies**.
+
+Under the hood, the **debug formats themselves remain normative**:
+
+* DWARF (v5+ in modern toolchains) is the standard hierarchical debug info format in ELF objects.
+* BTF is the compact, kernel-centric type format optimized for eBPF and tooling portability (used by libbpf and CO-RE tooling).
+
+Operational patterns that have emerged:
+
+1. **Live lookup via debuginfod/symbol-server endpoints** with strong **cache-first logic** and pinned build-IDs (`DEBUGINFOD_URLS`, client caching).
+2. **Signed artifact bundles** (e.g., DSSE/in-toto) anchored to transparency logs (e.g., Rekor) for **redistributable symbol packs** or marketplace distribution (toolchains outside public servers).
+3. **Enterprise mirrors + signed BTF bundles** for air-gapped sync: sync via rsync or OCI-style layers, groom cache, and serve locally to internal debug fleets under your own policies.
+
+Because vendor symbol servers (e.g., Microsoft's) **explicitly limit raw redistribution**, production systems should avoid republishing raw symbols from these endpoints unless you have a contractual agreement — instead rely on **attested metadata or signed bundles** you control.
+
+### References
+
+- [Introducing debuginfod, the elfutils debuginfo server](https://developers.redhat.com/blog/2019/10/14/introducing-debuginfod-the-elfutils-debuginfo-server)
+- [elfutils debuginfod services](https://sourceware.org/elfutils/Debuginfod.html)
+- [aquasecurity/btfhub](https://github.com/aquasecurity/btfhub)
+- [Microsoft Public Symbol Server for Windows Debuggers](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/microsoft-public-symbols)
+- [Using the Mozilla symbol server](https://firefox-source-docs.mozilla.org/toolkit/crashreporter/crashreporter/Using_the_Mozilla_symbol_server.html)
+
+---
+
+## Analysis
+
+### Outcome: No new gaps — archive
+
+Every pattern described in this advisory is already implemented or in-progress in Stella Ops:
+
+| Advisory Topic | Stella Ops Coverage | Module(s) |
+|---|---|---|
+| debuginfod integration | `DebuginfodConnector` — 3-phase pipeline (Fetch→Parse→Map), multi-server fallback, IMA sig framework | `src/BinaryIndex/` |
+| DWARF parsing | `DwarfDebugReader`, function boundary detection, confidence tiers | `src/Scanner/` |
+| Symbol server / distribution | Multi-tenant REST API, CAS-backed storage, DSSE-signed manifests | `src/Symbols/` |
+| OCI symbol packs | `application/vnd.stella.symbols.manifest.v1+json` as referrer artifacts | `src/Symbols/` |
+| Signed artifact bundles | DSSE envelopes, Rekor-backed transparency, offline bundle management | `src/Symbols/`, `src/Attestor/` |
+| Enterprise mirrors / air-gap | OCI-layer sync, offline kits, RootPack bundles | `src/AirGap/`, `src/Symbols/` |
+| Build-ID binding | ELF Build-IDs, PDB GUIDs, GNU build-ids | `src/Symbols/`, `src/BinaryIndex/` |
+| BTF / BTFHub | Partial — eBPF micro-witness uses deterministic symbolization tuples; not a primary connector | `src/Signals/` |
+
+### Competitive validation
+
+"Symbolized call-stack proofs" is claimed as a moat differentiator (REACH-005, REACH-006) in `docs/product/moat-strategy-summary.md`. This advisory confirms industry alignment with that positioning.
+
+### Note on BTFHub
+
+BTFHub (Apache-2.0 BTF archive) is not directly integrated as a ground-truth connector. Adding it would be incremental if kernel-level eBPF tooling becomes a customer requirement. Not actionable today.

docs-archived/product/advisories/2026-02-19-moat-experiments-chatgpt/19-Feb-2026 - Four Fast Moat Experiments.md

@@ -0,0 +1,69 @@
+# Advisory: Four Fast Moat Experiments
+
+**Date**: 2026-02-19
+**Source**: External (AI-generated, ChatGPT origin)
+**Status**: ARCHIVED — reviewed and dispositioned
+
+---
+
+## Advisory Content (verbatim)
+
+Four proposed "moat experiments" for Stella Ops:
+
+1. **Function-level semantic fingerprints ("semhash")** — Resilient artifact identity via DWARF-based IL extraction, normalization, embedding/hashing. CI job asserting >=80% cluster stability across compiler flags.
+
+2. **Deterministic short-run behavior attestations (sandbox traces)** — Containerized micro-handler under Firecracker/gVisor, recorded with `rr`, wrapped as DSSE, signed with cosign, anchored to Rekor. Verifier replays and checks.
+
+3. **Dual-log "twin-proof" stitching** — Same DSSE digest anchored to Rekor v2 AND signed Git tags. Verifier checks both inclusion proofs. Increased tamper cost.
+
+4. **Attestable runtime canary beacons** — Embedded Go binary at container entrypoint posts signed `{artifact_id, nonce, timestamp}` over mTLS to collector with Rekor anchoring.
+
+### Advisory's integration suggestions
+- Evidence Locker: store all four as DSSE records
+- Attestor: add sandbox-trace.verify() and twin-proof.verify()
+- AdvisoryAI: surface KPIs (semhash stability %, trace-replay PASS rate, etc.)
+- Release Orchestrator: optional gates per environment
+
+### Referenced technologies
+- KEENHash (ISSTA 2025), DWARF v5, diffoscope v312
+- Firecracker, rr, cosign, Rekor v2, Canarytokens
+
+---
+
+## Review Disposition
+
+| # | Proposal | Outcome | Sprint |
+|---|----------|---------|--------|
+| 1 | Semantic fingerprints | **ARCHIVED — already implemented** | None (BinaryIndex module complete) |
+| 2 | Sandbox traces | **PARTIAL ACCEPT — rescoped** | SPRINT_20260219_013 |
+| 3 | Dual-log stitching | **REJECTED** | None |
+| 4 | Runtime beacons | **PARTIAL ACCEPT — rescoped** | SPRINT_20260219_014 |
+
+### Item 1 — Semantic fingerprints: No gaps
+
+BinaryIndex module already implements: `SemanticFingerprintGenerator` (WL graph hashing), `IrLiftingService` (IR/SSA lifting), `SemanticGraphExtractor` (KSG extraction), `SemanticMatcher`, `FunctionDiffer`, `FunctionRenameDetector`. Multi-backend disassembly (B2R2, Iced) for ARM/x86/x64/AArch64. Integrated into Attestor proof chain via `BinaryFingerprintEvidenceGenerator` + `BinaryFingerprintEvidencePredicate` (DSSE-signed). Remaining Tier 4 work covered by sprints 7204-7206.
+
+### Item 2 — Sandbox traces: Rescoped to native primitives
+
+**Accepted concept**: Cryptographically attestable execution evidence.
+**Rejected toolchain**: Firecracker (Linux-only micro-VMs, platform coupling), `rr` (Linux-only, recording overhead), cosign keyless (requires Fulcio OIDC, incompatible with HSM/regional crypto), Rekor (public transparency log, breaks offline-first).
+**Replacement**: Existing Signals runtime-facts ingestion + Attestor DSSE chain + Signer multi-profile (all regional crypto profiles supported). See SPRINT_20260219_013.
+
+### Item 3 — Dual-log stitching: Rejected
+
+**Reason 1**: Rekor dependency breaks offline-first posture and air-gap capability.
+**Reason 2**: Existing ProofBlob dual-evidence approach (distro feed + source intelligence + binary fingerprinting) provides evidence-level redundancy, which is architecturally stronger than log-level redundancy (same claim written to two logs).
+**Reason 3**: Regional crypto conflict (Rekor uses Sigstore signing; Stella Ops supports GOST/SM/eIDAS/PQC).
+**Reason 4**: Transparency log anchoring is becoming table stakes (Level 2-3 moat). Stella Ops' proof-carrying verdicts are Level 5.
+**Alternative**: If customer demand materializes for transparency log export, add as optional ExportCenter adapter (P3).
+
+### Item 4 — Runtime beacons: Rescoped to native primitives
+
+**Accepted concept**: Low-volume signed proof of artifact execution for compliance.
+**Rejected approach**: Entrypoint-injected Go binary (breaks image integrity guarantees), mTLS collector (new infrastructure), Rekor anchoring (offline-first conflict).
+**Replacement**: eBPF uprobes / ETW DynamicTraceProvider on config-designated beacon functions (no image modification) + existing Signals ingestion + Attestor DSSE chain. See SPRINT_20260219_014.
+
+---
+
+**Reviewed by**: Product Manager
+**Review date**: 2026-02-19

docs-archived/product/advisories/2026-02-19-oci-referrers-api-registry-compatibility.md

@@ -0,0 +1,79 @@
+# Advisory: OCI Referrers API Registry Compatibility (2026-02-19)
+
+> **Status**: Archived (no implementation gaps)
+> **Date received**: 2026-02-19
+> **Archived**: 2026-02-19
+
+## Summary
+
+Advisory covering the fragmented state of OCI Referrers API support across major container registries (GHCR, ECR, Google Artifact Registry, Quay, Harbor, GitLab, Docker Hub) and its impact on supply-chain artifact discovery workflows.
+
+## Key points from advisory
+
+- **GHCR**: No OCI referrers API endpoint; requires tag-based fallback or GitHub Attestations API
+- **ECR**: Full OCI Distribution 1.1 support including referrers; lifecycle/GC rules must include referrer artifacts
+- **Google Artifact Registry**: Exposes an attachments model (`gcloud artifacts attachments list`) alongside standard OCI; some features in public preview
+- **Quay/Quay.io**: OCI Referrers API announced; self-hosted deployments may require admin toggles
+- **Harbor**: API-level support in 2.0+; UI may display cosign/SBOM referrers as "UNKNOWN" in v2.15+
+- **GitLab Container Registry**: Stores OCI artifacts with `subject` field but does not expose referrers endpoint
+- **Spec nuance**: OCI Distribution 1.1 requires runtime detection and fallback to tag-by-digest conventions
+
+## Assessment
+
+**No implementation gaps found.** Stella Ops already comprehensively handles the scenarios described:
+
+1. **Native-first with tag-based fallback**: `OciReferrerDiscovery.cs`, `OciReferrerFallback.cs` in ExportCenter
+2. **Runtime capability probing**: `ProbeRegistryCapabilitiesAsync()` detects OCI 1.1 via distribution headers
+3. **Registry compatibility matrix**: `docs/modules/export-center/registry-compatibility.md` covers 12+ registry types
+4. **Per-registry handling**: GHCR (fallback), ECR (native), GAR (native), Harbor 1.x/2.0+ (split), Quay (partial+fallback)
+5. **Cosign interoperability**: Full DSSE/cosign-compatible manifests and annotations
+6. **No external ORAS dependency**: Implements OCI Distribution Spec directly
+7. **Doctor health checks**: `RegistryReferrersApiCheck.cs`, `RegistryCapabilityProbeCheck.cs`
+8. **Operational runbooks**: `docs/runbooks/registry-compatibility.md`, `docs/runbooks/registry-referrer-troubleshooting.md`
+
+## Documentation updates applied
+
+Minor polish applied before archiving:
+
+1. **Added GitLab Container Registry** to compatibility matrix, troubleshooting runbook, and quick-reference runbook
+2. **Refined Google Artifact Registry** notes: documented attachments model as alternative UX alongside standard OCI API
+3. **Added Harbor UI classification caveat**: UI may show referrers as "UNKNOWN" in v2.15+; does not affect API discovery
+4. **Added Quay admin toggle note**: self-hosted deployments may need feature flags enabled for referrers API
+5. **Added troubleshooting entries**: Harbor UI "UNKNOWN" issue and Quay inconsistent referrers sections added to runbook
+
+### Files updated
+
+- `docs/modules/export-center/registry-compatibility.md`
+- `docs/runbooks/registry-compatibility.md`
+- `docs/runbooks/registry-referrer-troubleshooting.md`
+
+## Original advisory content
+
+OCI Referrers API and Distribution Spec -- the official mechanism to list related artifacts by subject (digest) -- is part of OCI Distribution 1.1, and spec text now clarifies fallback behavior when referrers are not supported (registries SHOULD return 200 on supported referrers calls; 404 or fallback tag otherwise).
+
+### GHCR -- Lack of referrers
+GHCR implements OCI image formats but does not support the OCI referrers API endpoint for generic discovery of artifacts by subject. Community threads confirm queries against `/v2/<name>/referrers/<digest>` do not work. The practical implication: you must use GitHub's specific Attestations/Policy APIs or fetch artifacts by known SHA.
+
+### ECR -- OCI 1.1 support
+AWS has documented support for OCI Image and Distribution 1.1 specs, including image referrers, SBOMs, signatures, and non-image artifact distribution. OCI-aware clients (ORAS, containerd tooling) should be able to list and pull referrers by digest. Referrers count toward storage and lifecycle policies; include these artifact patterns explicitly in lifecycle/GC rules.
+
+### Google Artifact Registry -- attachments + listing
+Google Artifact Registry provides an attachments model for metadata (SBOMs, provenance) tied to an artifact. Attachments can be listed with `gcloud artifacts attachments list` and via console UI. IAM roles govern access, and some features are in public preview.
+
+### Red Hat Quay / Quay.io -- OCI referrers implemented
+Quay has announced support for the OCI Referrers API, enabling clients to query relationships by subject and artifactType. Watch for deployment flags or admin toggles that control this feature.
+
+### Harbor -- evolving but partial
+Harbor can store OCI artifacts, but its implementation of referrers has historically lagged UI classification: cosign or SBOM referrers may be accepted at the API level while displayed as "UNKNOWN" in UI. Active work is on improving OCI 1.1 support, but UI behavior and mediaType classification may still lag the API capabilities in releases around v2.15+.
+
+### Spec and ecosystem nuance
+OCI Distribution 1.1 spec updates explicitly require registries that support referrers to return successful responses for referrers endpoints; otherwise clients should fall back to tag-by-digest conventions. Because referrers support is optional and not universal yet, generic clients must detect support at runtime and fallback where needed. Many registries (e.g., Docker Hub, GitLab) can store OCI artifacts with `subject` fields, but will not expose them via a referrers endpoint.
+
+### References
+- [OCI Image and Distribution Specs v1.1 Releases](https://opencontainers.org/posts/blog/2024-03-13-image-and-distribution-1-1/)
+- [GHCR provenance discussion](https://github.com/orgs/community/discussions/163029)
+- [OCI 1.1 support in Amazon ECR](https://aws.amazon.com/blogs/opensource/diving-into-oci-image-and-distribution-1-1-support-in-amazon-ecr/)
+- [Google Artifact Registry attachments](https://docs.cloud.google.com/artifact-registry/docs/manage-metadata-with-attachments)
+- [OCI Referrers API on Quay.io](https://www.redhat.com/en/blog/announcing-open-container-initiativereferrers-api-quayio-step-towards-enhanced-security-and-compliance)
+- [Harbor Architecture Overview](https://github.com/goharbor/harbor/wiki/Architecture-Overview-of-Harbor)
+- [GitLab Container Registry](https://docs.gitlab.com/user/packages/container_registry/)

docs-archived/product/advisories/2026-02-19-vex-callstack-determinism-competitive-landscape.md

@@ -0,0 +1,90 @@
+# 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