Feature request: minimum release age (cooldown) for resolved pins

Open
#132 3 comments 2 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Active
Tech stack
github-actions, go
Domain
cli, security

Research direction

Start by tracing the entry points for gh actions-lock, --relock, --verify, and --no-fix, focusing on how actions.lock references are resolved and checked. Compare the proposed --min-age behavior across initial pinning, relocking, ref narrowing, and verification, then clarify the fallback and configuration semantics before implementation.

Written by the indexing model from the issue text.

Description

area:cli feature-request

Summary

Add an option to exclude releases published less than N days ago when resolving action references into lockfile pins — the same "cooldown" concept as pinact's -min-age, Dependabot's cooldown, or the npm ecosystem's minimumReleaseAge settings, applied to actions.lock.

Motivation

  • Avoiding freshly-published releases is one of the cheapest supply-chain defenses. Recent research found that most compromised packages are detected and removed within about a week of publication (see https://nesbitt.io/2026/03/04/package-managers-need-to-cool-down.html), so simply not adopting versions younger than a few days moves consumers out of the blast window.
  • Automated update paths already have workarounds: tools like Renovate (minimumReleaseAge) and Dependabot (cooldown) can gate their own update proposals.
  • But when a maintainer runs gh actions-lock or gh actions-lock --relock manually, the tool always resolves the current latest SHA. There is no substitute on this path — unless the tool itself offers an age gate, manual relocking can pull in a release published minutes ago.

Prior art

  • Dependabot cooldown (default-days, semver-*-days): version updates wait out a cooldown by default (3 days); security updates bypass it. Same vendor, same problem space.
  • npm ecosystem: npm CLI min-release-age, pnpm minimumReleaseAge (on by default since pnpm 11), Yarn npmMinimalAgeGate, Bun install.minimumReleaseAge.
  • pinact -min-age / --verify-min-age: the direct predecessor for pinning GitHub Actions; filters candidate versions by tag commit date / release publish date, and can verify existing pins against the same floor.
  • action-locker --min-age-days: a third-party lockfile tool with the same feature, including a fallback mode that walks back to the newest release that clears the age floor instead of hard-failing.
  • Renovate minimumReleaseAge: feasible here because GitHub tag/release lookups expose release timestamps — the same data sources actions.lock resolution already touches.

Proposed semantics (strawman)

  • A --min-age <duration> flag and/or a lockfile/config field.
  • Applied wherever a version is selected: initial pinning, --relock, and ref narrowing (e.g. @v4 resolves to the newest v4.x.y tag that clears the age floor).
  • When no version satisfies the window: either fail-closed with a clear error, or fall back to the newest release that does (action-locker style) — open to maintainer preference.
  • --verify / --no-fix could additionally flag pins younger than the window (the pinact --verify-min-age equivalent), so CI can enforce the policy without restricting manual runs.

Notes

  • Checked gh actions-lock --help (v0.1.6): no age-related option exists.
  • I couldn't find an existing issue or discussion covering this (searched this repo's issues, github/actions-lockfile, cli/cli RFC #13314, and github/roadmap).
Dominant language
Go
Stars
253
Forks
15
Avg merge
19h 30m
Merged PRs (30d)
60

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from github/gh-actions-lock

All issues in github/gh-actions-lock

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.