Features
Technical mechanisms behind defensible release decisions
Stella combines scan evidence, reachability context, VEX statements, and approval policy into one digest-first control path for non-Kubernetes releases.
- → Reachability-first triage - prioritize exploitable CVEs instead of total CVE count
- → Deterministic replay - reproduce historical verdicts with frozen inputs and matching output
- → Signed Decision Capsules - export verifiable evidence for audit and incident review
What this means for your business
Reduce reachable-CVE triage queues, keep promotion verdicts reproducible, and move audit response from narrative reconstruction to signature and replay verification.
Proof anchors
Each claim links to inspectable evidence artifacts, replay workflow, and specification docs.
What you can validate in 30 minutes
Install
Docker Compose deployment
Scan
SBOM plus reachability
Promote
Dev -> Staging gate
Export
Signed Decision Capsule
Why promotion decisions are defensible
SBOM and VEX with conflict-aware consensus
Generate SPDX/CycloneDX SBOMs, ingest multi-issuer OpenVEX, and resolve conflicting assertions with deterministic K4 lattice logic. SBOMSoftware Bill of Materials - a complete list of all packages and dependencies in your software VEXVulnerability Exploitability eXchange - machine-readable statements about whether vulnerabilities are actually exploitable in your context
- → Generate
SPDXSoftware Package Data Exchange - another open standard format for SBOMs, widely used in open source3.0.1 andCycloneDXAn open standard format for software bill of materials (SBOM) used across the industry1.7 SBOMs from container images - → Ingest multi-issuer
OpenVEXAn open standard format for VEX statements about vulnerability exploitabilityand resolve conflicts with deterministic K4 lattice logic - → Match CVEs across 30+ advisory sources with fast warm-path scans
Reachability-backed risk decisions
Combine static call graphs, binary symbols, and runtime eBPF probes to prove which CVEs are reachable in real execution paths. ReachabilityAnalysis that proves whether vulnerable code is actually called by your application — filtering out false positives from scanner noise
- → Three-layer analysis: static call graphs, binary symbols, and runtime
eBPFExtended Berkeley Packet Filter — a Linux kernel technology that runs sandboxed programs for high-performance observability and runtime analysis without kernel modulesprobes - → Signed
DSSEDead Simple Signing Envelope - a simple, flexible standard for signing arbitrary data with cryptographic signaturesproofs that bind findings to executable paths - → Focus on reachable CVEs instead of inflated theoretical counts
Digest-pinned release identity
Resolve every release to immutable OCI digests at creation time so tags remain aliases and pulls remain tamper-detectable.
- → Release identity is an immutable
OCIOpen Container Initiative — the industry standard for container image formats and registriesdigest set fixed at creation time - → Tags stay aliases; digests remain source of truth
- → Audit history shows exactly what ran, where, and when
Agentless deployment for non-Kubernetes targets
Deploy over SSH/WinRM to Linux and Windows using canary, rolling, or blue-green strategies, with rollback to known-good digests.
- → Deploy to Docker Compose, Swarm, ECS, Nomad, or scripted hosts
- → Agentless SSH (Linux) and WinRM (Windows) execution
- → Canary, rolling, and blue-green strategies with fast rollback
Why technical buyers choose Stella
Most tools stop at findings or deployment. Stella records the decision path and the proof.
Evidence, Not Assertions
Every promotion emits signed evidence that auditors can verify independently without vendor lock-in.
Non-Kubernetes First
Docker Compose, ECS, Nomad, and scripted hosts are first-class targets, not edge cases.
Deterministic Replay
Re-run any decision with frozen inputs and verify bit-for-bit identical output.
Sovereign & Offline
Run fully air-gapped with signed feed bundles and customer-controlled key infrastructure.
How Stella compares by architecture
Compare tools by deployment model, evidence model, and operational fit.
| Tool | Category | Key Difference | |
|---|---|---|---|
| Trivy / Grype | Scanners | Strong findings scanner; no promotion orchestration or signed decision replay | Compare → |
| Snyk | SCASoftware Composition Analysis — automated scanning of third-party and open-source components for known vulnerabilities and license risks Platform | Strong SaaS security platform; limited sovereign/offline release control | Compare → |
| Octopus Deploy | CD Platform | Strong deployment automation; no built-in reachability-driven security evidence chain | Compare → |
| GitHub Actions | CI/CD | Excellent CI automation; not a dedicated release evidence control plane | Compare → |
| Harness | CD Platform | Powerful CD platform; primarily Kubernetes-first with limited non-Kubernetes evidence model | Compare → |
Run your first digest through Stella
Run one digest through scan, gate, promotion, and replay; measure reachable-CVE reduction, replay match, and audit packet generation time.