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

release orchestrator pivot, architecture and planning

Browse Source
This commit is contained in:
master
2026-01-10 22:37:22 +02:00
parent c84f421e2f
commit d509c44411
130 changed files with 70292 additions and 721 deletions
Download Patch File Download Diff File Expand all files Collapse all files

580
docs/product/VISION.md
View File

@@ -1,409 +1,299 @@
#  3 · Product Vision — **Stella Ops**
# Product Vision — Stella Ops Suite
> 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.
> Stella Ops Suite isn't just another scanner or deployment tool—it's a different product category: **a centralized, auditable release control plane** that gates releases using reachability-aware security and produces verifiable evidence for every decision.
## 1) Problem Statement & Goals
We ship containers. We need:
- **Authenticity & integrity** of build artifacts and metadata.
- **Provenance** attached to artifacts, not platforms.
- **Transparency** to detect tampering and retroactive edits.
- **Determinism & explainability** so scanner judgments can be replayed and justified.
- **Actionability** to separate theoretical from exploitable risk (VEX).
- **Minimal trust** across multi‑tenant and third‑party boundaries.
We ship containers to non-Kubernetes targets (Docker hosts, Compose, ECS, Nomad). We need:
**Non‑goals:** Building a new package manager, inventing new SBOM/attestation formats, or depending on closed standards.
- **Release governance** across environments (Dev → Stage → Prod) with approvals and audit trails.
- **Security as a gate, not a blocker** — integrate vulnerability decisions into promotion workflows.
- **Digest-based release identity** — immutable releases, not mutable tags.
- **Toolchain flexibility** — plug into any SCM, CI, registry, and secrets system.
- **Determinism & explainability** — release decisions can be replayed and justified.
- **Evidence packets** — every release decision links to concrete artifacts.
- **Non-Kubernetes first-class support** — Docker hosts, Compose, ECS, Nomad are not afterthoughts.
- **Pricing that doesn't punish automation** — no per-project, per-seat, or per-deployment taxes.
**Non-goals:** Replacing CI systems, building Kubernetes deployments (use ArgoCD/Flux), or inventing new SBOM/attestation formats.
---
## 2) Golden Path (Minimal End‑to‑End Flow)
## 2) Golden Path (Release-Centric Flow)
```
Build → Scan → Create Release → Request Promotion → Gate Evaluation → Deploy → Evidence
```
```mermaid
flowchart LR
A[Source / Image / Rootfs] --> B[SBOM Producer\nCycloneDX 1.7]
B --> C[Signer\nin‑toto Attestation + DSSE]
C --> D[Transparency\nSigstore Rekor - optional but RECOMMENDED]
D --> E[Durable Storage\nSBOMs, Attestations, Proofs]
E --> F[Scanner\nPkg analyzers + Entry‑trace + Layer cache]
F --> G[VEX Authoring\nOpenVEX + SPDX 3.0.1 relationships]
G --> H[Policy Gate\nOPA/Rego: allow/deny + waivers]
H --> I[Artifacts Store\nReports, SARIF, VEX, Audit log]
````
A[CI Build] --> B[OCI Registry\nPush by digest]
B --> C[Stella Scan\nSBOM + Vuln Analysis]
C --> D[Create Release\nDigest bundle]
D --> E[Request Promotion\nDev → Stage → Prod]
E --> F[Gate Evaluation\nSecurity + Policy + Approval]
F --> G{Decision}
G -->|Allow| H[Deploy to Targets\nDocker/Compose/ECS/Nomad]
G -->|Deny| I[Block with Explanation]
H --> J[Evidence Packet\nSigned + Stored]
```
**Adopted standards (pinned for interoperability):**
### What Stella Ops Suite Does
* **SBOM:** CycloneDX **1.7** (JSON/XML; 1.6 accepted for ingest)
* **Attestation & signing:** **in‑toto Attestations** (Statement + Predicate) in **DSSE** envelopes
* **Transparency:** **Sigstore Rekor** (inclusion proofs, monitoring)
* **Exploitability:** **OpenVEX** (statuses & justifications)
* **Modeling & interop:** **SPDX 3.0.1** (relationships / VEX modeling)
* **Findings interchange (optional):** SARIF for analyzer output
> Pinnings are *policy*, not claims about “latest”. We may update pins via normal change control.
| Capability | Description |
|------------|-------------|
| **Release orchestration** | UI-driven promotion (Dev → Stage → Prod), approvals, policy gates, rollbacks; steps are hook-able with scripts |
| **Security decisioning as a gate** | Scan on build, evaluate on release, re-evaluate on CVE updates—without forcing re-scans |
| **OCI-digest-first releases** | A release is an immutable digest (or bundle of digests); track "what is deployed where" |
| **Toolchain-agnostic integrations** | Plug into any SCM, any CI, any registry, any secrets system |
| **Auditability + standards** | Evidence packets (exportable), SBOM/VEX/attestation support, deterministic replay |
---
## 3) Security Invariants (What MUST Always Hold)
## 3) Design Principles & Invariants
1. **Artifact identity is content‑addressed.**
These principles are **inviolable** and MUST be reflected in all code, UI, documentation, and audit artifacts.
### Principle 1: Release Identity via Digest
```
INVARIANT: A release is a set of OCI image digests (component → digest mapping), never tags.
```
- Tags are convenience inputs for resolution
- Tags are resolved to digests at release creation time
- All downstream operations (promotion, deployment, rollback) use digests
- Digest mismatch at pull time = deployment failure (tamper detection)
### Principle 2: Determinism and Evidence
```
INVARIANT: Every deployment/promotion produces an immutable evidence record.
```
Evidence record contains:
- **Who**: User identity (from Authority)
- **What**: Release bundle (digests), target environment, target hosts
- **Why**: Policy evaluation result, approval records, decision reasons
- **How**: Generated artifacts (compose files, scripts), execution logs
- **When**: Timestamps for request, decision, execution, completion
### Principle 3: Pluggable Everything, Stable Core
```
INVARIANT: Integrations are plugins; the core orchestration engine is stable.
```
Plugins contribute:
- Configuration screens (UI)
- Connector logic (runtime)
- Step node types (workflow)
- Doctor checks (diagnostics)
- Agent types (deployment)
Core engine provides:
- Workflow execution (DAG processing)
- State machine management
- Evidence generation
- Policy evaluation
- Credential brokering
### Principle 4: No Feature Gating
```
INVARIANT: All plans include all features. Limits are only:
- Number of environments
- Number of new digests analyzed per day
- Fair use on deployments
```
### Principle 5: Offline-First Operation
```
INVARIANT: All core operations MUST work in air-gapped environments.
```
- No runtime calls to external APIs for core decisions
- Vulnerability data synced via mirror bundles
- Plugins may require connectivity; core does not
- Evidence packets exportable for external audit
### Principle 6: Immutable Generated Artifacts
```
INVARIANT: Every deployment generates and stores immutable artifacts.
```
Generated artifacts:
- `compose.stella.lock.yml`: Pinned digests, resolved env refs
- `deploy.stella.script.dll`: Compiled C# script (or hash reference)
- `release.evidence.json`: Decision record
- `stella.version.json`: Version sticker placed on target
---
## 4) Security Invariants (Scanning & Attestation)
These invariants from our scanning heritage remain core to the security gate:
1. **Artifact identity is content-addressed.**
- All identities are SHA-256 digests of immutable blobs.
* All identities are SHA‑256 digests of immutable blobs (images, SBOMs, attestations).
2. **Every SBOM is signed.**
- SBOMs MUST be wrapped in **in-toto DSSE** attestations tied to the container digest.
* SBOMs MUST be wrapped in **in‑toto DSSE** attestations tied to the container digest.
3. **Provenance is attached, not implied.**
- Build metadata (who/where/how) MUST ride as attestations linked by digest.
* Build metadata (who/where/how) MUST ride as attestations linked by digest.
4. **Transparency FIRST mindset.**
- Signatures/attestations SHOULD be logged to **Rekor** and store inclusion proofs.
* Signatures/attestations SHOULD be logged to **Rekor** and store inclusion proofs.
5. **Determinism & replay.**
- Scans MUST be reproducible given: input digests, scanner version, DB snapshot, and config.
* Scans MUST be reproducible given: input digests, scanner version, DB snapshot, and config.
6. **Explainability.**
- Findings MUST show the *why*: package → file path → call-stack / entrypoint (when available).
* Findings MUST show the *why*: package → file path → call‑stack / entrypoint (when available).
7. **Exploitability over enumeration.**
- Risk MUST be communicated via **VEX** (OpenVEX), including **under_investigation** where appropriate.
* Risk MUST be communicated via **VEX** (OpenVEX), including **under_investigation** where appropriate.
8. **Least privilege & minimal trust.**
* Build keys are short‑lived; scanners run on ephemeral, least‑privileged workers.
9. **Air‑gap friendly.**
* Mirrors for vuln DBs and containers; all verification MUST work without public egress.
10. **No hidden blockers.**
* Policy gates MUST be code‑reviewable (e.g., Rego) and auditable; waivers are attestations, not emails.
8. **Air-gap friendly.**
- Mirrors for vuln DBs and containers; all verification MUST work without public egress.
---
## 4) Trust Boundaries & Roles
## 5) Adopted Standards
<!-- ```mermaid
flowchart TB
subgraph DevTenant[Dev Tenant]
SRC[Source Code]
CI[CI Runner]
end
subgraph SecPlatform[Security Platform]
SB[SBOM Service]
AT[Attestation Service]
TR[Transparency Client]
SCN[Scanner Pool]
POL[Policy Gate]
ST[Artifacts Store]
end
subgraph External[External/3rd‑party]
REG[Container Registry]
REK[Rekor]
end
SRC --> CI
CI -->|image digest| REG
REG -->|pull by digest| SB
SB --> AT --> TR --> REK
AT --> ST
REK --> ST
ST --> SCN --> POL --> ST
``` -->
* **Build/CI:** Holds signing capability (short‑lived keys or keyless signing).
* **Registry:** Source of truth for image bytes; access via digest only.
* **Scanner Pool:** Ephemeral nodes; content‑addressed caches; no shared mutable state.
* **Artifacts Store:** Immutable, WORM‑like storage for SBOMs, attestations, proofs, SARIF, VEX.
| Domain | Standard | Stella Pin | Notes |
|--------|----------|------------|-------|
| **SBOM** | CycloneDX | **1.7** | JSON or XML; 1.6 ingest supported |
| **Attestation** | in-toto | **Statement v1** | Predicates per use case |
| **Envelope** | DSSE | **v1** | Canonical JSON payloads |
| **Transparency** | Sigstore Rekor | **API stable** | Inclusion proof stored alongside artifacts |
| **VEX** | OpenVEX | **spec current** | Map to SPDX 3.0.1 relationships as needed |
| **Interop** | SPDX | **3.0.1** | Use for modeling & cross-ecosystem exchange |
| **Findings** | SARIF | **2.1.0** | Optional but recommended |
---
## 5) Data & Evidence We Persist
## 6) Competitive Positioning
| Artifact | MUST Persist | Why |
| -------------------- | ------------------------------------ | ---------------------------- |
| SBOM (CycloneDX 1.7) | Raw file + DSSE attestation | Reproducibility, audit |
| in‑toto Statement | Full JSON | Traceability |
| Rekor entry | UUID + inclusion proof | Tamper‑evidence |
| Scanner output | SARIF + raw notes | Triage & tooling interop |
| VEX | OpenVEX + links to findings | Noise reduction & compliance |
| Policy decisions | Input set + decision + rule versions | Governance & forensics |
### Why Stella Wins (One Line Each)
Retention follows our Compliance policy; default **≥ 18 months**.
- **CI/CD tools** (Actions/Jenkins/GitLab CI): great at running pipelines, weak at being a central release authority with audit-grade evidence.
- **CD orchestrators** (Octopus/Harness/Spinnaker): strong promotions, but security is bolt-on and pricing scales poorly.
- **Registries** (Harbor/JFrog): can store and scan, but don't provide release governance.
- **Scanners/CNAPP** (Trivy/Snyk/Aqua): scan well, but don't provide release orchestration.
### Core Differentiators (Moats)
1. **Non-Kubernetes Specialization** — Docker hosts, Compose, ECS, Nomad are first-class, not afterthoughts.
2. **Signed Reachability** — Every reachability graph is sealed with DSSE; optional edge-bundle attestations for runtime/init/contested paths.
3. **Deterministic Replay** — Scans and release decisions run bit-for-bit identical from frozen feeds and manifests.
4. **Evidence-Linked Decisions** — Every gate evaluation produces a signed decision record with evidence refs.
5. **Sovereign + Offline Operation** — FIPS/eIDAS/GOST/SM/PQC profiles and offline mirrors as first-class toggles.
6. **Cost Model** — No per-seat, per-project, or per-deployment tax. Limits are environments + new digests/day.
---
## 6) Scanner Requirements (Determinism & Explainability)
## 7) Release Orchestration Architecture (Planned)
* **Inputs pinned:** image digest(s), SBOM(s), scanner version, vuln DB snapshot date, config hash.
* **Explainability:** show file paths, package coords (e.g., purl), and—when possible—**entry‑trace/call‑stack** from executable entrypoints to vulnerable symbol(s).
* **Caching:** content‑addressed per‑layer & per‑ecosystem caches; warming does not change decisions.
* **Unknowns:** output **under_investigation** where exploitability is not yet known; roll into VEX.
* **Interchange:** emit **SARIF** for IDE and pipeline consumption (optional but recommended).
### New Themes
| Theme | Purpose | Key Modules |
|-------|---------|-------------|
| **INTHUB** | Integration hub | Integration Manager, Connection Profiles, Connector Runtime |
| **ENVMGR** | Environment management | Environment Manager, Target Registry, Agent Manager |
| **RELMAN** | Release management | Component Registry, Version Manager, Release Manager |
| **WORKFL** | Workflow engine | Workflow Designer, Workflow Engine, Step Executor |
| **PROMOT** | Promotion and approval | Promotion Manager, Approval Gateway, Decision Engine |
| **DEPLOY** | Deployment execution | Deploy Orchestrator, Target Executor, Artifact Generator |
| **AGENTS** | Deployment agents | Agent Core, Docker/Compose/ECS/Nomad agents |
| **PROGDL** | Progressive delivery | A/B Manager, Traffic Router, Canary Controller |
| **RELEVI** | Release evidence | Evidence Collector, Sticker Writer, Audit Exporter |
| **PLUGIN** | Plugin infrastructure | Plugin Registry, Plugin Loader, Plugin SDK |
### Key Data Entities
- **Environment**: Dev/Stage/Prod with freeze windows, approval policies
- **Target**: Deployment destination (Docker host, Compose host, ECS service, Nomad job)
- **Agent**: Deployment executor with capabilities and heartbeat
- **Component**: Logical service mapped to image repository
- **Release**: Bundle of component digests with semantic version
- **Promotion**: Request to move release between environments
- **Workflow**: DAG of steps for deployment execution
- **Evidence Packet**: Signed bundle of decision inputs and outputs
---
## 7) Policy Gate (OPA/Rego) — Examples
## 8) Existing Capabilities (Operational)
> Gate runs after scan + VEX merge. It treats VEX as first‑class input.
These themes power the security gate within release orchestration:
### 7.1 Deny unreconciled criticals that are exploitable
```rego
package stella.policy
default allow := false
exploitable(v) {
v.severity == "CRITICAL"
v.exploitability == "affected"
}
allow {
not exploitable_some
}
exploitable_some {
some v in input.findings
exploitable(v)
not waived(v.id)
}
waived(id) {
some w in input.vex
w.vuln_id == id
w.status == "not_affected"
w.justification != ""
}
```
### 7.2 Require Rekor inclusion for attestations
```rego
package stella.policy
violation[msg] {
some a in input.attestations
not a.rekor.inclusion_proof
msg := sprintf("Attestation %s lacks Rekor inclusion proof", [a.id])
}
```
| Theme | Purpose | Key Modules |
|-------|---------|-------------|
| **INGEST** | Advisory ingestion | Concelier, Advisory-AI |
| **VEXOPS** | VEX document handling | Excititor, VEX Lens, VEX Hub |
| **REASON** | Policy and decisioning | Policy Engine, OPA Runtime |
| **SCANENG** | Scanning and SBOM | Scanner, SBOM Service, Reachability |
| **EVIDENCE** | Evidence and attestation | Evidence Locker, Attestor, Export Center |
| **RUNTIME** | Runtime signals | Signals, Graph, Zastava |
| **JOBCTRL** | Job orchestration | Scheduler, Orchestrator, TaskRunner |
| **OBSERVE** | Observability | Notifier, Telemetry |
| **REPLAY** | Deterministic replay | Replay Engine |
| **DEVEXP** | Developer experience | CLI, Web UI, SDK |
---
## 8) Version Pins & Compatibility
## 9) Pricing Model
| Domain | Standard | Stella Pin | Notes |
| ------------ | -------------- | ---------------- | ------------------------------------------------ |
| SBOM | CycloneDX | **1.7** | JSON or XML accepted; 1.6 ingest supported |
| Attestation | in‑toto | **Statement v1** | Predicates per use case (e.g., sbom, provenance) |
| Envelope | DSSE | **v1** | Canonical JSON payloads |
| Transparency | Sigstore Rekor | **API stable** | Inclusion proof stored alongside artifacts |
| VEX | OpenVEX | **spec current** | Map to SPDX 3.0.1 relationships as needed |
| Interop | SPDX | **3.0.1** | Use for modeling & cross‑ecosystem exchange |
| Findings | SARIF | **2.1.0** | Optional but recommended |
**Principle:** Pay for scale, not for features or automation.
| Plan | Price | Environments | New Digests/Day | Notes |
|------|-------|--------------|-----------------|-------|
| **Free** | $0/month | 3 | 333 | Full features, unlimited deployments (fair use) |
| **Pro** | $699/month | 33 | 3,333 | Same features |
| **Enterprise** | $1,999/month | Unlimited | Unlimited | Fair use on mirroring/audit bandwidth |
---
## 9) Minimal CLI Playbook (Illustrative)
## 10) Implementation Roadmap (Planned)
> Commands below are illustrative; wire them into CI with short‑lived credentials.
```bash
# 1) Produce SBOM (CycloneDX 1.7) from image digest
syft registry:5000/myimg@sha256:... -o cyclonedx-json > sbom.cdx.json
# 2) Create in‑toto DSSE attestation bound to the image digest
cosign attest --predicate sbom.cdx.json \
--type https://stella-ops.org/attestations/sbom/1 \
--key env://COSIGN_KEY \
registry:5000/myimg@sha256:...
# 3) (Optional but recommended) Rekor transparency
cosign sign --key env://COSIGN_KEY registry:5000/myimg@sha256:...
cosign verify-attestation --type ... --certificate-oidc-issuer https://token.actions... registry:5000/myimg@sha256:... > rekor-proof.json
# 4) Scan (pinned DB snapshot)
stella-scan --image registry:5000/myimg@sha256:... \
--sbom sbom.cdx.json \
--db-snapshot 2025-10-01 \
--out findings.sarif
# 5) Emit VEX
stella-vex --from findings.sarif --policy vex-policy.yaml --out vex.json
# 6) Gate
opa eval -i gate-input.json -d policy/ -f pretty "data.stella.policy.allow"
```
| Phase | Focus | Key Deliverables |
|-------|-------|------------------|
| **Phase 1** | Foundation | Environment management, integration hub, release bundles |
| **Phase 2** | Workflow Engine | DAG execution, step registry, workflow templates |
| **Phase 3** | Promotion & Decision | Approval gateway, security gates, decision records |
| **Phase 4** | Deployment Execution | Docker/Compose agents, artifact generation, rollback |
| **Phase 5** | UI & Polish | Release dashboard, promotion UI, environment management |
| **Phase 6** | Progressive Delivery | A/B releases, canary, traffic routing |
| **Phase 7** | Extended Targets | ECS, Nomad, SSH/WinRM agentless |
| **Phase 8** | Plugin Ecosystem | Full plugin system, marketplace |
---
## 10) JSON Skeletons (Copy‑Ready)
## 11) Change Log
### 10.1 in‑toto Statement (DSSE payload)
```json
{
"_type": "https://in-toto.io/Statement/v1",
"subject": [
{
"name": "registry:5000/myimg",
"digest": { "sha256": "IMAGE_DIGEST_SHA256" }
}
],
"predicateType": "https://stella-ops.org/attestations/sbom/1",
"predicate": {
"sbomFormat": "CycloneDX",
"sbomVersion": "1.7",
"mediaType": "application/vnd.cyclonedx+json",
"location": "sha256:SBOM_BLOB_SHA256"
}
}
```
### 10.2 DSSE Envelope (wrapping the Statement)
```json
{
"payloadType": "application/vnd.in-toto+json",
"payload": "BASE64URL_OF_CANONICAL_STATEMENT_JSON",
"signatures": [
{
"keyid": "KEY_ID_OR_CERT_ID",
"sig": "BASE64URL_SIGNATURE"
}
]
}
```
### 10.3 OpenVEX (compact)
```json
{
"@context": "https://openvex.dev/ns/v0.2.0",
"author": "Stella Ops Security",
"timestamp": "2025-10-29T00:00:00Z",
"statements": [
{
"vulnerability": "CVE-2025-0001",
"products": ["pkg:purl/example@1.2.3?arch=amd64"],
"status": "under_investigation",
"justification": "analysis_ongoing",
"timestamp": "2025-10-29T00:00:00Z"
}
]
}
```
| Version | Date | Note |
|---------|------|------|
| v2.0 | 09-Jan-2026 | Major revision: pivot to release control plane; scanning becomes gate |
| v1.4 | 29-Oct-2025 | Initial principles, golden path, policy examples, JSON skeletons |
| v1.3 | 12-Jul-2025 | Expanded ecosystem pillar, added metrics/integrations |
| v1.2 | 11-Jul-2025 | Restructured to link with WHY; merged principles |
| v1.1 | 11-Jul-2025 | Original OSS-only vision |
| v1.0 | 09-Jul-2025 | First public draft |
---
## 11) Handling “Unknowns” & Noise
## References
* Use **OpenVEX** statuses: `affected`, `not_affected`, `fixed`, `under_investigation`.
* Prefer **justifications** over free‑text.
* Time‑bound **waivers** are modeled as VEX with `not_affected` + justification or `affected` + compensating controls.
* Dashboards MUST surface counts separately for `under_investigation` so risk is visible.
---
## 12) Operational Guidance
**Key management**
* Use **ephemeral OIDC** or short‑lived keys (HSM/KMS bound).
* Rotate signer identities at least quarterly; no shared long‑term keys in CI.
**Caching & performance**
* Layer caches keyed by digest + analyzer version.
* Pre‑warm vuln DB snapshots; mirror into air‑gapped envs.
**Multi‑tenancy**
* Strict tenant isolation for storage and compute.
* Rate‑limit and bound memory/CPU per scan job.
**Auditing**
* Every decision is a record: inputs, versions, rule commit, actor, result.
* Preserve Rekor inclusion proofs with the attestation record.
---
## 13) Exceptions Process (Break‑glass)
1. Open a tracked exception with: artifact digest, CVE(s), business justification, expiry.
2. Generate VEX entry reflecting the exception (`not_affected` with justification or `affected` with compensating controls).
3. Merge into policy inputs; **policy MUST read VEX**, not tickets.
4. Re‑review before expiry; exceptions cannot auto‑renew.
---
## 14) Threat Model (Abbreviated)
* **Tampering**: modified SBOMs/attestations → mitigated by DSSE + Rekor + WORM storage.
* **Confused deputy**: scanning a different image → mitigated by digest‑only pulls and subject digests in attestations.
* **TOCTOU / re‑tagging**: registry tags drift → mitigated by digest pinning everywhere.
* **Scanner poisoning**: unpinned DBs → mitigated by snapshotting and recording version/date.
* **Key compromise**: long‑lived CI keys → mitigated by OIDC keyless or short‑lived KMS keys.
---
## 15) Implementation Checklist
* [ ] SBOM producer emits CycloneDX 1.7; bound to image digest.
* [ ] in‑toto+DSSE signing wired in CI; Rekor logging enabled.
* [ ] Durable artifact store with WORM semantics.
* [ ] Scanner produces explainable findings; SARIF optional.
* [ ] OpenVEX emitted and archived; linked to findings & image.
* [ ] Policy gate enforced; waivers modeled as VEX; decisions logged.
* [ ] Air‑gap mirrors for registry and vuln DBs.
* [ ] Runbooks for key rotation, Rekor outage, and database rollback.
---
## 16) Glossary
* **SBOM**: Software Bill of Materials describing packages/components within an artifact.
* **Attestation**: Signed statement binding facts (predicate) to a subject (artifact) using in‑toto.
* **DSSE**: Envelope that signs the canonical payload detached from transport.
* **Transparency Log**: Append‑only log (e.g., Rekor) giving inclusion and temporal proofs.
* **VEX**: Vulnerability Exploitability eXchange expressing exploitability status & justification.
---
## 9) Moats
<!-- TODO: Review for separate approval - updated moats section -->
**Four capabilities no competitor offers together:**
1. **Signed Reachability** – Every reachability graph is sealed with DSSE; optional edge-bundle attestations for runtime/init/contested paths.
2. **Deterministic Replay** – Scans run bit-for-bit identical from frozen feeds and analyzer manifests.
3. **Explainable Policy (Lattice VEX)** – Evidence-linked VEX decisions with explicit "Unknown" state handling.
4. **Sovereign + Offline Operation** – FIPS/eIDAS/GOST/SM/PQC profiles and offline mirrors as first-class toggles.
**Decision Capsules:** Every scan result is sealed in a Decision Capsule—a content-addressed bundle containing exact SBOM, vuln feed snapshots, reachability evidence, policy version, derived VEX, and signatures. Auditors can re-run any capsule bit-for-bit to verify the outcome.
**Additional moat details:**
- **Deterministic replay:** Hash-stable scans with frozen feeds and analyzer manifests; replay packs verifiable offline.
- **Hybrid reachability attestations:** Graph-level DSSE always; selective edge-bundle DSSE for runtime/init/contested edges with Rekor caps. Both static call-graph edges and runtime-derived edges can be attested.
- **Lattice VEX engine (Evidence-Linked):** Trust algebra across advisories, runtime, reachability, waivers; explainable paths with proof-linked decisions. Unlike yes/no approaches, explicit "Unknown" state handling ensures incomplete data never leads to false safety.
- **Crypto sovereignty:** FIPS/eIDAS/GOST/SM/PQC profiles and offline mirrors as first-class configuration.
- **Proof graph:** DSSE + Rekor spanning SBOM, call-graph, VEX, Decision Capsules, replay manifests for chain-of-custody evidence.
- **VEX Propagation:** Generate vulnerability status attestations downstream consumers can automatically trust and ingest—scalable VEX sharing across the supply chain.
See also: `docs/product/competitive-landscape.md` for vendor comparison and talking points.
---
## 8 · Change Log
| Version | Date | Note (high‑level) |
| ------- | ----------- | ----------------------------------------------------------------------------------------------------- |
| v1.4 | 29-Oct-2025 | Initial principles, golden path, policy examples, and JSON skeletons. |
| v1.4 | 14‑Jul‑2025 | First public revision reflecting quarterly roadmap & KPI baseline. |
| v1.3 | 12‑Jul‑2025 | Expanded ecosystem pillar, added metrics/integrations, refined non-goals, community persona/feedback. |
| v1.2 | 11‑Jul‑2025 | Restructured to link with WHY; merged principles into Strategic Pillars; added review §7 |
| v1.1 | 11‑Jul‑2025 | Original OSS‑only vision |
| v1.0 | 09‑Jul‑2025 | First public draft |
*(End of Product Vision v1.3)*
- [Overview](../overview.md) — 2-minute product summary
- [Architecture Overview](../ARCHITECTURE_OVERVIEW.md) — High-level architecture
- [Release Orchestrator Architecture](../modules/release-orchestrator/architecture.md) — Detailed orchestrator design
- [Competitive Landscape](competitive-landscape.md) — Vendor comparison
- [Roadmap](../ROADMAP.md) — Implementation priorities