224 lines
9.9 KiB
Markdown
Executable File
224 lines
9.9 KiB
Markdown
Executable File
# Product Vision — Stella Ops Suite
|
||
*Evidence-grade release orchestration for containerized applications outside Kubernetes.*
|
||
|
||
> Stella Ops Suite is not “a scanner” and not “another CD tool.”
|
||
> It is a **release control plane** that produces **verifiable evidence** for every promotion decision, and uses **reachability-aware security** as a first-class gate.
|
||
|
||
---
|
||
|
||
## 1) Why this product exists
|
||
|
||
Most non-Kubernetes container estates ship using a patchwork:
|
||
|
||
- CI produces images, registries store them, scanners emit long CVE lists.
|
||
- Deployment happens via Compose/scripts/Ansible plus tribal knowledge approvals.
|
||
- Audit evidence is reconstructed from screenshots and spreadsheets.
|
||
|
||
This fails in predictable ways:
|
||
|
||
- Security noise overwhelms engineers (too many non-actionable CVEs).
|
||
- Release governance is informal (approvals are not cryptographically bound to artifacts).
|
||
- “Why was this approved / blocked?” is not replayable or defensible.
|
||
- Audits become manual, slow, and error-prone.
|
||
|
||
**Stella’s premise:** in the AI economics era, code is cheap; trustworthy operations are expensive.
|
||
Stella’s job is to make *evidence-grade releases* routine, self-service, and hard to replicate.
|
||
|
||
---
|
||
|
||
## 2) Target users and where we win
|
||
|
||
### Who Stella is for
|
||
- Teams deploying containers **without Kubernetes** (Docker hosts, Docker Compose, ECS, Nomad, scripted targets).
|
||
- Small and mid organizations that need **practical, certifiable security** without a heavy platform team.
|
||
- Regulated or audit-exposed environments, including **offline/air-gapped** operations.
|
||
|
||
### Where we intentionally win
|
||
- **Evidence-grade governance**: every promotion is backed by signed, exportable evidence.
|
||
- **Reachability-aware security**: prioritize what is actually exploitable, not what is merely present.
|
||
- **Deterministic replay**: reproduce past decisions bit-for-bit to answer auditors and incident reviews.
|
||
- **Non-Kubernetes first-class**: targets and workflows that are not an afterthought.
|
||
|
||
### Non-goals
|
||
- Replacing CI systems (Jenkins/GitHub Actions/GitLab CI remain your build engine).
|
||
- Competing as a Kubernetes-first CD product (use Argo CD / Flux where Kubernetes is the estate).
|
||
- Inventing new SBOM, attestation, or VEX formats.
|
||
|
||
---
|
||
|
||
## 3) The North Star: “Every release is provable”
|
||
|
||
A **provable release** means:
|
||
|
||
1. Every new artifact digest has evidence (SBOM + reachability + verdict) generated once and reused.
|
||
2. Every promotion decision records inputs, policy, approvals, and reasons.
|
||
3. Evidence is exportable, verifiable offline, and reproducible by replay.
|
||
|
||
---
|
||
|
||
## 4) Golden path (Verified Release)
|
||
|
||
Stella supports both “Verified” and “CD-only” modes, but it is designed to excel at Verified releases.
|
||
|
||
### Verified release flow
|
||
```mermaid
|
||
flowchart LR
|
||
A[CI Build] --> B[Push to OCI Registry by digest]
|
||
B --> C[Deep Scan once per digest\nSBOM + reachability + findings]
|
||
C --> D[Create Release\nDigest bundle + provenance refs]
|
||
D --> E[Request Promotion\nDev -> Stage -> Prod]
|
||
E --> F[Gate Evaluation\nPolicy + security + approvals]
|
||
F --> G{Decision}
|
||
G -->|Allow| H[Deploy to targets\nCompose/Docker/ECS/Nomad/scripts]
|
||
G -->|Deny| I[Block with explainable reasons]
|
||
H --> J[Evidence Packet\nSigned + stored + exportable]
|
||
```
|
||
|
||
### CD-only mode (supported, not optimized)
|
||
Stella can orchestrate deployments while bypassing evidence gates. This exists to avoid competing in a saturated “CD-only” market and to allow gradual adoption. However, the differentiator is **evidence-grade governance**.
|
||
|
||
---
|
||
|
||
## 5) Product pillars (what we build)
|
||
|
||
### Pillar A — Release orchestration (control plane)
|
||
- Environment management and promotion workflows (Dev -> Stage -> Prod).
|
||
- Approvals, freeze windows, and separation-of-duties policies.
|
||
- Rollbacks and redeploys by immutable digest identity.
|
||
- “What is deployed where” inventory over time.
|
||
|
||
### Pillar B — Security decisioning as a gate
|
||
- Scan on build, evaluate on release, re-evaluate on intel updates.
|
||
- Reachability-aware vulnerability prioritization (reduce noise; focus on exploitable paths).
|
||
- VEX-first decisioning and policy explainability (“why blocked?” traces).
|
||
|
||
### Pillar C — Evidence & audit
|
||
- Signed evidence packets per decision: inputs, verdicts, approvals, deployment artifacts, logs.
|
||
- Exportable audit packs for auditors, incident reviews, and regulated reporting.
|
||
- Integrity guarantees (content-addressed artifacts + signatures + optional transparency logging).
|
||
|
||
### Pillar D — Determinism and replay
|
||
- Deterministic scanning and policy evaluation with replay manifests.
|
||
- Reproduce prior decisions given the same manifest, feeds, and versioned engines.
|
||
- Deterministic identifiers and ordering; UTC timestamps; canonical hashing.
|
||
|
||
### Pillar E — Self-service operations (Doctor-first)
|
||
- Self-diagnostics (“Doctor”) to remove dependency on vendor support.
|
||
- Offline-first posture; explicit allowlists; strict validation; predictable failure modes.
|
||
- A product that can reach meaningful production adoption without a sales/support org.
|
||
|
||
---
|
||
|
||
## 6) Design principles and invariants (non-negotiable)
|
||
|
||
### Invariant 1 — Digest-first release identity
|
||
A release is a **bundle of OCI digests** (component -> digest mapping), never mutable tags.
|
||
|
||
- Tags may be accepted as inputs but must be resolved to digests at release creation time.
|
||
- Downstream operations (promotion, deployment, rollback) operate on digests.
|
||
- Digest mismatch at pull time is a hard failure (tamper signal).
|
||
|
||
### Invariant 2 — Evidence-first decisions
|
||
Every promotion/deployment emits an immutable evidence record.
|
||
|
||
Evidence must capture:
|
||
- Who: authenticated identity and authorization context
|
||
- What: release bundle, target environment(s), target selection
|
||
- Why: policy outcome, approval chain, decision reasons
|
||
- How: generated artifacts and execution traces
|
||
- When: deterministic timestamps and ordering
|
||
|
||
### Invariant 3 — Deterministic replay
|
||
Given the recorded manifest (inputs + versions), Stella must reproduce:
|
||
- scan outputs,
|
||
- policy outcomes,
|
||
- gate reasons,
|
||
- and decision records.
|
||
|
||
### Invariant 4 — Offline-first operation
|
||
Core decisions must not require external network access.
|
||
External feeds are mirrored; verification and replay must work offline.
|
||
|
||
### Invariant 5 — Pluggable edges, stable core
|
||
Integrations and target types are plugins. The orchestration and evidence core remains stable.
|
||
|
||
Plugins may provide:
|
||
- connector logic (SCM/CI/registry/secrets),
|
||
- workflow step types,
|
||
- target/agent types,
|
||
- Doctor checks.
|
||
|
||
### Invariant 6 — No “feature gating”
|
||
Capabilities are not tier-gated.
|
||
Commercial limits (when relevant) apply only to **scale units** such as:
|
||
- environments (governance boundaries),
|
||
- new digests deep-scanned per month (evidence generation),
|
||
- fair-use constraints on exceptional bandwidth/support consumption.
|
||
|
||
---
|
||
|
||
## 7) Security and evidence invariants (carryover from scanning heritage)
|
||
|
||
1. Artifact identity is content-addressed (SHA-256 digests).
|
||
2. SBOMs and key evidence artifacts are signed (in-toto DSSE envelopes).
|
||
3. Provenance is attached via attestations, not implied via tags or CI logs.
|
||
4. Explainability is required: findings must connect to packages/paths/symbols when available.
|
||
5. Exploitability over enumeration: VEX and reachability drive actionability.
|
||
6. Air-gap posture is first-class: mirrors, offline kits, and offline verification flows.
|
||
|
||
---
|
||
|
||
## 8) Competitive positioning (category definition)
|
||
|
||
### What we are not
|
||
- **Not a pure scanner**: scanners find issues; Stella governs releases with evidence.
|
||
- **Not a generic CD tool**: CD tools deploy; Stella is a release authority with proof.
|
||
|
||
### Where alternatives typically stop
|
||
- Scanners: produce findings, but do not produce release-level evidence chains.
|
||
- CD tools: provide deployments, but security is bolt-on and audit evidence is manual.
|
||
- Registries: store artifacts, but are not a governance and decision system.
|
||
|
||
### Stella’s moat
|
||
- Digest-first release identity + signed evidence chain + deterministic replay
|
||
- Reachability-aware decisioning bound to promotion workflows
|
||
- Offline-first and sovereign crypto posture
|
||
- Self-service operability (Doctor-first) designed for small teams
|
||
|
||
---
|
||
|
||
## 9) Roadmap framing (outcome-driven)
|
||
|
||
This vision is delivered in phases, but the category remains consistent:
|
||
|
||
1) **Evidence foundation**: deep scan, policy, determinism, evidence export, Doctor maturity
|
||
2) **Release control plane**: environments, promotions, approvals, decision records
|
||
3) **Deployment execution**: non-Kubernetes targets, rollback, artifacts, verification checks
|
||
4) **Progressive delivery**: canary/A-B/blue-green where practical for non-K8s estates
|
||
5) **Ecosystem depth**: integrations/connectors, plugin surface hardening, docs, ops kits
|
||
|
||
---
|
||
|
||
## 10) Glossary (canonical terms)
|
||
|
||
- **Environment**: governance boundary (policy + config + approvals + targets)
|
||
- **Release**: immutable bundle of digests (component -> digest)
|
||
- **Promotion**: moving a release between environments
|
||
- **Gate**: policy check that blocks/allows promotion
|
||
- **Evidence packet**: signed bundle of decision inputs/outputs suitable for export and verification
|
||
- **Deterministic replay**: re-running a decision with the same manifest to reproduce outputs
|
||
|
||
---
|
||
|
||
## Change log
|
||
|
||
| Version | Date | Note |
|
||
|---|---:|---|
|
||
| v3.0 | 2026-01-17 | Reframed as evidence-grade release control plane; added Doctor-first and CD-only framing; removed pricing specifics. |
|
||
| v2.0 | 2026-01-09 | 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 |
|