Trivy under the eye of the hurricane: attack on the supply chain exposes credentials and shaking CI / CD

The software supply chain again tested one of its most dangerous cracks: Trivy, the Aqua Security vulnerability scanner known and massively used by developers and security equipment, was used by the group known as TeamPCP to distribute malware that steals credentials. The worrying thing is not only that a popular tool was contaminated, but the speed with which the attackers used persistent access to continue attacking other vectors, such as images in Docker Hub and the GitHub organization of Aqua itself.

Trivy has a wide community - its repository has tens of thousands of stars in GitHub - and is used to detect vulnerabilities, bad configurations and secrets exposed in artifacts and environments. This popularity amplifies the risk: any commitment to the construction or distribution process can be spread to many organizations and pipelines. Socket, a company dedicated to the security of the supply chain, reported that it detected images of Trivy published in Docker Hub with new labels that had no correspondence with official launches, pointing to committed artifacts linked to the infostealer that the attackers had committed through the organization of GitHub de Aqua. You can read the Socket analysis here: socket.dev.

Researchers point out that images labeled as 0.69.5 and 0.69.6 were pushed without equivalent official versions in GitHub; the last legitimate version known at that time was 0.69.3. In addition, they remember a basic but critical rule: in Docker Hub the labels are not immutable by design, so relying only on the name of a label to verify the integrity of a container is dangerous.

Aqua Security recognized that the incident in GitHub was not an isolated event but a continuation of a prior access that was not fully contained. According to his public communication, during the initial response secrets and tokens were rotated, but the process was not "atomic," which could have allowed the attackers to take advantage of tokens that were refreshed during containment. Aqua posted an explanation and updates on her official blog: Aqua Security and also held open discussions in GitHub on containment ( discussion file).

The dynamics of the attack, according to independent community analysis, were very direct: with access to a service account that had permits on multiple Aqua organizations, the attackers modified repositories in a massive way and added code to steal credentials from CI runners. An OpenSourceMalware report details how the perpetrators automated changes in the repositories (for example, by adding prefixes to the names and changing descriptions) and why they believe that the point of entry was a service account called Argon-DevOps-Mgt that used a GitHub Personal Access (PAT) instead of a safer mechanism like a GitHub App. The complete analysis is available here: OpenSourceMalware.

The relevant technical detail: PAT works as long-term passwords and, if present in the environment of a CI runner, can be exfiltered by malware that collects tokens, SSH keys, cloud credentials and environment variables. It's just that kind of theft that they attribute to TeamPCP: a cloud stealer aimed at collecting secrets from CI environments. This is why specialists insist on replacing, where possible, long credentials with ephemeral authorization mechanisms, such as the OIDC or GitHub Apps flow, and on reducing the useful life and privileges of tokens.

Aqua responded quickly by publishing clean versions of Trivy and hiring the Sygnia incident response firm for the forensic investigation. However, on March 22, the company reported suspicious additional activity that indicated that the attackers had managed to restore unauthorized access and had made changes in repositories; yet, Aqua claims to have not seen impact on the commercial edition of its platform, which incorporates Trivy with a controlled integration process and with a deliberate gap regarding the open-source repo. Your most recent update can be read on your official blog: communication from Aqua.

If there is an immediate lesson is that the supply chain attacks combine traditional techniques (tokens theft) with the exploitation of unsafe practices in pipelines and repositories. A configuration error, persistent token or exposed runner can transform a local incident into a mass spread campaign. This forces organizations to rethink how they manage secrets in CI, how they validate the integrity of published artifacts and how they audit access at the organizational level.

In practice, the recommendations emerging from this episode are not new, but urgent: to promote short-term and minimum-reach authentication mechanisms, to use GitHub Apps or federated identity options rather than long-term PATs, to ensure that the secret rotations are complete and atomic, to minimize service account privileges, to monitor massive changes in repositories and, where possible, to sign and verify binaries and images to avoid relying only on label names. GitHub explains the differences between authentication types and good practices in your authentication security documentation: GitHub documentation.

Beyond specific technical adjustments, this incident shows a cultural need: development and security teams must operate with attack assumptions, designing pipelines that "distrust by default" their own artifacts and incorporate independent validations before promoting a production version. It also requires transparency on the part of projects that are part of critical software infrastructure; timely communication and publication of commitment indicators help other organizations to detect and break infection chains.

In the end, the case of Trivy and Aqua Security is a strong reminder that confidence in the supply chain is fragile. It is not just a question of repairing a technical failure: it is an invitation to tighten processes, reduce the dependence on permanent secrets and assume that any widely distributed component can be targeted. For those who administer pipelines and repositories, the recommendation is clear: review the management of tokens and runners as soon as possible, apply minimum privilege principles and monitor the official sources of their tools. For the community at large, the task remains to demand and build mechanisms to verify the integrity of what we install and execute in production.