monumental-archive-db

Scopes are granted per job and each grant carries an inline comment saying why: packages: write only on the jobs that push an image, id-token: write only on the job that needs Sigstore OIDC. Everything else inherits the top-level contents: read. Runners additionally enforce egress-policy: block and disable-sudo where applicable.

No collaborator-supplied value is interpolated into a shell step. Enforced rather than asserted: zizmor at --persona=pedantic and actionlint run on every commit and in CI, and CodeQL analyses the workflows as its actions language — the combination is specifically good at template injection, which is the form this failure takes in GitHub Actions.

Every asset is identified by content: each layer and each per-architecture manifest carries its own sha256 digest, and the multi-arch index digest commits to all of them. The index is additionally tagged :sha-<commit>, associating the whole set with the exact commit that produced it. Nothing in a publish is identified by anything mutable.

The policy is documented and unusually simple, because the project deliberately holds nothing to manage: no long-lived registry or signing credential exists. GHCR authentication uses the workflow run's own short-lived token, and signing is keyless — an ephemeral Sigstore certificate bound to the workflow's OIDC identity, so there is no private key at rest to store, access or rotate. https://github.com/CarlAllenn/monumental-archive-db/blob/main/GOVERNANCE.md#access-continuity states this explicitly and gives the reason it was chosen: a private key is precisely the artifact that cannot be inherited by a successor. On the consumer side, https://github.com/CarlAllenn/monumental-archive-db/blob/main/SECURITY.md is equally explicit that the image ships no credentials and that POSTGRES_PASSWORD handling is the deployer's. Enforcement against accidents: gitleaks on every commit and over full history, plus persist-credentials: false on every checkout.

Both the README and https://github.com/CarlAllenn/monumental-archive-db/blob/main/SECURITY.md#verifying-what-you-pulled give the exact cosign command, including the certificate identity regexp and the OIDC issuer. Integrity is additionally verifiable by digest alone, since consumers pin digests rather than tags.

The published verification command names the expected author process precisely: the certificate identity is this repository's publish workflow, anchored through @refs/heads/main$ so a signature minted from any other ref does not verify. The documentation states plainly that a signature not verifying against that identity is not ours, whatever the tag says. The same string appears in the README, SECURITY.md and the pipeline's own post-signing verification step, so the three cannot drift apart silently.

https://github.com/CarlAllenn/monumental-archive-db/blob/main/SECURITY.md#supported-versions — the latest published digest only, with the reasoning: this image has no version surface of its own, so there are no back-branches to maintain. Support consists of the weekly cache-free rebuild plus pin bumps, and the upgrade path is a digest bump, which is what Renovate is for.

The same section states it without euphemism: only the latest published digest is supported. A superseded digest receives no further security updates — it is immutable and remains exactly as published. Because consumers pin digests, this is a property they control directly: a fix reaches you when you bump the digest.

Every published image carries an SPDX SBOM attestation generated at build time (sbom: true), alongside a provenance attestation at mode=max. Both are attached to the manifest and retrievable by digest. Note the SBOM is generated by the build that produced the image rather than reconstructed afterwards, so it describes the bytes that shipped.

The project is a single repository with no subprojects.

https://github.com/CarlAllenn/monumental-archive-db/blob/main/CONTRIBUTING.md#development-quick-start documents how — task smoke for the test suite, task ci for the whole gate, identical locally and in CI — and when: the lefthook hooks run the lint suite on every commit and build and smoke the image on push when the Dockerfile or the smoke script changed, and CI runs the full gate on every pull request. CONTRIBUTING also documents the one trap in the smoke script (the official entrypoint starts postgres twice on a fresh volume, so the script waits for the second ready line).

https://github.com/CarlAllenn/monumental-archive-db/blob/main/CONTRIBUTING.md#tests-are-part-of-the-change — a change to what the image contains comes with a smoke assertion that fails without it, with the reasoning stated: adding an extension without its assertion means the next refactor can silently drop it and the gate stays green. It is listed as one of the four ordered review checks, so it is applied at review rather than merely written down.

https://github.com/CarlAllenn/monumental-archive-db/blob/main/docs/assurance-case.md#threat-model is an explicit threat model ordered by exposure, naming supply-chain substitution as primary and enumerating its four distinct points (base image, extension build stage, apt layer, published manifest), then CI compromise, known-vulnerable OS packages, and configuration that misleads a consumer — each with what is explicitly out of scope. The attack surface analysis is the trust-boundary section, which states what crosses each boundary and by what mechanism. https://github.com/CarlAllenn/monumental-archive-db/blob/main/docs/security-review-2026.md then tests that model against the implementation on a dated pass and records where it did not hold.

The threshold is documented and is the strictest available: trivy runs at all severities — UNKNOWN through CRITICAL — with --ignore-unfixed, so any finding with an available fix fails the gate. There is no severity cutoff below which a fixable vulnerability is tolerated. The configuration is https://github.com/CarlAllenn/monumental-archive-db/blob/main/trivy.yaml, listed in the coding-standard table at https://github.com/CarlAllenn/monumental-archive-db/blob/main/CONTRIBUTING.md#coding-standard, and the remediation model behind it is https://github.com/CarlAllenn/monumental-archive-db/blob/main/SECURITY.md. Licence findings are handled separately and more strictly by reuse lint, which gates CI on full REUSE 3.3 compliance.

Documented, and the placement is a deliberate decision rather than an accident, so it is worth stating precisely. The blocking CVE gate lives on pull requests: nothing merges with a fixable vulnerability. It is deliberately NOT on the publish path, and https://github.com/CarlAllenn/monumental-archive-db/blob/main/SECURITY.md explains why — a CVE published tomorrow must not retroactively kill a publish, and the weekly remediation rebuild especially must not die because a scanner had a bad day. Publish runs scan report-only so every published digest still has its CVE state on the run log, and the actual remediation for the inherited layer is the weekly cache-free rebuild rather than a gate.

Every change is evaluated automatically and blocked on violation: trivy scans the filesystem and the built image on every pull request, and the scan tasks are deliberately never checksum-fingerprinted because vulnerability databases change without commits and a cached skip would be a false pass. Dependency provenance is gated too — https://github.com/CarlAllenn/monumental-archive-db/blob/main/scripts/check-edtf-attestation.sh proves the pinned extension image carries GitHub-attested provenance from edtf's own publish workflow at the matching release tag, which is a malicious-dependency control rather than a vulnerability one. Renovate keeps pins current between scans.

The threshold is zero, documented as such: https://github.com/CarlAllenn/monumental-archive-db/blob/main/CONTRIBUTING.md states that fixing tool output is never optional and that there are no bypass flags. Any finding from hadolint, shellcheck, actionlint, zizmor --persona=pedantic or CodeQL fails the gate regardless of severity, and the gate is enforced twice — locally by the lefthook hooks and remotely by required status checks on main.

All changes are evaluated automatically and blocked on violation. Static analysis of everything this repository actually authors: hadolint on the Dockerfile, shellcheck and shfmt on the two scripts, actionlint and zizmor at --persona=pedantic on the workflows, and CodeQL's actions analysis on the workflows — which is where this repository's real privilege lives, since that is what holds GHCR push, OIDC and cosign signing. Suppression is not available as a bypass: new words go in .codespellrc rather than a lint disable, by documented policy.