Trivy Security Scanner GitHub Actions Breached, 75 Tags Hijacked to Steal CI/CD Secrets

The open-source ecosystem faces a serious threat, and the latest attack on Trivy — a popular vulnerability scanner maintained by Aqua Security — provides further evidence of how fragile the foundations of our DevOps infrastructure are. Within just one month, Trivy fell victim to two security incidents, with the latest involving the compromise of 75 tags on GitHub, which were used to steal sensitive CI/CD secrets from thousands of development teams worldwide. This is not a typical breach — it is a precisely planned attack on the heart of the modern software deployment process.

The collapse of trust in a tool that was supposed to protect infrastructure reveals fundamental weaknesses in how we treat software supply chain security. When DevOps teams integrate GitHub Actions into their workflows, they expect them to be secure and trustworthy. The Trivy incident shows that such an assumption can be dangerously naive. Once attackers gained access to the official repositories, they could modify code that was executed with access rights to the most sensitive resources — access tokens, API keys, and credentials to container registries.

Anatomy of the attack: how 75 tags became a weapon

The attack on Trivy was neither random nor clumsy. The attackers who gained access to the repository systematically infected 75 different tags of GitHub Action versions — both for "aquasecurity/trivy-action" and "aquasecurity/setup-trivy". This means it was not a one-time infection that could be easily identified and eliminated. Instead, the attackers created a wide range of infected versions, which made detection difficult and allowed for the infection of the maximum possible number of teams.

Each tag represents a specific version of the action that developers can choose in their workflows. Some teams may be set to automatically download the latest version, while others may be "pinned" to older versions. By infecting a wide range of tags — from older to newest — the attackers ensured maximum reach. It was similar to adding poison to a water system at multiple levels simultaneously to ensure that people drinking water from different taps would be infected.

The malicious code embedded in these tags had a specific goal: to steal secrets stored in GitHub Actions environment variables. When the Trivy action was executed in a CI/CD workflow, the code ran with access to all variables available to that workflow — including GitHub tokens, AWS keys, Docker Hub credentials, and many other sensitive data. These secrets are typically stored in repository settings, but GitHub Actions automatically passes them to environment variables so that tools can use them.

Second attack in a month: pattern or coincidence?

The fact that Trivy fell victim to an attack for the second time in just 30 days is no coincidence. It suggests one of two scenarios: either Aqua Security has serious problems with repository access and security management, or the attackers who conducted the first attack left themselves a "backdoor" to return. In the security industry, there is a phenomenon known as "persistence" — when attackers gain access, they often install additional mechanisms that allow them to return even after the original attack vector is discovered and removed.

The recurring incidents also suggest that the first attack may not have been fully investigated. It is possible that the Aqua Security team focused on fixing visible damage without removing all the access paths used by the attackers. This is a classic mistake in incident response — teams often work under time pressure and focus on restoring normal operations instead of conducting thorough cyber forensics.

The series of attacks on a popular and trusted application also suggests that the attackers may be well-coordinated and have significant resources. This is not the work of a lone hacker acting from memory. It looks more like the work of a team with access to advanced tools and specialized knowledge of the GitHub ecosystem and CI/CD infrastructure.

Supply chain as a battlefield

Attacks on open-source tools like Trivy represent an evolution in security threats. Instead of attacking end-user applications directly, attackers target tools and libraries that are used by thousands or millions of projects. This is more efficient because one attack can infect hundreds of thousands of systems at once. This is an attack on the software supply chain — playing in the big leagues.

Aqua Security is not a typical hobbyist project. It is a commercial company specializing in container security, and Trivy is one of its flagship products. The fact that it was attacked shows that no company size or level of expertise guarantees protection against a determined attacker. Even companies that specialize in security can have gaps in their own security systems.

What is particularly concerning is that GitHub Actions are used by most modern DevOps teams to automate CI/CD processes. If attackers can infect popular actions, they can effectively position themselves at the heart of the infrastructure of thousands of organizations. It is like infecting a traffic control system — one vulnerability can affect millions of people.

CI/CD secrets: the attacker's most valuable treasure

Secrets stored in GitHub Actions — tokens, API keys, credentials — are not ordinary data. They are keys to the digital kingdom of every organization. When attackers gain access to a GitHub token with repository permissions, they can modify code, create new branches, and even directly deploy changes to production. AWS keys provide access to entire cloud infrastructure. Docker Hub credentials allow for infecting container images that are deployed across the infrastructure.

These secrets are typically very well protected — stored in encrypted vaults, accessible only to authorized processes. However, GitHub Actions automatically passes them to environment variables so that tools can use them. This is necessary for functionality, but also represents a point of weakness. If code executed as part of an action is malicious, it can easily display these variables and send them to the attacker's server.

Attackers can then use these secrets to:

• Directly access the repository and modify production code
• Infect Docker images stored in registries
• Seize cloud infrastructure and deploy backdoors
• Steal sensitive data stored in databases
• Create long-term access mechanisms to the organization's systems

Impact on the ecosystem: how many teams were threatened?

Trivy is one of the most popular vulnerability scanners in the container ecosystem. Aqua Security reports that Trivy actions are downloaded millions of times monthly. Even if only a small percentage of these downloads involved infected tags, the number of threatened systems is enormous. We are talking about potentially tens of thousands of organizations, from startups to Fortune 500 companies.

Particularly at risk are large organizations that have complex CI/CD workflows and store many sensitive secrets in GitHub Actions. These organizations are also more attractive targets for attackers because the potential benefits of accessing their systems are much greater. A startup with a few employees may lose access to their source code, but a Fortune 500 company could lose access to an entire infrastructure worth billions of dollars.

One must also consider the domino effect. If attackers gain access to organization A's repository, they can infect code that this organization uses in its products. These products may then be used by organization B, which in turn uses them in its own products. In this way, one attack can spread through multiple layers of the supply chain.

Lessons from the previous incident that were not implemented

The first attack on Trivy within a month should have been a warning signal for Aqua Security. Every security incident requires thorough investigation to identify the root cause and all possible attack vectors. However, the fact that the second attack occurred so quickly suggests that either the first investigation was not thorough enough, or its findings were not fully implemented.

In a well-managed incident response process, after the first attack, Aqua Security should have:

• Conducted a full audit of repository access and identified all accounts with code modification permissions
• Changed all passwords and access tokens
• Implemented additional layers of authentication for critical operations
• Installed tools to monitor suspicious activity in the repository
• Conducted full cyber forensics to identify all access paths used by attackers

The failure to implement these measures suggests that Aqua Security either lacked sufficient resources or did not treat the first attack with sufficient seriousness. This is a mistake that will cost the company far more than the investment in proper security measures.

Shifting responsibility: who should be accountable?

The Trivy incident raises an important question about accountability in the open-source ecosystem. Trivy is a free, open-source project, but it is also maintained by a commercial company — Aqua Security. Does Aqua Security have the same responsibility for Trivy's security as a traditional software vendor? Should developers using Trivy have had higher expectations about security?

In reality, responsibility is distributed. Aqua Security has responsibility for the security of the repository and deployment processes. Developers using Trivy have responsibility for verifying the integrity of downloaded code and monitoring changes in used dependencies. GitHub has responsibility for providing a secure platform to host repositories. All these players have a role to play.

However, in practice, most developers trust that tools downloaded from official sources are secure. This trust is largely justified, but incidents like Trivy show that trust alone is not enough. Additional layers of verification and monitoring are necessary.

How organizations should respond now

For organizations that used infected Trivy tags, time to act is critical. The first step should be to identify which versions of Trivy were used and whether any of them were infected. Aqua Security has published a list of infected tags, so this is relatively straightforward to check.

Next, organizations should assume that all secrets stored in GitHub Actions in the same repository may have been compromised. This means that all tokens, API keys, and credentials should be changed immediately. This is a tedious process, especially in large organizations, but it is absolutely necessary.

Long-term, organizations should also consider implementing more advanced security practices for their CI/CD workflows:

• Using Zero Trust Network Access (ZTNA) to restrict access to sensitive resources only to trusted processes
• Implementing Code signing for all GitHub Actions to ensure that code comes from a trusted source
• Regular audits of access and changes in the repository
• Monitoring anomalies in CI/CD workflows, such as unexpected network connections or access to secrets
• Rotating secrets at regular intervals, regardless of whether we suspect compromise

The Trivy incident is a reminder that CI/CD security cannot be treated as an add-on or secondary concern. It must be an integral part of every software deployment process, with the same level of investment and attention as the security of the application itself.