# Supply chain attacks: the libraries you install today can become backdoors tomorrow Published: May 3, 2026 URL: https://crony.cl/logs/supply-chain-attacks-las-librerias-que-instalas-hoy-pueden-convertirse-en-backdoors-manana --- As developers, we rarely build anything from scratch. We import open source libraries, rely on automated pipelines, install extensions in our editors, and ship code faster than ever. That speed is powered by a network of third-party code and services, and that's exactly what attackers have learned to use against us. A software supply chain attack happens when a hacker compromises something upstream in what you already trust: a dependency, a tool, or an IDE extension, instead of attacking your application directly. The malicious code travels alongside a legitimate package installation, a CI job, or a routine update, slipping past firewalls and code reviews because everything looks perfectly normal on the surface. And by the time anyone notices, the payload has already collected secrets or opened a backdoor. Why are developers the primary target? Modern applications typically contain between 70% and 90% third-party code. If an attacker poisons a widely used package or GitHub Action, they get much more for their effort because they reach thousands of projects at once — and all they need is one maintainer's token, one unreviewed dependency, or one misconfigured pipeline. Trust, automation, and scale all work in their favor. The main types of supply chain attacks 1. Open source dependency poisoning Attackers publish malicious packages to npm, PyPI, Maven, or similar registries. Common techniques include typosquatting, publishing a package called reqests instead of requests, for example, or dependency confusion: publishing a public package with the same name as a private internal one, so the package manager resolves it first. Or they hijack maintainer accounts to publish trojanized versions of legitimate libraries. Either way, malicious scripts run the moment you execute npm install, long before any code review has a chance to catch them. 2. Compromised build pipelines (CI/CD) Your source code can be completely clean and your binaries still infected, because attackers target GitHub Actions, Jenkins, GitLab CI, etc., to modify scripts, swap artifacts, or retag releases to point at malicious commits. A real example: the tj-actions/changed-files incident in March 2025 (CVE-2025-30066) showed how a single compromised GitHub Action used across more than 23,000 repositories can leak secrets into thousands of workflow logs overnight. 3. Update mechanism hijacking Update systems are trusted by design: they run with elevated permissions and users simply expect new code to be installed. But when an attacker compromises a vendor's update server or code-signing process, a routine patch becomes a malware delivery vehicle. Clients receive a signed binary that looks completely legitimate, and install it without a second thought. 4. Malicious developer tools and IDE extensions VS Code extensions, Docker base images, linters, and CLI utilities run on our workstations with access to source code, environment variables, and cloud credentials. A single malicious extension could exfiltrate your AWS keys, GitHub tokens, and .env files the moment you open your editor. A live example is the GlassWorm campaign (October 2025 – March 2026), a self-propagating worm that has infected a large number of VS Code extensions on marketplaces like OpenVSX and the Microsoft Marketplace. What makes it especially insidious is that it uses invisible Unicode characters to hide its malicious code directly inside source files, making it undetectable through visual code review, and it self-propagates by using stolen credentials to compromise new extensions. 5. Repository takeovers and maintainer account hijacking In information security, they say the weakest link in any system is always people, and that's why many attacks are purely social. The XZ Utils backdoor of 2024 (CVE-2024-3094) was made possible after two years in which an attacker disguised as a contributor patiently earned a maintainer's trust and eventually gained commit access to a critical Linux dependency. Just like that, tokens obtained through phishing or leaked from legitimate maintainers can compromise a system in minutes. Recent examples that hit developers hard → Shai-Hulud (2025–2026), a self-replicating worm in the npm ecosystem. Compromised packages ran pre-install scripts that stole GitHub, AWS, GCP, and Azure credentials, then used those stolen tokens to publish new malicious versions of other packages under legitimate maintainer accounts. By the end of 2025, Shai-Hulud 2.0 had exposed thousands of secrets across repositories belonging to accounts like Zapier, Postman, and PostHog, all through normal npm install commands. The worm works by installing the Bun runtime and using TruffleHog (a legitimate secrets auditing tool) to scan system credentials. That's both remarkable and deeply unsettling: attackers are weaponizing legitimate security tools, making these attacks increasingly harder to detect. → The Axios npm attack (March 2026). Attackers gained access to a lead maintainer's account not through a direct breach, but through a social engineering campaign that ended with their machine infected by a RAT, which then handed over their npm credentials. With that access, they published two malicious versions (1.14.1 and 0.30.4) of Axios, a library with approximately 100 million weekly downloads, completely bypassing the project's signed CI/CD pipeline. So, can I defend my code? Absolutely, you can't stop using third-party code, so the key to staying safe is visibility and control. Maintain a Software Bill of Materials (SBOM) so that when a critical vulnerability drops, you can answer were we affected? in minutes, not days. Get into the habit of pinning everything. Don't install latest. Use lockfiles, commit them to your repo, and review dependency updates the same way you'd review a code change. Scan continuously. Run SCA tools like Dependabot, Snyk, or OSV-Scanner against your full dependency tree, and block builds that include known malicious packages. Apply a dependency cooldown. A mitigation that emerged directly from the Axios incident: configure your package manager to skip versions published in the last 24–48 hours. In Axios's case, plain-crypto-js was published 18 hours before the attack, a cooldown would have blocked it automatically. Harden your pipelines. Give CI runners least-privilege credentials, pin Actions to commit SHAs instead of tags, enforce signed commits, and always require reviews on workflow changes. Protect maintainer accounts. Phishing-resistant MFA on npm, PyPI, and GitHub is no longer optional. Monitor at runtime. Watch closely for unexpected network calls, new processes, or credential access by dependencies after installation. If you think runtime monitoring isn't that important, consider this: the XZ Utils backdoor in 2024 was caught precisely because someone noticed that SSH login was slower and consuming more CPU than it should. Too long, didn't read? Beyond your application's login page, every package in your lockfile, every action in your workflow, and every extension in your editor is part of your security perimeter. Today, securing the code you write means securing the entire journey it takes, from installing libraries all the way to deploying to production. So it's OK to trust the tools you use, but make sure you always verify them anyway, and check regularly if they appear in some CVE.