stella-ops.org/git.stella-ops.org
1
0
Fork 0
Code Issues Pull Requests Actions 3 Releases Wiki Activity

feat: Implement distro-native version comparison for RPM, Debian, and Alpine packages

Browse Source 
- Add RpmVersionComparer for RPM version comparison with epoch, version, and release handling.
- Introduce DebianVersion for parsing Debian EVR (Epoch:Version-Release) strings.
- Create ApkVersion for parsing Alpine APK version strings with suffix support.
- Define IVersionComparator interface for version comparison with proof-line generation.
- Implement VersionComparisonResult struct to encapsulate comparison results and proof lines.
- Add tests for Debian and RPM version comparers to ensure correct functionality and edge case handling.
- Create project files for the version comparison library and its tests.
This commit is contained in:
StellaOps Bot
2025-12-22 09:49:38 +02:00
parent aff0ceb2fe
commit df94136727
111 changed files with 30413 additions and 1813 deletions
Download Patch File Download Diff File Expand all files Collapse all files

276
docs/modules/platform/moat-gap-analysis.md Normal file
View File

@@ -0,0 +1,276 @@
# Moat Gap Analysis: StellaOps Competitive Position
> **Source Advisory**: 19-Dec-2025 - Stella Ops candidate features mapped to moat strength
> **Analysis Date**: 2025-12-22
> **Status**: Sprints created, implementation pending
---
## Executive Summary
This document captures the gap analysis between the competitive moat advisory and StellaOps' current implementation, along with the sprint plan to address identified gaps.
### Moat Scale Reference
| Rating | Definition |
|--------|------------|
| **5** | Structural moat — new primitives, strong defensibility, durable switching cost |
| **4** | Strong moat — difficult multi-domain engineering; incumbents have partial analogs |
| **3** | Moderate moat — others can build; differentiation is execution + packaging |
| **2** | Weak moat — table-stakes soon; limited defensibility |
| **1** | Commodity — widely available in OSS / easy to replicate |
---
## Feature Implementation Matrix
| Feature | Moat | Current % | Key Gaps | Sprint Coverage |
|---------|------|-----------|----------|-----------------|
| Signed, replayable risk verdicts | 5 | 70% | OCI push, one-command replay | 4300_0001_* |
| VEX decisioning engine | 4 | 85% | Evidence hooks | Minimal |
| Reachability with proof | 4 | 75% | Standalone artifact | 4400_0001_0002 |
| Smart-Diff semantic delta | 4 | 80% | Signed delta verdict | 4400_0001_0001 |
| Unknowns as first-class state | 4 | 75% | Policy budgets, attestations | 4300_0002_* |
| Air-gapped epistemic mode | 4 | 70% | Sealed snapshot workflow | 4300_0003_0001 |
| SBOM ledger + lineage | 3 | 60% | Historical tracking, BYOS | 4600_0001_* |
| Policy engine with proofs | 3 | 85% | Compilation to artifact | Minimal |
| VEX distribution network | 3-4 | 30% | Hub layer entirely | 4500_0001_* |
---
## Detailed Gap Analysis
### 1. Signed, Replayable Risk Verdicts (Moat 5)
**What exists:**
- `VerdictReceiptStatement` with in-toto predicate
- `ProofSpine` and `ProofChainBuilder` infrastructure
- `TrustLatticeEngine.Evaluate()` producing `ProofBundle`
- `ReplayManifest` and `ReplayVerifier`
- Input hashing (sbomDigest, feedsDigest, policyDigest)
**Gaps:**
| Gap | Sprint |
|-----|--------|
| Verdict as OCI-attached attestation | 4300_0001_0001 |
| One-command audit replay CLI | 4300_0001_0002 |
| Formal replay determinism tests | 4300_0001_0002 |
**Moat Thesis**: "We don't output findings; we output an attestable decision that can be replayed."
---
### 2. VEX Decisioning Engine (Moat 4)
**What exists:**
- `VexConsensusEngine` with 5 modes
- `TrustLatticeEngine` with K4 lattice atoms
- `TrustWeightEngine` for issuer weighting
- VEX normalizers for CycloneDX, OpenVEX, CSAF
- `VexLens` module with consensus rationale
**Gaps:**
| Gap | Sprint |
|-----|--------|
| Configurable evidence hooks | Minor enhancement |
**Moat Thesis**: "We treat VEX as a logical claim system, not a suppression file."
---
### 3. Reachability with Proof (Moat 4)
**What exists:**
- `ReachabilityWitnessStatement` attestation type
- `PathWitnessBuilder` for call-path proofs
- `CallPath` models with entrypoint → symbol chain
- `ReachabilityLattice` for state management
- `CompositeGateDetector` for boundary extraction
**Gaps:**
| Gap | Sprint |
|-----|--------|
| Standalone reachability subgraph as OCI artifact | 4400_0001_0002 |
| Binary-level reachability proof | 6000_* (existing) |
**Moat Thesis**: "We provide proof of exploitability in *this* artifact, not just a badge."
---
### 4. Smart-Diff Semantic Risk Delta (Moat 4)
**What exists:**
- `MaterialRiskChangeDetector` with R1-R4 rules
- `RiskStateSnapshot` capturing full finding state
- Detection of all flip types
- Priority scoring algorithm
- SARIF output generation
**Gaps:**
| Gap | Sprint |
|-----|--------|
| Signed delta verdict attestation | 4400_0001_0001 |
| Diff over reachability graphs | Future |
**Moat Thesis**: "We explain what changed in exploitable surface area, not what changed in CVE count."
---
### 5. Unknowns as First-Class State (Moat 4)
**What exists:**
- `UncertaintyTier` (T1-T4) with entropy classification
- `UnknownStateLedger` tracking marker kinds
- Risk modifiers from uncertainty
- `BlocksNotAffected()` gate on T1 tier
**Gaps:**
| Gap | Sprint |
|-----|--------|
| Policy rule: "fail if unknowns > N" | 4300_0002_0001 |
| Unknown budgets with decay | 4100_0001_0002 (existing) |
| Unknowns in attestations | 4300_0002_0002 |
**Moat Thesis**: "We quantify uncertainty and gate on it."
---
### 6. Air-Gapped Epistemic Mode (Moat 4)
**What exists:**
- `AirGap.Controller` with state management
- `ReplayVerifier` with depth levels
- `TrustStore` and `TufMetadataValidator`
- `EgressPolicy` enforcement
- `TimeAnchor` for offline time validation
**Gaps:**
| Gap | Sprint |
|-----|--------|
| Sealed knowledge snapshot export CLI | 4300_0003_0001 |
| One-command import + replay validation | 4300_0003_0001 |
| Feed snapshot versioning with merkle roots | 4300_0003_0001 |
**Moat Thesis**: Air-gapped "runtime" is common; air-gapped **reproducibility** is not.
---
### 7. SBOM Ledger + Lineage (Moat 3)
**What exists:**
- `SbomService` with versioning events
- `CatalogRecord` for storage
- `Graph` module for dependency indexing
- `SbomVersionEvents`
**Gaps:**
| Gap | Sprint |
|-----|--------|
| Historical SBOM tracking with diff lineage | 4600_0001_0001 |
| BYOS ingestion workflow with validation | 4600_0001_0002 |
| SBOM grouping by artifact family | 4600_0001_0001 |
**Moat Strategy**: Make the ledger valuable via **semantic diff, evidence joins, and provenance**.
---
### 8. Policy Engine with Proofs (Moat 3)
**What exists:**
- `PolicyEvaluation` with `PolicyExplanation`
- OPA/Rego integration
- `ProofBundle` generation from TrustLattice
- Evidence pointers in verdict statements
**Gaps:**
| Gap | Sprint |
|-----|--------|
| Policy compilation to standalone decision artifact | Minor enhancement |
**Moat Strategy**: Keep policy language small but rigorous; always emit evidence pointers.
---
### 9. VEX Distribution Network (Moat 3-4)
**What exists:**
- Excititor ingests from 7+ VEX sources
- `VexConnectorMetadata` for source tracking
**Gaps:**
| Gap | Sprint |
|-----|--------|
| VEX Hub aggregation layer | 4500_0001_0001 |
| Trust scoring of VEX sources | 4500_0001_0002 |
| VEX verification + validation pipeline | 4500_0001_0001 |
| API for VEX discovery/subscription | 4500_0001_0001 |
**Moat Strategy**: Differentiate with **verification + trust scoring** of VEX sources.
---
## Sprint Roadmap
### Phase 1: Moat 5 Anchor (P0)
```
4300_0001_0001 → 4300_0001_0002
│
└── Verdict becomes portable, replayable
```
### Phase 2: Moat 4 Hardening (P1)
```
4300_0002_0001 → 4300_0002_0002
│
└── Unknowns become actionable
4300_0003_0001
│
└── Air-gap becomes reproducible
4500_0001_0001 → 4500_0001_0002
│
└── VEX becomes distributable
```
### Phase 3: Moat 4 Extensions (P2)
```
4400_0001_0001 (Delta Verdict)
4400_0001_0002 (Reachability Artifact)
```
### Phase 4: Moat 3 Foundation (P2)
```
4600_0001_0001 → 4600_0001_0002
│
└── SBOM becomes historical
```
---
## Competitive Positioning Summary
### Where StellaOps Is Strong
1. **VEX decisioning** — Multi-mode consensus engine is ahead of competitors
2. **Smart-Diff** — R1-R4 rules with priority scoring is unique
3. **Policy engine** — OPA/Rego with proof output is mature
4. **Attestor** — in-toto/DSSE infrastructure is complete
### Where StellaOps Must Improve
1. **Verdict portability** — OCI push makes verdicts first-class artifacts
2. **Audit replay** — One-command replay is essential for compliance
3. **VEX distribution** — Hub layer creates network effects
4. **Unknown governance** — Policy budgets make uncertainty actionable
### Avoid Head-On Fights
- **Snyk**: Don't compete on developer UX; compete on proof-carrying reachability
- **Prisma**: Don't compete on CNAPP breadth; compete on decision integrity
- **Anchore**: Don't compete on SBOM storage; compete on semantic diff + VEX reasoning
---
## References
- **Sprints**: `docs/implplan/SPRINT_4300_*.md`, `SPRINT_4400_*.md`, `SPRINT_4500_*.md`, `SPRINT_4600_*.md`
- **Original Advisory**: `docs/product-advisories/archived/19-Dec-2025 - Stella Ops candidate features mapped to moat strength.md`
- **Architecture**: `docs/07_HIGH_LEVEL_ARCHITECTURE.md`