ci: move image vulnerability scanning out of CI to a weekly scan of published images

[mforce]

AMENDED 2026-10-02 — re-scoped by the owner. This issue now tracks
redesigning how CI handles container image vulnerability scanning, prompted
by the CVE described below:

• Remove the Trivy scan from CI. It no longer runs on pull requests or on
  pushes to main, and it no longer gates publish. The image job keeps
  building and boot-testing both architectures, and those still gate publish.
• Scan published images weekly, plus on demand with workflow_dispatch.
  Report findings to the Security tab and file one issue per
  vulnerability, updated by later runs rather than duplicated.
• No ignore or accepted-risk file.

The PR implementing this closes this issue. It does not fix
CVE-2026-84782 itself. The weekly scan's first run files that as its own
issue, which closes when Microsoft ships a fixed aspnet:10.0 and the pin is
bumped.

Why: on 2026-10-01 this CVE in Microsoft's base image — unexploitable
here, see the comments below — turned every code PR's image check red and
stopped publish on every push to main. The last published image is
ad258d8f, and release v0.1.5 (#993) could not be promoted. Widely used
projects (Keycloak, Harbor, Kyverno) scan on a schedule and report rather
than block.

The original description is kept below for history.

---

The image job's Trivy gate now fails on every pull request that changes app code, because Microsoft's pinned .NET runtime image ships an OpenSSL with a fixable HIGH vulnerability.

Upstream: dotnet/dotnet-docker#7384 tracks Microsoft's rebuild. Its title names 10.0-noble-chiseled-extra, but the thread confirms the regular Ubuntu images we use are affected too. Ubuntu's fix is USN-8847. This closes when Microsoft ships a fixed aspnet:10.0 and we bump the pin.

What fails

ci.yml → Image build + Trivy scan → Scan image for HIGH/CRITICAL vulnerabilities:

Package	CVE	Severity	Installed	Fixed in
libssl3t64	CVE-2026-84782	HIGH	3.0.13-0ubuntu3.15	3.0.13-0ubuntu3.16
openssl	CVE-2026-84782	HIGH	3.0.13-0ubuntu3.15	3.0.13-0ubuntu3.16

Title: openssl: Information disclosure via DTLS handshake retransmission. Both rows come from the runtime base mcr.microsoft.com/dotnet/aspnet:10.0@sha256:2d584d8147faddb0d678c5748d47953e5b8e18621ed4fb7049a91381d9d7746f (Ubuntu 24.04).

First seen on #985, run 36800931106, and reproduced on a rerun. main passed the same job with the same pinned digest at ad258d8f about 15 minutes earlier, so this comes from Trivy's vulnerability database learning about the fix, not from any change in this repo. The gate uses ignore-unfixed: true on purpose, so it fails only because Ubuntu has already shipped the fix.

Unrelated noise in the same log: an NU1004 restore error appears just before the scan. That is the deliberate #315 locked-mode drift check, which breaks the lock in a throwaway copy and expects the build to fail. It passed.

Impact

• Every PR whose diff is not documentation-only runs the image job, so all of them fail this check until the base image is fixed.
• publish needs image, so the next merge to main publishes no :sha-<commit> image, and a release drafted from that commit cannot be promoted (CI builds the runtime image but never publishes it — deploy-by-digest has no artifact to point at #351).

Decision

Wait for Microsoft to republish aspnet:10.0 with the fixed OpenSSL, then bump the pin. Declined for now:

• Upgrading OpenSSL inside our Dockerfile. Fixes it today, but the runtime image would no longer be exactly the digest we pin, which is what Deploy: container/image hardening — non-root USER, pinned base digests, image vulnerability scan #267 requires.
• A dated Trivy exception for this CVE. Keeps the image unchanged but ships a known HIGH bug, and the repo's exception file (.github/security-exceptions.json) only covers the NuGet and npm gates today, so it would need a new mute mechanism.

To close this

1. Watch for a new aspnet:10.0 digest:
   sg docker -c 'docker buildx imagetools inspect mcr.microsoft.com/dotnet/aspnet:10.0'
   The digest differing from 2d584d81… is the signal.
2. Bump the pinned digest in src/Cluckwork.Api/Dockerfile. Dependabot's docker ecosystem is on a weekly schedule, so it may lag Microsoft by up to a week; bumping by hand, or triggering Dependabot, is fine. The sdk:10.0 build image may move in the same release and should be bumped alongside it.
3. Confirm the image job's Trivy step passes on that PR, then rerun the failed jobs on any PR that was blocked (build: enforce file-scoped namespaces and using placement at build time #985 at time of filing).

If Microsoft has not shipped a fixed image within a week, revisit the declined options above.

[mforce]

Upstream tracking: dotnet/dotnet-docker#7384, opened 2026-09-30. Its title names 10.0-noble-chiseled-extra, but a comment confirms the regular Ubuntu images (which we use) are affected too, and another says .NET 8 is as well. A maintainer (lbussell) acknowledged it at 2026-09-30 15:20 UTC ("taking a look"). No fixed image yet: as of filing, aspnet:10.0 still resolves to our pinned 2d584d81….

Ubuntu's fix is USN-8847 (3.0.13-0ubuntu3.16, released 2026-09-29): https://ubuntu.com/security/CVE-2026-84782

Watching #7384 closing, or a new aspnet:10.0 digest, is the trigger for step 2 above.

[mforce]

Exposure: none found, so this is a CI blocker, not a security fix. CVE-2026-84782 is in OpenSSL's DTLS (TLS over UDP) handshake code. Nothing under src/ uses DTLS, UDP sockets or QUIC. Every TLS connection the app makes (HTTPS, Postgres via Npgsql, Redis) is TLS over TCP, which this bug doesn't touch. Trivy flags the package because it is installed, not because the app reaches that code.

So no out-of-band release is needed. When Microsoft's fixed image lands, bump the pin on main and let it ship in the next normal release (currently #993).