The gap is operational discipline. Most teams know they should fork upstream actions and review updates before pulling them in. Almost none actually do it consistently. The Trivy attack is useful not because it revealed something unknown but because it made the abstract cost of that gap concrete.
Took a look at OneCLI after your comment. The approaches are different.
OneCLI stores the real key encrypted and decrypts it at request time, injecting it as a header through their gateway. The full key exists in plaintext at the moment of injection.
VaultProof splits the key into cryptographic shares using Shamir Secret Sharing. No complete key exists anywhere at rest. The proxy reconstructs it transiently for the duration of the API call then zeros it immediately.
Different trust models and different threat coverage. OneCLI is a solid approach for agent credential management. The Shamir splitting is specifically for teams where the key existing as plaintext even transiently on a third party server is a concern.
The difference with Shamir is what happens if the proxy itself is compromised. With token exchange the proxy holds or can reconstruct the real key server side. A compromised proxy is game over for the credential.
First: Git tags are not immutable. When you write actions/trivy-action@v0.69.4 in your pipeline you are not pinning to a fixed commit. The tag is just a pointer and whoever controls the repo can silently move it to point to different code. Most teams assume a version tag means a fixed version. It does not.
Second: Git does not verify who makes a commit. Anyone can set their name to any Aqua Security developer they want. The malicious commit looked like it came from a trusted author because Git has no identity enforcement at all.
The practical fix for the first problem is pinning to a full commit hash instead of a tag name. That hash cannot be moved.
Almost nobody does this by default which is why the attack worked at scale. its very common supply chain failure pattern.
The gap is third party APIs. OpenAI, Stripe, Anthropic, GitHub. None of them support OIDC. You still end up with a static API key that has to exist somewhere in the pipeline as a plaintext string. That is exactly what the Trivy payload targeted.
If the underlying project in turn uses named tags, i.e. if the hash pinning doesn't apply transitively, then the protection appears incomplete, doesn't it?
If the target pins their direct actions to commit hashes you compromise a dependency of the action instead. They pinned the top of the tree but you own something in the middle of it.
SolarWinds was not attacked directly. The attackers compromised Orion, a build tool SolarWinds depended on. SolarWinds had decent security on their own code. It did not matter because the attack came through a dependency they trusted and did not control.
The defender has to secure the entire chain. The attacker only has to find one weak link anywhere in it. That asymmetry is why supply chain attacks keep working.
As I mentioned below, another mitigation for this kind of supply chain attack is to fork the action repos into your own organization to allow tighter control over their content.