From artifact digest to living proof
Every release moves along one spine. Each stage holds evidence tied to the artifact digest, and each stage is in exactly one state: Missing, Recorded, or Signed. After deploy, Watch keeps checking that the proof still holds.
After first setup, you can validate:
- 1. Filter vulnerability backlog down to reachable-risk findings for a real artifact
- 2. Export a signed
Decision CapsuleA signed, exportable evidence bundle that seals every input and output of a release decision for offline audit and deterministic replayfor each promotion decision - 3. Replay the same decision later with frozen inputs and matching verdict
Control-plane role in your toolchain
CI builds and tests artifacts. Stella evaluates promotion eligibility, deploys to non-Kubernetes targets (Compose, SSH/WinRM), and preserves cryptographically verifiable decision records without replacing existing CI tooling.
Gate from any CI/CD system
Whatever runs your deployments — Jenkins, Octopus steps, GitLab CI, GitHub Actions, a shell script on a build box — gates on Stella the same way: add a stage that runs the CLI.
The command exits non-zero when the gate blocks, so the stage fails and the pipeline stops. There is nothing else to wire up: no inbound webhook, no callback URL, no network path from Stella into your build system.
The signature happens at the build, so the evidence does not depend on which CI produced it.
Four input categories feed the spine. Evidence is signed where it is produced, then verified by the control plane.
Registries · Pipeline evidence via CLI · Advisory & VEX sources · Secrets — Every source named, and what each one feeds →
The custody spine
Seven stages, one artifact digest. This is the page you open when someone asks what is running and why it was allowed. Watch it run · 4 min
Every stage is in exactly one of three states:
MISSING
No evidence exists for this stage. It reports MISSING until evidence arrives.
RECORDED
Evidence exists and is bound to the artifact digest, but is not yet signed.
SIGNED
Evidence carries a DSSEDead Simple Signing Envelope - a simple, flexible standard for signing arbitrary data with cryptographic signatures signature and can be verified offline.
- 1
Source
The commit and repository the artifact claims to come from, recorded from your pipeline — never inferred.
- 2
- 3
Scan
SBOMSoftware Bill of Materials - a complete list of all packages and dependencies in your softwareand vulnerability analysis bound to that exact digest. A new digest means a new scan; results are never carried over to a build they were not made from. - 4
- 5
Decision
The gate outcome and any human approval, recorded with the exact policy version that produced it.
- 6
Deploy
The rollout of the approved digest to a named environment: what ran, where, and when.
- 7
Watch
Continuous comparison of running digests against approved digests. Drift is detected, not assumed away.
Gate evaluation: reachable risk, not raw counts
Gates evaluate signed findings against a versioned policy. ReachabilityAnalysis that proves whether vulnerable code is actually called by your application — filtering out false positives from scanner noise narrows what blocks to findings on a path your code can execute. It covers Go, Java, C#/.NET, JavaScript and TypeScript, Python, Rust, PHP and Ruby; findings outside those languages stay in the working set — they are not marked unreachable by default.
On the demo Exposure screen: 7 findings → 1 blocking (reachable × unfixed). That one stops the release. The other six stay visible, one filter away.
Context: ~85% of critical container vulnerabilities are in inactive code (Sysdig 2024 Container Security Report).
$ stella gate evaluate --env staging --image sha256:8c1a4f…
Commands as shown in the product console (v1.0-RC1).
A check that could not run is reported as NOT EVALUATED and recorded in the verdict. It is never counted as a pass.
What blocks shipping — reachable, unfixed, policy-relevant exposure first. The long tail is one filter away.
Every failed check names the rule that fired, the evidence it read, and the finding behind it. The answer is in the verdict — not in re-running scanners or a message thread with the security team. “Why is my release blocked?” →
If Stella Ops is unreachable, the gate blocks.
A scanner or policy-engine timeout is treated as a failure by design rather than waved through, and there is no fail-open flag anywhere in the CLI. An artifact whose scan result cannot be retrieved does not deploy.
Releasing during an outage is a deliberate, accountable act rather than a workaround: a signed, scoped, time-limited exception, recorded against the operator who took it, and configured before first use.
Proof anchors
Each claim links to inspectable evidence artifacts, replay workflow, and specification docs.
Proof and methodology links: Evidence and Audit | Decision Capsule spec | Operations and Deployment
Deploy: approved digests to non-Kubernetes targets
The Deploy stage rolls the approved digest out and records what went where. Targets are the estates most release tooling ignores.
- → Docker Compose projects
- → SSH/WinRM hosts — agentless by design
- → Rolling, canary, and blue-green strategies
- → Rollback re-points to a known-good digest whose evidence is already on file
- → Every deploy records digest, environment, and time
A rollback is a verified deploy of an already-approved digest, not an exception to the process.
Operations and Deployment · Deploy to Servers Without Installing Agents
Watch: the proof has to keep holding
Approval is a point in time. After deploy, Watch compares every running digest against the approved digest for that service and environment. Nothing is installed on your hosts for either step: the Stella Ops agent service runs inside your own Stella installation, deploys over SSH, WinRM or Compose, and reads what is running through the Docker API on the daemons it can reach.
Drift, as the product defines it:
“running digest is not an approved/deployed digest (unapproved or altered image)”
Environments Stella cannot observe are shown as unproven, never assumed healthy.
The unit Watch observes is the container, identified by image digest — so drift detection covers containerised workloads on your hosts, whether they run on Docker over SSH, Compose, or a Windows daemon.
The boundary, stated plainly: what runs outside a container is outside Watch's proof. Files, services or executables deployed to a bare host carry deployment evidence — who deployed what, when, from which digest-identified release — but they are not continuously re-verified by image digest.
Go deeper
What Stella connects to Architecture path What audit and compliance teams receive