-
-
Notifications
You must be signed in to change notification settings - Fork 4
GH Actions: "pin" all action runners #57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Conversation
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
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
This commit makes two changes to the Dependabot config:
1. It introduces a "cooldown" period for updates to a new major release of action runners.
What this means, is that for updates to a new major, the Dependabot will be delayed by 10 days, which should give projects the chance to fix any "teething problems".
2. 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.
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
|
=== This is an auto-generated comment === Thank you for your PR. Please review the resulting final markdown files via the created artifact. N.B.: the above link will automatically be updated when this PR is updated. |
jrfnl
added a commit
that referenced
this pull request
Sep 19, 2025
Follow up on PR #57 Turns out that the `cooldown` configuration option is not supported for the `github-actions` ecosystem.... _sigh_ So I guess I better remove it again as otherwise Dependabot is blocked from running due to this "configuration error".
jrfnl
added a commit
that referenced
this pull request
Sep 19, 2025
Follow up on PR #57 Turns out that the `cooldown` configuration option is not supported for the `github-actions` ecosystem.... _sigh_ So I guess I better remove it again as otherwise Dependabot is blocked from running due to this "configuration error".
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.
Description
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:
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.
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:
Ref: https://docs.github.com/en/actions/reference/security/secure-use#using-third-party-actions
Dependabot: update config
This commit makes two changes to the Dependabot config:
What this means, is that for updates to a new major, the Dependabot will be delayed by 10 days, which should give projects the chance to fix any "teething problems".
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.
Refs: