Live data from Hacker News

GitHub Actions is the weakest link

nesbitt.io

91–95 of 95 posts

Re: GitHub Actions is the weakest link

#91
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)

A new problem is that even pinned actions themselves download unpinned transitive dependencies, such as the case with trivy action.

Zizmor recently shipped a rule to warn of such actions, but it only does it for two known actions so far.

Re: GitHub Actions is the weakest link

#92
post #67
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'…

Even SHA pinning only lets you go one hop. If the pinned action itself uses any non pinned actions, you’re still susceptible. I don’t think this problem is fixable without a higher level way to specify the full nested tree. Something like TOFU for the first time your action ran (pinning all children as of that run) might be an improvement, but that is still can be gamed by a timed attack that modifies the action at a…

It is more than just a tree of actions, since actions bring in shell scripts and they can download and execute arbitrary code that isn’t pinned.

Re: GitHub Actions is the weakest link

#93
post #78

Earlier quoted context omitted.

Valid point. We have minimum age requirements set on some rules to avoid absorbing every latest change instantly.

How would that solve the problem though? You're still bringing compromises in, just with a delay. And the fixes will come in after the compromise, in accordance with the delay policy. To make matters worse, you'd lose getting alerts on vulnerabilities. Dependabot won't send them, and neither will Renovate last time I checked.

Both Renovate and Dependabot will raise PRs for a security fix, regardless of minimumReleaseAge/cooldown config

Re: GitHub Actions is the weakest link

#94
post #78

Earlier quoted context omitted.

How would that solve the problem though? You're still bringing compromises in, just with a delay. And the fixes will come in after the compromise, in accordance with the delay policy. To make matters worse, you'd lose getting alerts on vulnerabilities. Dependabot won't send them, and neither will Renovate last time I checked.

Both Renovate and Dependabot will raise PRs for a security fix, regardless of minimumReleaseAge/cooldown config

Are you saying that Dependabot/Renovate...

- raises PRs for security fixes immediately, regardless of cooldown configs

- flags the PRs as security fixes

- does the above when actions are pinned by commit SHA

? If so, mind sharing some documentation and examples please? I don't mind being proven wrong, but I genuinely couldn't find anything that demonstrates this happens. Dependabot docs actually point to the contrary (see my blog posts).

Re: GitHub Actions is the weakest link

#95
I'm building a fix since over half a year. Very sophisticated workflow engine for the paranoid with strong AI integration and fully decentralized and deterministic behavior. Nix, Rust, SUI, Walrus, SEAL, IKA and my engine/framework + many tools. One goal is to have multiple workflows by independent parties that not only check the compiler output, but do advanced source chain analysis. When enough parties report successful run, the IKA network signs the build digests. You can hold the second part of the key, so only you + successful pipeline will result in a release. No single point of failure, no single party that can be hacked.
Post reply on HN