12 KiB
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.
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.
# 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/19_TEST_SUITE_OVERVIEW.md
Quick Reference
Key Commands
# 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/03_VISION.md - Architecture Overview:
docs/40_ARCHITECTURE_OVERVIEW.md - Quickstart:
docs/quickstart.md