Let's continue to look at interesting attacks on the supply chain in recent months. And i…

Let's continue to look at interesting attacks on the supply chain in recent months. And if last time we had a case about a harmful addiction that arrived transitively, then here the story is even cooler. Because attackers managed to hit the popular open source SCA tool. Let's do it again. Not by any package that developers used in their software, but by an entire tool that should look for vulnerabilities in packages and dependencies... Trivy hack ( https://www.aquasec.com/blog/trivy-supply-chain-attack-what-you-need-to-know/), ladies and gentlemen 😉

If we look at the mechanics of the attack, we get an illustrative example of the third scenario ( https://t.me/maxienergy_channel/386), because the blow fell not so much on the code, but on the build, release and delivery infrastructure. It all started back at the end of February 2026, when attackers were able to steal credentials from the Trivy CI environment. And already on March 19, this access turned into a full-fledged attack. Then the attackers did not attack head-on, but took advantage of the fact that developers and pipelines already trust official releases and GitHub Actions. In March, the malicious release Trivy v0.69.4 was published, in addition to which the tags for trivy-action and setup-trivy were rewritten ( https://github.com/aquasecurity/trivy/discussions/10425). The substitution itself took place through several delivery channels at once (through a binary, through an action and through a setup chain)

As is usually the case with supply chain attacks, everything looked normal to the victims. The pipeline launched a familiar action or installed a familiar binary, and then Trivy could even work as usual and show the scanning results. But before that, malicious code was executed. Socket describes this as a compromise of entrypoint.sh, in which secrets were stolen first, and then the actual scanner logic was run. The script looked for runner GitHub Actions processes on the machine, including Runner.Worker, Runner.Listener, runsvc and run.sh, and then read their environment variables through /proc//environ. He was interested in values ​​similar to env, ssh and other potentially sensitive variables. If the value pointed to a file, the script tried to read the file itself. After this, the collected data was encrypted (AES-256-CBC and RSA-4096) and went outside

The alarm was raised quite quickly. One of the first to draw attention to the malicious Trivy v0.69.4 was researcher Paul McCarty ( https://www.linkedin.com/posts/mccartypaul_updated-march-20-2026-at-3pm-heads-up-activity-7440548548775038976-ruRt) (almost the Beatles, but not the Beatles), after which Aqua, Socket ( https://socket.dev/blog/trivy-under-attack-again-github-actions-compromise), Wiz ( https://www.wiz.io/blog/trivy-compromised-teampcp-supply-chain-attack), CrowdStrike ( https://www.crowdstrike.com/en-us/blog/from-scanner-to-stealer-inside-the-trivy-action-supply-chain-compromise/), SANS and other experts. Researchers noticed anomalies in releases and tags (old versions began to reference new commits)

As a result, it’s already March 20 ( https://www.aikido.dev/blog/teampcp-deploys-worm-npm-trivy-compromise)attackers began using stolen tokens for a new wave of infections in npm. This is how CanisterWorm appeared (malware that installed a Python backdoor via postinstall, secured itself via systemd --user and tried to turn stolen npm tokens into the next stage of distribution). That is, Trivy in this story turned out to be not the final goal, but the entry point. First, the tool was compromised and secrets were collected from pipelines, then these secrets were used to publish malicious packages further down the chain 💀

How should you protect yourself from this (and is it possible)?

Firstly, the advice that I already gave in the post about axios also works here ( https://t.me/maxienergy_channel/387): don't live on floating versions. In the Trivy story, this applies not only to packages, but also to GitHub Actions. Aqua directly recommended using trivy-action not by tags, but by full commit SHA, because the tag can be rewritten. The same thing with images (it’s better to refer to the container by digest, and not by a tag like latest)

Secondly, everything we discussed in the context of reproducible installation and fixing dependencies is also absolutely on topic here. It's just that the level of application is wider. It is necessary to record both package versions in the lockfile, and versions of actions, setup scripts, container images, and in general everything that is involved in the pipeline

Thirdly, it is necessary to reduce the amount of secrets available to the runner

Well, the last thing. Such attacks push us to the idea that just checking the composition of dependencies is no longer enough. It is also important to limit the behavior of what we launch 🧠