Harden has failed every Sunday since 2026-09-27: the mc build (dead
quay.io/minio/mc) aborted the job before a single trivy step ran, so
for a month no image was scanned and nothing said so beyond an
auto-filed issue per week.
Harden (gen_config -> .gitea/workflows/harden.yml)
- Each image is built -> scanned -> pushed on its own. A failed build
is continue-on-error and skips only that image's scan and push; a
gate step after the vuln report fails the job, so the breakage is
still filed, never swallowed.
- Builds use --pull --no-cache: --no-cache alone reused whatever stale
base the runner had cached.
- mc is scanned now too (it was built but excluded).
Tooling pins (harden, deploy, rebuild-all, pkg-supply-chain)
- trivy 0.76.0 via the tagged installer (it checks the release sha256)
instead of install.sh from `main`.
- crane 0.22.1 with its sha256 checked against the release
checksums.txt, instead of an unverified `releases/latest` tarball.
- Both are Renovate-tracked constants in backends/gitea.py.
Package supply chain
- docs/pnpm-lock.yaml is scanned nightly into data/pkg-vulns-docs.json
and filed like uv.lock findings.
- pkg_issues.py read only the first 50 open `ci` issues, so once CI
failures piled up every known CVE past page one was invisible: re-filed
nightly (174 open issues for 91 titles) and never closed. It now walks
every page, closes all duplicates of a title, and runs the close pass
even when a scan comes back clean — it used to return early there,
i.e. exactly when the most issues resolve. Dry run against the live
tracker with the new lock: closes all 174, files none.
Refs #1365
41c7d318e9