Trivy Supply Chain Attack
Aqua Security · Published 2026-03-01
That would be basically going back to manual release steps and / or a human in the loop via 2FA for the publish / release step (npm introduced something like that) instead of long-lived tokens / keys with too wide scopes as secrets shared between workflows.
There was always a good reason (out of fear that a token with the needed permissions could be stolen - and as you can read later, default misconfigurations by GH definitely made it worse), why I was not using GHA for automatic releases but did this from my local laptop (but this could lead to other issues like hard to debug release failures, missing logs and less transparency).
Theoretically you can configure GHA workflows with input fields (https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#onworkflow_dispatchinputs), to prompt for some additional data (like a passphrase for the GPG key or something else like an OTP code). But In never tried it beyond some small tests and I don't think this would be a very secure solution.
And the fine-grained modern tokens were not that easy.
Some manual unseal option would make sense (Shamirs Secret Sharing could be used, so for example 2 of 5 allowed contributors have to enter their code to publish a release / get a waiting release workflow into the next phase - which practically prevents that a single affected user or system can do the whole step alone). Well known solutions already use SSS for such things (like Hashicorp Vault with the unseal command).
(personal note: until today I still wonder why GitHub and others never adopted SSS, since I often read that a single compromised machine or maintainer resulted in full compromise like in the case of gluestack/gluestack-ui#2894 - but storing a secret directly in GitHub and past security flaws in GHA do not result in a good design)
On another note: PR approvals could be a lightweight solution, but still: secrets would still be stored without additional sealing or sharding across multiple maintainers.
Injections due to bash expansion and other tricks, automatic (and previously wrongly configured) tokens per workflow run and bad design decisions by GitHub definitely made it easy, to shoot yourself in the foot with GHA. See also https://www.wiz.io/blog/github-actions-security-guide and real (sorry for the wording) fuck-ups by GitHub like https://www.wiz.io/blog/github-actions-security-guide#:~:text=1.%20Set%20Read,least%2Dprivilege%20crucial (https://github.blog/changelog/2023-02-02-github-actions-updating-the-default-github_token-permissions-to-read-only/) about which I learned only from the news.
So either trust GH with the full secrets and fully audit and harden the GHA workflows + processes or try to distribute the the secret between multiple people (as shards) and use some established solution (doesn't have to be Hashicorp Vault, it's just the solution I worked with at work).