Every repo we give a lockfile becomes newly breakable by a routine Dependabot bump
⚠️ Observed once, not measured at scale. This is filed as a forward risk with one confirmed instance — not as a claim that it is happening estate-wide. See the scope section.
The mechanism
Dependabot edits uses: version strings in workflow files and does not touch .github/workflows/actions.lock. The lockfile then pins one version while the workflow requests another.
Before GitHub's Workflow Dependency Locking rollout (#657) that mismatch was harmless — the workflow simply used what it asked for. Under enforcement it stops the run starting, at startup_failure, with zero jobs and no logs.
The one confirmed instance
hyperpolymath/Cliometrics.jl:
05:01:45 remediation PR #50 merged
05:01:50 Governance runs -> `failure` (it STARTED; the fix worked)
05:38:10 dependabot[bot] "chore(deps): bump the actions group across 1 directory with 2 updates"
.github/workflows/codeql.yml +2/-2
.github/workflows/hypatia-scan.yml +1/-1
.github/workflows/push-email-notify.yml +1/-1
.github/workflows/actions.lock NOT TOUCHED
05:38:16 Hypatia Security Scan -> `startup_failure`
Four lines changed. Nothing deleted, repo entirely intact (141 files, 13 workflows). The commit is unremarkable — and it undid a fix 36 minutes old.
Scope — measured, and reassuring so far
0 of 20 remediated repos have a Dependabot commit since remediation began. So this is not currently widespread. But:
- the remediation sweep has now added a lockfile to 113 repos that previously had none
- every one of those is newly exposed to this, where it was not before
- Dependabot runs on a schedule, so exposure accrues rather than being a one-off
Remediating without addressing this makes a repo more fragile in this one specific respect, not less. That trade is still worth it — a repo with a correct lockfile runs, and one without does not — but the gap should be closed rather than left.
Options
(A) Post-Dependabot regeneration job. A workflow triggered on Dependabot's PRs that runs gh actions-lock and commits the result into the same PR. Closes the gap fully; needs write permission on Dependabot PRs.
(B) dependabot.yml ignore for actions. Stop Dependabot bumping GitHub Actions entirely, and bump them deliberately alongside lockfile regeneration. Simplest and safest; loses automatic action security updates.
(C) A CI gate that fails a PR when a workflow's uses: changes without actions.lock changing. Does not fix it, but makes it visible and unmergeable rather than silently fatal. Cheapest to build.
(D) Accept and monitor. The estate-wide drift detector (lockfile-drift-detect.yml in standards) already exists; extend it to report this specific class.
Suggest (C) + (D) as the low-risk pair, with (A) if the permission model allows it.
⚠️ Whatever is chosen must handle the partial-lockfile trap (#657): regenerating with gh actions-lock alone produces a lockfile that omits reusable-workflow callers, and a partial lockfile is worse than none — P(startup_failure | has lockfile) = 91.7% vs 15.8% without. Any automated regeneration must hand-add '<path>': [] entries for callers and restore SPDX to line 1, exactly as the remediation script does.
Related: #657, #669.
Every repo we give a lockfile becomes newly breakable by a routine Dependabot bump
The mechanism
Dependabot edits
uses:version strings in workflow files and does not touch.github/workflows/actions.lock. The lockfile then pins one version while the workflow requests another.Before GitHub's Workflow Dependency Locking rollout (#657) that mismatch was harmless — the workflow simply used what it asked for. Under enforcement it stops the run starting, at
startup_failure, with zero jobs and no logs.The one confirmed instance
hyperpolymath/Cliometrics.jl:Four lines changed. Nothing deleted, repo entirely intact (141 files, 13 workflows). The commit is unremarkable — and it undid a fix 36 minutes old.
Scope — measured, and reassuring so far
0 of 20 remediated repos have a Dependabot commit since remediation began. So this is not currently widespread. But:
Remediating without addressing this makes a repo more fragile in this one specific respect, not less. That trade is still worth it — a repo with a correct lockfile runs, and one without does not — but the gap should be closed rather than left.
Options
(A) Post-Dependabot regeneration job. A workflow triggered on Dependabot's PRs that runs
gh actions-lockand commits the result into the same PR. Closes the gap fully; needs write permission on Dependabot PRs.(B)
dependabot.ymlignore for actions. Stop Dependabot bumping GitHub Actions entirely, and bump them deliberately alongside lockfile regeneration. Simplest and safest; loses automatic action security updates.(C) A CI gate that fails a PR when a workflow's
uses:changes withoutactions.lockchanging. Does not fix it, but makes it visible and unmergeable rather than silently fatal. Cheapest to build.(D) Accept and monitor. The estate-wide drift detector (
lockfile-drift-detect.ymlinstandards) already exists; extend it to report this specific class.Suggest (C) + (D) as the low-risk pair, with (A) if the permission model allows it.
gh actions-lockalone produces a lockfile that omits reusable-workflow callers, and a partial lockfile is worse than none —P(startup_failure | has lockfile) = 91.7%vs15.8%without. Any automated regeneration must hand-add'<path>': []entries for callers and restore SPDX to line 1, exactly as the remediation script does.Related: #657, #669.