Hacker News new | ask | show | jobs
by maxloh 56 days 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.
3 comments

Agreed. Good news is GitHub will address that with Immutable Releases 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.
What an absolute joke that it has taken GitHub this long to clean up it's act when it comes to supply chain security.
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

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.
Even with a lock file, the action can download and execute arbitrary code from the internet.
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.
"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.