Skip to content

build(deps): refresh the pinned base image digests - #140

Merged
bgard68 merged 1 commit into
mainfrom
claude/new-session-muubr7
Aug 25, 2026
Merged

build(deps): refresh the pinned base image digests#140
bgard68 merged 1 commit into
mainfrom
claude/new-session-muubr7

Conversation

@bgard68

@bgard68 bgard68 commented Aug 25, 2026

Copy link
Copy Markdown
Owner

Clears the four open Trivy alerts on the API image — two systemd CVEs, each reported twice (a local privilege escalation via systemd-homed, and an unprivileged local user being able to terminate arbitrary processes). Both live in Debian packages inside the base image, not in application code.

Why they were open, and why this is the whole fix

The scan runs with ignore-unfixed: true, so anything it reports has a patch available. These were waiting on nothing but a digest refresh — Microsoft had already rebuilt the images.

They didn't fail CI because the gate is severity: CRITICAL,HIGH and these are MEDIUM. That's the design working as intended: the gate blocks on what's urgent, the Security tab shows what's coming. It just needs someone to act on the tab.

Pinning by digest is what makes the base auditable (review finding M10). The cost of that is exactly this — a tag would have picked the rebuild up silently, a digest has to be moved deliberately.

sdk:10.0     e1fc6e42… -> e1ffd2a9…
aspnet:10.0  207cc514… -> a4556ed0…

Both read from mcr.microsoft.com today, the way the comment at the top of Dockerfile.api describes.

Verification

Container build & scan runs on the Dockerfile.api path, so its own Trivy step on this PR is the check on whether this actually cleared them — and it uploads SARIF either way. Merging re-scans main and closes the alerts.

Also

dapper pinned the identical digests, so it carried the identical exposure with no alerts raised against it. Same one-line change: #141.

🤖 Generated with Claude Code

https://claude.ai/code/session_019h7znwAftvs36vD4YwKMRf


Generated by Claude Code

Clears the four open Trivy alerts on the API image (two systemd CVEs, each
reported twice): a local privilege escalation via systemd-homed, and an
unprivileged local user being able to terminate arbitrary processes. Both are
Debian packages inside the base image, not application code.

The scan runs with ignore-unfixed, so anything it reports has a patch
available — these were waiting on nothing but a digest refresh. Pinning by
digest is what makes the base auditable (review finding M10), and the cost of
that is exactly this: the pin has to be moved deliberately when the upstream
image is rebuilt.

  sdk:10.0     e1fc6e42… -> e1ffd2a9…
  aspnet:10.0  207cc514… -> a4556ed0…

Both taken from mcr.microsoft.com today, the way the comment at the top of the
file describes. Container build & scan runs on this path, so its own Trivy step
is the check on whether this actually cleared them.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019h7znwAftvs36vD4YwKMRf
@bgard68
bgard68 merged commit 826e5af into main Aug 25, 2026
10 checks passed
@bgard68
bgard68 deleted the claude/new-session-muubr7 branch August 25, 2026 05:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant