The Trivy attack did not hack anyone's secrets manager.
It just waited until the key was retrieved and sitting
in memory as a plaintext string. Then read it.
VaultProof solves that specific moment. The key never
exists as plaintext in your app or pipeline.
And even if VaultProof gets hacked, that is the whole
point. We only store shares. Individual shares are
mathematically useless. An attacker who completely owns
our infrastructure still gets nothing they can use.
There is nothing to steal. That is the architecture.
Compromise VaultProof and you get worthless shares.
The Trivy malware bypassed log masking entirely by reading
directly from runner process memory. Secrets managers did not help because
the credentials had already been retrieved and placed in memory as plaintext
strings. That is what got stolen.
Ephemeral tokens are a valid approach and some systems use exactly that.
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.
Correct. As an attacker you just move one level deeper.
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.
You're right and forking actions is the correct mitigation.
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.
Fair criticism on the framing and it reads more promotional than I intended.
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.
OIDC is the right call for cloud provider credentials like AWS, GCP,
Azure all support it well and short lived tokens are genuinely better
than static keys.
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.
First: Git tags are not immutable.
When you write actions/[email protected] 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 auto routing tier selection is interesting, curious how it handles the credential surface area as you add providers. Each provider in the rotation is another API key that needs to exist somewhere in the request path.
With 7+ providers, the secrets management problem compounds: rotation schedules differ per provider, a compromised key at one provider doesn't invalidate the others, and CI/CD pipelines end up holding plaintext keys for all of them simultaneously.
Does the router hold the provider keys server side, or does the client pass them per request? The architecture doc doesn't make this clear.
Author here. Built VaultProof after analyzing the Trivy attack
the credential harvesting worked specifically because the keys existed
as plaintext in the CI/CD environment after retrieval from the secrets
manager. Happy to go deep on the Shamir architecture or the attack
mechanics if useful.
VaultProof solves that specific moment. The key never exists as plaintext in your app or pipeline.
And even if VaultProof gets hacked, that is the whole point. We only store shares. Individual shares are mathematically useless. An attacker who completely owns our infrastructure still gets nothing they can use.
There is nothing to steal. That is the architecture.
Compromise VaultProof and you get worthless shares.