5 ms·

GitHub Actions doesn't have a lock file, so your repo is still prone to transitive attacks if the SHA-locked actions you use also happen to use other composite

by maxloh 6mo ago

GitHub Actions doesn't have a lock file, so your repo is still prone to transitive attacks if the SHA-locked actions you use also happen to use other composite actions by tags, which could be compromised in the future.

xenophonf 6mo ago
"Require actions to be pinned to a full-length commit SHA" applies to composite actions, too. I had to replace pre-commit/action as a result.
Munksgaard 6mo ago
Even with a lock file, the action can download and execute arbitrary code from the internet.
- shykes 6mo ago
  It would be cool if CI could inject a platform-wide lockfile into every remote download or lookup made by your scripts. So if you pull a container or git tag, the CI platform would automatically ensure that the exact digest downloaded is controlled by a lock file that you can inspect, check in, etc.
mmarian 6mo ago
Agreed. Good news is GitHub will address that with Immutable Releases https://github.blog/news-insights/product-news/whats-coming-to-our-github-actions-2026-security-roadmap/ https://github.blog/news-insights/product-news/whats-coming-... You won't even need to use commit SHA as long as the maintainer follows this approach.
- phist_mcgee 6mo ago
  What an absolute joke that it has taken GitHub this long to clean up it's act when it comes to supply chain security.
- cyberclimb 6mo ago
  The actions/checkout repo still doesn't even use immutable releases so I'll believe it when I see it https://github.com/actions/checkout/issues/2316 https://github.com/actions/checkout/issues/2316
  - mmarian 6mo ago
    Yes, it's maddening. Especially since it's a fair amount of effort to move to commit SHA pinning and establish a good maintenance/monitoring process around it; if I knew it would be adopted quickly, I could argue that people should just wait and accept temporary risk.

5 ms·

GitHub Actions doesn't have a lock file, so your repo is still prone to transitive attacks if the SHA-locked actions you use also happen to use other composite

by maxloh 6mo ago

xenophonf 6mo ago
"Require actions to be pinned to a full-length commit SHA" applies to composite actions, too. I had to replace pre-commit/action as a result.
Munksgaard 6mo ago
Even with a lock file, the action can download and execute arbitrary code from the internet.
- shykes 6mo ago
  It would be cool if CI could inject a platform-wide lockfile into every remote download or lookup made by your scripts. So if you pull a container or git tag, the CI platform would automatically ensure that the exact digest downloaded is controlled by a lock file that you can inspect, check in, etc.
mmarian 6mo ago
Agreed. Good news is GitHub will address that with Immutable Releases https://github.blog/news-insights/product-news/whats-coming-to-our-github-actions-2026-security-roadmap/ https://github.blog/news-insights/product-news/whats-coming-... You won't even need to use commit SHA as long as the maintainer follows this approach.
- phist_mcgee 6mo ago
  What an absolute joke that it has taken GitHub this long to clean up it's act when it comes to supply chain security.
- cyberclimb 6mo ago
  The actions/checkout repo still doesn't even use immutable releases so I'll believe it when I see it https://github.com/actions/checkout/issues/2316 https://github.com/actions/checkout/issues/2316
  - mmarian 6mo ago
    Yes, it's maddening. Especially since it's a fair amount of effort to move to commit SHA pinning and establish a good maintenance/monitoring process around it; if I knew it would be adopted quickly, I could argue that people should just wait and accept temporary risk.