Skip to content

Conversation

@jrfnl
Copy link
Collaborator

@jrfnl jrfnl commented Dec 14, 2025

GH Actions: "pin" all action runners

Recently there has been more and more focus on securing GH Actions workflows - in part due to some incidents.

The problem with "unpinned" action runners is as follows:

  • Tags are mutable, which means that a tag could point to a safe commit today, but to a malicious commit tomorrow.
    Note that GitHub is currently beta-testing a new "immutable releases" feature (= tags and release artifacts can not be changed anymore once the release is published), but whether that has much effect depends on the ecosystem of the packages using the feature.
    Aside from that, it will likely take years before all projects adopt immutable releases.
  • Action runners often don't even point to a tag, but to a branch, making the used action runner a moving target.
    Note: this type of "floating major" for action runners used to be promoted as good practice when the ecosystem was "young". Insights have since changed.

While it is convenient to use "floating majors" of action runners, as this means you only need to update the workflows on a new major release of the action runner, the price is higher risk of malicious code being executed in workflows.

Dependabot, by now, can automatically submit PRs to update pinned action runners too, as long as the commit-hash pinned runner is followed by a comment listing the released version the commit is pointing to.

So, what with Dependabot being capable of updating workflows with pinned action runners, I believe it is time to update the workflows to the current best practice of using commit-hash pinned action runners.

The downside of this change is that there will be more frequent Dependabot PRs.

If this would become a burden/irritating, the following mitigations can be implemented:

  1. Updating the Dependabot config to group updates instead of sending individual PRs per action runner.
  2. A workflow to automatically merge Dependabot PRs as long as CI passes.

Ref: https://docs.github.com/en/actions/reference/security/secure-use#using-third-party-actions

Dependabot: update config

👉 Important: this is for version updates only, not for security updates, which are handled separately and don't depend on this configuration.


This commit makes the following changes to the Dependabot config to reduce the number of Dependabot PRs, while still keeping the workflows up to date with a reasonable frequency:

  • It introduces a "group".
    By default Dependabot raises individual PRs for each update. Now, it will group updates to new minor or patch release for all action runners into a single PR.
    Updates to new major releases of action runners will still be raised as individual PRs.
  • It changes the schedule from weekly (on Monday, at whatever time this repo reaches the front of the HUGE queue which it will always have on Monday) to twice a month at a specific time which is not midnight.
    Aside from making the PRs less frequent, it should also make the arrival time more predictable as the queue created at 22:10 (in whatever timezone Dependabot runs in) will be next to nothing as it would need more repos to use this exact configuration.

Refs:

Recently there has been more and more focus on securing GH Actions workflows - in part due to some incidents.

The problem with "unpinned" action runners is as follows:
* Tags are mutable, which means that a tag could point to a safe commit today, but to a malicious commit tomorrow.
    Note that GitHub is currently beta-testing a new "immutable releases" feature (= tags and release artifacts can not be changed anymore once the release is published), but whether that has much effect depends on the ecosystem of the packages using the feature.
    Aside from that, it will likely take years before all projects adopt _immutable releases_.
* Action runners often don't even point to a tag, but to a branch, making the used action runner a moving target.
    _Note: this type of "floating major" for action runners used to be promoted as good practice when the ecosystem was "young". Insights have since changed._

While it is convenient to use "floating majors" of action runners, as this means you only need to update the workflows on a new major release of the action runner, the price is higher risk of malicious code being executed in workflows.

Dependabot, by now, can automatically submit PRs to update pinned action runners too, as long as the commit-hash pinned runner is followed by a comment listing the released version the commit is pointing to.

So, what with Dependabot being capable of updating workflows with pinned action runners, I believe it is time to update the workflows to the _current_ best practice of using commit-hash pinned action runners.

The downside of this change is that there will be more frequent Dependabot PRs.

If this would become a burden/irritating, the following mitigations can be implemented:
1. Updating the Dependabot config to group updates instead of sending individual PRs per action runner.
2. A workflow to automatically merge Dependabot PRs as long as CI passes.

Ref: https://docs.github.com/en/actions/reference/security/secure-use#using-third-party-actions
👉 Important: this is for **version** updates only, not for security updates, which are handled separately and don't depend on this configuration.

---

This commit makes the following changes to the Dependabot config to reduce the number of Dependabot PRs, while still keeping the workflows up to date with a reasonable frequency:
* It introduces a "group".
    By default Dependabot raises individual PRs for each update. Now, it will group updates to new minor or patch release for all action runners into a single PR.
    Updates to new major releases of action runners will still be raised as individual PRs.
* It changes the schedule from `weekly` (on Monday, at whatever time this repo reaches the front of the HUGE queue which it will always have on Monday) to twice a month at a specific time which is not midnight.
    Aside from making the PRs less frequent, it should also make the arrival time more predictable as the queue created at 22:10 (in whatever timezone Dependabot runs in) will be next to nothing as it would need more repos to use this exact configuration.

Refs:
* https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/optimizing-pr-creation-version-updates
* https://docs.github.com/en/code-security/dependabot/working-with-dependabot/dependabot-options-reference
@jrfnl jrfnl added this to the 2.7.0 milestone Dec 14, 2025
@jrfnl jrfnl requested a review from gmazzap December 14, 2025 13:39
@jrfnl jrfnl added dependencies Pull requests that update a dependency file github_actions Pull requests that update GitHub Actions code labels Dec 14, 2025
Copy link
Contributor

@gmazzap gmazzap left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a ton @jrfnl for the work and the explaination and context.

@gmazzap gmazzap merged commit 3f029bb into master Dec 15, 2025
66 checks passed
@gmazzap gmazzap deleted the feature/ghactions-pin-action-runners branch December 15, 2025 10:38
@jrfnl
Copy link
Collaborator Author

jrfnl commented Dec 15, 2025

@gmazzap No problem.
Pro-tip in case you want to make the same change elsewhere: use pinact.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file github_actions Pull requests that update GitHub Actions code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants