The check is one line of logic. Resolve the tag named in the pin comment, compare the result against the SHA on that line, and fail the build when they disagree. That is one API call, and according to the dev.to writeup almost nobody performs it [13]. It catches precisely the shape tj-actions had, where the tags were moved and the commits were not [12]. A disagreement narrows to two cases and both deserve a human look: either your pin is behind the tag, or the tag was repointed under you [13].
That check has to live in software because the review it replaces cannot work. A pinned line followed by `# v5.1.0` makes two claims, and GitHub enforces the first while ignoring the second, because the second is a comment [11]. The diff a reviewer is asked to approve is two hex strings that differ, carrying nothing that says what changed [7].
Volume finishes the job. GitHub's own engineering blog describes a repository where roughly one in six commits were Dependabot version bumps, 61 of them in twelve months, sometimes several in a single day [8]. That works out to about five a month [1]. One maintainer wrote on her own blog that she blindly accepts Dependabot pull requests and that this negates the benefit of pinning [9].
The 61 is a claim about someone else's repository. For it to describe yours you need a comparable count of third-party actions and upstreams that cut releases as often. Four pinned actions with a quarterly bump is a workload a person can genuinely read, and there the reviewer is a real control. A dozen workflows deep in composite actions is the other case, and there the reviewer is a rubber stamp with a merge button.
The asymmetry underneath is the part I would raise at review. Dependabot Alerts do not cover SHA-pinned actions, and users have been asking GitHub to fix that for a while [10]. The format you are told to adopt is the one the vulnerability alerting does not read, so your staleness signal arrives instead as version-update pull requests whose diffs contain no information [7].
The scale is why this belongs in a required check rather than in someone's discipline. GitHub reported 11.5 billion Actions minutes in 2025, up 35% year over year [14], which puts the prior year near 8.5 billion [2]. Datadog's security research found two out of three organisations have at least one vulnerability in an Actions workflow [15]. The incidents kept arriving after tj-actions: in May 2026 a threat group compromised 5,561 public repositories in about six hours by pushing workflows carrying dormant `workflow_dispatch` backdoors [16], and TanStack's router was breached through cache poisoning that led to OIDC token theft and 84 malicious npm packages [17]. The source's explanation for the move to CI is unglamorous. CI holds credentials and gets less review than application code [18].
My read, with the context stated. Keep the pin, since the immutability is real and it held in March 2025 [4]. Then stop treating the bump review as a control and enforce the comment mechanically, so the line that looks like diligence has something behind it besides eyesight.
