Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub Actions is the weakest link

nesbitt.io

Post reply on HN
Print view View original

11–20 of 95 posts

Re: GitHub Actions is the weakest link

#11

Post by arionmiles »

rmunn wrote: post #4

Back when GitHub Actions first came out, I used commit hashes rather than tags in all my `uses:` lines. Some of my colleagues disagreed, saying that tags were secure enough. I eventually said, "Well, for well-known actions like actions/checkout, sure; if that one gets compromised it'll be all over the news within minutes." But for all the third-party actions, I kept commit hashes. I feel rather vindicated now. There'…

I feel pretty happy we use Renovator (EDIT: It's Renovate) at my current workplace which by default will raise PRs to change any tags for actions with the SHA instead. Then, even when it bumps the version in future PRs, it bumps the SHA (with a comment of which tag version it represents)

Re: GitHub Actions is the weakest link

#12

Post by maxloh »

rmunn wrote: post #4

Back when GitHub Actions first came out, I used commit hashes rather than tags in all my `uses:` lines. Some of my colleagues disagreed, saying that tags were secure enough. I eventually said, "Well, for well-known actions like actions/checkout, sure; if that one gets compromised it'll be all over the news within minutes." But for all the third-party actions, I kept commit hashes. I feel rather vindicated now. There'…

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.

Re: GitHub Actions is the weakest link

#13

Post by rileymichael »

rmunn wrote: post #4

Back when GitHub Actions first came out, I used commit hashes rather than tags in all my `uses:` lines. Some of my colleagues disagreed, saying that tags were secure enough. I eventually said, "Well, for well-known actions like actions/checkout, sure; if that one gets compromised it'll be all over the news within minutes." But for all the third-party actions, I kept commit hashes. I feel rather vindicated now. There'…

just noting that pinning within your own actions is not enough, you also need to ensure any composite actions do not use mutable references (for actions, docker images, etc.)

Re: GitHub Actions is the weakest link

#14

Post by shykes »

I apologize in advance for the plug. I've spent the last 5 years warning of the importance of not leaving CI locked in a black box platform and proprietary DSL. All the while going on a quest to reinvent CI as an open, programmable platform. Honestly it's still a work-in-progress: it turns out that reinvention is hard! But, if you want a glimpse of what CI can be when you shed 30 years of legacy, consider checking out Dagger (https://dagger.io).

Or, if you just want to talk about the future of CI with like-minded systems engineers, without committing to using a particular product, consider joining our Discord: https://discord.com/invite/dagger-io

Re: GitHub Actions is the weakest link

#15

Post by bastardoperator »

recursivedoubts wrote: post #10

Programming in YAML has always seemed crazy to me. Actions seem like a great place to create a simple mixed imperative/declarative scripting language (js extension or whatever) with a solid instrumented/observable/debuggable runtime and an OO API that can be run locally against mock infrastructure.

No thanks, Jenkins has three DSL languages and none of it is good. You dont have to inline code in yaml, you can call a script and call it day, write that script in any language you want.

Re: GitHub Actions is the weakest link

#16

Post by cenamus »

bastardoperator wrote: post #15
recursivedoubts wrote: post #10

Programming in YAML has always seemed crazy to me. Actions seem like a great place to create a simple mixed imperative/declarative scripting language (js extension or whatever) with a solid instrumented/observable/debuggable runtime and an OO API that can be run locally against mock infrastructure.

No thanks, Jenkins has three DSL languages and none of it is good. You dont have to inline code in yaml, you can call a script and call it day, write that script in any language you want.

You can do the same in jenkins, but a bit of scripting is probably more readable in Groovy than whatever Yaml dsl.

But I totally agree that the Jenkins langs are terrible, the errors even worse, somehow they managed to make jvm backtraces even more unreadable.

Re: GitHub Actions is the weakest link

#17

Post by tagraves »

tomaytotomato wrote: post #3

Github actions is running like treacle now. Even when our company pays lots of money for cloud and private Github runners. I know its the go-to punchbag but I think enabling Copilot reviews globally for a large proportion of Github was a bit hasty. The security problems aside, if it continues this way, people won't be able to ship and deploy code from Github actions. We might dare I say it, have to go back to self ho…

shameless self plug, but please check out RWX! (rwx.com)

Re: GitHub Actions is the weakest link

#18

Post by tecleandor »

arionmiles wrote: post #11
rmunn wrote: post #4

Back when GitHub Actions first came out, I used commit hashes rather than tags in all my `uses:` lines. Some of my colleagues disagreed, saying that tags were secure enough. I eventually said, "Well, for well-known actions like actions/checkout, sure; if that one gets compromised it'll be all over the news within minutes." But for all the third-party actions, I kept commit hashes. I feel rather vindicated now. There'…

I feel pretty happy we use Renovator (EDIT: It's Renovate) at my current workplace which by default will raise PRs to change any tags for actions with the SHA instead. Then, even when it bumps the version in future PRs, it bumps the SHA (with a comment of which tag version it represents)

Is it Renovator or Renovate? I'm trying to find it to check it out...

Re: GitHub Actions is the weakest link

#19

Post by arionmiles »

tecleandor wrote: post #18
arionmiles wrote: post #11

Earlier quoted context omitted.

I feel pretty happy we use Renovator (EDIT: It's Renovate) at my current workplace which by default will raise PRs to change any tags for actions with the SHA instead. Then, even when it bumps the version in future PRs, it bumps the SHA (with a comment of which tag version it represents)

Is it Renovator or Renovate? I'm trying to find it to check it out...

Oops, my bad. We keep calling it Renovator internally but the name is RenovateBot or Renovate.

https://docs.renovatebot.com/

Re: GitHub Actions is the weakest link

#20

Post by electricapps »

Great writeup. Though combined with the lack of lockfiles for transitive actions, relying purely on static analysis is tough. Linter like zizmor are great, but they struggle with deep composite actions trees and runtime template injection.

I got frustrated with the lack of security to started working myself on an open-source runtime sandbox for GHA: https://github.com/electricapp/hasp

The first check was inspired by the trivy attack. hasp enforces SHA pinning AND checks that a comment (# v4.1.2) actaully resolves to its preceding SHA. That grew into a larger suite of checks.

Instead of just statically parsing YAML it hooks into the runner env itself. Some of its runtime checks mirror what zizmor already does including resolving upstream SHAs to canonical branches (no impostor commits) and traversing the transitive dependency tree. I have a PR up with a comparison document here (hasp vs. zizmor): https://github.com/electricapp/hasp/pull/13/changes#diff-aab...

Furthermore, it sandboxes itself to prevent sensitive exfiltration by acting as a token broker which injects the secret at runtime -- the GH token can only ever be used to call the GH API. It uses landlock, seccomp, and eBPF via Rust, so no docker. The token broker sandbox can also be used to wrap a generic executable giving hasp generic applicability beyond GHA context (i.e. agentic or other contexts, where token runtime injection seems quite in vogue)

I'm using this as a stopgap until GH rolls out some of the features on its roadmap. I'm moving torward treating the runner as a zero-trust or actively malicious environment, so this was my small contribution on that front.

Post reply on HN