Integrations
Connect the sources that make release decisions possible
Build and scan evidence needs no connector at all — the CLI signs it inside your build job.
Four categories of sources feed release decisions: registries, pipeline evidence, advisory and VEX data, and secrets. All of them land on the same custody spine — Source → Build → Scan → Verdict → Decision → Deploy → Watch.
Connectors are not the moat
Pipeline evidence (CLI): This category is not a connector — deliberately. Build and scan evidence needs no SCM connector, no CI connector, and no inbound webhook: the CLI runs inside your existing pipeline and pushes signed evidence out.
Connectors are the least defensible layer here by design — any vendor can match a logo grid. What they feed is harder to copy: evidence signed at its source, verified by the control plane, and replayable later. Compare the chain, not the checklist.
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 CLI ships as a pinned container image, so there is nothing to install on the runner. registry.stella-ops.org/stella-cli:v1.0 pulls anonymously — no credentials, no CI/CD variable, just outbound access to the registry. Runners without that egress point STELLA_CLI_IMAGE at an internal mirror instead.
$ docker run --rm \
-e STELLA_OCI_REGISTRY_USERNAME="$CI_REGISTRY_USER" \
-e STELLA_OCI_REGISTRY_PASSWORD="$CI_JOB_TOKEN" \
-v "$CI_PROJECT_DIR:/src:ro" \
registry.stella-ops.org/stella-cli:v1.0 \
sbom attach --generate --reachability --reachability-source /src \
--image "$IMAGE_REF" --digest "$IMAGE_DIGEST" \
--commit "$CI_COMMIT_SHA" --repo-url "$CI_PROJECT_URL" \
--source-id "gitlab-cr/$CI_PROJECT_PATH"
Commands as shown in the product console (v1.0-RC1).
The source tree is mounted read-only at /src so the reachability extractor can read the code that produced the image; the container runs as a non-root user. Registry credentials are read from the environment only — the CLI refuses them as arguments, so they cannot leak into build logs or process listings.
Start advisory. In the pipeline this example comes from, every Stella step ends in || echo … (non-fatal): the build stays green whether or not the evidence lands, so a team can adopt the step before it trusts it. Enforcing is a separate decision, made later — not a precondition for starting.
Once the evidence is attached, a later stage can block on it: stella gate evaluate --env staging --image sha256:… asks whether that digest may enter an environment.
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.
Evidence travels outbound. The CLI signs the build attestation and pushes it from inside the job; the control plane never reaches in to collect it.
stella ci init scaffolds ready-made pipeline files for GitHub, GitLab, and Gitea today. Every other CI system calls the same CLI directly — the commands are identical, only the YAML around them differs.
Suggested setup order
- 1 Registries — where images and digests come from
- 2 Pipeline evidence (CLI) — signed inside the build job, no connector needed
- 3 Advisory & VEX sources — what keeps verdicts current
- 4 Secrets — what the other integrations authenticate with
The order the product's Integrations hub suggests.
The four sources a release decision runs on
Registries
The container sources Stella discovers, scans, versions, and promotes. The digest is the identity everything else binds to. Watch for new digests and pull images for scanning and promotion. Digest-firstRelease identity based on immutable content hashes (SHA-256 digests) rather than mutable tags — ensuring byte-identical deployments
Docker Hub · Harbor · AWS ECR · Google GCR / Artifact Registry · Azure ACR · Any OCIOpen Container Initiative — the industry standard for container image formats and registries-compliant registry — Anything that speaks the OCIOpen Container Initiative — the industry standard for container image formats and registries distribution spec works.
Pipeline evidence via CLI
The CLI scans each build and signs a build attestation (DSSEDead Simple Signing Envelope - a simple, flexible standard for signing arbitrary data with cryptographic signatures) inside the job. Your pipeline pushes the evidence out; the control plane does not reach into your build system to collect it.
Advisory & VEX sources
Advisory feeds: NVDNational Vulnerability Database - the U.S. government repository of standards-based vulnerability data + OSVOpen Source Vulnerabilities - a distributed vulnerability database for open source projects + GHSAGitHub Security Advisories - security vulnerability database for packages on GitHub · CISACybersecurity and Infrastructure Security Agency - U.S. federal agency responsible for cybersecurity guidance and vulnerability catalogs KEVKnown Exploited Vulnerabilities - CISA's catalog of vulnerabilities actively exploited in the wild · National CERTsComputer Emergency Response Teams - regional cybersecurity organizations that publish vulnerability advisories · Vendor feeds. See the full source breakdown →
VEX ingestion: Ingest and produce VEXVulnerability Exploitability eXchange - machine-readable statements about whether vulnerabilities are actually exploitable in your context statements for multi-issuer trust resolution. OpenVEXAn open standard format for VEX statements about vulnerability exploitability · CSAF 2.0 · Custom issuers. Custom issuers: Vendor-published VEXVulnerability Exploitability eXchange - machine-readable statements about whether vulnerabilities are actually exploitable in your context with configurable trust weights. SBOM & VEX →
CSAF 2.0: Common Security Advisory Framework for structured advisories.
Secrets
Credential stores that downstream integrations read from. Registry and deploy connectors hold a secret reference — never the credential itself.
Built-in secrets store · HashiCorp Vault · Azure Key Vault · AWS Secrets Manager · HSM / PKCS#11. Built-in secrets store: Registry and deploy credentials live in the secrets store and are injected at execution time. Secret values do not appear in evidence or capsules.
Advisory & VEX sources
38 active advisory sources feed vulnerability evaluation — the count is live on the product's Feed Status screen. Feed freshness drives re-evaluation: when a source updates, affected verdicts are re-evaluated instead of standing on stale data.
Conflicting VEX statements are resolved through a documented five-state lattice, and the resolution itself is recorded as evidence.
Deployment Targets
Deploy gated releases to non-Kubernetes infrastructure.
Docker Compose · SSH (Linux/Unix) · WinRM (Windows) · AWS / Fargate · HashiCorp · Scripted (.NET 10)
Deployment targets are unlimited on every tier. Tiers meter environments and new-digest scans — never targets.
The non-Kubernetes operating model Agentless SSH and WinRM deployment See drift across the whole estate
Who can sign in
The default setup uses local users held by Stella Ops. Passwords are hashed with Argon2id.
SAML, OIDC and LDAP/Active Directory connectors ship signed with the platform, and the install bundle carries a configuration file for each. Enabling one is an operator configuration step, not a default.
All access is tenant-scoped. A user acts inside one tenant, and roles are evaluated within that boundary. TenantAn isolated workspace with its own users, roles, policies, and evidence history. Tenants share an installation; evidence and access are separated per tenant, and suspending a tenant freezes all of its access
Scoped by construction: Your access is bounded to four things. Broad operator or approver rights are never a prerequisite for shipping your own service.
- Your services You see and update the services assigned to you, not the whole estate.
- Your repositories Access follows the repositories bound to your services. Other teams' repositories are outside your scope.
- Your image namespaces Candidate digests are accepted from the image namespaces bound to your service, not from anywhere in the registry.
- Your environments You act only in the environments your role permits — direct update or promotion request, decided per environment.
Self-service requires your platform team to enable it for each environment. Where it is off, your path is a promotion request to the approvers. Stella shows which environments you may touch; it never widens that set on its own.
Go deeper
Ready to connect your toolchain?
Stella Ops works with what you already have. Start with a single registry and expand from there.