[diggan]

> Using Third-Party GitHub Actions

Maybe I'm overly pedantic, but this whole section seems to miss the absolutely most obvious way to de-risk using 3rd party Actions, review the code itself? It talks about using popularity, number of contributors and a bunch of other things for "assessing the risk", but it never actually mentions reviewing the action/code itself.

I see this all the time around 3rd party library usage, people pulling in random libraries without even skimming the source code. Is this really that common? I understand for a whole framework you don't have time to review the entire project, but for these small-time GitHub Actions that handle releases, testing and such? Absolute no-brainer to sit down and review it all before you depend on it, rather than looking at the number of stars or other vanity-metrics.

[KolmogorovComp]

Because reading the code is useless if you can't pin the version, and the article explains well it's hard to do

> However, only hash pinning ensures the same code runs every time. It is important to consider transitive risk: even if you hash pin an Action, if it relies on another Action with weaker pinning, you're still exposed.

[ratrocket]

Depending on your circumstances (and if the license of the action allows it) it's "easy" to fork the action and use your own fork. Instant "pinning".

[carlmr]

But how does that solve the issue with the forked action not using pinned versions itself.

You need to recursively fork and modify every version of the GHA and do that to its sub-actions.

You'd need something like a lockgile mechanism to prevent this.

[ratrocket]

Yes, that is completely true -- transitive dependencies are a problem. What I suggested only works in the simplest cases and isn't a great solution, more of a bandaid.