Actions have consequences: The overlooked Security Risks in 3rd party GitHub Actions

The talk opens with GitHub Actions' permission model. Each workflow run receives a short-lived token whose scopes can be broad. Organizations created before February 2023 defaulted to read-write access, and most projects still have that setting, so a compromised third-party action can push code, publish packages, or reach cloud resources through the token.

The speaker built Piper, a tool that statically analyzes an action's code to work out the minimum permissions it needs. Using build logs from the top 2,000 starred repositories on GitHub, he found that most projects granted more permissions than their workflows required, and that about half of the actions he examined never needed a token at all. He then challenged commit pinning, the commonly recommended defense. He described "unpinnable" actions that still change after pinning, for example by pulling a mutable container tag such as latest, installing unlocked packages, downloading binaries without checksums, or fetching remote scripts. He estimated that roughly a third of popular marketplace actions fall into this category.

He closed with practical steps: set the default workflow token to read-only, declare exact permissions in each workflow file, isolate jobs so one compromise does not spread, pin dependencies with tooling such as ratchet, and fork or vet actions that cannot be pinned safely.