sprints completion. new product advisories prepared
This commit is contained in:
master
@@ -110,10 +110,10 @@ Deployment targets are **unlimited** (no per-target / per-machine licensing).
|
||||
|
||||
| Tier | Monthly | Annual (11x) | Environments | New digest deep scans / month | Support |
|
||||
|---|---:|---:|---:|---:|---|
|
||||
| **Free** | $0 | $0 | **3** | **999** | Doctor self-diagnostics + community forum |
|
||||
| **Plus** | **$399** | **$4,389** | **33** | **9,999** | Doctor + priority forum + **1 support ticket/month** |
|
||||
| **Pro** | **$999** | **$10,989** | **333** | **99,999** | Doctor + priority forum + **5 support tickets/month** |
|
||||
| **Business** | **$2,999** | **$32,989** | **3,333** | **999,999** | Doctor + priority forum + **email channel** + **25 support tickets/month** (best-effort) + fair use |
|
||||
| **Free** | $0 | $0 | **3** | **999** | Community forum + Doctor |
|
||||
| **Plus** | **$399** | **$4,389** | **33** | **9,999** | Community forum + Doctor |
|
||||
| **Pro** | **$999** | **$10,989** | **333** | **99,999** | Community + Doctor + **$99/ticket** (pay-per-incident) |
|
||||
| **Business** | **$2,999** | **$32,989** | **3,333** | **999,999** | Community + Doctor + **5 tickets/month included** + $99/additional |
|
||||
|
||||
---
|
||||
|
||||
@@ -121,7 +121,6 @@ Deployment targets are **unlimited** (no per-target / per-machine licensing).
|
||||
|
||||
| Add-on | Price | Intended use |
|
||||
|---|---:|---|
|
||||
| **+10 support tickets** | **$299** | Incident bursts, onboarding assistance, expansion without tier change |
|
||||
| **+10,000 new digest deep scans** | **$499** | Temporary capacity for release sprints, migrations, or one-off spikes |
|
||||
|
||||
---
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,114 +0,0 @@
|
||||
## Stella Ops Suite card
|
||||
|
||||
### What Stella Ops Suite is
|
||||
|
||||
**Stella Ops Suite is a centralized, auditable release control plane for non‑Kubernetes 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 **plug‑in friendly** to any SCM/CI/registry/secrets stack.
|
||||
|
||||
### What it does
|
||||
|
||||
* **Release orchestration (non‑K8s):** UI-driven promotion (Dev → Stage → Prod), approvals, policy gates, rollbacks; steps are **hook‑able with scripts** (and/or step providers).
|
||||
* **Security decisioning as a gate:** scan on **build**, evaluate on **release**, and **re‑evaluate** 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.
|
||||
* **Toolchain‑agnostic 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
|
||||
|
||||
* **Non‑Kubernetes 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 doesn’t 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 **bolt‑on**, and pricing often scales poorly (projects/services/users).
|
||||
* **Docker registries / artifact platforms** (Harbor/JFrog/Docker registry ecosystems): can store + scan images, but don’t 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 |
|
||||
| **Non‑K8s 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 doesn’t 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** (don’t 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** | Non‑K8s 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 non‑K8s container targets, and (c) produces verifiable evidence for audit and reproducibility—while reusing the customer’s 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 | What’s 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 it’s 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 non‑Kubernetes 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).
|
||||
@@ -1,29 +0,0 @@
|
||||
I’m sharing this because it’s a crisp snapshot of how some modern AppSec and supply‑chain tools *feel* in real workflows—where they fit, and what trade‑offs teams bump into as they try to shift left without losing signal or evidence.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**Snyk** leans hard into developer‑first onboarding and inline feedback early in IDE/CI flows, with rich docs and in‑product training that help catch issues before builds, though it’s still mostly about surfacing textual context and guidance rather than anchored cryptographic evidence about what changed. ([Snyk][1])
|
||||
|
||||
**JFrog Xray** brings deep SCA into the artifact‑centric world of Artifactory, with detailed binary and vulnerability context tied to your repos; it’s strong for repo‑centric enforcement and policy gating, but typical remediation flows are policy or ticket‑oriented rather than built around machine‑verifiable proofs. ([JFrog][2])
|
||||
|
||||
**GitLab’s security scanners** are embedded into its CI/CD and MR experience, showing vulnerability data right in merge requests and making triage visible where devs work; panels tend to prioritize traditional metadata like CVSS and advisory info rather than deterministic proofs or binary diff traces. ([JFrog][3])
|
||||
|
||||
**Aqua Security** scans containers and runtimes across lifecycle stages with rich integrations and AI‑guided remediation suggestions that help push fixes into ticketing/workflows, but such guidance often feels generic without machine‑verifiable evidence of safety. ([strongdm.com][4])
|
||||
|
||||
**Anchore’s open tools (Syft & Grype)** are SBOM‑first: Syft generates detailed bills of materials, Grype scans them for vulnerabilities; they excel at inventory and actionable plans but their UIs and workflows don’t inherently include cryptographic attestations or tight evidence‑anchored remediation flows. ([Anchore][5])
|
||||
|
||||
Each of these tools is useful in its niche, but the subtle differences in how they onboard devs, present context, and *anchor evidence* matter a lot when you’re aiming for deterministic, supply‑chain‑proof workflows.
|
||||
|
||||
[1]: https://snyk.io/articles/developer-first-security/?utm_source=chatgpt.com "Developer-First Security"
|
||||
[2]: https://jfrog.com/help/r/jfrog-security-user-guide/products/xray?utm_source=chatgpt.com "Xray"
|
||||
[3]: https://jfrog.com/jfrog-vs-gitlab/?utm_source=chatgpt.com "JFrog vs GitLab Comparison"
|
||||
[4]: https://www.strongdm.com/blog/devsecops-tools?utm_source=chatgpt.com "8 DevSecOps Tools for Modern Security-First Teams in 2026"
|
||||
[5]: https://anchore.com/opensource/?utm_source=chatgpt.com "Open Source Container Security with Syft & Grype"
|
||||
@@ -0,0 +1,309 @@
|
||||
Here’s a short, implementation‑ready plan to turn your SBOMs into enforceable, cryptographic gates in Stella Ops—sequence, gate checks, and a compact threat model you can wire into a sprint.
|
||||
|
||||
---
|
||||
|
||||
# Minimal sequence (do now)
|
||||
|
||||
1. **CI build → Scanner/Sbomer**
|
||||
Compute `sha256` of each artifact and emit CycloneDX 1.6 SBOM with `components[].hashes[]`. ([CycloneDX][1])
|
||||
2. **Authority (DSSE sign)**
|
||||
Canonicalize SBOM JSON; wrap as DSSE `payloadType` for attestations and sign (HSM/KMS key). ([in-toto][2])
|
||||
3. **Router (Rekor v2)**
|
||||
Upload DSSE / in‑toto Statement to Rekor v2; persist returned `uuid`, `logIndex`, `integratedTime`. ([Sigstore Blog][3])
|
||||
4. **Vexer/Excititor (VEX)**
|
||||
Emit OpenVEX/CSAF (or in‑toto predicate) referencing CycloneDX `serialNumber`/`bom-ref` and the Rekor `uuid`. ([in-toto][2])
|
||||
5. **CI gate (OPA/Rego)**
|
||||
Verify (a) DSSE signature chain, (b) `payloadType` matches expected, (c) Rekor inclusion (via `logIndex`/UUID), (d) allowed `predicateType`, (e) component hash equals subject digest. ([Witness][4])
|
||||
|
||||
---
|
||||
|
||||
# Paste‑in Rego (gate)
|
||||
|
||||
```rego
|
||||
package stella.gate
|
||||
|
||||
deny[msg] {
|
||||
input.attestation.payloadType != "application/vnd.cyclonedx+json"
|
||||
msg = "unexpected payloadType"
|
||||
}
|
||||
|
||||
deny[msg] {
|
||||
not input.rekor.logIndex
|
||||
msg = "missing rekor logIndex"
|
||||
}
|
||||
|
||||
/* extend:
|
||||
- verify DSSE signature against Authority key
|
||||
- verify Rekor inclusion proof/integratedTime
|
||||
- ensure predicateType ∈ {
|
||||
"https://cyclonedx.org/schema/bom-1.6",
|
||||
"https://openvex.org/v1"
|
||||
}
|
||||
- ensure subject digest == components[].hashes[].content
|
||||
*/
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# Compact threat model (top 3 + mitigations)
|
||||
|
||||
* **Tampering at rest** → Anchor in Rekor v2; verify inclusion + `integratedTime`; require DSSE signature with Authority HSM key. ([Sigstore Blog][3])
|
||||
* **Time‑shift / backdating** → Reject if `integratedTime` < pipeline build time − skew; optional RFC‑3161 timestamping on uploads. (Policy check in Scheduler.) ([Sigstore Blog][3])
|
||||
* **Provenance spoofing** → Enforce valid `predicateType` (in‑toto/OpenVEX), and map `signatures[].keyid` to trusted Authority keys (Fulcio/HSM). ([in-toto][2])
|
||||
|
||||
---
|
||||
|
||||
# Where this lands in Stella
|
||||
|
||||
* **Scanner**: compute subject digests; emit artifact metadata.
|
||||
* **Sbomer**: produce CycloneDX 1.6 with hashes, CBOM/attestations support ready. ([CycloneDX][1])
|
||||
* **Authority**: create DSSE envelope + sign; maintain key roster & rotation. ([Gradle Documentation][5])
|
||||
* **Router**: call Rekor v2; persist `uuid`/`logIndex`/`integratedTime` and expose `verifyRekor(uuid)`. ([Sigstore Blog][3])
|
||||
* **Vexer/Excititor**: emit OpenVEX / in‑toto predicates linking `bom-ref` and Rekor `uuid`. ([in-toto][2])
|
||||
|
||||
---
|
||||
|
||||
# Final sprint checklist
|
||||
|
||||
* Enable DSSE wrapping + Authority signing in one CI pipeline; push to Rekor v2; store `logIndex`. ([Sigstore Blog][3])
|
||||
* Add OPA policy to verify `payloadType`, Rekor presence, and digest match; fail CI on violation. ([Witness][4])
|
||||
* Add Scheduler job to periodically re‑verify Rekor roots and enforce time‑skew rules. ([Sigstore Blog][3])
|
||||
|
||||
**Why now:** CycloneDX 1.6 added attestations/CBOM, making SBOMs first‑class, signed evidence; Rekor v2 lowers cost and simplifies ops—ideal for anchoring these facts and gating releases. ([CycloneDX][1])
|
||||
|
||||
If you want, I can drop this into `docs/policies/OPA/stella.gate.rego` and a sample CI job for your GitLab pipeline next.
|
||||
|
||||
[1]: https://cyclonedx.org/news/cyclonedx-v1.6-released/?utm_source=chatgpt.com "CycloneDX v1.6 Released, Advances Software Supply ..."
|
||||
[2]: https://in-toto.io/docs/specs/?utm_source=chatgpt.com "Specifications"
|
||||
[3]: https://blog.sigstore.dev/rekor-v2-ga/?utm_source=chatgpt.com "Rekor v2 GA - Cheaper to run, simpler to maintain"
|
||||
[4]: https://witness.dev/docs/docs/concepts/policy/?utm_source=chatgpt.com "Policies"
|
||||
[5]: https://docs.gradle.com/develocity/dpg/current/?utm_source=chatgpt.com "Develocity Provenance Governor"
|
||||
|
||||
|
||||
|
||||
---
|
||||
Here’s a compact, engineer‑first guide to emitting a CycloneDX SBOM, wrapping it in a DSSE/in‑toto attestation, and anchoring it in Rekor v2—so you can copy/paste shapes straight into your Sbomer → Authority → Router flow.
|
||||
|
||||
---
|
||||
|
||||
# Why this matters (quick background)
|
||||
|
||||
* **CycloneDX**: the SBOM format you’ll emit.
|
||||
* **DSSE**: minimal, unambiguous envelope for signing arbitrary payloads (your SBOM).
|
||||
* **in‑toto Statement**: standard wrapper with `subject` + `predicate` so policy engines can reason about artifacts.
|
||||
* **Rekor (v2)**: transparency log anchor (UUID, index, integrated time) to verify later at gates.
|
||||
|
||||
---
|
||||
|
||||
# Minimal CycloneDX 1.6 SBOM (emit from `Sbomer`)
|
||||
|
||||
```json
|
||||
{
|
||||
"$schema": "http://cyclonedx.org/schema/bom-1.6.schema.json",
|
||||
"bomFormat": "CycloneDX",
|
||||
"specVersion": "1.6",
|
||||
"serialNumber": "urn:uuid:11111111-2222-3333-4444-555555555555",
|
||||
"metadata": {
|
||||
"component": {
|
||||
"bom-ref": "stella-app",
|
||||
"type": "application",
|
||||
"name": "stella-app",
|
||||
"version": "1.2.3"
|
||||
}
|
||||
},
|
||||
"components": [
|
||||
{
|
||||
"bom-ref": "lib-a",
|
||||
"type": "library",
|
||||
"name": "lib-a",
|
||||
"version": "0.1.0",
|
||||
"hashes": [
|
||||
{ "alg": "SHA-256", "content": "<hex-hash>" }
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
**Must‑emit fields (Sbomer):** `specVersion`, `serialNumber`, `components[].bom-ref`, `components[].hashes[].(alg,content)`.
|
||||
|
||||
---
|
||||
|
||||
# Wrap SBOM with DSSE (signed by `Authority`)
|
||||
|
||||
```json
|
||||
{
|
||||
"payloadType": "application/vnd.cyclonedx+json",
|
||||
"payload": "<base64(cyclonedx-bom.json)>",
|
||||
"signatures": [
|
||||
{ "keyid": "cosign:sha256:abcd...", "sig": "<base64-signature>" }
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
**Must‑emit (Authority):** `payloadType`, `payload` (base64), `signatures[].keyid`, `signatures[].sig`.
|
||||
|
||||
---
|
||||
|
||||
# Optional: in‑toto Statement (produced by `Excititor/Vexer`)
|
||||
|
||||
```json
|
||||
{
|
||||
"_type": "https://in-toto.io/Statement/v0.1",
|
||||
"subject": [
|
||||
{ "name": "stella-app", "digest": { "sha256": "<artifact-sha256>" } }
|
||||
],
|
||||
"predicateType": "https://cyclonedx.org/schema/bom-1.6",
|
||||
"predicate": {
|
||||
"bomRef": "stella-app",
|
||||
"uri": "oci://registry.example.com/stella-app@sha256:<digest>#sbom"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Must‑emit (Excititor/Vexer):** `predicateType` and a `predicate` your policy engine can dereference (embed SBOM or provide a pointer).
|
||||
|
||||
---
|
||||
|
||||
# Rekor v2 anchor (persist in `Router`, verify at gates)
|
||||
|
||||
```json
|
||||
{
|
||||
"uuid": "c3f2e4a8-...",
|
||||
"logIndex": 123456,
|
||||
"integratedTime": "2026-01-15T12:34:56Z"
|
||||
}
|
||||
```
|
||||
|
||||
**Must‑store (Router):** `uuid`, `logIndex`, `integratedTime`.
|
||||
|
||||
---
|
||||
|
||||
# End‑to‑end checks (put these in your CI gate)
|
||||
|
||||
* **SBOM shape**: JSON Schema validate CycloneDX; ensure `serialNumber` + per‑component hashes exist.
|
||||
* **DSSE**: verify signature over `payload` and `payloadType`; match `keyid` to trusted keys/profile.
|
||||
* **in‑toto**: confirm `subject.digest` equals the release OCI digest; `predicateType` matches CycloneDX 1.6/1.7.
|
||||
* **Rekor v2**: look up `uuid` → confirm `logIndex` & `integratedTime` and verify inclusion proof.
|
||||
|
||||
---
|
||||
|
||||
# Stella Ops module contract (TL;DR)
|
||||
|
||||
* **Sbomer** → emits CycloneDX 1.6/1.7 with `bom-ref` + hashes.
|
||||
* **Authority** → DSSE sign (`payloadType=application/vnd.cyclonedx+json`).
|
||||
* **Excititor/Vexer** → optional in‑toto Statement with CycloneDX predicate or pointer.
|
||||
* **Router** → store Rekor v2 tuple; expose verify endpoint for gates.
|
||||
|
||||
If you want, I can turn this into ready‑to‑run .NET 10 DTOs + validation (FluentValidation) and a tiny verifier CLI that checks all four layers in one go.
|
||||
Here’s a compact, auditor‑friendly way to sign **binary diffs** so they fit cleanly into today’s supply‑chain tooling (DSSE, in‑toto, Sigstore/Rekor) without inventing a new envelope.
|
||||
|
||||
---
|
||||
|
||||
# DSSE “delta‑sig” predicate for signed binary diffs (what & why)
|
||||
|
||||
* **Goal:** prove *exactly what changed* in a compiled artifact (per‑function patching, hotfixes/backports) and who signed it—using the standard **DSSE** (Dead Simple Signing Envelope) + **in‑toto predicate typing** so verifiers and transparency logs work out‑of‑the‑box.
|
||||
* **Why not just hash the whole file?** Full‑file hashes miss *where* and *how* a patch changed code. A delta predicate captures function‑level changes with canonical digests, so auditors can verify the patch is minimal and intentional, and policy can gate on “only approved backports applied.”
|
||||
|
||||
---
|
||||
|
||||
# Envelope strategy
|
||||
|
||||
* Keep the **DSSE envelope** as usual (`payloadType`, `payload`, `signatures`).
|
||||
* The DSSE `payload` is a **canonical JSON** object typed as an in‑toto predicate.
|
||||
* Predicate type (minimal): `stellaops/delta-sig/v1`.
|
||||
|
||||
This keeps interoperability with:
|
||||
|
||||
* **Sigstore/Rekor** (log DSSE envelopes),
|
||||
* **in‑toto** (predicate typing & subject semantics),
|
||||
* existing verification flows (cosign/sigstore‑python/in‑toto‑verify).
|
||||
|
||||
---
|
||||
|
||||
# Minimal predicate schema
|
||||
|
||||
```json
|
||||
{
|
||||
"predicateType": "stellaops/delta-sig/v1",
|
||||
"subject": [
|
||||
{
|
||||
"uri": "oci://registry.example.com/app@sha256:…",
|
||||
"digest": { "algo": "sha256", "hex": "<artifact_sha256>" },
|
||||
"filename": "bin/app",
|
||||
"arch": "linux-amd64"
|
||||
}
|
||||
],
|
||||
"delta": [
|
||||
{
|
||||
"function_id": "foo::bar(int,char)",
|
||||
"addr": 140737488355328,
|
||||
"old_hash": "<sha256_of_old_bytes>",
|
||||
"new_hash": "<sha256_of_new_bytes>",
|
||||
"hash_algo": "sha256",
|
||||
"diff_len": 112,
|
||||
"patch_offset": 4096,
|
||||
"compressed_diff_b64": "<optional_zstd_or_gzip_b64>"
|
||||
}
|
||||
],
|
||||
"tooling": {
|
||||
"lifter": "ghidra",
|
||||
"lifter_version": "11.1",
|
||||
"canonical_ir": "llvm-ir-15"
|
||||
},
|
||||
"canonicalization": {
|
||||
"json_canonicalization_version": "RFC8785"
|
||||
},
|
||||
"signer": {
|
||||
"keyid": "SHA256:…",
|
||||
"signer_name": "Release Engineering"
|
||||
},
|
||||
"signed_digest": {
|
||||
"algo": "sha256",
|
||||
"hex": "<sha256_of_canonical_payload_bytes>"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Notes**
|
||||
|
||||
* Use **SHA‑256** for `subject.digest`, `old_hash`, `new_hash`, and `signed_digest` to maximize compatibility with Rekor/Sigstore. (If you control both ends, **BLAKE2b‑256** is a fine faster alternative.)
|
||||
* `function_id` should be a **stable signature** (normalized symbol or demangled prototype); fall back to address + size if needed.
|
||||
* `compressed_diff_b64` is optional but handy for reproducible patch replay.
|
||||
|
||||
---
|
||||
|
||||
# Signing & verification (practical)
|
||||
|
||||
1. **Produce canonical payload**
|
||||
|
||||
* Serialize JSON with **RFC 8785** canonicalization (no insignificant whitespace, deterministic key order).
|
||||
2. **Wrap in DSSE**
|
||||
|
||||
* `payloadType`: `application/vnd.in-toto+json` (common) or a dedicated type string if you prefer.
|
||||
* `payload`: base64 of canonical JSON bytes.
|
||||
3. **Sign**
|
||||
|
||||
* Use **cosign** or **sigstore‑python** to sign DSSE; store in **Rekor** (transparency).
|
||||
4. **Verify**
|
||||
|
||||
* Check DSSE signature → decode predicate → verify each `old_hash`/`new_hash` against the target bytes → optionally replay `compressed_diff_b64` and re‑hash to confirm `new_hash`.
|
||||
|
||||
Policy examples you can enforce:
|
||||
|
||||
* Only allow releases whose delta predicate touches **≤ N functions** and **no control‑flow edges** outside whitelisted modules.
|
||||
* Require `tooling.lifter` in an approved set and `signed_digest.algo == "sha256"`.
|
||||
|
||||
---
|
||||
|
||||
# Why this fits your stack (Stella Ops, CI/CD, auditors)
|
||||
|
||||
* **Auditable:** function‑level intent captured, reproducible verification, deterministic hashing.
|
||||
* **Composable:** works with existing DSSE/in‑toto pipelines; attach to OCI artifacts or release manifests.
|
||||
* **Gate‑able:** let release policy check the delta surface and signer identity before promotion.
|
||||
* **Future‑proof:** can add PQC keys later without changing the predicate.
|
||||
|
||||
If you want, I can generate:
|
||||
|
||||
* A JSON Schema (`$id`, types, enums, bounds) for `stellaops/delta-sig/v1`.
|
||||
* A tiny reference **signer** (CLI) that emits canonical JSON + DSSE, and a **verifier** that checks function‑level diffs against a binary.
|
||||
647
docs/product/advisories/17-Jan-2026 - Features Gap.md
Normal file
647
docs/product/advisories/17-Jan-2026 - Features Gap.md
Normal file
@@ -0,0 +1,647 @@
|
||||
# Product Advisory: Interface Surfacing Strategy for “Hidden” Backend Capabilities
|
||||
ID: ADVISORY-20260116-IFACE-SURFACING
|
||||
Status: ACTIVE
|
||||
Owner intent: Product-wide directive
|
||||
Applies to: FEATURE_MATRIX.md, CLI, Web UI, Doctor, module dossiers, sprints
|
||||
|
||||
## 0) Why this advisory exists
|
||||
|
||||
The Feature Gaps Report shows a typical problem in fast-moving monorepos:
|
||||
- capabilities exist in code,
|
||||
- but are not surfaced in CLI/UI,
|
||||
- and therefore are not usable, not supportable, and not credibly marketable.
|
||||
This product advisory is based features discovered and documented on file FEATURE_GAPS_REPORT.md in code but not listed in FEATURE_MATRIX.md
|
||||
|
||||
Therefore, interface work must do two things:
|
||||
1) reduce support burden (“Doctor-first operability”), and
|
||||
2) strengthen the suite’s moat (evidence-grade decisions, explainability, determinism).
|
||||
|
||||
This advisory defines which backend capabilities should be surfaced via **CLI** and/or **UI**, and the minimal “how” to do it.
|
||||
|
||||
---
|
||||
|
||||
## 1) Non-negotiable principles (solo-scale rules)
|
||||
|
||||
### P1: No “capability theatre”
|
||||
If a capability is claimed in FEATURE_MATRIX.md as “available”, it must have:
|
||||
- a supported activation path (**UI or CLI or config + Doctor validation**), and
|
||||
- documentation that explains how to use it.
|
||||
|
||||
If not, it must be marked as:
|
||||
- **Automatic (always-on)**, or
|
||||
- **Internal (not supported / not marketed)**, or
|
||||
- **Planned**.
|
||||
|
||||
### P2: Prefer “exports” and “inspectors” over new UI pages
|
||||
To avoid UI explosion, surface many capabilities as:
|
||||
- **Export profiles** (downloadable artifacts)
|
||||
- **Inspector views** (read-only detail panes)
|
||||
- **Minimal admin actions** (rotate key, test connector, download SARIF)
|
||||
|
||||
Avoid building bespoke UI workflows unless they materially reduce operator labor.
|
||||
|
||||
### P3: CLI is the control plane for automation and air-gap
|
||||
Anything used in:
|
||||
- CI,
|
||||
- offline operations,
|
||||
- bulk admin,
|
||||
- reproducibility / debugging,
|
||||
must have a CLI path.
|
||||
|
||||
UI is for:
|
||||
- day-to-day operator workflows,
|
||||
- triage,
|
||||
- explainability (“why blocked?”),
|
||||
- visualizations.
|
||||
|
||||
### P4: Doctor-first for support reduction
|
||||
If a feature is likely to generate tickets (connectors, crypto, queues, replay),
|
||||
it must have:
|
||||
- a Doctor check (and a Doctor bundle payload),
|
||||
- deterministic “reason codes” for failures,
|
||||
- a runbook entry.
|
||||
|
||||
### P5: Progressive disclosure
|
||||
Don’t overwhelm users with advanced controls.
|
||||
Expose:
|
||||
- simple defaults in UI,
|
||||
- advanced knobs in CLI/config,
|
||||
- deep internals only in Doctor bundles.
|
||||
|
||||
---
|
||||
|
||||
## 2) Decision rubric: UI vs CLI vs Doc-only
|
||||
|
||||
Classify each discovered capability into exactly one of these:
|
||||
|
||||
### Class A — Automatic (Doc-only)
|
||||
Use when the capability:
|
||||
- runs implicitly as part of scan/policy/evidence workflows, and
|
||||
- doesn’t require user input to be valuable.
|
||||
|
||||
Requirement:
|
||||
- Document it in FEATURE_MATRIX.md as **Automatic**.
|
||||
- Ensure its outcomes show up in existing UI/exports (e.g., findings detail, evidence packet).
|
||||
|
||||
Examples:
|
||||
- Secrets detection that runs during scan
|
||||
- OS package analyzers invoked implicitly
|
||||
- Symlink/whiteout handling in layered filesystem
|
||||
|
||||
### Class B — CLI-first (automation/admin/offline)
|
||||
Use when the capability:
|
||||
- is primarily an operator/admin action,
|
||||
- is needed in automation/CI,
|
||||
- is needed offline,
|
||||
- or is a bulk/advanced workflow.
|
||||
|
||||
Requirement:
|
||||
- Add CLI commands with `--format json` and `--output`.
|
||||
- Update docs with copy/paste examples.
|
||||
- Add Doctor checks if it can fail due to environment dependencies.
|
||||
|
||||
Examples:
|
||||
- SBOM convert/validate
|
||||
- Key rotation, trust anchors
|
||||
- Policy verdict export
|
||||
- Timeline/HLC inspection
|
||||
|
||||
### Class C — UI-first (triage/explainability)
|
||||
Use when the capability:
|
||||
- improves human decision-making,
|
||||
- reduces triage effort,
|
||||
- is part of “why blocked/approved”.
|
||||
|
||||
Requirement:
|
||||
- Add a minimal UI surface (read-only or download action).
|
||||
- Provide deterministic “reason” traces and evidence links.
|
||||
|
||||
Examples:
|
||||
- Path witness visualization for reachability
|
||||
- SARIF download in the UI
|
||||
- Connector status dashboard
|
||||
|
||||
### Class D — Both (high-value + frequent usage)
|
||||
Use when the capability:
|
||||
- is used in pipelines (CLI), and
|
||||
- is also used in investigations/audits (UI).
|
||||
|
||||
Examples:
|
||||
- Audit bundle export
|
||||
- VEX consensus/verification
|
||||
- Evidence packs
|
||||
|
||||
### Class E — Internal (do not surface yet)
|
||||
Use when the capability:
|
||||
- is not stable enough to support,
|
||||
- would multiply permutations,
|
||||
- or is not aligned with current product focus.
|
||||
|
||||
Requirement:
|
||||
- Do not list as a primary feature in FEATURE_MATRIX.md.
|
||||
- It may remain in a “Known internal capabilities” appendix for engineering only.
|
||||
|
||||
---
|
||||
|
||||
## 3) Priority: what to surface first (P0/P1/P2)
|
||||
|
||||
### P0 (must surface) — Moat + Support reduction
|
||||
These directly improve “why blocked?”, auditability, operability, and adoption.
|
||||
|
||||
#### P0-1: Exports and evidence surfaces
|
||||
- Add/standardize CLI:
|
||||
- `stella export audit ...`
|
||||
- `stella export lineage ...`
|
||||
- `stella export risk ...`
|
||||
- `stella export evidence-pack ...`
|
||||
- UI: ensure Export Center supports:
|
||||
- download audit bundles,
|
||||
- download lineage evidence packs,
|
||||
- download risk bundles.
|
||||
|
||||
Acceptance:
|
||||
- Export outputs are deterministic, versioned, and include a manifest with hashes.
|
||||
- Doctor validates export prerequisites (storage, permissions, disk space).
|
||||
|
||||
#### P0-2: “Why blocked?” explainability completeness
|
||||
- CLI:
|
||||
- `stella score explain <digest|runId> --format json`
|
||||
- `stella reachability witness <digest> --vuln <cve> --format mermaid|json`
|
||||
- `stella reachability guards <digest> --format json`
|
||||
- UI:
|
||||
- add “Witness Path” view for reachable findings (Mermaid/GraphViz render),
|
||||
- show confidence breakdown (path/guard/runtime components),
|
||||
- link to evidence URIs (`stella://...`) and replay manifests where available.
|
||||
|
||||
Acceptance:
|
||||
- For any blocked decision, UI can show:
|
||||
- which gate blocked,
|
||||
- what evidence triggered it,
|
||||
- and at least one witness or explanation trace.
|
||||
|
||||
#### P0-3: SARIF in UI (high adoption win)
|
||||
- UI: add “Download SARIF” for a scan run and/or digest.
|
||||
- CLI already exists (`stella scan sarif`).
|
||||
|
||||
Acceptance:
|
||||
- UI downloads match CLI outputs (same schema/version).
|
||||
- Exports include metadata (digest, scan time, policy profile id).
|
||||
|
||||
#### P0-4: Concelier connector truth (reduce ticket load)
|
||||
- Docs: update FEATURE_MATRIX.md to reflect connector reality (33+ connectors).
|
||||
- UI: add a “Feeds & Connectors Status” page:
|
||||
- list connectors, last success, last error, next scheduled run (if applicable),
|
||||
- link to logs and Doctor bundle instructions.
|
||||
- CLI:
|
||||
- `stella db status`
|
||||
- `stella db connectors list`
|
||||
- `stella db connectors test <name>`
|
||||
|
||||
Acceptance:
|
||||
- Any ingestion failure has a reason code and remediation hint.
|
||||
|
||||
---
|
||||
|
||||
### P1 (next) — Admin confidence + advanced workflows
|
||||
These increase operational safety and enterprise readiness without large UI build.
|
||||
|
||||
#### P1-1: SBOM lineage CLI parity (UI already exists)
|
||||
- Add:
|
||||
- `stella sbom lineage list`
|
||||
- `stella sbom lineage show <id>`
|
||||
- `stella sbom lineage export <id> --format json|spdx|cdx`
|
||||
|
||||
#### P1-2: VEX operational completeness
|
||||
- CLI:
|
||||
- `stella vex verify <doc>`
|
||||
- `stella vex evidence export <digest|component>`
|
||||
- `stella vex webhooks list/add/remove`
|
||||
- `stella issuer keys list/create/rotate/revoke`
|
||||
- UI:
|
||||
- minimal webhook management screen (list + add/remove),
|
||||
- issuer keys page can remain UI-only if already present, but CLI needed for automation.
|
||||
|
||||
#### P1-3: Policy debug and portability
|
||||
- CLI:
|
||||
- `stella policy lattice explain ...`
|
||||
- `stella policy verdicts export ...`
|
||||
- `stella policy promote ...` (if promotion pipeline exists)
|
||||
- UI:
|
||||
- add “download verdict” and “download decision capsule” actions in policy and release views.
|
||||
|
||||
#### P1-4: Auth/admin CLI coverage
|
||||
- Add CLI wrappers for UI-only admin tasks:
|
||||
- `stella auth clients list/create/...`
|
||||
- `stella auth roles ...`
|
||||
- `stella auth scopes list`
|
||||
- `stella auth token inspect`
|
||||
- `stella auth api-keys ...`
|
||||
|
||||
---
|
||||
|
||||
### P2 (later) — Nice-to-have / heavy UI
|
||||
These can be strong, but risk expanding support and UI scope.
|
||||
|
||||
- BinaryIndex corpus ingestion UI
|
||||
- Fingerprint visualization UI
|
||||
- Evidence holds (legal hold) management UI
|
||||
- Incident mode workflows and dashboards beyond a basic toggle + export hooks
|
||||
- Full timeline UI (unless needed for core workflows)
|
||||
|
||||
---
|
||||
|
||||
## 4) Mapping: discovered gaps -> recommended surfacing
|
||||
|
||||
This section is the “agent checklist”.
|
||||
|
||||
### Batch 1: SBOM & ingestion
|
||||
- SPDX 3.0 Build Attestation
|
||||
- Class: D (Both) if used for audits; otherwise B (CLI-first)
|
||||
- CLI: `stella attest build --format spdx3 --output ...`
|
||||
- UI: Export Center adds “Build Attestation (SPDX 3.0)”
|
||||
- CycloneDX CBOM Support
|
||||
- Class: B (CLI-first) + Doc
|
||||
- CLI: `stella sbom export --type cbom --format cdx`
|
||||
- Layer SBOM composition
|
||||
- Class: B (CLI-first) + Doc
|
||||
- Ensure docs explain when/why layer SBOM is useful (base image triage, provenance).
|
||||
- SBOM advisory matching
|
||||
- Class: A (Automatic) + UI visibility
|
||||
- UI: show “matched advisory sources” in SBOM/finding details; doc-only if already visible.
|
||||
- Graph lineage service (UI exists)
|
||||
- Class: B (CLI-first) to match UI
|
||||
- CLI: `stella graph lineage show <digest|purl>`
|
||||
- SBOM validation pipeline / format conversion
|
||||
- Class: B (CLI-first)
|
||||
- CLI: `stella sbom validate`, `stella sbom convert`
|
||||
- Trivy DB export (offline)
|
||||
- Class: B (CLI-first) + optional UI under Offline Kit
|
||||
- UI: optional “download trivy db” action if it reduces ticket load.
|
||||
|
||||
### Batch 2: scanning & detection
|
||||
- Secrets detection, OS analyzers
|
||||
- Class: A (Automatic) + Document
|
||||
- Update FEATURE_MATRIX.md: “runs during scan; shown in findings”.
|
||||
- Symbol-level vulnerability matching
|
||||
- Class: C (UI-first) if it materially improves triage
|
||||
- UI: “Symbol match” tab in finding detail (no heavy workflow).
|
||||
- SARIF export
|
||||
- Class: D (Both)
|
||||
- Add UI download.
|
||||
- Concurrent worker config
|
||||
- Class: B (CLI-first)
|
||||
- CLI: `stella scanner workers set/get` or `stella scan run --workers N`.
|
||||
|
||||
### Batch 3: reachability analysis
|
||||
- Confidence calculator / EWS explanation
|
||||
- Class: D (Both)
|
||||
- CLI: `stella score explain`, `stella reachability explain`
|
||||
- UI: confidence breakdown and witness.
|
||||
- Path witness generation
|
||||
- Class: C (UI-first) + keep CLI support
|
||||
- UI: render witness (Mermaid/GraphViz).
|
||||
- Runtime signal correlation
|
||||
- Class: B (CLI-first) to complement UI
|
||||
- CLI: `stella signals inspect <digest|runId>`
|
||||
- Gate detection (guards)
|
||||
- Class: B (CLI-first) + UI is already present
|
||||
- CLI: `stella reachability guards <digest>`.
|
||||
|
||||
### Batch 4: binary analysis
|
||||
- Keep CLI-first; avoid UI until demanded.
|
||||
- Add minimal doc + optional UI download links (export fingerprint result) later.
|
||||
|
||||
### Batch 5: advisory sources / Concelier
|
||||
- Primary action: documentation correction + connector status.
|
||||
- UI: Feeds & Connectors Status page (P0).
|
||||
- CLI: connector list/status/test.
|
||||
|
||||
### Batch 6: VEX processing
|
||||
- P1: CLI for verify/evidence export/webhooks/issuer keys.
|
||||
- UI: minimal webhook mgmt + improve “consensus rationale” explainability.
|
||||
|
||||
### Batch 7: policy engine
|
||||
- P1: CLI lattice explain, verdict export, risk provider config exposure (at least in docs + config validation + Doctor).
|
||||
- UI: provide download actions; avoid building policy authoring wizard.
|
||||
|
||||
### Batch 8: attestation & signing
|
||||
- Key rotation and trust anchors:
|
||||
- Class: B (CLI-first), optionally UI later
|
||||
- CLI: `stella keys rotate`, `stella trust-anchors add/list/remove`
|
||||
- Predicate registry browser:
|
||||
- Class: B (CLI-first)
|
||||
- CLI: `stella attest predicates list`
|
||||
- Signer audit logs:
|
||||
- Class: B (CLI-first)
|
||||
- CLI: `stella sign audit export`.
|
||||
|
||||
### Batch 9: regional crypto
|
||||
- Crypto profiles and plugin health:
|
||||
- Class: B (CLI-first)
|
||||
- CLI: `stella crypto profiles list/select`, `stella crypto plugins status`
|
||||
- Doctor checks required (HSM/PKCS#11 availability, cert chains, etc.)
|
||||
|
||||
### Batch 10: evidence & findings
|
||||
- Audit bundle export:
|
||||
- Class: D (Both)
|
||||
- CLI: `stella export audit`
|
||||
- UI: ensure it’s a first-class export action.
|
||||
- Evidence holds / incident mode:
|
||||
- Class: P2 unless required by early customers; keep as internal or config-only with docs.
|
||||
|
||||
### Batch 11: determinism & replay
|
||||
- HLC inspection, timeline query, scoring explanation:
|
||||
- Class: B (CLI-first) for diagnostics
|
||||
- CLI: `stella hlc status`, `stella timeline query`, `stella score explain`.
|
||||
|
||||
### Batch 12: operations
|
||||
- Where UI exists but CLI missing:
|
||||
- Class: B (CLI-first)
|
||||
- Add:
|
||||
- `stella orchestrator jobs list/show/retry/cancel`
|
||||
- `stella orchestrator deadletter list/show/replay`
|
||||
- `stella scheduler preview`
|
||||
|
||||
### Batch 13: release orchestration
|
||||
- (When release orchestration is shipped)
|
||||
- Class: D (Both)
|
||||
- CLI parity required:
|
||||
- `stella release create/promote/rollback`
|
||||
- `stella release hooks ...`
|
||||
- `stella agent status`
|
||||
|
||||
### Batch 14: auth & access control
|
||||
- Class: B (CLI-first)
|
||||
- Add admin CLI wrappers for: scopes, clients, roles, api-keys, token inspect.
|
||||
|
||||
### Batch 15: notifications & integrations
|
||||
- UI exists; add CLI for automation/testing:
|
||||
- `stella notify channels list/test`
|
||||
- `stella notify templates list/render`
|
||||
- `stella integrations test`
|
||||
- `stella notify preferences export/import`
|
||||
|
||||
---
|
||||
|
||||
## 5) Documentation requirements (must be done alongside surfacing)
|
||||
|
||||
When surfacing a capability:
|
||||
1) Update FEATURE_MATRIX.md (and the correct category).
|
||||
2) Update the relevant module dossier (`docs/modules/<module>/architecture.md` or a dedicated guide).
|
||||
3) Add examples (copy/paste) for CLI usage and for UI navigation paths.
|
||||
4) If the capability is automatic, document where its output appears.
|
||||
|
||||
Also: do not claim “UI support” if it is “API-only”.
|
||||
|
||||
---
|
||||
|
||||
## 6) Implementation pattern (avoid interface sprawl)
|
||||
|
||||
### Preferred UI patterns
|
||||
- “Download” button for exportable artifacts (SARIF, audit bundle, evidence pack).
|
||||
- “Inspector” panels inside existing pages (Findings detail, VEX detail, Policy detail).
|
||||
- One consolidated “Ops” section for status dashboards.
|
||||
- One consolidated “Integrations” section for connectors and tests.
|
||||
|
||||
### Preferred CLI patterns
|
||||
- Command groups match product nouns:
|
||||
- `stella sbom ...`
|
||||
- `stella export ...`
|
||||
- `stella vex ...`
|
||||
- `stella policy ...`
|
||||
- `stella auth ...`
|
||||
- `stella keys ...`
|
||||
- `stella reachability ...`
|
||||
- `stella orchestrator ...`
|
||||
- Every new CLI command must support:
|
||||
- `--format json` (machine use)
|
||||
- `--output <path>` (CI use)
|
||||
- deterministic ordering and stable schemas
|
||||
|
||||
---
|
||||
|
||||
## 7) Definition of Done (interface surfacing)
|
||||
|
||||
For any interface surfacing task:
|
||||
|
||||
DOD-1: Feature matrix updated with correct classification (A/B/C/D/E)
|
||||
DOD-2: CLI/UI path implemented (as required by classification)
|
||||
DOD-3: Docs updated with copy/paste examples and screenshots where appropriate
|
||||
DOD-4: Doctor coverage added if failures are environment-dependent
|
||||
DOD-5: Determinism tests added if outputs are exported/signed/hashed
|
||||
DOD-6: Reason codes and explainability exist for decision-related features
|
||||
|
||||
---
|
||||
|
||||
## 8) Immediate next sprints (recommended)
|
||||
|
||||
1) P0 exports completeness: Export Center + `stella export ...` standardization
|
||||
2) P0 explainability: witness path UI + `stella score explain`
|
||||
3) P0 SARIF UI download
|
||||
4) P0 Feeds/connectors status UI + CLI
|
||||
5) P1 SBOM lineage CLI parity
|
||||
6) P1 VEX verify/evidence export + webhooks mgmt
|
||||
7) P1 Policy debug + verdict export
|
||||
8) P1 Admin CLI (auth/keys/crypto profiles)
|
||||
|
||||
Archive this advisory only when superseded by a newer interface strategy directive.
|
||||
|
||||
|
||||
---
|
||||
Here’s a tight UX spec you can drop into Stella Ops to make “proof‑first” triage obvious and quiet by default.
|
||||
|
||||
# Triage Card (Signed Evidence Card)
|
||||
|
||||
* **Purpose:** Show one issue = one verifiable proof bundle.
|
||||
* **Header:** vuln id + package@version + scope (image/layer/path). Right side: **Risk chip** (score + reason).
|
||||
* **One‑click “Rekor Verify”:** Runs DSSE/Sigstore verify and expands to show:
|
||||
|
||||
* ✅ signature subject/issuer, ✅ timestamp, ✅ Rekor index + raw entry (copyable), ✅ digest(s).
|
||||
* **Evidence chips:** OpenVEX status (affected/not_affected), patch proof (binary/backport), reachability (stack path), EPSS band.
|
||||
* **Actions:** “Explain” (AI note), “Create task,” “Mute (reasoned),” “Export evidence (.dsse)”.
|
||||
* **Micro‑interactions:**
|
||||
|
||||
* Hover on chips → mini‑tooltip with why.
|
||||
* Copy icons on digests/Rekor IDs.
|
||||
* Keyboard shortcuts: `v` verify, `e` export, `m` mute.
|
||||
|
||||
# Binary‑Diff Panel
|
||||
|
||||
* **Purpose:** Prove fixes at the **binary** level, not just SBOM claims.
|
||||
* **Scope selector:** `file → section → function`.
|
||||
* **Layers:** Base vs candidate (or pre‑ vs post‑patch) with inline diff.
|
||||
* **Hashes:** Per‑file SHA‑256, per‑section, per‑function rolling hashes.
|
||||
* **Context:** CWE + symbol names, addresses, and relocation notes.
|
||||
* **Artifacts:**
|
||||
|
||||
* **Export “Signed Diff”** → DSSE envelope (hash map + metadata + signer + timestamp).
|
||||
* Attach to the triage card as “Patch proof”.
|
||||
* **Micro‑interactions:**
|
||||
|
||||
* Click on symbol in call‑graph to jump to function diff.
|
||||
* Toggle opcodes ⇄ decompiled view (if available).
|
||||
* “Show only changed blocks” toggle.
|
||||
|
||||
# Quiet/Accessible Filter Strip
|
||||
|
||||
* **Purpose:** Deterministic, low‑noise prioritization—no casino lights.
|
||||
* **Precedence toggles (left→right strongest to weakest):**
|
||||
|
||||
1. **OpenVEX** (not_affected/affected)
|
||||
2. **Patch proof present**
|
||||
3. **Reachability** (call‑path to runtime)
|
||||
4. **EPSS** (≥ threshold)
|
||||
* **Determinism:** When ties occur, sort by OCI digest, then path, then CVSS.
|
||||
* **Controls:**
|
||||
|
||||
* EPSS slider; “Only reachable” checkbox; “Only with patch proof” checkbox.
|
||||
* “Deterministic order” lock icon (on by default).
|
||||
* **A11y:** High‑contrast theme, focus rings, full keyboard nav, prefers‑reduced‑motion honored; all chips have aria‑labels.
|
||||
* **Micro‑interactions:** Filters update counts without reflow; announcement region reads changes.
|
||||
|
||||
---
|
||||
|
||||
## Why this matters
|
||||
|
||||
* **Trustable triage:** Users see cryptographic evidence (signatures, Rekor entries, per‑function hashes), not just scanner claims.
|
||||
* **Noise‑free:** Precedence rules (OpenVEX → patch proof → reachability → EPSS) cut alert fatigue predictably.
|
||||
* **Audit‑ready:** Every click can emit an exportable **DSSE‑signed** artifact for tickets, audits, and vendors.
|
||||
|
||||
---
|
||||
|
||||
## Minimal data model additions
|
||||
|
||||
* `EvidencePacket { sbom_ref, dsse_envelope, rekor_index, signer, timestamp }`
|
||||
* `BinaryProof { file_hashes[], section_hashes[], function_hashes[], diff_summary }`
|
||||
* `TriageMeta { openvex_status, reachability_path[], epss_score, precedence_tuple }`
|
||||
|
||||
---
|
||||
|
||||
## Done‑means‑Done checks
|
||||
|
||||
* Triage card verify shows **raw Rekor JSON** + signature details.
|
||||
* Binary‑diff export produces a DSSE file that re‑verifies offline.
|
||||
* Filter strip yields identical ordering given the same inputs (golden test).
|
||||
* Keyboard‑only usage covers: open card, verify, export, toggle filters, navigate diffs.
|
||||
|
||||
Want me to turn this into three Figma‑ready wireframes (with exact layout specs and aria‑labels), or generate sample DSSE envelopes + Rekor verify outputs so your team can test end‑to‑end?
|
||||
|
||||
--
|
||||
Here’s a tight, practical first pass for a **“doctor” setup wizard** that runs right after install and anytime from Settings → Diagnostics. It gives instant confidence that Stella Ops is wired correctly, without needing full integrations configured.
|
||||
|
||||
---
|
||||
|
||||
# What the “doctor” does (in plain terms)
|
||||
|
||||
It runs a few lightweight health checks to confirm your system can:
|
||||
|
||||
* talk to its database,
|
||||
* reach its attestation store (for signed proofs),
|
||||
* verify a sample artifact end‑to‑end (SBOM + VEX).
|
||||
|
||||
If these pass, your install is sound and you can add integrations later at your pace.
|
||||
|
||||
---
|
||||
|
||||
# Mandatory checks (first pass)
|
||||
|
||||
1. **DB connectivity + schema version**
|
||||
|
||||
* **Why**: If the DB is unreachable or the schema is outdated, nothing else matters.
|
||||
* **Checks**:
|
||||
|
||||
* TCP/connect to Postgres URI.
|
||||
* `SELECT 1;` liveness.
|
||||
* Read `schema_version` from `stella.meta` (or your flyway/liquibase table).
|
||||
* Compare to the app’s expected version; warn if migrations pending.
|
||||
* **CLI sketch**:
|
||||
|
||||
```bash
|
||||
stella doctor db \
|
||||
--url "$STELLA_DB_URL" \
|
||||
--expect-schema "2026.01.0"
|
||||
```
|
||||
* **Pass criteria**: reachable + current (or actionable “run migrations” hint).
|
||||
|
||||
2. **Attestation store availability (Rekor/Cosign)**
|
||||
|
||||
* **Why**: Stella relies on signed evidence; if the ledger/store isn’t reachable, you can’t prove integrity.
|
||||
* **Checks**:
|
||||
|
||||
* Resolve/HTTP 200 for Rekor base URL (or your mirror).
|
||||
* Cosign key material present (KMS, keyless, or offline bundle).
|
||||
* Clock skew sanity (<5s) for signature verification.
|
||||
* **CLI sketch**:
|
||||
|
||||
```bash
|
||||
stella doctor attest \
|
||||
--rekor-url "$STELLA_REKOR_URL" \
|
||||
--cosign-key "$STELLA_COSIGN_KEY" \
|
||||
--mode "online|offline"
|
||||
```
|
||||
* **Pass criteria**: ledger reachable (or offline bundle found) + keys valid.
|
||||
|
||||
3. **Artifact verification pipeline run (SBOM + VEX sample)**
|
||||
|
||||
* **Why**: Proves the *whole* trust path works—fetch, verify, evaluate policy.
|
||||
* **Checks**:
|
||||
|
||||
* Pull a tiny, known test artifact by **digest** (immutable).
|
||||
* Verify signature/attestations (DSSE in Rekor or offline bundle).
|
||||
* Fetch/validate **SBOM** (CycloneDX/SPDX) and a sample **VEX**.
|
||||
* Run policy engine: “no‑go if critical vulns without VEX justification.”
|
||||
* **CLI sketch**:
|
||||
|
||||
```bash
|
||||
stella doctor verify \
|
||||
--artifact "oci://registry.example/test@sha256:deadbeef..." \
|
||||
--require-sbom \
|
||||
--require-vex
|
||||
```
|
||||
* **Pass criteria**: signature + SBOM + VEX validate; policy engine returns ✅.
|
||||
|
||||
---
|
||||
|
||||
# Output & UX
|
||||
|
||||
* **One‑screen summary** with green/yellow/red statuses and terse fixes.
|
||||
* **Copy‑paste remediations** (DB URI example, Rekor URL, cosign key path).
|
||||
* **Evidence links** (e.g., “View attestation entry” or “Open policy run”).
|
||||
* **Export**: `stella doctor --json > doctor-report.json` for support.
|
||||
|
||||
---
|
||||
|
||||
# Where this fits in the installer/wizard
|
||||
|
||||
* **UI & CLI** both follow the same steps:
|
||||
|
||||
1. DB setup → quick migration → **Doctor: DB**
|
||||
2. Choose attestation mode (Rekor/cosign keyless/offline bundle) → **Doctor: Attest**
|
||||
3. Minimal “verification pipeline” config (test registry creds or bundled sample) → **Doctor: Verify**
|
||||
* Each step has **defaults** (Postgres + Rekor URL + bundled demo artifact) and a **“Skip for now”** with a reminder tile in Settings → Integrations.
|
||||
|
||||
---
|
||||
|
||||
# Failure → Suggested fixes (examples)
|
||||
|
||||
* **DB schema mismatch** → “Run `stella migrate up` to 2026.01.0.”
|
||||
* **Rekor unreachable** → “Check DNS/proxy; or switch to Offline Attestations in Settings.”
|
||||
* **Cosign key missing** → “Add key (KMS/file) or enable keyless; see Keys → Add.”
|
||||
* **SBOM/VEX missing** → “Enable ‘Generate SBOM on build’ and ‘Collect VEX from vendors’, or load a demo bundle.”
|
||||
|
||||
---
|
||||
|
||||
# Next steps (beyond first pass)
|
||||
|
||||
* Optional checks the wizard can add later:
|
||||
|
||||
* **Registry** reachability (pull by digest).
|
||||
* **Settings store** (Valkey cache reachability).
|
||||
* **Notifications** (send test webhook/email).
|
||||
* **SCM/Vault/LDAP** plugin stubs: ping + auth flow (but not required to pass install).
|
||||
|
||||
If you want, I can turn this into:
|
||||
|
||||
* a ready‑to‑ship **CLI command spec**,
|
||||
* a **UI wireframe** of the three-step doctor,
|
||||
* or **JSON schemas** for the doctor’s machine‑readable report.
|
||||
202
docs/product/advisories/17-Jan-2026 - The AI Economics Moat.md
Normal file
202
docs/product/advisories/17-Jan-2026 - The AI Economics Moat.md
Normal file
@@ -0,0 +1,202 @@
|
||||
# Product Advisory: AI Economics Moat
|
||||
ID: ADVISORY-20260116-AI-ECON-MOAT
|
||||
Status: ACTIVE
|
||||
Owner intent: Product-wide directive
|
||||
Scope: All modules, docs, sprints, and roadmap decisions
|
||||
|
||||
## 0) Thesis (why this advisory exists)
|
||||
|
||||
In AI economics, code is cheap, software is expensive.
|
||||
|
||||
Competitors (and future competitors) can produce large volumes of code quickly. Stella Ops must remain hard to catch by focusing on the parts that are still expensive:
|
||||
- trust
|
||||
- operability
|
||||
- determinism
|
||||
- evidence integrity
|
||||
- low-touch onboarding
|
||||
- low support burden at scale
|
||||
|
||||
This advisory defines the product-level objectives and non-negotiable standards that make Stella Ops defensible against "code producers".
|
||||
|
||||
## 1) Product positioning (the class we must win)
|
||||
|
||||
Stella Ops Suite must be "best in class" for:
|
||||
|
||||
Evidence-grade release orchestration for containerized applications outside Kubernetes.
|
||||
|
||||
Stella is NOT attempting to be:
|
||||
- a generic CD platform (Octopus, GitLab, Jenkins replacements)
|
||||
- a generic vulnerability scanner (Trivy, Grype replacements)
|
||||
- a "platform of everything" with infinite integrations
|
||||
|
||||
The moat is the end-to-end chain:
|
||||
digest identity -> evidence -> verdict -> gate -> promotion -> audit export -> deterministic replay
|
||||
|
||||
The product wins when customers can run verified releases with minimal human labor and produce auditor-ready evidence.
|
||||
|
||||
## 2) Target customer and adoption constraint
|
||||
|
||||
Constraint: founder operates solo until ~100 paying customers.
|
||||
|
||||
Therefore, the product must be self-serve by default:
|
||||
- install must be predictable
|
||||
- failures must be diagnosable without maintainer time
|
||||
- docs must replace support
|
||||
- "Doctor" must replace debugging sessions
|
||||
|
||||
Support must be an exception, not a workflow.
|
||||
|
||||
## 3) The five non-negotiable product invariants
|
||||
|
||||
Every meaningful product change MUST preserve and strengthen these invariants:
|
||||
|
||||
I1. Evidence-grade by design
|
||||
- Every verified decision has an evidence trail.
|
||||
- Evidence is exportable, replayable, and verifiable.
|
||||
|
||||
I2. Deterministic replay
|
||||
- Same inputs -> same outputs.
|
||||
- A verdict can be reproduced and verified later, not just explained.
|
||||
|
||||
I3. Digest-first identity
|
||||
- Releases are immutable digests, not mutable tags.
|
||||
- "What is deployed where" is anchored to digests.
|
||||
|
||||
I4. Offline-first posture
|
||||
- Air-gapped and low-egress environments must remain first-class.
|
||||
- No hidden network dependencies in core flows.
|
||||
|
||||
I5. Low-touch operability
|
||||
- Misconfigurations fail fast at startup with clear messages.
|
||||
- Runtime failures have deterministic recovery playbooks.
|
||||
- Doctor provides actionable diagnostics bundles and remediation steps.
|
||||
|
||||
If a proposed feature weakens any invariant, it must be rejected or redesigned.
|
||||
|
||||
## 4) Moats we build (how Stella stays hard to catch)
|
||||
|
||||
M1. Evidence chain continuity (no "glue work" required)
|
||||
- Scan results, reachability proofs, policy evaluation, approvals, promotions, and exports are one continuous chain.
|
||||
- Do not require customers to stitch multiple tools together to get audit-grade releases.
|
||||
|
||||
M2. Explainability with proof, not narrative
|
||||
- "Why blocked?" must produce a deterministic trace + referenced evidence artifacts.
|
||||
- The answer must be replayable, not a one-time explanation.
|
||||
|
||||
M3. Operability moat (Doctor + safe defaults)
|
||||
- Diagnostics must identify root cause, not just symptoms.
|
||||
- Provide deterministic checklists and fixes.
|
||||
- Every integration must ship with health checks and failure-mode docs.
|
||||
|
||||
M4. Controlled surface area (reduce permutations)
|
||||
- Ship a small number of Tier-1 golden integrations and targets.
|
||||
- Keep the plugin system as an escape valve, but do not expand the maintained matrix beyond what solo operations can support.
|
||||
|
||||
M5. Standards-grade outputs with stable schemas
|
||||
- SBOM, VEX, attestations, exports, and decision records must be stable, versioned, and backwards compatible where promised.
|
||||
- Stability is a moat: auditors and platform teams adopt what they can depend on.
|
||||
|
||||
## 5) Explicit non-goals (what to reject quickly)
|
||||
|
||||
Reject or de-prioritize proposals that primarily:
|
||||
- add a generic CD surface without evidence and determinism improvements
|
||||
- expand integrations broadly without a "Tier-1" support model and diagnostics coverage
|
||||
- compete on raw scanner breadth rather than evidence-grade gating outcomes
|
||||
- add UI polish that does not reduce operator labor or support load
|
||||
- add "AI features" that create nondeterminism or require external calls in core paths
|
||||
|
||||
If a feature does not strengthen at least one moat (M1-M5), it is likely not worth shipping now.
|
||||
|
||||
## 6) Agent review rubric (use this to evaluate any proposal, advisory, or sprint)
|
||||
|
||||
When reviewing any new idea, feature request, PRD, or sprint, score it against:
|
||||
|
||||
A) Moat impact (required)
|
||||
- Which moat does it strengthen (M1-M5)?
|
||||
- What measurable operator/auditor outcome improves?
|
||||
|
||||
B) Support burden risk (critical)
|
||||
- Does this increase the probability of support tickets?
|
||||
- Does Doctor cover the new failure modes?
|
||||
- Are there clear runbooks and error messages?
|
||||
|
||||
C) Determinism and evidence risk (critical)
|
||||
- Does this introduce nondeterminism?
|
||||
- Are outputs stable, canonical, and replayable?
|
||||
- Does it weaken evidence chain integrity?
|
||||
|
||||
D) Permutation risk (critical)
|
||||
- Does this increase the matrix of supported combinations?
|
||||
- Can it be constrained to a "golden path" configuration?
|
||||
|
||||
E) Time-to-value impact (important)
|
||||
- Does this reduce time to first verified release?
|
||||
- Does it reduce time to answer "why blocked"?
|
||||
|
||||
If a proposal scores poorly on B/C/D, it must be redesigned or rejected.
|
||||
|
||||
## 7) Definition of Done (feature-level) - do not ship without the boring parts
|
||||
|
||||
Any shippable feature must include, at minimum:
|
||||
|
||||
DOD-1: Operator story
|
||||
- Clear user story for operators and auditors, not just developers.
|
||||
|
||||
DOD-2: Failure modes and recovery
|
||||
- Documented expected failures, error codes/messages, and remediation steps.
|
||||
- Doctor checks added or extended to cover the common failure paths.
|
||||
|
||||
DOD-3: Determinism and evidence
|
||||
- Deterministic outputs where applicable.
|
||||
- Evidence artifacts linked to decisions.
|
||||
- Replay or verify path exists if the feature affects verdicts or gates.
|
||||
|
||||
DOD-4: Tests
|
||||
- Unit tests for logic (happy + edge cases).
|
||||
- Integration tests for contracts (DB, queues, storage where used).
|
||||
- Determinism tests when outputs are serialized, hashed, or signed.
|
||||
|
||||
DOD-5: Documentation
|
||||
- Docs updated where the feature changes behavior or contracts.
|
||||
- Include copy/paste examples for the golden path usage.
|
||||
|
||||
DOD-6: Observability
|
||||
- Structured logs and metrics for success/failure paths.
|
||||
- Explicit "reason codes" for gate decisions and failures.
|
||||
|
||||
If the feature cannot afford these, it cannot afford to exist in a solo-scaled product.
|
||||
|
||||
## 8) Product-level metrics (what we optimize)
|
||||
|
||||
These metrics are the scoreboard. Prioritize work that improves them.
|
||||
|
||||
P0 metrics (most important):
|
||||
- Time-to-first-verified-release (fresh install -> verified promotion)
|
||||
- Mean time to answer "why blocked?" (with proof)
|
||||
- Support minutes per customer per month (must trend toward near-zero)
|
||||
- Determinism regressions per release (must be near-zero)
|
||||
|
||||
P1 metrics:
|
||||
- Noise reduction ratio (reachable actionable findings vs raw findings)
|
||||
- Audit export acceptance rate (auditors can consume without manual reconstruction)
|
||||
- Upgrade success rate (low-friction updates, predictable migrations)
|
||||
|
||||
## 9) Immediate product focus areas implied by this advisory
|
||||
|
||||
When unsure what to build next, prefer investments in:
|
||||
- Doctor: diagnostics coverage, fix suggestions, bundles, and environment validation
|
||||
- Golden path onboarding: install -> connect -> scan -> gate -> promote -> export
|
||||
- Determinism gates in CI and runtime checks for canonical outputs
|
||||
- Evidence export bundles that map to common audit needs
|
||||
- "Why blocked" trace quality, completeness, and replay verification
|
||||
|
||||
Avoid "breadth expansion" unless it includes full operability coverage.
|
||||
|
||||
## 10) How to apply this advisory in planning
|
||||
|
||||
When processing this advisory:
|
||||
- Ensure docs reflect the invariants and moats at the product overview level.
|
||||
- Ensure sprints and tasks reference which moat they strengthen (M1-M5).
|
||||
- If a sprint increases complexity without decreasing operator labor or improving evidence integrity, treat it as suspect.
|
||||
|
||||
Archive this advisory only if it is superseded by a newer product-wide directive.
|
||||
Reference in New Issue
Block a user