stella-ops.org/git.stella-ops.org
1
0
Fork 0
Code Issues Pull Requests Actions 2 Releases Wiki Activity
Files
6e687b523aa572c0850de61175d702ad3f7d9c24
git.stella-ops.org/docs/product/VISION.md

9.9 KiB
Executable File
Raw Blame History

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

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