3 ms·
> 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 A
by diggan 1y ago
> 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 1y agoBecause 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 1y agoDepending 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 1y agoBut 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 1y agoYes, 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.