[P1] Build an immutable signed release, promotion, and rollback pipeline

[seonghobae]

Current production gap — exact protected truth 2026-09-12 KST

Protected/default main is f8260f1e03836039ff9463dd99fa982e4e270c4b after #155. Wardnet still has no GitHub Release. Fresh protected-tree inventory confirms the repository-owned workflow directory still contains only ci.yml, fuzz.yml, and scorecard-analysis.yml; there is no repository-owned release workflow on protected main.

The package declares waf-ids-ai-soc version 0.1.0, and CHANGELOG.md exists but remains release-candidate authority rather than an immutable published release. The gap is to bind one reviewed protected source identity to exact version/tag/package/image, SBOM, signature, provenance, reproducibility, promotion, rollback and recovery evidence.

The deployment manifest still must be proven to consume an immutable verified image digest rather than mutable-tag authority before release. No current protected Wardnet source/tag/package/release identity binds protected main to a complete SBOM/signature/provenance/reproducibility/promotion/rollback receipt.

Required pipeline

Build and test

1. Use the exact supported/pinned Rust toolchain and immutable action SHAs; no floating compiler/workflow dependency.
2. Require 100% owned-production statement/branch/edge/public-rustdoc evidence on the exact candidate. Predecessor, stacked-child, inferred or model-reported figures do not satisfy this gate.
3. Run format, locked workspace tests, strict Clippy, rustdoc/doc coverage, fuzz/property regressions, smoke tests, dependency review, OSV, Trivy/container scanning, Semgrep, CodeQL, secret scanning, license policy and the real deployed Strix attack lane from 서버를 켜고 Strix가 포트를 향해 각종 공격을 할 때 감지해내야 함 (CI) #11 on the same exact candidate.
4. Use deterministic/hermetic feed/integration fixtures while retaining required real PostgreSQL/browser/deployed-runtime acceptance.
5. Upload machine-readable test, coverage, security, attack and recovery evidence bound to exact source SHA.

Artifact integrity

1. Build the release image once from the reviewed protected commit; do not rebuild independently by environment.
2. Pin builder/runtime bases and reusable workflows by immutable digest/SHA.
3. Generate CycloneDX or SPDX SBOMs for Rust dependencies and final container filesystem.
4. Produce SLSA provenance and narrowly scoped keyless Sigstore/Cosign signatures.
5. Record source SHA, version, Cargo.lock digest, toolchain, image digest, SBOM digest, signature bundle, provenance and exact-head test evidence in the release manifest.
6. Verify signature/provenance before deployment/admission; mutable tags never establish authority.
7. Run reproducibility comparison and record bounded explained differences rather than inferring reproducibility from one build.

Promotion, rollback and publication

1. Deploy by digest to a production-shaped ephemeral environment with hardened external-secret/IAM contracts and then-current protected runtime prerequisites.
2. Validate Kubernetes Restricted Pod Security, NetworkPolicies, resource bounds, probes, graceful shutdown, migration compatibility, non-root/read-only filesystem and exact external-secret/IAM assumptions.
3. Run smoke, persistence/restart, fail-closed management auth ([P0] Fail closed when management credentials are absent #78), outbound authorization ([P0] Enforce a fail-closed destination policy for all outbound traffic #79 through released EgressWeave contract), deployed attack (서버를 켜고 Strix가 포트를 향해 각종 공격을 할 때 감지해내야 함 (CI) #11), PostgreSQL recovery and rollback against the exact digest.
4. Promote the same digest with recorded policy/approval evidence; no rebuild-on-promotion, force update, mutable-tag authority or routine branch-protection bypass.
5. Define canary/blue-green halt criteria, database compatibility window, rollback/roll-forward and measured exercise evidence.
6. Convert Unreleased changelog material into versioned notes only when the exact protected candidate is releasable; then create immutable GitHub Release/package/tag identity plus supported-upgrade/support/deprecation contract.
7. Re-fetch the published release, artifact digests, SBOM/provenance/signature and deployment/rollback evidence. A local artifact or successful workflow alone is not completion.

RED → GREEN verification

Tampered image/SBOM/signature/provenance/source SHA/version/Cargo.lock/workflow identity fails verification. A mutable tag resolving elsewhere cannot be admitted or promoted. Missing exact-head coverage/security/attack/migration/restore/review/thread/governance evidence blocks release. Rebuild differences are surfaced. Rollback restores the prior approved digest and compatible schema/state within the measured exercise result; no unmeasured buyer RTO/RPO is invented. The full evidence bundle remains independently retrievable after workflow completion and bound to immutable release identity.

Acceptance criteria

• One reviewed protected SHA maps to one immutable version/tag/package/image digest and complete evidence manifest.
• SBOM, signature, provenance, reproducibility and exact-head test/security/attack/recovery evidence are verified before promotion.
• No production manifest or promotion decision relies on mutable image tags or repository-shipped credentials.
• Rollback/roll-forward is rehearsed and measured.
• Versioned release notes, supported-upgrade compatibility, support window and deprecation policy are published.
• Current-head review/thread/governance evidence is terminal-valid; self/model approval and routine administrator bypass remain forbidden.
• GitHub Release/package/tag and promoted digest are freshly re-fetched and proven immutable before closure.

Dependency / ownership boundary

Issue #87 remains the aggregate production-readiness gate. #11, #78, #79, #80/#192/#243 and active PostgreSQL recovery/operability lineage remain release prerequisites. EgressWeave, quarantine-sandbox-runtime, contextual-orchestrator, Keyverse, CGC and EA Core remain separate canonical owners; Wardnet consumes only immutable compatible released contracts and does not copy their source/truth.

Generic changelog-driven release governance/reusable GitHub Actions belongs to central .github owner contracts, including .github#1552 or verified successor; exact-artifact SBOM attestation belongs to .github#783 or verified successor. Wardnet does not create a competing generic release engine or credential-bearing attestation implementation. Once central contracts are protected, immutable and versioned, Wardnet consumes them through exact-SHA callers while retaining product versioning, build/package inputs, runtime acceptance, migration compatibility and buyer/security release eligibility as Wardnet truth.

Release completion remains exact protected head GREEN → ordinary protected integration → immutable build/sign/SBOM/provenance/reproducibility → production-shaped deployment/attack/recovery → measured rollback/roll-forward → immutable GitHub Release/package/tag → fresh re-fetch verification. Do not close because a Draft head, predecessor workflow, local artifact, mutable dependency, changelog entry or release-plan document exists.

References

• SLSA Project. (2025). SLSA specification version 1.2. https://slsa.dev/spec/v1.2/
• Sigstore. (n.d.). Cosign documentation. https://docs.sigstore.dev/cosign/
• Kubernetes Authors. (2026). Pod Security Standards. https://kubernetes.io/docs/concepts/security/pod-security-standards/
• Kubernetes Authors. (2026). Good practices for Kubernetes Secrets. https://kubernetes.io/docs/concepts/security/secrets-good-practices/
• National Institute of Standards and Technology. (2022). Secure Software Development Framework (SSDF) version 1.1 (NIST SP 800-218). https://doi.org/10.6028/NIST.SP.800-218

[seonghobae]

Release/supply-chain execution has an active bounded implementation lane: Draft PR #164, stacked on the exact Rust-toolchain prerequisite #77 rather than duplicating or bypassing it.

Exact stack at creation:

• prerequisite build(rust): pin and track Rust 1.98.0 #77: agent/rust-toolchain-refresh-2026-08-19@2f96565b9452ea49627b28f7ae380e07b68af115, which is a clean descendant of protected main@cc15cc2c34daf8c104eeb83d52a6a66f3cd6e128;
• build(release): bind reviewed source to SBOM and provenance evidence #164 current candidate: codex/release-evidence-foundation-20260904@f90e9312a6c911c60e999db612afdb18e5a7ae49.

TDD lineage is explicit: RED bf6ba08557b0900ef7959d8e9e2b83b0ad0f7fe9 requires the release-evidence contract before the workflow exists; GREEN 5ce56d19e2c37ce1824b1d4d8657f6391387238f adds the repository-owned workflow. The slice repeats fmt/locked tests/strict Clippy, builds the locked release binary, creates a deterministic archive and SHA-256 source/output evidence, generates SPDX JSON, and on protected-main workflow_dispatch only creates GitHub/Sigstore build-provenance and SBOM attestations. It deliberately retains contents: read, so it cannot create a tag/release/image/deployment or accidentally promote this incomplete product state.

Fresh standards correction is recorded in docs/doctoring/release-evidence-supply-chain.md: as rechecked 2026-09-04, SLSA v1.1 is the latest Approved Specification found; NIST SP 800-218r1 / SSDF 1.2 remains an Initial Public Draft while SSDF 1.1 is finalized; SPDX 3.1 remains a release candidate. Do not use the older issue wording as authority for a non-existent approved SLSA 1.2 baseline.

This does not close #84. OCI image digest/SBOM, signature/provenance verification before admission, exact deployment/attack evidence, promotion, independent evidence retention, and measured rollback/roll-forward remain mandatory. Retarget/non-force restack #164 only after #77 is protected truth, then reacquire all exact-head evidence; no predecessor or same-SHA foreign-PR results transfer.

[seonghobae]

Superseded live inventory correction: an immediately subsequent fresh GitHub Releases read now returns [], and direct lookup of v0.0.2-safe returns 404. The earlier snapshot that appeared to expose historical release objects is not current repository truth and must not be treated as release evidence.

Latest verified state is therefore consistent with #84: Wardnet currently has no GitHub Release objects. The release/supply-chain lane remains incomplete until the then-current protected head is bound to version/CHANGELOG, package or image digest, SBOM, signature/provenance, reproducibility, production-shaped promotion, rollback/roll-forward, recovery, and live security/governance evidence. This corrected comment supersedes my preceding release-inventory assertion.