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.
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.
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 practical fix for the first problem is pinning to a full commit hash instead of a tag name
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?
Well...obviously secrets available in the runtime environment of a CI job are vulnerable to attacks that can compromise the runtime environment. I think everyone knew that. Also GitHub actions that come from less than unreproachable sources (GitHub themselves, ?) have always been an obvious attack vector. In places I've worked where we were concerned about this we forked all the actions repos into our own org so we could never pick up mystery meat in our jobs.
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.
Regarding GitHub actions and it's secret manager. Any decently organized company would do well to stay away from well known secret interfaces.
Instead use oidc auth to fetch secrets just in time, all short-lived for the duration of the pipeline.
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.
Leaving aside the fact that this is an ad thinly veiled as an article, OneCli does the same, and recently NanoClaw made OneCli setup their default.
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.
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.
Why use a Shamir architecture at all, instead of giving the CI run an ephemeral token that will be exchanged on the proxy?
Can you explain what this is please? "Exploits mutable Git tags and self-declared commit identity"
Two things combined.
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 practical fix for the first problem is pinning to a full commit hash instead of a tag name
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?
Well...obviously secrets available in the runtime environment of a CI job are vulnerable to attacks that can compromise the runtime environment. I think everyone knew that. Also GitHub actions that come from less than unreproachable sources (GitHub themselves, ?) have always been an obvious attack vector. In places I've worked where we were concerned about this we forked all the actions repos into our own org so we could never pick up mystery meat in our jobs.
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.
Regarding GitHub actions and it's secret manager. Any decently organized company would do well to stay away from well known secret interfaces. Instead use oidc auth to fetch secrets just in time, all short-lived for the duration of the pipeline.
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.