300 lines
13 KiB
Markdown
Executable File
300 lines
13 KiB
Markdown
Executable File
# 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
|
|
```
|
|
|
|
```mermaid
|
|
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
|
|
|
|
- [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
|