Pin the actions that compose this action

[ericcornelissen]

Summary

Currently, the actions that compose this action are specified by their major version only. This has some advantages, mainly that users always use up-to-date versions of those actions without having to upgrade this action. However it has some disadvantages as well, mainly potential instability and possible security concerns.

All Options

• Keep specifying these actions by their major version
• Specify these actions by an exact version
• Specify these actions by a commit SHA (associated to an exact version)

Specify these actions by an exact version

The advantage is increased stability for users in the off chance dependent actions release changes that don't quite work for this action.

The disadvantage is that updates to dependent actions now require this action to release an update as well (note: not every update in a dependent action necessarily requires this action to release an update). Similarly, this increases maintenance of this action as all dependent actions have to be kept up-to-date.

Example

- uses: actions/checkout@v3
+ uses: actions/checkout@v3.5.3

Specify these actions by a commit SHA (associated to an exact version)

Analysis is pretty much the same as the "Specify these actions by an exact version" option. The main advantage of this over that is the security benefits of pinning by SHA.

Example

- uses: actions/checkout@v3
+ uses: actions/checkout@c85c95e3d7251135ab7dc9ce3241c5835cc595a9 # v3.5.3

Open Questions

• Is there a pre-existing automated way of keeping dependent actions in action.yml up-to-date (similar to Dependabot keeping action in GitHub Actions workflows up-to-date)?
• What do other (prominent) composite actions do in this regard?
• Does GitHub have guidelines for composite actions in this regard?

[ericcornelissen]

"Does GitHub have guidelines for composite actions in this regard?"

The official docs for composite actions states:

We strongly recommend that you include the version of the action you are using by specifying a Git ref, SHA, or Docker tag number. If you don't specify a version, it could break your workflows or cause unexpected behavior when the action owner publishes an update.

Thus, sticking with Git refs as we do currently would be fine by GitHub's guidelines.

Interestingly, the Semgrep scan is reporting on the use of tags as well:

An action sourced from a third-party repository on GitHub is not pinned to a full length commit SHA. Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload.

References:

• Semgrep Rule
• owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components
• docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#using-third-party-actions

"What do other (prominent) composite actions do in this regard?"

I did not really find any evidence that many other composite-based actions use commit SHAs for their dependencies. Please let me know here if you know of one.

"Is there a pre-existing automated way of keeping dependent actions in action.yml up-to-date"

From what I can tell Dependabot does not have support for this (missed opportunity...). I did find mheap/pin-github-action which actually has support for this!