In March 2026, attackers compromised Trivy, a widely used open-source security scanner, and used its trusted distribution channels to deliver credential-stealing malware. The attack affected GitHub Actions, software releases, and container images, potentially exposing credentials belonging to organizations that relied on the tool to secure their development environments.

The attackers didn’t need to convince developers to install an unfamiliar package. They compromised credentials that allowed them to distribute malicious code through a tool developers already trusted.

The incident illustrates a growing challenge in software supply chain security: protecting the credentials that authorize changes to the software we build, distribute, and deploy.

When trusted development tools become the attack path

Software supply chain attacks are often associated with malicious dependencies and vulnerable third-party components. But those threats don’t always explain how attackers gain control of the software being distributed.

In the Trivy incident, attackers exploited compromised credentials to publish malicious releases and manipulate GitHub Actions tags. According to Aqua Security’s incident investigation, the March attack followed an earlier credential theft incident that hadn’t been fully contained. Although credentials had been rotated, the process was incomplete, allowing attackers to retain access.

Once inside the release infrastructure, attackers could distribute malicious software through channels developers and automated pipelines routinely trusted. The malicious components were designed to steal additional credentials from affected environments.

A single compromised credential had created opportunities to reach additional repositories, cloud accounts, and CI/CD systems.

The credential problem behind supply chain attacks

The Trivy attack is part of a broader pattern.

In its 2026 State of NHI & AI Agent Breach Report, NHI Management Group analyzed more than 200 publicly reported breaches involving non-human identities and AI agents.

Supply chain compromises were the most common identified attack route in the dataset, appearing in 51 incidents. Leaked secrets accounted for 48 incidents, while stolen credentials appeared in 47.

The report also identified 45 incidents involving source control tokens and 40 involving CI/CD or publishing tokens. These categories overlap, but they illustrate how frequently development infrastructure and its credentials appear in documented compromises.

The 2025 Shai-Hulud npm attacks demonstrated a similar risk. Attackers used compromised maintainer and publishing credentials to distribute malicious packages, steal additional credentials, and propagate through the npm ecosystem.

In both cases, legitimate development infrastructure became part of the attack. The credentials that enabled routine software distribution also created opportunities for attackers to reach downstream environments.

A stolen token is only the beginning

The impact of a compromised credential depends on what it can access.

A publishing token might allow an attacker to modify packages or distribute malicious releases. A CI/CD credential could provide access to repositories, cloud infrastructure, or additional secrets stored within automated workflows.

This makes development environments particularly attractive targets. Build pipelines routinely connect source control, package registries, artifact repositories, and cloud services. A compromised credential with broad permissions can potentially expose multiple systems.

For security teams, finding an exposed token is only the first step. They also need to determine whether it’s active, what permissions it grants, and which systems could be affected.

Without that context, it’s difficult to assess the urgency of an exposure or identify every credential that needs to be revoked.

Protecting the credentials behind software delivery

Reducing supply chain risk requires protecting both software artifacts and the credentials used to build and distribute them.

One important step is reducing reliance on long-lived publishing credentials. For example, npm’s trusted publishing uses OpenID Connect (OIDC) to authenticate authorized CI/CD workflows without storing long-lived publishing tokens.

Organizations should also prioritize several practices:

• Expand secret discovery beyond source code. Credentials can appear in CI/CD logs, configuration files, container images, and other development artifacts.

• Limit credential permissions. Publishing tokens, service accounts, and automation credentials should have only the access required for their intended purpose.

• Reduce long-lived credentials. Use short-lived credentials and workload identity federation where supported.

• Verify credential revocation. Removing an exposed secret from a repository doesn’t eliminate the risk. Teams must revoke or rotate compromised credentials and verify that the old credentials no longer authenticate.

These measures complement established supply chain protections such as dependency verification, artifact signing, and secure build configurations.

Supply chain security starts before the package is published

The Trivy and Shai-Hulud incidents demonstrate how compromised credentials can undermine the trust organizations place in software development and distribution.

As development environments become more automated and interconnected, the credentials behind those workflows become increasingly valuable targets.

Protecting the software supply chain requires more than inspecting dependencies and verifying artifacts. Organizations also need visibility into the credentials that authorize software changes, the permissions those credentials carry, and whether compromised access has been eliminated.

When attackers can use legitimate credentials to distribute malicious software, the compromise may begin long before anyone downloads the package.