A Release Protocol Must Fail Closed Too

A security check is not a gate just because it appears in the release dashboard.

A gate changes what can happen when the check fails. If publication can continue independently, then the system relies on an operator noticing the red result and stopping the release. That may be a valid short-term control, but the distinction needs to be stated clearly.

What happened on v1.29.0

The v1.29.0 tag-time OSV audit failed on a development-only dependency path: joi 18.2.5 through wait-on. By then, the tag had already triggered separate publication workflows. GHCR aliases had published. The operator cancelled the Tauri workflow before it created a GitHub Release.

That was a manual fail-closed action for the desktop release. It did not undo the container aliases that had already been published. The audit and publication workflows were mechanically independent, so the human response mattered.

This is why the release record needs separate outcomes: the audit failed, the Docker image published, and the Tauri path was cancelled before GitHub Release creation. Calling the whole event either “blocked” or “released” hides the important ordering.

Fix the finding, then fix the protocol

PR #909 upgraded joi to 18.2.9 and established an override floor of at least 18.2.6. That corrected the dependency finding in resulting main. A dependency fix addresses the known vulnerability path; it does not by itself create a future publication gate.

For v1.29.1, the procedural mitigation was executed: the fresh scan stopped candidate 99a664c5 when six new development-only advisories appeared; after #912, the team froze and requalified candidate f255d767, watched its tag-time Security Audit, and completed publication and verification. This worked for that release; it does not make the workflow dependency mechanical.

A later review found that rerunning the CI/CD Security Audit job also reruns dependent jobs such as GitHub Pages deployment. The current interim method recorded on #911 is a standalone security-scheduled.yml dispatch with no deploy jobs, only while origin/main equals the frozen candidate. The mechanical Tauri/GHCR dependency remains future work.

Durable enforcement is a different state

QNB-162 and GitHub issue #911 track post-release machine-enforced hardening: make Tauri and GHCR publication depend on the required security result. That would move a critical stop condition from an operator checklist into the workflow dependency graph.

The distinction is not a criticism of the current recovery. Manual containment can be the right immediate response when a release is already in motion. The engineering follow-up is to decide which parts should become deterministic and make the transition only after implementation and verification.

Until then, a diagram should use different shapes for the three stages:

1. Historical intervention: a human cancelled the Tauri path after the failed audit, but GHCR had already published.
2. v1.29.1 procedural control: fresh exact-candidate scan stopped the first candidate; the remediated candidate passed and was watched through publication and verification. A rerun side effect led to a safer interim freshness procedure.
3. Future hardening: #911 remains open and proposes a workflow-level dependency; it is not current behavior.

A gate needs an executable contract

A useful gate states the candidate, the check, the result expected, who or what observes it, and what happens on failure. For manual steps, record the exact evidence and how the operator confirms completion. For automated steps, encode the dependency so a downstream publish job cannot start after a red result.

The word “gate” should never be inferred from a green badge next to a separate workflow. It is a claim about control flow. Show the graph, show the terminal outcome, and keep the release record current.

Continue reading

This closes Release Engineering & Testing Reality. Start with Green Build, Broken First Boot for the first qualification boundary, then follow the series through candidate identity and publication state.

Related: A Release Is More Than a Tag connects these states across release outputs.

Practical extension: make the gate graph enforce its claim

A release gate is a dependency relationship, not a dashboard widget. Draw the graph from security qualification to packaging to publication, then check whether a failed required job actually blocks every publishing job. A separate workflow can publish around the gate even when the security workflow is red.

Keep remediation and enforcement distinct:

1. Fix the vulnerable or misconfigured input.
2. Re-run qualification on the exact candidate.
3. Preserve the failed candidate and its result.
4. Verify the dependency graph prevents publication on a future failure.
5. Exercise the emergency path and document its narrow scope.

For WorldScript Studio, v1.29.1 was verified after a procedural qualification and release run. As of 2026-10-01, the mechanical release-gate hardening remained tracked in issue #911; the release success did not mean that automation gap had been closed. The interim security-only dispatch was chosen because rerunning the broader CI/CD workflow could also trigger a dependent Pages deployment. That is a useful warning: “rerun the failed job” can have side effects beyond the check being investigated.

GitHub recommends explicit minimum workflow permissions and careful treatment of third-party actions in its Actions security guidance. Make the gate fail closed, but keep the override observable, time-bounded, and tied to a human decision.