4 ms·

The crazier part is, people typically don't even pin versions! It's possible to list a commit hash, but usually people just use a tag or branch name, and those

by sestep 2y ago

The crazier part is, people typically don't even pin versions! It's possible to list a commit hash, but usually people just use a tag or branch name, and those can easily be changed (and often are, e.g. `v3` being updated from `v3.5.1` to `v3.5.2`).

harrisi 2y ago
You and someone else pointed this out. I only use GitHub-org actions, and I just thought that surely there would be a "one version to rule them all" type rule.. how else can you audit things? I've never seen anything recommending specifying a specific commit hash or anything for GitHub actions. It's always just v1, v2, etc.
- mcpherrinm 2y ago
  OpenSSF scorecard flags dependencies (including GitHub actions) which aren’t pinned by hash https://scorecard.dev/ https://scorecard.dev/ https://github.com/ossf/scorecard/blob/main/docs/checks.md#pinned-dependencies https://github.com/ossf/scorecard/blob/main/docs/checks.md#p...
- evntdrvn 2y ago
  it is documented as recommended here fwiw: https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions#using-third-party-actions https://docs.github.com/en/actions/security-for-github-actio...
  - sundarurfriend 2y ago
    And the syntax to do that is to use `foo/bar@commitshagoeshere` as in - uses: RafaelGSS/bad-action@e20fd1d81b3f403df56f5f06e2aa9653a6a60763 # v1.0.1 (example from https://blog.rafaelgss.dev/why-you-should-pin-actions-by-commit-hash https://blog.rafaelgss.dev/why-you-should-pin-actions-by-com...)
  - 0rzech 2y ago
    This. Using tags is acceptable only for official GitHub actions, anything else should be pinned.
nextts 2y ago
Fuck. Insecure defaults again. I argue that a version specifier should be only a hash. Nothing else is acceptable. Forget semantic versions. (Have some other method for determining upgrade compatibility you do out of band. You need to security audit every upgrade anyway). Process: old hash, new hash, diff code, security audit, compatibility audit (semver can be metadata), run tests, upgrade to new hash.

by sestep 2y ago

harrisi 2y ago

You and someone else pointed this out. I only use GitHub-org actions, and I just thought that surely there would be a "one version to rule them all" type rule.. how else can you audit things? I've never seen anything recommending specifying a specific commit hash or anything for GitHub actions. It's always just v1, v2, etc.

mcpherrinm 2y ago
OpenSSF scorecard flags dependencies (including GitHub actions) which aren’t pinned by hash https://scorecard.dev/ https://scorecard.dev/ https://github.com/ossf/scorecard/blob/main/docs/checks.md#pinned-dependencies https://github.com/ossf/scorecard/blob/main/docs/checks.md#p...
evntdrvn 2y ago
it is documented as recommended here fwiw: https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions#using-third-party-actions https://docs.github.com/en/actions/security-for-github-actio...
- sundarurfriend 2y ago
  And the syntax to do that is to use `foo/bar@commitshagoeshere` as in - uses: RafaelGSS/bad-action@e20fd1d81b3f403df56f5f06e2aa9653a6a60763 # v1.0.1 (example from https://blog.rafaelgss.dev/why-you-should-pin-actions-by-commit-hash https://blog.rafaelgss.dev/why-you-should-pin-actions-by-com...)
- 0rzech 2y ago
  This. Using tags is acceptable only for official GitHub actions, anything else should be pinned.

nextts 2y ago

Fuck. Insecure defaults again. I argue that a version specifier should be only a hash. Nothing else is acceptable. Forget semantic versions. (Have some other method for determining upgrade compatibility you do out of band. You need to security audit every upgrade anyway). Process: old hash, new hash, diff code, security audit, compatibility audit (semver can be metadata), run tests, upgrade to new hash.