Live data from Hacker News

Trivy under attack again: Widespread GitHub Actions tag compromise secrets

socket.dev

71–80 of 97 posts

Re: Trivy under attack again: Widespread GitHub Actions tag compromise secrets

#73
post #38

"GitHub's own security guidance recommends pinning actions to full commit SHAs as the only truly immutable way to consume an action" Why doesn't GitHub just enforce immutable versioning for actions? If you don't want immutable releases, you don't get to publish an Action. They could decide to enforce this and mitigate this class of issue.

You can pin a GitHub Action to a SHA, but the GitHub Action can be a Docker one pointing to a mutable Docker image label.

Example:

https://github.com/github-community-projects/issue-metrics/b...

> Why doesn't GitHub just enforce immutable versioning for actions?

You can't. They can execute arbitrary code. They can download another bash file via Curl and execute that.

Re: Trivy under attack again: Widespread GitHub Actions tag compromise secrets

#74
post #38

"GitHub's own security guidance recommends pinning actions to full commit SHAs as the only truly immutable way to consume an action" Why doesn't GitHub just enforce immutable versioning for actions? If you don't want immutable releases, you don't get to publish an Action. They could decide to enforce this and mitigate this class of issue.

You can pin a GitHub Action to a SHA, but the GitHub Action can be a Docker one pointing to a mutable Docker image label. Example: https://github.com/github-community-projects/issue-metrics/b... > Why doesn't GitHub just enforce immutable versioning for actions? You can't. They can execute arbitrary code. They can download another bash file via Curl and execute that.

> You can't. They can execute arbitrary code. They can download another bash file via Curl and execute that.

Presumably you'd check the code of the action before you include it (and then don't use an action with non-pinned versions). This way you know the action won't execute arbitrary code for this version and won't get any other code because of version pinning.

The docker action you linked is ironic in this regard since every other version in the code seems to be pinned except the one you linked to.

Re: Trivy under attack again: Widespread GitHub Actions tag compromise secrets

#77
post #38

"GitHub's own security guidance recommends pinning actions to full commit SHAs as the only truly immutable way to consume an action" Why doesn't GitHub just enforce immutable versioning for actions? If you don't want immutable releases, you don't get to publish an Action. They could decide to enforce this and mitigate this class of issue.

This recommendation is currently broken. Even when you pin the full commit SHA for an action, that action may still pull in transitive dependencies (other actions) that aren't pinned.

Re: Trivy under attack again: Widespread GitHub Actions tag compromise secrets

#79
post #59

Earlier quoted context omitted.

> it might not be so explicitly state, but a desire to have constant updated-ness w/ security patches amounts to an argument against pinning When you want to update, you update the hashes too. This isn’t an issue in any other packaging ecosystem, where locking (including hashing) is a baseline expectation. The main issue is developer ergonomics, which comes back to GitHub Actions providing very poor package managemen…

Honestly what I really want is the latter (mutable references), but pointing to aliases that I own and update manually (the former).

So, fork the action repository and pull from upstream at your own pace?

Re: Trivy under attack again: Widespread GitHub Actions tag compromise secrets

#80
post #38

"GitHub's own security guidance recommends pinning actions to full commit SHAs as the only truly immutable way to consume an action" Why doesn't GitHub just enforce immutable versioning for actions? If you don't want immutable releases, you don't get to publish an Action. They could decide to enforce this and mitigate this class of issue.

> Why doesn't GitHub just enforce immutable versioning for actions? I always wish these arguments came with a requirement to include a response to "well, what about the other side of the coin?", otherwise, you've now forced me to ask: well? The two sides of the coin: Security wants pinned versions, like you have, so that compromises aren't pulled in. Security does not want¹ pinned versions, so that security updates a…

Auto upgrade to version deemed OK by security team. Basically you need to get updates that patch exploits then wait and be more patient for feature upgrades.
Post reply on HN