release-lab

Every workflow declares an explicit permissions: block scoped to what that job actually needs, on top of a read-only default set by the repository baseline. The strongest case is enforced by a lint: no workflow that runs caller-supplied code may hold id-token: write, and lint:capability-boundary fails the build if one ever does.

Collaborator-supplied input is validated rather than trusted: workflow inputs are checked against allowlists (the artifact classes: set, the release-stub shape), and zizmor fails the gate on any pattern that would interpolate untrusted context into a shell.

Verified on the published release: every asset is named for the release identifier (release-lab-0.24.4-x86_64-unknown-linux-musl.tar.gz, lab_pg-0.24.4-pg18-linux-amd64.tar.gz, release-lab-0.24.4.spdx.json) and each is additionally bound by cryptographic digest in checksums.txt and in the attestations. https://github.com/monumental-archive/release-lab/releases/tag/v0.24.4

docs/continuity.md is the secrets policy in operational form: an asset table naming every credential the project uses, where it is stored, who can reach it, and how it is rotated or recreated — including the one standing token, whose expiry is designed to fail loudly rather than silently under-claim. The policy is short because the architecture removes most secrets: publishing is keyless via OIDC and trusted publishing, and no signing key exists to store. https://github.com/monumental-archive/.github/blob/main/docs/continuity.md

The governance repository's runbook has a section written from the consumer's position — 'Verifying as a consumer would' — giving the commands to check a release's attestations and evidence bundle against the published digests. Every release of this repository is verified that way before the machinery is relied on elsewhere. https://github.com/monumental-archive/.github/blob/main/docs/runbook.md#verifying-as-a-consumer-would

The same documentation covers authorship identity, which in a keyless design is the workflow identity: verification checks the signer's workflow ref in the certificate rather than a personal key, and the release tooling exposes an explicit signer-workflow flag so a consumer can assert which identity must have signed. https://github.com/monumental-archive/.github/blob/main/docs/runbook.md

SECURITY.md states the support scope explicitly: only the latest release of each project receives security updates, fixes ship by rolling forward rather than backporting, and there are no long-term support branches. This repository is additionally documented as a lab whose versions are spent freely. https://github.com/monumental-archive/.github/blob/main/SECURITY.md

SECURITY.md states the end-of-life rule in the same section: a release is supported exactly until the next release exists, at which point it is end-of-life for security purposes. https://github.com/monumental-archive/.github/blob/main/SECURITY.md

GOVERNANCE.md's 'Escalation and permissions' section states the policy: a collaborator is reviewed before being granted any escalated permission — who they are, why the access is needed, and the smallest sufficient grant — and the grant is recorded in the settings-as-code baseline so drift is auditable. https://github.com/monumental-archive/.github/blob/main/GOVERNANCE.md

Every release ships an SPDX software bill of materials as a release asset — verified on v0.24.4: release-lab-0.24.4.spdx.json and release-lab-0.24.4-image.spdx.json, alongside the binaries, the extension packages, checksums.txt, the OpenVEX document and the evidence bundles. https://github.com/monumental-archive/release-lab/releases/tag/v0.24.4

A release of this project comprises this single source repository; there are no subprojects releasing alongside it.

Documented in both places a reader would look: README.md states that mise run ci locally is exactly what CI runs, and CONTRIBUTING.md makes a green gate a requirement for every change.

CONTRIBUTING.md, 'Requirements for acceptable contributions' item 3, states the policy in the contributor-facing documentation: a change that adds or changes behaviour adds the check that holds it, and a bug fix adds the case that reproduced the bug. https://github.com/monumental-archive/.github/blob/main/CONTRIBUTING.md

docs/build-assessment.md and docs/source-assessment.md carry the threat model and attack-surface analysis: the critical paths are named (caller code reaching a privileged signing identity, unpinned supply-chain substitution, silent settings drift, forged signer identities in the transparency log), each with the control that protects it and the residual risk accepted. https://github.com/monumental-archive/.github/blob/main/docs/build-assessment.md

The release path emits OpenVEX documents keyed by package@version recording non-exploitability decisions, shipped as a release asset (release-lab-0.24.4.vex.openvex.json) — and it is enforced, not optional: publishing is refused while an advisory in the SBOM is undecided, which blocked v0.19.1 until RUSTSEC-2021-0127 was decided. https://github.com/monumental-archive/release-lab/releases/tag/v0.24.4

docs/dependency-track.md defines the thresholds: cargo-deny bans and licence rules are deterministic and fail the gate, sources are restricted to a single registry with unknown-registry and unknown-git denied, and every advisory must exit through an explicit decision rather than being left open. https://github.com/monumental-archive/.github/blob/main/docs/dependency-track.md

The policy is enforced at the release boundary, not merely stated: the release path refuses to publish with an undecided advisory in its SBOM. It has already blocked a real release in the lab rather than being theoretical. https://github.com/monumental-archive/.github/blob/main/docs/dependency-track.md

Automatically, on every change: cargo-deny runs deterministically in the gate over the lockfile and the committed deny.toml, dependency-review runs on every pull request, and Renovate and Dependabot raise updates as advisories land. The policy those checks enforce is written in docs/dependency-track.md. https://github.com/monumental-archive/.github/blob/main/docs/dependency-track.md

SECURITY.md's 'Static analysis policy' states the remediation threshold and it is zero: any static-analysis finding fails the gate, a red gate cannot merge, and there is therefore no state in which a finding is outstanding on the default branch. https://github.com/monumental-archive/.github/blob/main/SECURITY.md

Every change is automatically evaluated and blocked on violation: CodeQL is enforced organisation-wide, and cargo-deny, osv-scanner, shellcheck, actionlint, zizmor and trivy run in the gate, which is a required status check.