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

51–60 of 95 posts

Re: GitHub Actions is the weakest link

#51

Post by woodruffw »

mmarian wrote: post #33
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'…

There are downsides to it though. You... - lose vulnerability alerts - increase maintenance overhead - take on all that for value that will go to 0 once Immutable Releases gets widely adopted I wrote a couple of blog posts on it, and a makeshift way of tackling that https://developerwithacat.com/blog/202604/github-actions-sup...

You lose vulnerability alerts, on GitHub. This is a (ridiculous, IMO) platform limitation that GitHub could lift by applying more engineering time to Dependabot and Dependabot's integrated security alerts feature.

zizmor (and other tools) correctly recovers vulnerability information for SHA-pinned actions[1].

[1]: https://docs.zizmor.sh/audits/#known-vulnerable-actions

Re: GitHub Actions is the weakest link

#52

Post by baby_souffle »

mmarian wrote: post #33
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'…

There are downsides to it though. You... - lose vulnerability alerts - increase maintenance overhead - take on all that for value that will go to 0 once Immutable Releases gets widely adopted I wrote a couple of blog posts on it, and a makeshift way of tackling that https://developerwithacat.com/blog/202604/github-actions-sup...

The maintenance aspect is relatively straightforward to automate.

Renovate handles this well. Ratchet and pinact can also be used

Re: GitHub Actions is the weakest link

#54

Post by phist_mcgee »

mmarian wrote: post #37
maxloh wrote: post #12

Earlier quoted context omitted.

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.

Agreed. Good news is GitHub will address that with Immutable Releases https://github.blog/news-insights/product-news/whats-coming-... You won't even need to use commit SHA as long as the maintainer follows this approach.

What an absolute joke that it has taken GitHub this long to clean up it's act when it comes to supply chain security.

Re: GitHub Actions is the weakest link

#55

Post by mmarian »

woodruffw wrote: post #51
mmarian wrote: post #33

Earlier quoted context omitted.

There are downsides to it though. You... - lose vulnerability alerts - increase maintenance overhead - take on all that for value that will go to 0 once Immutable Releases gets widely adopted I wrote a couple of blog posts on it, and a makeshift way of tackling that https://developerwithacat.com/blog/202604/github-actions-sup...

You lose vulnerability alerts, on GitHub . This is a (ridiculous, IMO) platform limitation that GitHub could lift by applying more engineering time to Dependabot and Dependabot's integrated security alerts feature. zizmor (and other tools) correctly recovers vulnerability information for SHA-pinned actions[1]. [1]: https://docs.zizmor.sh/audits/#known-vulnerable-actions

I agree, silly limitation.

On zizmor, there's no mention of coverage on commit SHA the section you've linked, nor in the entire page when I do Ctrl+F. Is there anything I'm missing?

Re: GitHub Actions is the weakest link

#56

Post by woodruffw »

mmarian wrote: post #55
woodruffw wrote: post #51

Earlier quoted context omitted.

You lose vulnerability alerts, on GitHub . This is a (ridiculous, IMO) platform limitation that GitHub could lift by applying more engineering time to Dependabot and Dependabot's integrated security alerts feature. zizmor (and other tools) correctly recovers vulnerability information for SHA-pinned actions[1]. [1]: https://docs.zizmor.sh/audits/#known-vulnerable-actions

I agree, silly limitation. On zizmor, there's no mention of coverage on commit SHA the section you've linked, nor in the entire page when I do Ctrl+F. Is there anything I'm missing?

Oh, I guess I didn't document it explicitly. My bad!

You can see it in the source here[1].

[1]: https://github.com/zizmorcore/zizmor/blob/db5ed6b3bb445848a8...

Re: GitHub Actions is the weakest link

#57

Post by shykes »

Munksgaard wrote: post #27
maxloh wrote: post #12

Earlier quoted context omitted.

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.

Even with a lock file, the action can download and execute arbitrary code from the internet.

It would be cool if CI could inject a platform-wide lockfile into every remote download or lookup made by your scripts. So if you pull a container or git tag, the CI platform would automatically ensure that the exact digest downloaded is controlled by a lock file that you can inspect, check in, etc.

Re: GitHub Actions is the weakest link

#58

Post by mmarian »

baby_souffle wrote: post #52
mmarian wrote: post #33

Earlier quoted context omitted.

There are downsides to it though. You... - lose vulnerability alerts - increase maintenance overhead - take on all that for value that will go to 0 once Immutable Releases gets widely adopted I wrote a couple of blog posts on it, and a makeshift way of tackling that https://developerwithacat.com/blog/202604/github-actions-sup...

The maintenance aspect is relatively straightforward to automate. Renovate handles this well. Ratchet and pinact can also be used

I mention in the posts the problem with the likes of Renovate. Auto merging is equivalent to semantic versioning. You have to properly vet the influx of updates, and that unfortunately won't work in practice.

Re: GitHub Actions is the weakest link

#59

Post by LelouBil »

cenamus wrote: post #16
bastardoperator wrote: post #15

Earlier quoted context omitted.

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.

I don't know why they don't pivot to Kotlin.

Gradle did it successfully and it's great now.

Re: GitHub Actions is the weakest link

#60

Post by LelouBil »

renegade-otter wrote: post #45
pydry wrote: post #42

Earlier quoted context omitted.

The YAML is way less concerning than the lack of any decent tooling to test and debug the code.

When GHA were dead simple, there were projects simulating it locally. It's not possible anymore, and one had to burn a tens of hours just to develop the pipeline.

There is this : https://github.com/nektos/act
Post reply on HN