Trivy compromise shows why credential architecture failed at scale

At a glance

What this is: This is an analysis of the Trivy compromise, showing that the larger failure was not just supply chain trust but the credential architecture that let malicious code harvest high-value machine credentials at scale.

Why it matters: It matters because IAM, PAM, and NHI teams need controls that reduce blast radius when trusted tooling is compromised, not just controls that try to protect stored secrets after they exist.

By the numbers:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.

👉 Read Aembit’s analysis of the Trivy compromise and machine credential exposure

Context

Trivy compromise analysis is really a test of whether identity programmes can survive trusted tooling being turned against them. The article’s central point is that the incident was not only a supply chain integrity problem; it was also a machine credential problem, because the malicious package found long-lived secrets that already existed inside CI/CD workflows.

That distinction matters for NHI governance because secrets management and workload identity solve different problems. If a pipeline still depends on persistent credentials, then compromise of the execution environment can turn one malicious build step into broad credential exposure across cloud and Kubernetes systems.

Key questions

Q: What breaks when build pipelines still rely on long-lived machine credentials?

A: A compromised build step can read and reuse the same credentials that were meant to support automation, which turns one trusted runtime into a secret-harvesting point. The failure is not just exposure, but persistence. If the credential outlives the job, an attacker can weaponise it after the original execution ends.

Q: Why do secrets managers not fully solve credential theft in CI/CD?

A: Secrets managers reduce handling friction, but they do not remove the secret from the environment where code runs. If a malicious package or runner compromise can access memory or environment variables, the credential is still reachable. That is why pipeline design matters as much as vault design.

Q: What do security teams get wrong about workload identity for pipelines?

A: They sometimes treat it as a way to manage secrets better, when the real value is eliminating stored secrets from the workflow entirely. Workload identity changes the trust model by issuing short-lived access after runtime attestation, which limits what a compromised job can steal.

Q: Who is accountable when a trusted scanner harvests cloud credentials from pipelines?

A: Accountability sits with the teams that own pipeline identity, secret placement, and artifact trust, not with any single tool. Frameworks such as NIST CSF and OWASP NHI both point to governance, access control, and detection as shared responsibilities across build, cloud, and identity teams.

Technical breakdown

How a GitHub Actions PAT became the entry point

The attack began when an attacker found a long-lived personal access token in a GitHub Actions workflow. A PAT is a stored secret that can authenticate on behalf of a pipeline, so once it is exposed, the attacker can publish or modify packages and impersonate trusted automation. The important mechanism here is not the package name itself, but the mutable trust path: pipelines pulled code by name or tag and assumed the artifact was authentic. That assumption allows a repository or registry compromise to become execution compromise inside downstream builds.

Practical implication: pin build inputs to immutable digests and verify artifact signing before any trusted pipeline step executes.

Why the malicious scanner could harvest machine credentials

Once the compromised scanner executed inside pipelines, it had access to the environment in which many CI/CD systems place secrets for convenience. That means cloud keys, tokens, and service account credentials are often reachable in memory or environment variables during the job. The scanner did not need to break cryptography; it simply read what the pipeline had already made available. This is why secrets management often becomes a visibility problem rather than an access problem. The secret still exists, so compromise of the runtime can expose it.

Practical implication: remove persistent machine credentials from pipeline runtime wherever possible and treat exposed environment variables as a breach surface.

How ephemeral workload identity changes the blast radius

Workload identity replaces stored secrets with runtime attestation and short-lived credential issuance. Instead of authenticating with a static token, the workload proves its identity from contextual properties and receives access only for the current task. That changes the attack economics. A malicious build step may still run, but any credential it steals has a short useful lifetime and is much harder to reuse outside the intended session. This does not stop compromise of the tool chain itself, but it sharply limits credential harvesting as a follow-on effect.

Practical implication: move high-value pipeline access to attested workload identity so stolen credentials expire before they can be operationalised.

Threat narrative

Attacker objective: The attacker’s objective was to collect persistent non-human identity credentials with enough privilege and lifespan to pivot across multiple pipelines and cloud environments.

1. Entry occurred through a long-lived GitHub Actions personal access token embedded in a workflow, which let the attacker publish malicious versions of a trusted scanner.
2. Credential access happened when the malicious scanner ran inside downstream pipelines and harvested AWS keys, GCP tokens, Azure credentials, and Kubernetes service account tokens from the runtime.
3. Impact followed as those stolen machine credentials enabled further propagation across interconnected CI/CD environments and expanded the blast radius beyond the original tool compromise.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Credential architecture, not just supply chain trust, was the real scaling factor in the Trivy incident. The attack became severe because the malicious scanner found long-lived machine credentials inside the environments it touched. That means the blast radius was created by persistent NHI exposure, not merely by a bad package release. Practitioners should treat this as a credential design failure, not only an integrity failure.

Static credentials in CI/CD are a standing assumption that hostile code can safely run inside the same runtime as privileged secrets. That assumption fails whenever an attacker can turn a trusted build step into a secret collection point. The implication is that access models built around stored tokens no longer match the threat shape of modern pipelines.

Ephemeral credential trust debt: The Trivy incident shows how much risk accumulates when temporary build convenience depends on secrets that behave like permanent identities. Rotation can shorten exposure, but it does not remove the credential from the attack surface. Practitioners should read this as a structural debt in the NHI programme, not an isolated incident.

Workload identity is now a governance boundary, not an optimisation. The article is correct that artifact verification and dependency pinning matter, but those controls only address one layer. If a malicious tool can still reach durable cloud tokens, the organisation has left the highest-value identity objects inside the blast radius. Security teams should re-evaluate where persistence is still accepted in machine access paths.

CI/CD trust has become an identity problem disguised as a software supply chain problem. The pipeline did not just execute untrusted code; it executed code with access to machine identities that outlived the job that used them. That is exactly the kind of cross-domain failure NHIMG sees across NHI, PAM, and lifecycle governance. Practitioners should align build security and identity governance as one control plane.

From our research:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to The State of Secrets Sprawl 2026.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• A useful next step is to compare this pattern with the CI/CD pipeline exploitation case study, which shows how exposed build credentials can turn one compromise into full environment takeover.

What this signals

Ephemeral credential trust debt: Security teams should expect more incidents where trusted automation becomes the secret collector, not just the delivery mechanism. As build and deployment systems converge with cloud access, the question is no longer whether a pipeline can run code, but whether it can do so without leaving durable identity objects behind.

A programme that still depends on stored machine credentials should treat this as a near-term redesign priority. The operational signal to watch is simple: if a compromised runner can recover cloud access without additional proof of identity, the control plane is still anchored in persistence rather than runtime trust.

The governance implication is broader than CI/CD. NHI and PAM teams need to align artifact verification, secret lifecycle, and workload identity so the same identity object is not reused across too many execution contexts. The Trivy pattern is a reminder that a single exposed token can become a multi-environment failure if the access model is static.

For practitioners

• Remove long-lived machine credentials from pipeline runtimes Replace stored tokens in GitHub Actions and similar systems with attested workload identity and just-in-time credential issuance so build steps never see durable secrets.
• Pin and verify every build artifact Require immutable digests, artifact signing, and signature verification before a job can execute third-party tooling or pull mutable tags into a trusted pipeline.
• Segregate high-value cloud and Kubernetes access Split pipeline permissions so a compromised scanner cannot reach broad AWS, GCP, Azure, or Kubernetes service account scopes from the same runtime context.
• Treat secrets exposure as a lifecycle failure Track where machine credentials are created, where they are injected, and where they are removed so offboarding and revocation happen when workflows or vendors change.

Key takeaways

• The Trivy compromise exposed a dual failure: trusted software supply chains and persistent machine credentials can fail together.
• The scale of the problem is already measurable in the wild, with tens of millions of new hardcoded secrets appearing in public code and many previously leaked secrets still usable.
• The control that most directly limits this blast radius is workload identity with short-lived, attested credentials, because it removes durable secrets from the pipeline runtime.

Key terms

• Workload Identity: Workload identity is a way to authenticate software by proving what it is at runtime instead of presenting a stored secret. In practice, it ties access to attested context such as environment, workload state, or cryptographic identity, which makes secret theft much harder to operationalise.
• Personal Access Token: A personal access token is a reusable secret that lets software act on behalf of an account. In CI/CD systems it often becomes a high-risk credential because it can be embedded in automation, reused across jobs, and stolen if the workflow runtime is compromised.
• Credential Harvesting: Credential harvesting is the collection of secrets, tokens, or keys from a compromised environment for later reuse. In pipeline attacks, the goal is often not immediate execution but gathering enough machine credentials to move across systems after the first compromise completes.
• Artifact Signing: Artifact signing adds cryptographic proof that a build output or dependency came from the expected source and has not been altered. For pipeline security, it is a verification control that reduces trust in mutable tags and prevents attackers from swapping in malicious packages without detection.

Deepen your knowledge

Trivy compromise analysis and workload identity are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are redesigning CI/CD access around ephemeral credentials, the course will help you map the governance shift cleanly.

This post draws on content published by Aembit: analysis of the Trivy compromise and its credential exposure lessons. Read the original.