fix: unblock CI — base image pinned to a digest predating two sqlite CVEs - #72
Open
alimobrem wants to merge 2 commits into
Open
fix: unblock CI — base image pinned to a digest predating two sqlite CVEs#72alimobrem wants to merge 2 commits into
alimobrem wants to merge 2 commits into
Conversation
Trivy started failing container-scan on every commit, including docs-only ones, on CVE-2026-11822 and CVE-2026-11824 in sqlite-libs. Nothing in the repo changed to cause it: main was green on 25 August, and both CVEs were published against a digest that has been pinned since well before that. This is the same shape as #56 (curl), and the same trade applies — an immutable base is worth chasing a digest occasionally — so this is again its own commit rather than a drive-by inside an unrelated change, and it stays pinned by digest rather than reverting to a floating tag. Both CVEs report Status=fixed with 3.34.1-11.el9_8 available, and the scan runs with ignore-unfixed, so a base carrying the patched package clears them. registry.access.redhat.com/ubi9/ubi-minimal:latest currently resolves to 7fbeae18, which ships sqlite-libs-3.34.1-11.el9_8 — confirmed with rpm -q inside the amd64 image, not inferred from the digest being newer. Verified by running the same Trivy invocation CI uses (--severity CRITICAL,HIGH --ignore-unfixed --exit-code 1) against an image built from this Dockerfile: the old digest reproduces exactly the two HIGH findings, the new one reports 0 for both the redhat 9.8 layer and the gobinary, and exits 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Second time a newly published CVE against the pinned base has turned main red with nothing in the repo having changed (#56, then the sqlite bump in the previous commit), so this addresses the recurrence rather than the instance. Detection was never the gap. Dependabot had already opened the exact right digest bump (#68) on 31 August at 15:27, before main went red — the fix sat in an open PR the whole time. So a new scheduled digest-refresh workflow would only duplicate a bot that already did its job; what actually bounded the outage was cadence. The docker ecosystem ran weekly, on Mondays, which means a CVE published on a Tuesday blocks every branch until the following Monday. Moving it to daily caps that at about a day using the machinery already in place, instead of adding a second thing that has to be maintained. Also documents the refresh procedure, which did not exist — the only prior note was a README line saying Dependabot opens a PR when a digest moves. The runbook says to check Dependabot first, and records two things that cost time to rediscover this round: - The builder stage is not scanned. ubi9/go-toolset still carries the vulnerable sqlite-libs-3.34.1-10, yet the final image scans clean, because CGO_ENABLED=0 means it contributes only the static binary and none of its RPMs. Bumping the builder would not have fixed this. - Reproducing the CI image on an arm64 workstation needs a native builder. docker build --platform linux/amd64 runs the builder's Go under emulation, which miscompiles it as "fatal error: found pointer to free object" — a local-only failure, since the runner is amd64-native. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changed
Two commits, deliberately separate:
Dockerfile:29— runtime base bumped fromsha256:8eb2830d…937f41tosha256:7fbeae18dc9476399f565e68255f602a3374ea8614ba3d14843565131a13ff93. Still pinned by digest; the pin is intentional and stays..github/dependabot.ymldocker ecosystem moved fromweeklytodaily, plus a written refresh procedure inSECURITY.md(cross-linked from the README's security section).Why
container-scanhas been failing on every commit since 31 August, including docs-only ones. Nothing in the repo caused it: main was green on 25 August, and CVE-2026-11822 / CVE-2026-11824 (SQLite arbitrary code execution via crafted FTS5) were published against a digest pinned well before that. Installedsqlite-libs 3.34.1-10.el9_8, fixed in3.34.1-11.el9_8.Same shape as #56 (curl), so the second commit addresses the recurrence rather than just the instance.
Verification
Ran the exact Trivy invocation CI uses (
--severity CRITICAL,HIGH --ignore-unfixed --exit-code 1):pulse-operator:ciimagemanager: 0)The new digest was confirmed to ship
sqlite-libs-3.34.1-11.el9_8viarpm -qinside the amd64 image — not inferred from the digest being newer. Both old and new digests were confirmed resolvable in the registry first, so this can't fail the build on a bad reference.Notes for the reviewer
The builder stage does not need a bump.
ubi9/go-toolsetstill carries the vulnerablesqlite-libs-3.34.1-10, yet the final image scans clean —CGO_ENABLED=0means it contributes only the staticmanagerbinary and none of its RPMs (Trivy saw 107 packages, all from ubi-minimal). Dependabot's #67 is unrelated to this failure and is left alone.Why cadence, not a new scheduled job. Detection was never the gap — Dependabot had already opened this exact bump as #68 on 31 August at 15:27, before main went red. The fix sat in an open PR the whole time. A scheduled digest-refresh workflow would duplicate a bot that already did its job; what bounded the outage was the weekly (Monday) cadence, under which a CVE published on a Tuesday blocks every branch until the following Monday. Daily caps that at ~1 day using machinery already in place.
This supersedes #68 — that PR can be closed once this merges.
A local-repro trap, now documented.
docker build --platform linux/amd64on an arm64 workstation fails withfatal error: found pointer to free objectingo mod download— qemu miscompiling Go, not a Dockerfile problem, since the runner is amd64-native. To scan a faithful image I built the builder natively on arm64 (it already cross-compiles viaGOOS=linux GOARCH=amd64) with only the runtime stage pinned to amd64, and verified that mirror is instruction-identical to the committed Dockerfile.No CHANGELOG entry — that file is organized strictly by released tag with no Unreleased section, so this belongs in the next release's entry.
🤖 Generated with Claude Code