dac8e10e36
## Summary
This commit completes Phase 2 of the configuration-driven crypto architecture, achieving
100% crypto compliance by eliminating all hardcoded cryptographic implementations.
## Key Changes
### Phase 1: Plugin Loader Infrastructure
- **Plugin Discovery System**: Created StellaOps.Cryptography.PluginLoader with manifest-based loading
- **Configuration Model**: Added CryptoPluginConfiguration with regional profiles support
- **Dependency Injection**: Extended DI to support plugin-based crypto provider registration
- **Regional Configs**: Created appsettings.crypto.{international,russia,eu,china}.yaml
- **CI Workflow**: Added .gitea/workflows/crypto-compliance.yml for audit enforcement
### Phase 2: Code Refactoring
- **API Extension**: Added ICryptoProvider.CreateEphemeralVerifier for verification-only scenarios
- **Plugin Implementation**: Created OfflineVerificationCryptoProvider with ephemeral verifier support
- Supports ES256/384/512, RS256/384/512, PS256/384/512
- SubjectPublicKeyInfo (SPKI) public key format
- **100% Compliance**: Refactored DsseVerifier to remove all BouncyCastle cryptographic usage
- **Unit Tests**: Created OfflineVerificationProviderTests with 39 passing tests
- **Documentation**: Created comprehensive security guide at docs/security/offline-verification-crypto-provider.md
- **Audit Infrastructure**: Created scripts/audit-crypto-usage.ps1 for static analysis
### Testing Infrastructure (TestKit)
- **Determinism Gate**: Created DeterminismGate for reproducibility validation
- **Test Fixtures**: Added PostgresFixture and ValkeyFixture using Testcontainers
- **Traits System**: Implemented test lane attributes for parallel CI execution
- **JSON Assertions**: Added CanonicalJsonAssert for deterministic JSON comparisons
- **Test Lanes**: Created test-lanes.yml workflow for parallel test execution
### Documentation
- **Architecture**: Created CRYPTO_CONFIGURATION_DRIVEN_ARCHITECTURE.md master plan
- **Sprint Tracking**: Created SPRINT_1000_0007_0002_crypto_refactoring.md (COMPLETE)
- **API Documentation**: Updated docs2/cli/crypto-plugins.md and crypto.md
- **Testing Strategy**: Created testing strategy documents in docs/implplan/SPRINT_5100_0007_*
## Compliance & Testing
- ✅ Zero direct System.Security.Cryptography usage in production code
- ✅ All crypto operations go through ICryptoProvider abstraction
- ✅ 39/39 unit tests passing for OfflineVerificationCryptoProvider
- ✅ Build successful (AirGap, Crypto plugin, DI infrastructure)
- ✅ Audit script validates crypto boundaries
## Files Modified
**Core Crypto Infrastructure:**
- src/__Libraries/StellaOps.Cryptography/CryptoProvider.cs (API extension)
- src/__Libraries/StellaOps.Cryptography/CryptoSigningKey.cs (verification-only constructor)
- src/__Libraries/StellaOps.Cryptography/EcdsaSigner.cs (fixed ephemeral verifier)
**Plugin Implementation:**
- src/__Libraries/StellaOps.Cryptography.Plugin.OfflineVerification/ (new)
- src/__Libraries/StellaOps.Cryptography.PluginLoader/ (new)
**Production Code Refactoring:**
- src/AirGap/StellaOps.AirGap.Importer/Validation/DsseVerifier.cs (100% compliant)
**Tests:**
- src/__Libraries/__Tests/StellaOps.Cryptography.Plugin.OfflineVerification.Tests/ (new, 39 tests)
- src/__Libraries/__Tests/StellaOps.Cryptography.PluginLoader.Tests/ (new)
**Configuration:**
- etc/crypto-plugins-manifest.json (plugin registry)
- etc/appsettings.crypto.*.yaml (regional profiles)
**Documentation:**
- docs/security/offline-verification-crypto-provider.md (600+ lines)
- docs/implplan/CRYPTO_CONFIGURATION_DRIVEN_ARCHITECTURE.md (master plan)
- docs/implplan/SPRINT_1000_0007_0002_crypto_refactoring.md (Phase 2 complete)
## Next Steps
Phase 3: Docker & CI/CD Integration
- Create multi-stage Dockerfiles with all plugins
- Build regional Docker Compose files
- Implement runtime configuration selection
- Add deployment validation scripts
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
93 lines
9.6 KiB
Markdown
93 lines
9.6 KiB
Markdown
# Key Features – Capability Cards
|
||
|
||
> Stella Ops isn't just another scanner—it's a different product category: **deterministic, evidence-linked vulnerability decisions** that survive auditors, regulators, and supply-chain propagation.
|
||
|
||
Each card below pairs the headline capability with the evidence that backs it and why it matters day to day.
|
||
|
||
<!-- TODO: Review for separate approval - added Decision Capsules as feature 0 -->
|
||
## 0. Decision Capsules - Audit-Grade Evidence Bundles (2025-12)
|
||
- **What it is:** Every scan result is sealed in a **Decision Capsule**-a content-addressed bundle containing all inputs, outputs, and evidence needed to reproduce and verify the vulnerability decision.
|
||
- **Evidence:** Each capsule includes: exact SBOM (and source provenance if available), exact vuln feed snapshots (or IDs to frozen snapshots), reachability evidence (static artifacts + runtime traces if any), policy version + lattice rules, derived VEX statements, and signatures over all of the above.
|
||
- **UX surface:** Vulnerability triage is built around VEX-first decisions and one-click immutable audit bundles; reference `docs/product-advisories/archived/27-Nov-2025-superseded/28-Nov-2025 - Vulnerability Triage UX & VEX-First Decisioning.md`.
|
||
- **Why it matters:** Auditors can re-run any capsule bit-for-bit to verify the outcome. This is the heart of audit-grade assurance-every decision becomes a provable, replayable fact.
|
||
|
||
## 1. Delta SBOM Engine
|
||
- **What it is:** Layer-aware ingestion keeps the SBOM catalog content-addressed; rescans only fetch new layers and update dependency/vulnerability cartographs.
|
||
- **Evidence:** Deterministic Replay Manifest (SRM) captures the exact analyzer inputs/outputs per layer.
|
||
- **Why it matters:** Warm scans drop below one second, so CI/CD pipelines stay fast even under the free-tier quota.
|
||
|
||
## 2. Lattice Policy + OpenVEX (Evidence-Linked)
|
||
- **What it is:** Policy engine merges SBOM, advisories, VEX, and waivers through lattice logic that prioritises exploitability. Every VEX assertion includes pointers to an internal evidence graph.
|
||
- **Evidence:** OpenVEX is treated as first-class input; the policy UI renders explain traces with proof-linked decisions. Custom rule packs let teams automate muting, expirations, and non-VEX alert logic.
|
||
- **Why it matters:** Teams can distinguish exploitable risk from noise, tune the experience beyond VEX statements, and prove why a deployment was blocked or allowed. Unlike simplistic yes/no approaches, the lattice model explicitly handles an "Unknown" state, ensuring incomplete data doesn't lead to false safety.
|
||
|
||
## 3. Sovereign Crypto Profiles
|
||
- **What it is:** Bring-your-own trust bundles that switch signing algorithms (FIPS, eIDAS, GOST, SM) without code changes.
|
||
- **Evidence:** Crypto profiles travel with Offline Update Kits and post-quantum trust packs, keeping signatures verifiable in regulated sectors.
|
||
- **Why it matters:** You meet regional crypto requirements while keeping provenance attestations consistent across tenants.
|
||
|
||
## 4. Deterministic Replay & Evidence Bundles — The Heart of Audit-Grade Assurance
|
||
- **What it is:** Every scan produces a DSSE + SRM bundle that can be replayed with `stella replay srm.yaml`.
|
||
- **Evidence:** Replay manifests capture analyzer versions, lattice state, and attestations in content-addressed storage for audit trails.
|
||
- **Why it matters:** A CVE found 6 months ago can be re-verified today by running `stella replay srm.yaml`, yielding an identical result—an audit trail no other scanner provides. This is why Stella decisions survive auditors, regulators, and supply-chain propagation.
|
||
|
||
## 5. Transparent Quotas & Offline Operations
|
||
- **What it is:** Redis-backed counters surface `{{ quota_token }}` scans/day via headers, UI banners, and `/quota` API; Offline Update Kits mirror feeds.
|
||
- **Evidence:** Quota tokens verify locally using bundled public keys, and Offline Update Kits include mirrored advisories, SBOM feeds, and VEX sources.
|
||
- **Why it matters:** You stay within predictable limits, avoid surprise throttling, and operate entirely offline when needed.
|
||
|
||
## 6. Signed Reachability Proofs — Hybrid Static + Runtime Attestations
|
||
- **What it is:** Every reachability graph is sealed with a graph-level DSSE and optional edge-bundle DSSEs for runtime/init/contested edges; Rekor-backed when enabled. Both static call-graph edges and runtime-derived edges can be attested—true hybrid reachability.
|
||
- **Evidence:** CAS layout `cas://reachability/graphs/{hash}` + `{hash}.dsse`; edge bundles capped and sorted; quarantine/dispute uses per-edge revocation. See `docs/reachability/hybrid-attestation.md`.
|
||
- **Why it matters:** You can prove (or contest) exactly why a vuln is reachable, replay results offline, and avoid flooding transparency logs. Hybrid analysis combining static call-graph analysis with runtime process tracing provides confidence across build and runtime contexts.
|
||
|
||
## 7. Competitive Moats — Four Capabilities (2025-12 refresh)
|
||
- **What it is:** Four capabilities no competitor offers together: (1) Signed Reachability, (2) Deterministic Replay, (3) Explainable Policy (Lattice VEX), (4) Sovereign + Offline Operation. Plus Decision Capsules for audit-grade evidence bundles.
|
||
- **Evidence:** `docs/market/competitive-landscape.md` distils a 15-vendor comparison; `03_VISION.md` lists moats; `docs/reachability/lead.md` details the reachability proof moat.
|
||
- **Why it matters:** Clear differentiation guides roadmap and sales; keeps us focused on replayable, sovereign, evidence-linked, and explainable security.
|
||
|
||
## 8. Semantic Smart-Diff (2025-12)
|
||
- **What it is:** Diff security meaning, not just artifacts. Compare reachability graphs, policy outcomes, and trust weights between releases.
|
||
- **Evidence:** Drift detection in `src/Scanner/__Libraries/StellaOps.Scanner.ReachabilityDrift/`; DSSE-attested drift results.
|
||
- **Why it matters:** Outputs "This release reduces exploitability by 41% despite +2 CVEs" — no competitor quantifies semantic security deltas.
|
||
|
||
## 9. Unknowns as First-Class State (2025-12)
|
||
- **What it is:** Explicit modeling of Unknown-Reachable and Unknown-Unreachable states with risk scoring implications.
|
||
- **Evidence:** Unknowns Registry in Signals; `unknowns_pressure` factor in scoring; UI chips for unknowns.
|
||
- **Why it matters:** Uncertainty is risk. We don't hide it — we surface and score it. Critical for air-gapped and zero-day scenarios.
|
||
|
||
## 10. Call-Path Reachability Proofs (2025-12)
|
||
- **What it is:** Three-layer reachability: static call graph + binary resolution + runtime gating. All three must align for exploitability.
|
||
- **Evidence:** Vulnerability surfaces in `src/Scanner/__Libraries/StellaOps.Scanner.VulnSurfaces/`; confidence tiers (Confirmed/Likely/Present/Unreachable).
|
||
- **Why it matters:** Makes false positives *structurally impossible*, not heuristically reduced. Path witnesses are DSSE-signed.
|
||
|
||
## 12. Trust Algebra and Lattice Engine (2025-12)
|
||
- **What it is:** A deterministic claim resolution engine using **Belnap K4 four-valued logic** (Unknown, True, False, Conflict) to aggregate heterogeneous security assertions (VEX, SBOM, reachability, provenance) into signed, replayable verdicts.
|
||
- **Evidence:** Implementation in `src/Policy/__Libraries/StellaOps.Policy/TrustLattice/`; 110 unit+integration tests; normalizers for CycloneDX, OpenVEX, and CSAF VEX formats; ECMA-424 disposition output (resolved, exploitable, in_triage, etc.).
|
||
- **Technical primitives:**
|
||
- **K4 Lattice**: Conflict-preserving knowledge aggregation with join/meet/order operations
|
||
- **Security Atoms**: Six orthogonal propositions (PRESENT, APPLIES, REACHABLE, MITIGATED, FIXED, MISATTRIBUTED)
|
||
- **Trust Labels**: Four-tuple (AssuranceLevel, AuthorityScope, FreshnessClass, EvidenceClass) for issuer credibility
|
||
- **Disposition Selection**: Priority-based rules that detect conflicts before auto-dismissal
|
||
- **Proof Bundles**: Content-addressed audit trail with decision trace
|
||
- **Why it matters:** Unlike naive VEX precedence (vendor > distro > scanner), the lattice engine:
|
||
- Preserves conflicts as explicit state (⊤) rather than hiding them
|
||
- Reports critical unknowns (PRESENT, APPLIES, REACHABLE) separately from ancillary ones
|
||
- Produces deterministic, explainable dispositions that survive audit
|
||
- Makes "what we don't know" visible and policy-addressable
|
||
|
||
## 11. Deterministic Task Packs (2025-11)
|
||
- **What it is:** TaskRunner executes declarative Task Packs with plan-hash binding, approvals, sealed-mode enforcement, and DSSE evidence bundles.
|
||
- **Evidence:** Product advisory `docs/product-advisories/29-Nov-2025 - Task Pack Orchestration and Automation.md`; architecture contract in `docs/modules/taskrunner/architecture.md`; runbook/spec in `docs/task-packs/*.md`.
|
||
- **Why it matters:** Security teams get auditable, air-gap-friendly automation with human approvals and provable provenance, reusing the same workflows online or offline.
|
||
|
||
## 13. Evidence-Grade Testing and Deterministic Gates (2026-12)
|
||
- **What it is:** A model-driven test taxonomy and CI lanes that make determinism, offline behavior, and contract stability continuously provable.
|
||
- **Evidence:** `docs/testing/testing-strategy-models.md` and the catalog in `docs/testing/TEST_CATALOG.yml` define required test types per module; `docs/19_TEST_SUITE_OVERVIEW.md` lists the gated lanes.
|
||
- **Why it matters:** Regression-proof audits and predictable CI gates ensure that evidence, not assumptions, drives releases.
|
||
|
||
### Explore Further
|
||
- Walk the first deployment in [quickstart.md](quickstart.md).
|
||
- Dive into architectural flows in [high-level-architecture.md](high-level-architecture.md).
|
||
- Need detailed matrices? The legacy [feature matrix](04_FEATURE_MATRIX.md) and [vision](03_VISION.md) remain available for deep dives.
|