Supply chain attacks hide malicious code inside the software you trust

A supply chain attack does not break into the software you use. It poisons one of the pieces that software is built from, then waits for the normal update process to carry it onto your machine. The app still installs cleanly, the signature still checks out, and the update still arrives through the official channel. The malicious code rides in with it. That inversion is what makes the technique so effective. It turns the trust that keeps software working into the thing that gets exploited.

Almost nothing you run today is written entirely by the company whose name is on it. A single app can pull in hundreds or thousands of open-source packages, each maintained by strangers, each pulling in more packages of their own. Developers rarely read that code; they trust the registry it came from and the version number attached to it. An attacker who slips into any link of that chain reaches everyone downstream at once, which is why a single poisoned component can affect tens of thousands of projects before anyone notices.

The entry points cluster into a few patterns. Typosquatting plants a malicious package with a name one keystroke away from a popular one and waits for the slip. Dependency confusion exploits how build tools resolve names, tricking them into grabbing a public package instead of a company’s private one. Account takeover hijacks a real maintainer’s credentials and ships malware as a routine update — in early 2026 the widely used axios package briefly shipped a compromised version after its lead maintainer’s machine was breached through social engineering. And build-pipeline poisoning targets the automated systems that assemble and release software, where a single corrupted step touches every project that depends on it.

The build pipeline has become the highest-value target precisely because it sits upstream of everything. When the popular GitHub Actions component tj-actions/changed-files was compromised in 2025, attackers rewrote its version tags to point at malicious code and pulled secrets from the build logs of more than twenty thousand repositories: access keys, tokens, and private keys, all printed in plain text. A later campaign that researchers named Megalodon turned GitHub Actions into a self-spreading backdoor that reached 5,561 repositories in about six hours. The machine that builds your software can be subverted as easily as the software itself.

The tools developers use every day are in the blast radius too. GlassWorm, first found in late 2025, spread through extensions for Visual Studio Code on the OpenVSX and Microsoft marketplaces. It hid its payload using invisible Unicode characters, so the malicious lines were literally unreadable in the editor and slipped past human review. Once installed, it stole npm, GitHub, and Git credentials, then used them to infect more packages and extensions automatically — the defining trait of a worm. Because editors update extensions silently in the background, victims received the poisoned versions without clicking anything. A separate poisoned VS Code extension was used to steal roughly 3,800 of GitHub’s own internal repositories.

What makes these attacks so hard to catch is that every individual step looks legitimate. The package is signed. The update comes from the real registry. The maintainer account is genuine. Traditional defenses scan for known-bad files and obvious malware, but supply chain attacks hide inside trusted, expected, and often invisible code that arrives exactly when and how software is supposed to arrive. Worse, the usual security advice to update immediately is the very mechanism the attacker depends on. For the first time, installing the latest version is not unambiguously the safe choice.

Defenders have converged on a handful of practices that work. Lockfiles pin every dependency to an exact, verified version, so an installer fetches only what was reviewed rather than whatever is newest. Disabling automatic install scripts blocks the most common way a malicious package runs code the moment it lands. Pinning GitHub Actions to a specific commit hash, instead of a movable tag, neutralizes the tag-rewriting trick. A software bill of materials, an itemized list of every component inside a build, lets a team know within minutes whether it is exposed when the next compromise is disclosed. Many of the organizations that escaped recent attacks did nothing exotic; they built from a committed lockfile and ran behind a registry proxy that quarantined brand-new packages.

For people who do not write code, the protection is mostly indirect, but the lesson is not. The software supply chain is now a primary battleground, and the companies that build the apps on your phone and laptop are the ones who have to secure it. The reasonable response is neither panic nor the old reflex of updating everything the instant a notification appears. It is to favor software from teams that publish what they ship and how they build it, and to treat a trusted source as a claim that has to be earned at every link rather than a property that travels down the chain on its own.

The industry’s answer is taking shape around provenance: cryptographic proof of where a piece of code came from and how it was built, checked automatically before anything is installed. It is the same idea that secured web traffic a generation ago, applied to the assembly line of software itself. Until that proof is universal, every install remains an act of trust in people you will never meet.