Release Checklist (Operators)

This checklist consolidates production-rollout guardrails that must be re-verified for every cut of the StellaOps suite. It supplements the module-specific runbooks under docs/operations/ and is meant to be reviewed by the release approver before a tag is pushed to a production environment.

Cutting the evaluation bundle? This page is the reviewer’s guardrail list, not the procedure. For the ordered steps from a clean tree to published, verifiable artefacts — build, sign, upload, verify, roll back — see release-bundle-procedure.md. Both apply.

Unsupported deployment targets

Stella Ops targets non-Kubernetes container estates. Kubernetes manifests, Helm charts, kubectl rollout commands, and Helm rollback procedures are not supported release artifacts.

Reviewers must verify, before approving a production release tag:

• [ ] No Helm chart or Kubernetes manifest is included in active release packaging.
• [ ] Release notes and operator docs direct customers to Docker Compose, Offline Kit, and signed release manifests only.
• [ ] Any mention of Helm/Kubernetes in scoped release docs is explicitly historical or unsupported.

Historical note: release digest tooling may still be used for non-Kubernetes release packaging because it validates digest-pinned release-manifest authority from local CI artifacts.

Before a release, verify this checklist against the current release digest inventory, release/evidence schemas, default local model guidance and provider-pack guidance.

Assurance pack evidence-scope guardrails

NIS2 and DORA are optional software-estate Assurance packs, not broad compliance-product modes. Reviewers must verify, before approving a production release tag:

• [ ] stella assurance pack inspect nis2 --json and stella assurance pack inspect dora --json include operator-observed-estate, operator-supplied, and stella-supplier evidence scopes.
• [ ] The /assurance page and setup Assurance step display software-estate coverage and operator-supplied gaps without using “NIS2 compliant”, “DORA compliant mode”, or “CRA compliant mode” wording.
• [ ] The release evidence pack deliberately marks unavailable the stella-supplier-evidence-v1 profile for the shipped Stella release. Note: stella-supplier-evidence-v1 is still Draft/roadmap — no serializer, validator, export profile, or endpoint produces this payload yet (verified against src/ 2026-05-30; see docs/contracts/stella-supplier-evidence-v1.md). What is implemented is the reference to the profile id stella.supplier-evidence from the Assurance pack descriptors; the supplier-evidence export itself must not be cited as a delivered artifact.
• [ ] DORA schema/taxonomy pins are rechecked and release notes identify the exact local pins or local-contract markers used for major incident and RoI artifacts.
• [ ] QTSP/QSCD or release-signing provider selection guidance is current for the release-signature profile used by the release. The authoritative on-ramp is the Production signing runbook — follow it to move compliance-evidence signing from the lab dev-stable key to a sovereign provider, then complete the checklist below.

Production signing (compliance evidence)

The compliance-evidence signing surfaces ship in the lab on a clearly-marked dev-stable software seed (not a secret). A production release must move them to a sovereign provider (Vault / PKCS#11 HSM / eu.eidas.soft / fips.ecdsa.soft / GOST / SM) — never a cloud-managed KMS as a default — and publish the matching verification key so air-gapped operators verify evidence fully offline. The full procedure, before/after config diffs, and the eIDAS QES opt-in posture live in the Production signing runbook.

Reviewers must verify, before approving a production release tag:

• [ ] EvidenceLocker capsule key: EvidenceLocker__Signing__UseCryptoRegistry is true, the dev-stable EvidenceLocker__Signing__KeyMaterial__Ed25519PrivateKeyBase64 seed is removed, EvidenceLocker__Signing__AllowEphemeralKeyMaterial is false, EvidenceLocker__Signing__AllowUnsignedCapsules is false, and the EvidenceLocker__Signing__KeyId is pre-provisioned on the sovereign provider. (Config surface verified against src/EvidenceLocker/.../Core/Configuration/EvidenceLockerOptions.cs SigningOptions/SigningKeyMaterialOptions.)
• [ ] Capsule JWKS: GET /api/v1/evidence/capsules/signing-keys/jwks returns 200 and keys[0].x matches the provider public key (not the lab seed), and a sealed capsule verifies fully offline against it (no service call). (Endpoint path verified against src/EvidenceLocker/.../Api/Capsules/CapsuleSigningKeyEndpoints.cs.)
• [ ] ExportCenter NIS2 SoA key: the inline Export__Nis2Soa__SigningPrivateKeyPem is unset (a sovereign-provider ICryptoProviderRegistry owns Export__Nis2Soa__SigningKeyId), the production Export__Nis2Soa__TrustRoots__0__{PublicKeyPem,Fingerprint} is published, Export__Nis2Soa__ExpectedSignerKeyId is aligned, and POST /v1/exports/nis2/soa/runs returns verification.isValid=true with an offline-verifiable bundle. The endpoint is guarded by the StellaOpsResourceServerPolicies.ExportOperator policy, which maps to the export.operator scope (StellaOpsScopes.ExportOperator). NB: the endpoint’s descriptive metadata payload prints "export:operate", but that colon-form string is not a registered scope — the OpTok must carry export.operator (dot form) from the canonical scope catalog.
• [ ] Provider gate + no cloud default: the chosen provider’s env gate is enabled (e.g. EIDAS_SOFT_ALLOWED=1 / FIPS_SOFT_ALLOWED=1) and it appears first in the registry preferred order; no cloud-managed KMS is configured as a default; sim.crypto.remote (test-only) is not enabled for release evidence.
• [ ] eIDAS posture is explicit: soft (eu.eidas.soft, non-certified) unless a customer requires QES — and if QES is claimed, the Compliance.StrictValidation/EnforceJurisdiction flags and QTSP/QSCD/TSL evidence are in place per the runbook §6. The release notes do not present a soft software signature as eIDAS-qualified.

Authority / anonymous-fallback guardrails (audit finding A3)

The Scanner and Signals services both enforce a fail-fast on production startup if Authority:AllowAnonymousFallback is left enabled or if Authority:Enabled is false. The validators are:

• StellaOps.Scanner.WebService.Hosting.ScannerRuntimeConfigurationValidator (Sprint 20260430-003 SCAN-FALLBACK-01).
• StellaOps.Signals.Hosting.SignalsRuntimeConfigurationValidator (existing; Sprint 20260430-003 SIG-FALLBACK-01 lifted it from a top-level local function so it is unit-testable).

The two validators do not short-circuit identically (verified against source 2026-05-30):

• Scanner (ScannerRuntimeConfigurationValidator.Validate) returns early for TestingLocalHarness, for Development/Testing with Scanner:LocalHarness:Enabled=true, and for a bare Development or Testing environment unconditionally.
• Signals (SignalsRuntimeConfigurationValidator.Validate) returns early only for TestingLocalHarness or for Development/Testing with Signals:LocalHarness:Enabled=true. A plain Development/Testing host without that opt-in still runs the checks. (Signals additionally enforces an explicit cache connection string and rejects the filesystem artifact-storage driver in production — Sprint 20260430-003 / 20260502_013.)

Reviewers must verify, before approving a production release tag:

• [ ] devops/compose/docker-compose.stella-services.yml declares SCANNER_SCANNER__AUTHORITY__ENABLED: "true" and SCANNER_SCANNER__AUTHORITY__ALLOWANONYMOUSFALLBACK: "false" on the scanner-web service.
• [ ] The same compose file declares Signals__Authority__Enabled: "true" and Signals__Authority__AllowAnonymousFallback: "false" on the signals service.
• [ ] No production override file (e.g. an environment-specific docker-compose.<env>.yml) loosens those values back to true.
• [ ] The release notes call out that any local developer run that previously relied on the credential-derived AllowAnonymousFallback=true now requires either ASPNETCORE_ENVIRONMENT=Development or the explicit <Service>:LocalHarness:Enabled=true opt-in.

If any of the above fails, the release is blocked until the compose profile is fixed; the services are designed to refuse to start, but the explicit env declaration prevents an operator from silently inheriting the credential-derived default at runtime.

Zastava admission webhook fail-open posture (audit finding A6) — RETIRED

RETIRED 2026-05-12 (SPRINT_20260512_018). No longer a release gate. The Zastava module — including the zastava-webhook admission service and the ZastavaWebhookRuntimeConfigurationValidator referenced below — was a Kubernetes-native admission flow that conflicts with the non-Kubernetes deployment posture asserted in the “Unsupported deployment targets” section above. It was fully retired and the source moved to docs-archive/code-snapshots/zastava-2026-05-12-retired/. The compose stacks no longer wire a zastava-webhook service: slot 43 is held vacant in devops/compose/docker-compose.stella-services.yml (the legacy monolith compose that carried a matching decommission note was deleted 2026-09-01, SPRINT_20260824_010 P8-12). The zastava__webhook__admission__failOpenByDefault and acknowledgeFailOpenRisk keys exist only in the archived snapshot — there is nothing for a release reviewer to verify, and the verification steps that previously lived here are no longer applicable.

Runtime-admission responsibilities were absorbed by the deployment agent (StellaOps.Agent.Host); see docs/modules/zastava/architecture.md (public retirement record) and docs/modules/release-orchestrator/architecture.md (replacement runtime-observation design). The historical fail-open audit events and the runbook owner assignment that this section described are no longer emitted by any live service.