Every few months, a supply chain incident makes the rounds and the security community debates the same things: better vendor vetting, stricter pipeline controls, faster incident response. These are important conversations. But they conveniently miss an essential part of the solution.
The compromise of Aqua Security’s Trivy, a widely deployed vulnerability scanner, had two distinct failure modes. The security industry will spend most of its time talking about supply chain integrity. The second one – credential management – is a more pervasive and embedded problem.
What Happened
An attacker found a long-lived personal access token (PAT) in a GitHub Actions workflow. A PAT is just a form of a secret. They used it to publish malicious versions of a widely trusted scanner – versions designed to harvest machine credentials from every pipeline that ran them: AWS keys, GCP tokens, Azure credentials, Kubernetes service account tokens. Because CI/CD pipelines are deeply interconnected, those stolen credentials enabled further propagation.
There are two problems here. The first is that pipelines were blindly executing a tool they assumed was trustworthy – a supply chain integrity failure. The second is that when the malicious tool ran, it found an abundance of high-value, long-lived credentials to steal – a credential architecture failure.
The Supply Chain Problem
The more upstream failure is trust. The affected pipelines pulled a tool by name or mutable tag, without verifying that what they were executing was what they expected. An attacker who can push to a package registry or container repository can become that tool.
The mitigations here are well-understood but underdeployed: artifact signing and verification (Sigstore/cosign), pinning dependencies to immutable digests rather than mutable tags, and runtime controls that limit what a tool can actually do while it’s executing.
Even with perfect credential hygiene, a compromised tool running inside your pipeline can exfiltrate data, tamper with build outputs, or pivot laterally within the scope of that job’s permissions. Supply chain integrity and credential architecture are not substitutes for each other. They operate at different layers.
Why Secrets Managers Struggle to Prevent Credential Theft
The second failure is what made the blast radius so large. The attacker didn’t just compromise one pipeline – they harvested persistent, high-value credentials from thousands of them. That scale is a function of architecture, not negligence.
Secrets management is built on a well-intentioned but flawed premise: store, rotate, and audit secrets carefully enough, and you’ve solved the problem. But a secret has to be known to be used. It must exist somewhere – in memory, in an environment variable, in a CI runner. Every place it exists is an attack surface.
Here’s a deeper look at why static credentials fall short in cloud-native environments. The pattern holds regardless of how carefully secrets are managed.
The Trivy PAT was presumably managed – likely stored in GitHub’s secrets store, not hardcoded in plaintext. But it still existed. It had persistent permissions. When the workflow was compromised, the attacker had everything they needed.
There’s also a deeper issue that secrets management can’t resolve: the authentication bootstrap problem. Every secrets manager – Vault, AWS Secrets Manager, GCP Secret Manager – requires something to authenticate before it will hand over a secret. That “something” is itself a credential. You’ve pushed the problem one level up the stack, not eliminated it.
Workload Identity Is a Different Architecture
The question organizations should be asking isn’t “how do we manage this secret better?” It’s “why does this workload need a long-lived secret at all?”
Workload identity-based access changes the foundation. Instead of authenticating with a stored credential, the workload proves who it is through cryptographic attestation – verifiable, contextual, tied to the specific runtime environment. Access is granted just-in-time, scoped to exactly what’s needed, and expires in minutes rather than months.
Projects like SPIFFE provide a foundational approach to secretless identity, and platforms like Aembit are built to productionize that with workload attestation, policy-based access control, and ephemeral credential issuance – with no stored secrets, manual rotation, or bootstrap credential sitting in a config file.
HashiCorp Vault’s dynamic secrets capability, for example, reduces secret lifespan but preserves the secrets model.
Aembit Workload IAM replaces it – workloads never fetch or store a credential at all, instead replacing the process with attestation, run-time policy evaluation, and just-in-time ephemeral credential issuance. (This should help you understand how workload identity and access management are distinct disciplines, which matters for how you architect your controls.)
Under this model, there’s no PAT sitting in a workflow waiting to be stolen. The Trivy attacker’s primary objective – harvesting persistent non-human identity (NHI) tokens with broad permissions – fails. Short-lived, ephemeral credentials don’t prevent a compromised tool from running, but they make the payload worthless. An attacker who needs hours or days to weaponize a credential gains nothing from one that expires in fifteen minutes.
This is not a complete defense against supply chain attacks. It’s a defense against credential harvesting at scale — which is what turned the Trivy incident from a targeted intrusion into a mass compromise.
Frequently Asked Questions
What is workload identity and access management (Workload IAM)?
Workload IAM is a security model that assigns verifiable cryptographic identities to NHIs – services, containers, CI/CD pipelines, AI agents – and manages their access to other systems through policy-based controls rather than stored credentials. Instead of authenticating with a static API key or token, a workload proves who it is through attestation, and access is granted dynamically based on that identity and runtime context. Workload IAM eliminates the need for secrets management by removing the stored credential from the equation entirely.
What is the difference between secrets management and workload identity?
Secrets management tools like HashiCorp Vault or AWS Secrets Manager store and distribute static credentials. They make secrets easier to handle, but the secret still exists and must be protected. Workload identity eliminates the stored secret entirely: The workload proves who it is through cryptographic attestation, and access is granted dynamically via ephemeral credentials that expire in minutes.
Why do secrets managers fail to prevent credential theft?
Because a secret has to exist somewhere to be used – in memory, in an environment variable, in a CI runner. Every place it exists is an attack surface. Secrets managers reduce exposure through rotation and access controls, but they can’t eliminate the credential itself. When the environment is compromised, as in the Trivy incident, the secret is available to any process running in it.
What is the authentication bootstrap problem?
Every secrets manager requires something to authenticate before it will hand over a secret. That “something” – a token, a key, an IAM role binding – is itself a credential. You’ve pushed the problem one level up the stack, not solved it. Workload identity-based systems resolve this by grounding authentication in verifiable runtime properties (the workload’s cryptographic identity) rather than a stored credential.
How do ephemeral credentials limit blast radius from a supply chain attack?
Ephemeral credentials are issued just-in-time and expire within minutes. If a compromised tool harvests them, the window to weaponize them is too short to be useful. The Trivy attacker’s value came from collecting persistent, long-lived tokens – AWS keys, GCP tokens – that could be used long after exfiltration. Ephemeral credentials remove that value entirely without preventing the tool from running.
The Lesson
The Trivy incident will accelerate conversations about open-source supply chain security. Organizations should invest in artifact verification, dependency pinning, and runtime controls. That layer of defense is real and necessary.
But organizations that stop there will have addressed how the attacker got in without addressing why the damage was so extensive. The credential architecture is what scaled a single compromised tool into a mass credential harvest.
You cannot manage your way out of secrets. Every secret you create is a liability – one you’re responsible for protecting, rotating, and eventually cleaning up. The alternative is to get out of the secrets business for machine-to-machine access entirely: Replace static credentials with dynamic, attested, short-lived access grounded in workload identity – thereby addressing the credential exposure problem at its root.
