chore(deps): track Docker base images in dependabot - #154
Merged
Conversation
Salvages the one useful part of #39 and deliberately drops the rest. Both Dockerfiles — `/Dockerfile` (the CLI image, python:3.13-slim) and `/docker/Dockerfile` (remo-web: node:20-slim, python:3.11-slim) — were unwatched, so a base image could sit on an unpatched tag indefinitely. Base images are where container CVEs usually arrive, and an untracked one fails invisibly: it simply never produces a PR. What is NOT taken from #39, and why: * Its cooldown additions are already on main — #70 added `default-days: 7` to both the pip and github-actions entries on 2026-07-22. * Its `[tool.uv] exclude-newer = "7 days"` would reopen a security advisory. Applied to this repo it resolves cryptography to 49.0.0 instead of 50.0.0, and 49.0.0 sits inside the vulnerable range of GHSA `>=44.0.0,<50.0.0` — the advisory cleared only yesterday. It also invalidates uv.lock outright (`uv lock --check` fails). The PR's claim that "security updates are never delayed" holds for Dependabot, which exempts them; uv's `exclude-newer` is a resolution-time filter with no such carve-out. For a repo with a committed lockfile the cooldown belongs at the proposal layer, where it already is. * Its docker directories were `/` and `/notifier`. `/notifier` exists only on an unmerged feature branch, so that entry would have looked like coverage while providing none. `tests/unit/test_dependabot_config.py` guards both directions: every configured directory must exist (which is what #39 got wrong), and every Dockerfile must be covered by some entry (so a new or moved image cannot go unwatched). Mutation-verified — #39's exact `/notifier` path fails three checks. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NiM3TyqKUySZr9en9quq5c
This was referenced Aug 7, 2026
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
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.
Salvages the one useful part of #39 and deliberately drops the rest. Closes #39.
What this adds
Both Dockerfiles were unwatched:
/Dockerfilepython:3.13-slim/docker/Dockerfilenode:20-slim,python:3.11-slimA base image could sit on an unpatched tag indefinitely. Base images are where container CVEs usually arrive, and an untracked one fails invisibly — it simply never produces a PR.
What this does NOT take from #39, and why
1. Its cooldown additions are already on main. #70 added
default-days: 7to both thepipandgithub-actionsentries on 2026-07-22. That half of #39 is redundant.2. Its
[tool.uv] exclude-newer = "7 days"would reopen a security advisory.Not theoretical — I applied it and resolved:
cryptography 50.0.0was published 5 days ago, inside the 7-day window. 49.0.0 sits inside the vulnerable range of the>=44.0.0, <50.0.0advisory — the one cleared yesterday in #145. It also invalidates the lockfile outright (uv lock --checkfails).The PR body says "Security updates are never delayed". That is true of Dependabot, which exempts security updates from cooldown. It is not true of uv's
exclude-newer, which is a blunt resolution-time filter with no security carve-out. For a repo with a committed lockfile, resolution only happens when someone deliberately runsuv lock— which Dependabot already gates. The cooldown belongs at the proposal layer, where it already is; adding it at the resolver buys nothing and costs security latency.3. Its docker directories were wrong.
/and/notifier— but/notifierexists only on an unmerged feature branch. That entry would have looked like Docker coverage while providing none, and nothing would have said so.Also worth noting for whoever revisits #39: its diff is 73 files, because the branch is stale (June 15) and carries the entire unmerged notifier feature — that work is #45/#47. Merging #39 would pull all of it in.
Guard
tests/unit/test_dependabot_config.pychecks both directions:Mutation-verified: #39's exact
/notifierpath fails 3 checks; dropping/dockerfails the coverage check; removing a cooldown fails the third. 2135 tests pass.🤖 Generated with Claude Code
https://claude.ai/code/session_01NiM3TyqKUySZr9en9quq5c