this is offset by taking your job slightly seriously when implementing gh actions for your org by understanding how they're resolved and pinning them to commit SHAs, like how github themselves recommend under their basic security guide
after hearing similar stories from frontend developers who haven't even heard of "npm ci" or use range pinned dependencies on production systems, im almost never going to be sympathetic on blaming the package maintainers over developer ignorance following basic security guidelines
Sure, but then again the link you sent says: `Pin actions to a tag only if you trust the creator`
If I don't trust GitHub, why am I storing my source code on it and running CI via GitHub actions?
There are also some security gains from ranged pinning. Suppose I pin my library to `1.1.x` instead of `1.1.0`, when a security patch comes along for some CVE, my service will automatically run the `1.1.1` patch release the next time we deploy it.
I would say the likelihood of a developer getting lazy and not bumping a dependency causing a security incident is higher than a supply chain attack if you're already using reputable libraries.
Let's be frank, how many developers care enough to go into the 10 repos they've ended up owning to go and change their `actions/checkout@v3.1.6` to `actions/checkout@v3.1.7`.
https://docs.github.com/en/actions/security-guides/security-...
after hearing similar stories from frontend developers who haven't even heard of "npm ci" or use range pinned dependencies on production systems, im almost never going to be sympathetic on blaming the package maintainers over developer ignorance following basic security guidelines