Frequently Asked Questions

Stella Ops is a container vulnerability scanner that treats SBOMs as the source of truth. It seals every reachability graph with cryptographic signatures (in-toto + DSSE), replays scans bit-for-bit from frozen advisory feeds, and supports sovereign crypto profiles (FIPS, GOST, SM2, eIDAS) for regulated environments.

Unlike SaaS-only scanners, Stella Ops works fully offline and gives you complete control over vulnerability 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.

Three capabilities no competitor offers together:

1. Signed reachability proofs — Graph-level DSSE with optional edge attestations
2. Deterministic replay — Bit-for-bit reproducible scans from frozen feeds
3. Sovereign crypto — FIPS, GOST, SM2, eIDAS profiles without code changes

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

• 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.