Today, the situation is very different. Modern applications are no longer built in the traditional sense. They are assembled using layers of third-party libraries, SDKs, APIs, and services. A simple feature can depend on multiple packages, and each of those packages can bring in dozens of indirect dependencies. In ecosystems like Node.js or Python, it is common for a project to depend on hundreds of packages without the developer fully realizing it.
This change has made development faster and more efficient. Teams can ship features quickly without reinventing basic functionality. Open source has played a huge role in this progress. Platforms like GitHub have made it easy to discover, reuse, and contribute to code at a global scale. But this convenience has also created a hidden layer of risk. The risk is called a supply chain attack.
A software supply chain attack is when attackers target the tools, libraries, or processes used to build software instead of attacking the application directly.
Supply chain attacks are not entirely new, but their scale and impact have grown significantly in recent years. Earlier, attackers focused on breaking into servers or exploiting application vulnerabilities directly. Now, they are targeting the software supply chain, which includes open source libraries, package managers, CI/CD pipelines, and even developer tools. Instead of attacking one system, they compromise a widely used component and gain access to thousands of systems at once.
Recent data clearly show how serious the situation has become. According to reports from Sonatype, software supply chain attacks have increased by more than 700 percent over the past few years. This is not just a spike but a consistent upward trend. At the same time, reports from Snyk show a steady rise in open source vulnerabilities. These numbers confirm an important point. As our dependency on external packages increases, so does the attack surface.
Modern development ecosystems make this problem worse. In environments like Node.js, a single package can bring in dozens of indirect dependencies. Many developers do not even review these dependencies. They trust the ecosystem, the number of downloads, or the popularity of a repository on GitHub. However, popularity does not guarantee security. A package with thousands of stars can still be compromised.
There have already been several real-world incidents that highlight the risks, and the pace is increasing. The compromise of the event-stream package remains a classic example, where malicious code was introduced to target cryptocurrency wallets. In another case, the ua-parser-js library was hijacked and used to distribute malware. The breach involving Codecov exposed sensitive environment variables from many companies, including secrets and tokens.
More recently, the attack on Axios in March 2026 clearly shows how dangerous this has become. Attackers managed to hijack a maintainer’s npm account and publish malicious versions of the library. These versions silently added a trojanized dependency that installed a cross-platform remote access trojan on Windows, macOS, and Linux systems. Because Axios is used in millions of applications and sees tens of millions of downloads every week, even a short exposure window created a large impact.
Another recent wave of attacks targeted widely used developer tools and libraries across different ecosystems. The machine learning framework PyTorch Lightning was targeted through malicious packages designed to look like legitimate extensions. These packages were used to execute unauthorized code during installation. Similarly, attackers went after data tooling projects like elementary-data by publishing compromised or lookalike packages to trick developers into installing them.
Security tools themselves have also become targets. The Bitwarden CLI ecosystem saw supply chain concerns where attackers attempted to distribute malicious versions or abuse trust around automation workflows that rely on it. In another case, developers working with AI tools were targeted through malicious packages linked to Codex, where fake or tampered libraries were used to inject harmful code into development environments.
These were not just a few cases. Around the same time, multiple open source projects across ecosystems were targeted in a coordinated manner. Security researchers linked campaigns where tools like vulnerability scanners, AI libraries, and communication SDKs were compromised within days of each other. In parallel, attackers have also been using social engineering to trick developers into installing malicious npm packages or running compromised code from fake repositories, effectively turning developers themselves into the entry point.
In all these attacks, a pattern was common. Attackers are no longer looking for a single vulnerability in your application. They are going after the entire ecosystem that your application depends on. These incidents are part of a broader and rapidly growing attack surface that spans Node.js modules, Python packages, WordPress plugins, and almost every modern development stack.
The primary reason behind this change in mindset is not difficult to understand. Open source ecosystems are built on trust, and that trust can be exploited. Many widely used libraries are maintained by a small number of developers, sometimes even a single individual. If an attacker gains access to a maintainer’s account, they can push malicious updates that will be distributed to a large number of users. Automation further amplifies the impact. Continuous integration systems and automatic dependency updates can quickly propagate a compromised package across multiple environments.
Another important factor is the way developers approach dependencies. In many projects, adding a new package is often the easiest solution to a problem. Over time, this leads to a large and complex dependency tree. Each dependency increases the risk, especially when it is not actively maintained or audited. In my experience, many teams do not fully understand how many external components their applications rely on.
To address this issue, developers and organizations need to change their approach. The first step is to be more selective about dependencies. Not every problem requires a new library. In many cases, a simple in-house solution can reduce risk. It is also important to use lock files and avoid blindly updating dependencies in production systems. Updates should be reviewed and tested before being deployed.
Security tools can help, but they are not a complete solution. Platforms like Snyk and tools such as Dependabot can identify known vulnerabilities, but they cannot detect every possible threat. Developers should also verify package sources, check maintainers’ activity, and monitor any unusual behavior during installation or runtime.
Organizations also need to think beyond basic precautions and focus on limiting the impact when something goes wrong. Restricting access to sensitive environment variables is important, but that alone is not enough. Secrets should not sit in plain environment files or CI logs. They should be managed using proper systems, rotated regularly, and given only the minimum permissions required. If a dependency gets compromised, it should not automatically have access to production databases, cloud credentials, or internal services.
Isolation is another area where most teams still need improvement. Build systems, CI pipelines, and production environments are often too connected. If a malicious package runs during installation, it should not be able to reach critical systems. Using containers, sandboxed builds, and network restrictions can reduce this risk. Many companies are slowly moving towards zero-trust models internally, where every component has limited access and needs explicit permission.
Visibility is equally important. In many projects, teams do not even have a clear idea of how many dependencies they are using. A single feature can bring in dozens of indirect packages. Maintaining a Software Bill of Materials is becoming necessary. It helps track all dependencies and makes it easier to respond when a vulnerability or attack is discovered. Without this, teams are often reacting blindly.
There is also a need to control dependency sprawl. Over time, developers have become comfortable adding new packages for small tasks. This increases the attack surface without much benefit. In many cases, simple logic can replace a full dependency. Regular audits can help remove unused or risky packages and keep the codebase cleaner.
Verification should become a standard step. Developers should not blindly trust packages just because they are popular. Checking maintainers, recent activity, and update patterns can give useful signals. Using tools that verify package integrity and signatures can also help. Efforts from projects like Sigstore are trying to solve this, but adoption is still limited.
Monitoring should not stop at servers and infrastructure. Applications also need runtime monitoring. If a dependency suddenly starts making unexpected network calls or behaves differently, it should be flagged. These signals are often ignored, but they can be early signs of a compromise.
Platforms and ecosystems also need to do more at a broader level. Services like GitHub and package registries have started enforcing measures like multi-factor authentication, but that is just a start. There should be stricter controls on publishing updates, better detection of suspicious changes, and faster response to reported issues.
Supply chain attacks are not going away because they are a direct result of how modern software is built. We depend heavily on third-party code, and attackers are simply targeting that reality.
The real problem is not dependencies themselves. It is how casually we trust them. From my experience, this needs a mindset change. Developers have to treat third-party code with the same responsibility as their own code. Trust should not come from download numbers or GitHub stars. It should come from verification and continuous monitoring.
If teams start thinking this way and apply these practices, the risk can be reduced to a large extent. It will not eliminate the problem, but it will make it much harder for attackers to succeed.
