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

13 KiB
Executable File
Raw Blame History

Product Vision — Stella Ops Suite

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 to non-Kubernetes targets (Docker hosts, Compose, ECS, Nomad). We need:

  • 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 (Release-Centric Flow)

Build → Scan → Create Release → Request Promotion → Gate Evaluation → Deploy → Evidence

flowchart LR
    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]

What Stella Ops Suite Does

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) Design Principles & Invariants

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.

  2. Every SBOM is signed.

    • 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.

  4. Transparency FIRST mindset.

    • 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.

  6. Explainability.

    • 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.

  8. Air-gap friendly.

    • Mirrors for vuln DBs and containers; all verification MUST work without public egress.

5) Adopted Standards

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

6) Competitive Positioning

Why Stella Wins (One Line Each)

  • 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.

7) Release Orchestration Architecture (Planned)

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

8) Existing Capabilities (Operational)

These themes power the security gate within release orchestration:

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

9) Pricing Model

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

10) Implementation Roadmap (Planned)

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

11) Change Log

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

References