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.

▲

mmarian 2 days ago | parent | next [-]

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.

▲

phist_mcgee 2 days ago | parent | next [-]

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 12 hours ago | parent | prev [-]

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

	▲	mmarian 11 hours ago \| parent [-]
		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.

▲

Munksgaard 2 days ago | parent | prev | next [-]

Even with a lock file, the action can download and execute arbitrary code from the internet.

	▲	shykes 2 days ago \| parent [-]
		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.

▲

xenophonf 2 days ago | parent | prev [-]

"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.