.github

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: assets are named for the release identifier (github-1.22.2.tar.gz, github-1.22.2.spdx.json) and each is additionally bound by cryptographic digest in checksums.txt and in the attestations.intoto.jsonl evidence bundle, so the association survives a rename. https://github.com/monumental-archive/.github/releases/tag/v1.22.2

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

docs/runbook.md has a section written from the consumer's position — 'Verifying as a consumer would' — giving the commands to check a release's attestations and Sigstore evidence bundle against the published digests. https://github.com/monumental-archive/.github/blob/main/docs/runbook.md

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 section 'Supported versions and end of life' states the scope and duration of support: only the latest release of each project receives security updates, fixes ship by rolling forward from main rather than by backporting, and a release is therefore supported exactly until the next release exists. There are no long-term support branches and no announced support windows. A repository with different needs states its own policy in its own SECURITY.md, which then replaces this one for that repository. https://github.com/monumental-archive/.github/blob/main/SECURITY.md

The same section states when a release stops receiving security updates: a release is end-of-life for security purposes at the point the next release exists, since fixes ship only by rolling forward from main. This is a deliberate consequence of the release design - every release stays reproducible and its evidence permanent, but maintenance effort goes to the tip. https://github.com/monumental-archive/.github/blob/main/SECURITY.md

GOVERNANCE.md section 'Escalation and permissions' carries the policy: a collaborator is reviewed before being granted any escalated permission. Concretely, before an account joins @monumental-archive/owners or receives write access anywhere, the maintainer reviews who they are, why the access is needed and what the smallest sufficient grant is - and the grant is then recorded in the settings-as-code baseline so drift is auditable. https://github.com/monumental-archive/.github/blob/main/GOVERNANCE.md#escalation-and-permissions

Every release ships an SPDX software bill of materials as a release asset — verified on v1.22.2: github-1.22.2.spdx.json, alongside github-1.22.2.tar.gz, checksums.txt and the attestations.intoto.jsonl evidence bundle. The SBOM is generated by the release pipeline (release/generate-sbom.sh) rather than hand-maintained. Previously answered N/A on the grounds that this repository compiles nothing; that was technically available but less true than the facts — the SBOM is published regardless. https://github.com/monumental-archive/.github/releases/tag/v1.22.2

A release of this project comprises this single source repository; there are no subprojects releasing alongside it. Other repositories in the organisation consume this one's governance, which is by construction as strict or stricter.

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. When they run is equally explicit — on every pull request and every push to main, with the network-bound checks on a Monday schedule. https://github.com/monumental-archive/.github/blob/main/CONTRIBUTING.md

CONTRIBUTING.md, item 3 of 'Requirements for acceptable contributions', is the policy and it sits in the contributor-facing documentation: a change that adds or changes behaviour adds the check that holds it - a test that fails without the change where a test suite exists, or a lint, audit task or workflow assertion where the product is configuration and policy - 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

Exactly this: the dependency track emits VEX documents keyed by package@version recording non-exploitability decisions for advisories that do not affect the project, with coverage derived rather than asserted, and the release path refuses to publish while an advisory in the SBOM is undecided. https://github.com/monumental-archive/.github/blob/main/docs/dependency-track.md

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 section 'Static analysis policy' defines the remediation threshold, and it is zero: any SAST finding - CodeQL, the lint belt, zizmor and peers - fails the CI gate, and a red gate cannot merge, so findings are remediated or explicitly and reviewably suppressed with a written reason before the change lands. There is no severity triage queue for static findings because there is no state in which one is outstanding on a default branch. https://github.com/monumental-archive/.github/blob/main/SECURITY.md

Every change is automatically evaluated and blocked on violation: CodeQL default setup is enforced organisation-wide, and shellcheck, actionlint, zizmor and trivy run in the gate, which is a required status check that a pull request cannot merge past. The requirement that the gate pass is documented in CONTRIBUTING.md; what is missing is only a stated severity threshold, recorded honestly under osps_vm_06_01. https://github.com/monumental-archive/.github/blob/main/CONTRIBUTING.md