save progress

This commit is contained in:
master
2026-01-09 18:27:36 +02:00
parent e608752924
commit a21d3dbc1f
361 changed files with 63068 additions and 1192 deletions

View File

@@ -0,0 +1,114 @@
## Stella Ops Suite card
### What Stella Ops Suite is
**Stella Ops Suite is a centralized, auditable release control plane for nonKubernetes container estates.**
It sits between your CI and your runtime targets, governs **promotion across environments**, enforces **security + policy gates**, and produces **verifiable evidence** for every release decision—while remaining **plugin friendly** to any SCM/CI/registry/secrets stack.
### What it does
* **Release orchestration (nonK8s):** UI-driven promotion (Dev → Stage → Prod), approvals, policy gates, rollbacks; steps are **hookable with scripts** (and/or step providers).
* **Security decisioning as a gate:** scan on **build**, evaluate on **release**, and **reevaluate** on vulnerability intelligence updates without forcing re-scans of the same artifact.
* **OCI-digest first:** treats a release as an immutable **digest** (or bundle of digests) and tracks “what is deployed where” with integrity.
* **Toolchainagnostic integrations:** plug into any **SCM / repo**, any **CI**, any **registry**, and any **secrets** system; customers can reuse what they already run.
* **Auditability + standards:** audit log + evidence packets (exportable), SBOM/VEX/attestation-friendly, standards-first approach.
### Core strengths
* **NonKubernetes specialization:** Docker hosts/Compose/ECS/Nomad-style targets are first-class, not an afterthought.
* **Reproducibility:** deterministic release decisions captured as evidence (inputs + policy hash + verdict + approvals).
* **Attestability:** produces and verifies release evidence/attestations (provenance, SBOM linkage, decision records) in standard formats.
* **Verity (integrity):** digest-based release identity; signature/provenance verification; tamper-evident audit trail.
* **Hybrid reachability:** reachability-aware vulnerability prioritization (static + “hybrid” signals) to reduce noise and focus on exploitable paths.
* **Cost that doesnt punish automation:** no per-project tax, no per-seat tax, no “deployments bill.” Limits are **only**:
**(1) number of environments** and **(2) number of new digests analyzed per day.**
---
# Why Stella wins vs competitors (in one line each)
* **CI/CD tools** (Actions/Jenkins/GitLab CI): great at *running pipelines*, weak at being a **central release authority across environments + registries + targets** with audit-grade evidence and security decisioning as a gate.
* **Deployment tools / CD orchestrators** (Octopus/Harness/Spinnaker/CloudBees): strong promotions, but security depth (reachability, attestations, continuous re-evaluation) is often **bolton**, and pricing often scales poorly (projects/services/users).
* **Docker registries / artifact platforms** (Harbor/JFrog/Docker registry ecosystems): can store + scan images, but dont provide a **release governance control plane** (promotion workflows, approvals, policy reasoning, deploy execution across targets).
* **Vulnerability scanners / CNAPP** (Trivy/Snyk/Aqua/Anchore/etc.): can scan well, but do not provide **release orchestration + promotion governance + deploy execution** with a single evidence ledger.
---
# Feature table: Stella vs “typical” alternatives (detailed)
**Legend:**
* **Native** = built-in, first-class
* **Partial** = exists but not release-centric / limited scope
* **Via integration** = possible but not owned end-to-end
* **N/A** = not a focus of that tool category
* **Varies** = depends heavily on vendor/edition/plugins
| Feature area | Stella Ops Suite (Release + Security Control Plane) | CI/CD tools (Actions/Jenkins/GitLab CI) | CD/Deploy orchestrators (Octopus/Harness/Spinnaker) | Registries / artifact platforms (Harbor/JFrog/Docker) | Scanners / CNAPP (Trivy/Snyk/Aqua/Anchore/etc.) |
| ------------------------------------------------------------------- | -------------------------------------------------------------------------------- | --------------------------------------- | -------------------------------------------------------- | ----------------------------------------------------- | ----------------------------------------------- |
| **Primary abstraction** | **Release by OCI digest** + environment promotion | Pipeline run / job | Release / deployment pipeline | Artifact/image repo | Scan report / project |
| **NonK8s container focus** | **Native** (Docker/ECS/Nomad style) | Partial (scripts can deploy anywhere) | Partial (often broad incl. K8s) | Native for registries; not deploy | N/A |
| **Environment model** (Dev/Stage/Prod) | **Native** (envs are first-class) | Partial (vendor-dependent env tracking) | **Native** | Partial (some repos have “projects,” not env) | N/A |
| **Promotion workflow** (Dev→Prod) | **Native** | Via integration / custom pipeline | **Native** | N/A | N/A |
| **Approvals / manual gates** | **Native** | Partial (manual steps exist) | **Native** | N/A | N/A |
| **Separation of duties** (policy) | **Native** (policy-driven) | Partial / varies | Partial / varies | N/A | N/A |
| **Freeze windows / release windows** | Native (policy-driven) | Varies | Varies | N/A | N/A |
| **Deployment execution** to targets | **Native** (agents + target adapters) | Via scripts | **Native** | N/A | N/A |
| **Rollback / redeploy same digest** | **Native** | Via scripts | **Native** | N/A | N/A |
| **Target inventory** (hosts/services) | **Native** | N/A | Partial (depends) | N/A | N/A |
| **Scriptable step hooks** | **Native** (hooks everywhere) | Native (pipelines are scripts) | **Native/Partial** (often supported) | N/A | Partial (hooks in CI) |
| **Pluggable connectors** (SCM/CI/registry) | **Native design goal** (reuse customer stack) | N/A (they *are* the CI) | Partial | Partial | Partial |
| **Registry-neutral operation** | **Native** (works with any registry; can reuse) | Via scripts | Via integration | Registry-centric | N/A |
| **Release gating based on security** | **Native** (scanner verdict is a gate) | Via integration | Via integration | Partial (policy usually at pull time) | N/A (scanner doesnt deploy) |
| **Scan timing: build-time** | **Native** (CI integration) | Via integration | Via integration | Partial | **Native** |
| **Scan timing: release-time** | **Native** (gate uses cached evidence) | Via integration | Via integration | Partial | Partial |
| **Scan timing: CVE update re-evaluation** | **Native** (continuous re-eval) | Rare / custom | Rare / custom | Partial (platform dependent) | Varies (often supported) |
| **New-digest accounting** (dont charge for redeploys) | **Native (digest-cache first)** | N/A | N/A | N/A | Varies |
| **SBOM generation** | **Native** | Via integration | Via integration | Partial | **Native/Partial** |
| **VEX support** (clarify not-affected/fixed) | **Native** (standards-first) | Via integration | Via integration | Partial | Varies |
| **Reachability analysis** | **Native** (incl. hybrid reachability) | Via integration | Via integration | Rare | Varies (often not reachability) |
| **Hybrid reachability** (static + optional runtime signals) | **Native** | N/A | N/A | N/A | Rare |
| **Exploit intelligence / prioritization** (KEV-like, etc.) | Native / planned (as decision inputs) | Via integration | Via integration | Partial | Varies |
| **Backport / fix verification** | Native / planned (noise reduction) | N/A | N/A | N/A | Rare |
| **Attestability** (produce attestations/evidence) | **Native** (evidence packet export) | Partial | Partial | Partial | Partial |
| **Verity** (signature/provenance verification) | **Native** (enforce verifiable releases) | Via integration | Via integration | Partial (registry dependent) | Partial |
| **Reproducibility** (replayable decision/evidence) | **Native** (policy+inputs hashed) | Rare | Rare | N/A | N/A |
| **Central audit ledger** (who/what/why) | **Native** | Partial (logs exist, not unified) | Partial (deployment logs) | Partial (artifact logs) | Partial (scan logs) |
| **“Why blocked?” explainability** | **Native** (decision reasons + evidence refs) | Varies | Varies | Varies | Varies |
| **Multi-toolchain governance** (one control plane over many stacks) | **Native** | No (each CI silo) | Partial | No (registry silo) | No (scanner silo) |
| **Open-source extensibility** | **Native** (OSS agents/connectors, paid core) | Native OSS for some (Jenkins) | Varies | Varies | Varies |
| **Pricing pain point** | **No per-seat / per-project / per-deploy tax** | Often per-seat or usage | Often per-project/service/user | Often storage/traffic/consumption | Often per-seat / consumption |
| **Best fit** | NonK8s container teams needing centralized, auditable releases + security gates | Teams wanting pipeline automation | Teams wanting deployment automation (security bolted on) | Teams needing artifact storage + basic scanning | Teams needing scanning, not orchestration |
**Interpretation:** Stella is not trying to “replace CI” or “be a registry.” It is the **release integrity layer** that (a) makes promotion decisions, (b) executes deployments to nonK8s container targets, and (c) produces verifiable evidence for audit and reproducibility—while reusing the customers existing SCM/CI/registry.
---
# Stella pricing proposal (all features included; only scale limits)
**Pricing principle:**
You pay for **(1) environments** and **(2) new artifact digests analyzed per day**.
Deployments/promotions are unlimited (fair use), and **re-evaluation on CVE updates is included** and does not consume “new digest analyses.”
| Plan | Price | Environments | New digests analyzed/day | Whats included |
| ----------------------------------------------- | -----------------: | -----------: | -----------------------: | ------------------------------------------------------------------------------------- |
| **Free + Registration** (monthly token renewal) | $0 | 3 | 333 | Full suite features, unlimited deployments (fair use), evidence + audit, integrations |
| **Pro** | **$699 / month** | 33 | 3333 | Same features |
| **Enterprise** | **$1,999 / month** | Unlimited | Unlimited | Same features, “no hard limits,” fair use on mirroring/audit-confirmation bandwidth |
### “Fair use” (make it explicit so its credible)
* Unlimited deployments/promotions assume normal operational usage (no abusive tight-loop triggers).
* “Unlimited” in Enterprise is protected by fair use for:
* vulnerability feed mirroring bandwidth and update frequency
* audit confirmation / evidence export traffic spikes
* storage growth beyond reasonable bounds (offer storage retention controls)
---
# Short “elevator pitch” for the card (copy-ready)
**Stella Ops Suite** gives nonKubernetes container teams a **central release authority**: it orchestrates environment promotions, gates releases using **reachability-aware security** and policy, and produces **verifiable, auditable evidence** for every decision—without charging per project, per seat, or per deployment.
If you want, I can compress this into a true one-page “sales card” layout (same content, but formatted exactly like a procurement-ready PDF/one-pager), and a second version tailored to your best ICP (Docker host fleets vs ECS-heavy teams).