Compliance Readiness Tracker

Version: 1.1.1 Created: 2026-01-15 Last Updated: 2026-05-31 Status: Active

This document tracks implementation progress against the 7-item Compliance Readiness Checklist that regulated customers expect Stella Ops to satisfy before deployment. It is for product, engineering, and customer-success leads who need a single, current view of what is shipped, what is in flight, and which sprint owns each gap.

For the product framing of compliance and the canonical claim-boundary wording, start at Assurance and Compliance Packs. Source under src/ is the ground truth for any technical claim below.

June 2026 code-verified reconciliation (2026-06-16): This tracker covers the 7-item offline/air-gap readiness checklist. The separate EU regime trackers (CRA/NIS2/DORA) were reconciled against src/ on 2026-06-16; see State of European Union compliance (2026-06) for the code-verified per-regime status and the remaining gap clusters (CRA C1-C5, NIS2 N1-N5, DORA D1-D4). The cross-cutting remediation-log items X1 (attestor verdict-ledger write-on-seal) and X4 (Authority seed-gate) are DONE and live-verified; X2 (events-flag projection tables) is retired as a non-gap; X3 (eIDAS soft provider) is reconciliation-only (a real ECDSA provider, registered and gated). The only externally-blocked item is the DORA major-incident EBA XBRL/XSD taxonomy (D1/X5): no valid upstream DORA-IR taxonomy package exists, so conformance there is honestly not-claimed. The offline/operator-support claim boundary is unchanged: Stella produces and signs evidence; the regulated customer remains the reporting party. Most remaining EU gaps are HTTP/write-path parity (code) rather than capability gaps; live security mailbox/key, on-call, and standards-mapping sign-off are org-process. No status in the 7-item table below changes.

Executive Summary

Sprint Allocation

Phase 1: Demo Blockers (016)

Target: Features needed for 10-minute compliance demo.

Sprint files for items 016/017/018 have been archived; links point to docs-archive/implplan/.

Phase 2: RFP Compliance (017)

Target: Features needed to pass RFP security questionnaires.

Phase 3: Audit Readiness (018)

Target: Features needed to pass security audits.

Detailed Item Status

Item 1: Attestation Caching (Offline)

Why it matters: Regulated shops can’t reach public Sigstore/Rekor during audits.

DSSE verdict caching, offline Rekor receipt verification, and exportable hash-manifested evidence bundles are implemented in Attestor + EvidenceLocker (src/Attestor/StellaOps.Attestor/StellaOps.Attestor.Core/Verification/, src/Attestor/__Libraries/StellaOps.Attestor.TrustVerdict/Caching/, src/EvidenceLocker/.../Services/EvidencePortableBundleService.cs). Remaining work is the operator-facing surface: an offline stella attest verify path with golden fixtures and a bundled VERIFY.md script.

Proof Artifacts:

• [ ] Demo verifying image on laptop with Wi-Fi off
• [ ] SHA-256 match + signature chain report

Item 2: Offline RBAC & Break-Glass

Why it matters: No cloud IdP during outages/air-gap. Auditors want least-privilege and emergency access trails.

Incident-mode access is live: a dedicated incident scope, freshness-bound (auth_time) tokens carrying a reason claim, and an Authority audit endpoint that records entry/exit. Scope and claim constants are canonical in src/Authority/StellaOps.Authority/StellaOps.Auth.Abstractions/StellaOpsScopes.cs and the adjacent StellaOpsClaimTypes.cs; do not re-enumerate them here. Remaining work is a fully offline fallback path: a file-backed policy store, a bootstrap break-glass account, and session auto-revocation.

Proof Artifacts:

• [ ] RBAC matrix (roles -> verbs -> resources)
• [ ] Audit log showing break-glass entry/exit

Item 3: Signed SBOM Archives (Immutable)

Why it matters: SBOMs must be tamper-evident and tied to exact build inputs.

CycloneDX/SPDX export and DSSE signing exist in Scanner + Signer. The remaining work is an immutable archive format that binds the SBOM to its build inputs (tool versions, scanner image digest) plus a one-click stella sbom verify. The format is specified in docs/modules/scanner/signed-sbom-archive-spec.md — that spec is authoritative for the archive layout and metadata.json shape. RFC 3161 timestamping is deferred.

Proof Artifacts:

• [ ] One-click “Verify SBOM” checking signature, timestamps, content hashes

Item 4: HSM / Key Escrow Patterns

Why it matters: Key custody is a governance hotspot.

Key management runs through the crypto plugin layer (src/Cryptography/): a PKCS#11 HSM plugin and key-rotation service exist, with optional KMS clients (src/__Libraries/StellaOps.Cryptography.Kms/) available as plugins for customers who require them — never as a default, per the on-prem-first posture. Operator config is authoritative in the HSM setup runbook. Remaining governance work is dual-control (M-of-N) signing ceremonies and Shamir-based key escrow.

Proof Artifacts:

• [ ] Config targeting HSM slot
• [ ] Simulated key rotation with attestation continuity

Item 5: Local Rekor (Transparency) Mirrors

Why it matters: Auditors want inclusion proofs even when offline.

Tile verification, checkpoint-signature verification, and offline receipt verification are implemented in Attestor Core (src/Attestor/StellaOps.Attestor/StellaOps.Attestor.Core/Verification/). Remaining work is a persistent local mirror: periodic checkpoint sync into a Postgres-backed checkpoint store, plus root-divergence detection (see the checkpoint-divergence runbook).

Proof Artifacts:

• [ ] Verify inclusion proof against local checkpoint without internet
• [ ] Mismatch alarm if roots diverge

Item 6: Offline Policy Engine (OPA/Conftest-class)

Why it matters: Gates must hold when the network doesn’t.

Versioned policy bundles, a sealed (air-gap) evaluation mode, and the existing gate family — VEX proof/trust, unknowns budget, evidence freshness — are implemented in the Policy engine (src/Policy/StellaOps.Policy.Engine/AirGap/ for sealed mode; src/Policy/__Libraries/StellaOps.Policy/Gates/ for the gate catalog, which is authoritative for the full gate list). Remaining work adds three release-control gates: CVSS threshold, SBOM presence, signature-required.

Proof Artifacts:

• [ ] Local policy pack on sample image showing fail
• [ ] Compliant pass after adding VEX exception with justification

Item 7: Upgrade & Evidence-Migration Paths

Why it matters: “Can we upgrade without invalidating proofs?” is a top blocker.

Forward-only DB migrations (see ADR-004), Merkle-rooted evidence manifests, and per-module backup/restore are in place. Operator procedures live in the blue/green deployment and upgrade runbook docs. Remaining work is tooling to re-index evidence across an upgrade (stella evidence reindex) and cross-reference old/new Merkle roots for proof continuity.

Proof Artifacts:

• [ ] Staged upgrade in test namespace
• [ ] Before/after verification reports
• [ ] Unchanged artifact digests

Documentation Deliverables

Demo Script (10 Minutes)

A ~10-minute, network-off walkthrough that exercises each readiness item end to end. The scenarios below give the narrative and what each proves; for the exact stella subcommands and flags, see the CLI command source (src/Cli/StellaOps.Cli/Commands/) — it is authoritative and avoids drift from aspirational flag names. Several commands map to TODO items above and only land as those sprints complete.

Stakeholder Sign-Off

Change Log