The software supply chain in check: compromised Trivy images and exposed credentials

Software development security has once again been the focus of attention after a new wave of supply chain-oriented attacks: stranded versions of the Trivy vulnerability scanner, distributed by Docker Hub, have served as a vector to filter credentials and spread malware beyond the original environment. The scope is not limited to a simple committed image: the effects have been felt in repositories, GitHub actions and open source ecosystem packages.

According to the researchers who have analyzed the campaign, the latest reliable public versions of Trivy in Docker Hub dated from the 0.69.3 label; immediately afterwards, images labeled as 0.69.4, 0.69.5 and 0.69.6 were found to be malicious and removed. You can check the historical labels on the official image repository page aquasec / trivy in Docker Hub.

The pattern of attack described by analysts points to a chain escalation: a malicious actor exploited committed credentials to upload versions of Trivy with a embedded credentials thief, and also managed to inject changes in two GitHub actions linked to the project - those that facilitate the integration of Trivy into pipelines - which multiplied the surface of infection in CI / CD environments. The technical detail and commitment indicators have been documented by the Socket Security team in this report about the images of Trivy committed.

This intrusion was not isolated: with the exfiltered credentials the attackers managed to compromise packages in the npm record and distribute an self-replicating threat known as CanisterWorm. Independent researchers tracking the campaign attributed the actions to a actor named TeamPCP, who had already shown interest in cloud infrastructure and native components such as APIs de Docker, Kubernetes clusters and exposed services.

The impact also hit the Aqua Security organization. According to the forensic tracking published by the team OpenSourceMalware, 44 internal repositories of the organization aquasec@-@ com in GitHub were renamed and publicly exposed in a very short time interval, suggesting an automated operation through a committed token of a service account. The technical analysis available on his blog explains how a persistent token (from the "Argon-DevOps-Mgt" service) served as a key to writing in multiple organizations, amplifying the chain damage: analysis of the commitment.

Technical reports have also documented the evolution of the capabilities of the attacking group: in addition to the theft of credentials and the distribution of worms, payloads designed to sabotage environments have been identified. Researchers of the Aikido firm describe a component that, according to the rules included in its script, deploys privileged DaemonSet in each Kubernetes node and, in systems with Iran-oriented geographical detections, runs mass deletion and forced reboot routines. Aikido's technical article aunts how this burden behaves and in the separation of actions according to the location of the objective: analysis of the payload and its impact on K8s.

If there is a clear lesson from this incident, it is that a single weak link in the supply chain (for example, a service account with a long-term token) can have cascade consequences. Persistent credentials and too wide permits are precisely what attackers seek to exploit to move laterally and poison automated workflows..

For teams that use Trivy in their pipelines, immediate recommendations are evident: avoid affected versions, audit recent executions and make commitment if these images or actions were used in critical processes. The Repository of Trivy in GitHub and its maintainers have published official information on research and safe versions, so it is appropriate to contrast with the primary source: Trivy repository in GitHub.

Beyond replacing or blocking images, the response should include credentials hygiene measures: revoke tokens and suspicious keys, reduce service tokens life time, review permits assigned to automated accounts and apply less privileged principles in inter-organization integration. It is also advisable to strengthen the control of access to Docker APIs (for example, avoid exposing port 2375 without authentication) and to apply network segmentation that prevents a committed server from spreading agents to local subnetworks.

At the organizational level, it is appropriate to complement these actions with detection and response: to review CI / CD logs in search of abnormal executions, to check the integrity of deployed artifacts and to use signatures and source verification for images in production. Public security authorities and teams have published risk mitigation guides in the software supply chain; their consultation can help formalize incident control and response policies, for example in the CISA resource repository on risk management in the software supply chain ( CISA - Software Supply Chain Risk Management).

It is important to remember that in such attacks there is not always one visible victim: the organization that owns the project concerned can become an involuntary platform to engage tens or hundreds of consumers of its software. Confidence in third party components and actions must be continuously validated, not assumed for life.

While forensic teams and platform managers continue to correct vectors and publish commitment indicators, companies and developers must take immediate action to contain the impact and prevent small local failures from becoming massive gaps. The software supply chain is as strong as the weakest link: minimizing these weaknesses is now an inescapable priority.