Frequently Asked Questions

Stella Ops isn't just another container scanner—it's a different product category: deterministic, evidence-linked vulnerability decisions that survive auditors, regulators, and supply-chain propagation.

Every reachability graph is sealed with cryptographic signatures (in-toto + DSSE). Hybrid static + runtime analysis proves whether a CVE can execute. Every verdict comes with an OpenVEX-based proof trail. Auditors can replay any finding bit-for-bit from frozen feeds.

Sovereign crypto profiles (FIPS, GOST, SM2, eIDAS, PQC) work fully offline—you control the data sources, policy decisions, and cryptographic trust anchors.

No. Anonymous users get 33 scans per day. For more headroom, request a free token to unlock 333 scans/day. The token is a signed JWT that works offline—no external validation required.

Stella Ops uses soft limits that never block your pipeline:

• A warning appears at 90% quota usage
• Beyond the limit, requests are throttled (5s delay initially, 60s later)
• Everything resets at midnight UTC

The quota header X-Stella-Quota-Remaining tells you exactly how many scans are left.

Everything is open source under AGPL-3.0-or-later:

• Source: git.stella-ops.org
• Docs: /docs/ — every page maps to a Git tag
• Chat: Matrix #stellaops:libera.chat

The core scanner is free and open source (AGPL-3.0). Pre-built container images require a free token. Self-built distributions need no token at all.

Optional commercial add-ons include high-availability Redis/MongoDB, custom TLS/crypto adapters, and priority support.

Current status: v0.1 alpha (2025). The roadmap:

• v0.2 beta — Q1 2026: Zastava K8s agent, Cartographer dashboards
• v0.3 beta — Q2 2026: Policy packs, SARIF/JSON exports
• v0.4 RC — Q3 2026: AI remediation, LDAP/AD SSO
• v1.0 GA — Q4 2026: SLSA L3 provenance, 24-month LTS support

Pre-GA releases receive critical and high-severity fixes only.

Stella Ops is built for regulated environments:

• SBOM formats: CycloneDX 1.6, SPDX 3.0.1
• VEX standards: OpenVEX, CSAF VEX, CycloneDX VEX
• Attestations: in-toto DSSE, Sigstore Rekor transparency logs
• Crypto profiles: FIPS-140-3, GOST R 34.10, SM2/SM3 (China), eIDAS (EU), post-quantum ready

Every scan produces a Deterministic Replay Manifest (SRM) that auditors can re-run to verify findings.

Yes. The Offline Update Kit bundles everything needed for disconnected operation:

• Pre-merged vulnerability databases (NVD, OSV, GHSA + regional feeds)
• Container images for x86-64 and arm64
• Cosign signatures and SPDX SBOMs
• Time anchors to prevent clock-drift attacks

Import is atomic and takes under 7 seconds on SSD. JWT tokens verify locally with bundled public keys—no outbound network calls.

Four capabilities no competitor offers together:

1. Signed reachability proofs — Graph-level DSSE with optional edge attestations; hybrid static + runtime
2. Deterministic replay — Bit-for-bit reproducible scans from frozen feeds (Decision Capsules)
3. Explainable policy (Lattice VEX) — Evidence-linked VEX decisions with proof pointers, not just statements
4. Sovereign + offline operation — FIPS, GOST, SM2, eIDAS profiles and air-gap ready by default

See our 15-vendor comparison covering Trivy, Snyk, JFrog Xray, Docker Scout, Wiz, and others.

A Decision Capsule is a content-addressed bundle that seals all inputs, outputs, and evidence needed to reproduce and verify a vulnerability decision:

• Exact SBOM and source provenance
• Vuln feed snapshots (or IDs to frozen snapshots)
• Reachability evidence — static artifacts + runtime traces
• Policy version + lattice rules applied
• Derived VEX statements with proof trails
• Cryptographic signatures over all of the above

Why it matters: Auditors can re-run any capsule bit-for-bit to verify the outcome. Given the same capsule inputs, Stella Ops produces the same outputs—reproducibility that auditors can actually test. No other scanner offers this level of deterministic assurance.

Stella Ops combines static analysis with runtime signals to determine whether a vulnerability is actually reachable:

• Static call-graph analysis — identifies theoretically reachable code paths
• Runtime tracing — collects actual process/library loads via Zastava agent
• Evidence reconciliation — merges both sources with explicit confidence levels

The "Unknown" state: Unlike simplistic yes/no tools, Stella explicitly tracks an "Unknown" state when data is insufficient. Incomplete information never leads to false safety—you always know what you don't know.

Both static and runtime-derived edges can be individually attested (DSSE signed), allowing per-edge verification and dispute resolution.

• Access logs: IP addresses kept 7 days, then stored as salted hashes
• Token requests: Email kept only until delivery (≤7 days), then hashed
• Quota ledger: Stores token-ID hash only—no plain email or IP
• No trackers: No cookies, analytics, or third-party telemetry in the scanner

OS packages: Alpine, Debian, Ubuntu, RHEL, Alma, Rocky, SUSE, Amazon Linux, Wolfi, Chainguard

SBOM ingestion:

• CycloneDX 1.6 (JSON/XML) — preferred
• SPDX 3.0.1 (JSON)
• Trivy-JSON v2
• Auto-detection on upload

VEX support:

• OpenVEX — exploitability statuses and justifications
• CSAF VEX — Common Security Advisory Framework
• CycloneDX VEX — embedded in SBOM

VEX statements from multiple sources are merged using lattice mathematics with issuer trust weighting and freshness decay.

stella scan IMAGE_OR_SBOM [OPTIONS]

Options:
  --sbom-type {auto|cyclonedx-json|spdx-json|trivy-json-v2}
  --delta                 # Use layer cache for faster scans
  --policy-file PATH      # Override with local YAML/Rego
  --threshold LEVEL       # low|medium|high|critical (default: critical)
  --output-json PATH      # Write results to file
  --wait-quota            # Auto-retry on 429

Exit codes: 0 = pass, 1 = vulnerabilities or policy block, 2 = error

Additional tools: stella replay for deterministic replay, stellopsctl for admin tasks.

Stella Ops is CI/CD-ready out of the box:

• Exit codes for pass/fail gating in any pipeline
• Token auth via JWT or OAuth2 client credentials
• Policy override per environment with --policy-file
• Async scanning with SSE progress streams for large images
• JSON output for downstream processing

# GitHub Actions example
- name: Scan container
  run: |
    stella scan $IMAGE \
      --output-json results.json \
      --threshold high
  env:
    STELLA_JWT: $

Yes. Key endpoints:

• POST /scan — Submit SBOM or image (target: <5s cold, <1s warm)
• POST /layers/missing — Check delta cache (<20ms)
• POST /api/v1/policy/preview — Dry-run policy changes
• GET /api/v1/scans/{id}/events — SSE progress stream
• POST /connect/token — OAuth2/OIDC client credentials

Rate limit: 40 requests/second/token. The Retry-After header is included on 429 responses.

The lattice policy engine merges evidence from multiple sources into a single signed verdict:

• SBOM data — packages, dependencies, versions
• Advisory feeds — 30+ sources including NVD, OSV, GHSA, regional CERTs
• VEX statements — from vendors, your team, or third parties
• Custom rules — YAML (simple) or Rego (advanced OPA)

Every decision ships with an explain trace showing exactly why a finding was muted, escalated, or remained open. Auditors can replay any verdict with stella replay srm.yaml.

Databases: Redis (required) for caching and quota. MongoDB (optional) for audit history and long-term retention.

Docker Compose (single-node):

docker compose -f docker-compose.infrastructure.yml up -d
docker compose -f docker-compose.stella-ops.yml up -d

Kubernetes (Helm):

helm install stellaops ./deploy/helm/stellaops \
  --values values-prod.yaml

Profiles available: dev, staging, air-gapped. Horizontal scaling and HA (Redis Sentinel + MongoDB replica set) available as commercial add-on.

Yes. Zastava is a Kubernetes-native agent that provides:

• Admission webhook — validate signatures and SBOMs before pod creation
• DaemonSet observer — collect runtime events and process metadata
• Drift detection — trigger rescans when posture changes
• Event buffering — works offline with local queue

Runtime signals (entrypoint, loaded libraries) feed into the policy engine alongside static SBOM analysis.

Connected mode: Feeds update automatically (weekly during alpha, daily at GA).

Offline mode: Use the Offline Update Kit:

# Download latest bundle (on connected host)
stellaops-cli offline kit pull

# Transfer to air-gapped host, then import
stellaops-cli offline kit import ./stella-ouk-2025-11.tar.gz

Delta patches keep bundles under 350 MB. Import is atomic (<7s on SSD) with no service restart required.

Benchmarked SLOs on 8-vCPU reference rig (P95):

System sustains 60 concurrent scans on an 8-core node without queue depth exceeding 10.

• Metrics: Prometheus endpoint at /metrics with per-phase latency histograms
• Dashboards: Grafana provisioning included
• Logging: Structured JSON logs with UTC timestamps (RFC 5424 audit events)
• Tracing: OpenTelemetry spans with activity tags for correlation
• Health: /health and /ready endpoints for K8s probes

Three isolation levels:

• Connected — Normal operation with live feed updates
• Constrained — Allow-listed egress only (feed mirrors)
• Sealed — Deny-all egress, preloaded bundles only

Sealed mode requires:

• Offline Update Kit with vulnerability databases
• Time anchors to prevent clock-drift attacks
• Bundled public keys for local JWT verification

Policy banners display mirror generation, manifest hash, and staleness status so operators know exactly what data is in use.