git.stella-ops.org/docs/key-features.md

# Key Features – Capability Cards

> **Core Thesis:** Stella Ops isn't a scanner that outputs findings. It's a platform that outputs **attestable decisions that can be replayed**. That difference survives auditors, regulators, and supply-chain propagation.

> **Looking for the complete feature catalog?** See [`full-features-list.md`](full-features-list.md) for the comprehensive list of all platform capabilities, or [`FEATURE_MATRIX.md`](FEATURE_MATRIX.md) for tier-by-tier availability.

---

## At a Glance

| What Competitors Do | What Stella Ops Does |
|--------------------|---------------------|
| Output findings | Output decisions with proof chains |
| VEX as suppression file | VEX as logical claim system (K4 lattice) |
| Reachability as badge | Reachability as signed proof |
| "+3 CVEs" reports | "Exploitability dropped 41%" semantic deltas |
| Hide unknowns | Surface and score unknowns |
| Online-first | Offline-first with full parity |

---

Each card below pairs the headline capability with the evidence that backs it and why it matters day to day.

## 0. Decision Capsules — Audit-Grade Evidence Bundles

**The core moat capability.** Every scan result is sealed in a **Decision Capsule**—a content-addressed bundle containing everything needed to reproduce and verify the vulnerability decision.

| Component | What's Included |
|-----------|----------------|
| **Inputs** | Exact SBOM, frozen feed snapshots (with Merkle roots), policy version, lattice rules |
| **Evidence** | Reachability proofs (static + runtime), VEX statements, binary fingerprints |
| **Outputs** | Verdicts, risk scores, remediation paths |
| **Signatures** | DSSE envelopes over all of the above |

**Why it matters:** Six months from now, an auditor can run `stella replay srm.yaml --assert-digest <sha>` and get *identical* results. This is what "audit-grade assurance" actually means.

**No competitor offers this.** Trivy, Grype, Snyk—none can replay a past scan bit-for-bit because they don't freeze feeds or produce deterministic manifests.

## 1. Delta SBOM Engine

**Performance without sacrificing determinism.** Layer-aware ingestion keeps the SBOM catalog content-addressed; rescans only fetch new layers.

- **Speed:** Warm scans < 1 second; CI/CD pipelines stay fast
- **Determinism:** Replay Manifest (SRM) captures exact analyzer inputs/outputs per layer
- **Evidence:** Binary crosswalk via Build-ID mapping; `bin:{sha256}` fallbacks for stripped binaries

**Modules:** `Scanner`, `SbomService`, `BinaryIndex`

---

## 2. Lattice Policy + OpenVEX (K4 Logic)

**VEX as a logical claim system, not a suppression file.** The policy engine uses **Belnap K4 four-valued logic** (Unknown, True, False, Conflict) to merge SBOM, advisories, VEX, and waivers.

| What Competitors Do | What Stella Does |
|--------------------|------------------|
| VEX filters findings (boolean) | VEX is logical claims with trust weighting |
| Conflicts hidden | Conflicts are explicit state (⊤) |
| "Vendor says not_affected" = done | Vendor + runtime + reachability merged; conflicts surfaced |
| Unknown = assume safe | Unknown = first-class state with risk implications |

**Why it matters:** When vendor says "not_affected" but your runtime shows the function was called, you have a *conflict*—not a false positive. The lattice preserves this for policy resolution.

**Modules:** `VexLens`, `TrustLatticeEngine`, `Excititor` (110+ tests passing)

---

## 3. Sovereign Crypto Profiles

**Regional compliance without code changes.** FIPS, eIDAS, GOST, SM, and PQC (post-quantum) profiles are configuration toggles, not recompiles.

| Profile | Algorithms | Use Case |
|---------|-----------|----------|
| **FIPS-140-3** | ECDSA P-256, RSA-PSS | US federal requirements |
| **eIDAS** | ETSI TS 119 312 | EU qualified signatures |
| **GOST-2012** | GOST R 34.10-2012 | Russian Federation |
| **SM2** | GM/T 0003.2-2012 | People's Republic of China |
| **PQC** | Dilithium, Falcon | Post-quantum readiness |

**Why it matters:** Multi-signature DSSE envelopes (sign with FIPS *and* GOST) for cross-jurisdiction compliance. No competitor offers this.

**Modules:** `Cryptography`, `CryptoProfile`, `RootPack`

---

## 4. Deterministic Replay

**The audit-grade guarantee.** Every scan produces a DSSE + SRM bundle that can be replayed with `stella replay srm.yaml`.

```bash
# Six months later, prove what you knew
stella replay srm.yaml --assert-digest sha256:abc123...
# Output: PASS - identical result
```

**What's frozen:**
- Feed snapshots (NVD, KEV, EPSS, distro advisories) with content hashes
- Analyzer versions and configs
- Policy rules and lattice state
- Random seeds for deterministic ordering

**Why it matters:** This is what "audit-grade" actually means. Not "we logged it" but "you can re-run it."

---

## 5. Offline Operations (Air-Gap Parity)

**Full functionality without network.** Offline Update Kits bundle everything needed for air-gapped operation.

| Component | Online | Offline |
|-----------|--------|---------|
| Feed updates | Live | Sealed bundle with Merkle roots |
| Crypto verification | OCSP/CRL | Embedded revocation lists |
| Transparency logging | Rekor | Local transparency mirror |
| Trust roots | Live TSL | RootPack bundles |

**Why it matters:** Air-gapped environments get *identical* results to connected, not degraded. Competitors offer partial offline (cached feeds) but not epistemic parity (sealed, reproducible knowledge state).

**Modules:** `AirGap.Controller`, `TrustStore`, `EgressPolicy`

---

## 6. Signed Reachability Proofs

**Proof of exploitability, not just a badge.** Every reachability graph is sealed with DSSE; optional edge-bundle attestations for contested paths.

| Layer | What It Proves | Attestation |
|-------|---------------|-------------|
| **Static** | Call graph says function is reachable | Graph-level DSSE |
| **Binary** | Compiled binary contains the symbol | Build-ID mapping |
| **Runtime** | Process actually executed the code path | Edge-bundle DSSE (optional) |

**Why it matters:** Not "potentially reachable" but "here's the exact call path from `main()` to `vulnerable_function()`." You can quarantine or dispute individual edges, not just all-or-nothing.

**No competitor signs reachability graphs.** They claim reachability; we *prove* it.

**Modules:** `ReachGraph`, `PathWitnessBuilder`, `CompositeGateDetector`

---

## 7. Semantic Smart-Diff

**Diff security meaning, not CVE counts.** Compare reachability graphs, policy outcomes, and trust weights between releases.

```
Before: 5 critical CVEs (3 reachable)
After:  7 critical CVEs (1 reachable)

Smart-Diff output: "Exploitability DECREASED by 67% despite +2 CVEs"
```

**What's compared:**
- Reachability graph deltas
- VEX state changes
- Policy outcome changes
- Trust weight shifts

**Why it matters:** "+3 CVEs" tells you nothing. "Reachable attack surface dropped by half" tells you everything.

**Modules:** `MaterialRiskChangeDetector`, `RiskStateSnapshot`, `Scanner.ReachabilityDrift`

---

## 8. Unknowns as First-Class State

**Uncertainty is risk—we surface and score it.** Explicit modeling of what we *don't* know, with policy implications.

| Band | Meaning | Policy Action |
|------|---------|---------------|
| **HOT** | High uncertainty + exploit pressure | Immediate investigation |
| **WARM** | Moderate uncertainty | Scheduled review |
| **COLD** | Low uncertainty | Decay toward resolution |
| **RESOLVED** | Uncertainty eliminated | No action |

**Why it matters:** Competitors hide unknowns (assume safe). We track them with decay algorithms, blast-radius containment, and policy budgets ("fail if unknowns > N").

**Modules:** `UnknownStateLedger`, `Policy`, `Signals`

---

## 9. Three-Layer Reachability Proofs

**Structural false positive elimination.** All three layers must align for exploitability to be confirmed.

```
Layer 1 (Static):  Call graph shows path from entrypoint → vulnerable function
Layer 2 (Binary):  Compiled binary contains the symbol with matching offset
Layer 3 (Runtime): eBPF probe confirms function was actually executed
```

**Confidence tiers:**
- **Confirmed** — All three layers agree
- **Likely** — Static + binary agree; no runtime data
- **Present** — Package present; no reachability evidence
- **Unreachable** — Static analysis proves no path exists

**Why it matters:** False positives become *structurally impossible*, not heuristically reduced.

**Modules:** `Scanner.VulnSurfaces`, `PathWitnessBuilder`

---

## 10. Competitive Moats Summary

**Four capabilities no competitor offers together:**

| # | Capability | Why It's Hard to Copy |
|---|-----------|----------------------|
| 1 | **Signed Reachability** | Requires three-layer instrumentation + cryptographic binding |
| 2 | **Deterministic Replay** | Requires content-addressed evidence + feed snapshotting |
| 3 | **K4 Lattice VEX** | Requires rethinking VEX from suppression to claims |
| 4 | **Sovereign Offline** | Requires pluggable crypto + offline trust roots |

**Reference:** `docs/market/competitive-landscape.md`, `docs/market/moat-strategy-summary.md`

---

## 11. Trust Algebra Engine (K4 Lattice)

**Formal conflict resolution, not naive precedence.** The lattice engine uses Belnap K4 four-valued logic to aggregate heterogeneous security assertions.

| State | Meaning | Example |
|-------|---------|---------|
| **Unknown (⊥)** | No information | New package, no VEX yet |
| **True (T)** | Positive assertion | "This CVE affects this package" |
| **False (F)** | Negative assertion | "This CVE does not affect this package" |
| **Conflict (⊤)** | Contradictory assertions | Vendor says not_affected; runtime says called |

**Security Atoms (six orthogonal propositions):**
- PRESENT, APPLIES, REACHABLE, MITIGATED, FIXED, MISATTRIBUTED

**Why it matters:** Unlike naive precedence (vendor > distro > scanner), we:
- Preserve conflicts as explicit state, not hidden
- Track critical unknowns separately from ancillary ones
- Produce deterministic, explainable dispositions

**Modules:** `TrustLatticeEngine`, `Policy` (110+ tests passing)

---

## 12. Deterministic Task Packs

**Auditable automation.** TaskRunner executes declarative Task Packs with plan-hash binding, approvals, and DSSE evidence bundles.

- **Plan-hash binding:** Task pack execution is tied to specific plan versions
- **Approval gates:** Human sign-off required before execution
- **Sealed mode:** Air-gap compatible execution
- **Evidence bundles:** DSSE-signed results for audit trails

**Why it matters:** Same workflows online or offline, with provable provenance.

**Reference:** `docs/task-packs/spec.md`, `docs/modules/taskrunner/architecture.md`

---

## 13. Evidence-Grade Testing

**Determinism as a continuous guarantee.** CI lanes that make reproducibility continuously provable.

| Test Type | What It Proves |
|----------|---------------|
| **Determinism tests** | Same inputs → same outputs |
| **Offline parity tests** | Air-gapped = connected results |
| **Contract stability tests** | APIs don't break |
| **Golden fixture tests** | Historical scans still replay |

**Why it matters:** Regression-proof audits. Evidence, not assumptions, drives releases.

**Reference:** `docs/testing/testing-strategy-models.md`, `docs/TEST_SUITE_OVERVIEW.md`

---

## Quick Reference

### Key Commands

```bash
# Determinism proof
stella scan --image <img> --srm-out a.yaml
stella scan --image <img> --srm-out b.yaml
diff a.yaml b.yaml  # Identical

# Replay proof
stella replay srm.yaml --assert-digest <sha>

# Reachability proof
stella graph show --cve CVE-XXXX-YYYY --artifact <digest>

# VEX evaluation
stella vex evaluate --artifact <digest>

# Offline scan
stella rootpack import bundle.tar.gz
stella scan --offline --image <digest>
```

### Key Documents

- **Competitive Landscape**: `docs/market/competitive-landscape.md`
- **Moat Strategy**: `docs/market/moat-strategy-summary.md`
- **Proof Architecture**: `docs/modules/platform/proof-driven-moats-architecture.md`
- **Vision**: `docs/VISION.md`
- **Architecture Overview**: `docs/ARCHITECTURE_OVERVIEW.md`
- **Quickstart**: `docs/quickstart.md`