Open source software is the backbone of much of what we use online. But recent incidents remind us that our supply chains are only as strong as their weakest links. In early September, attackers gained access to a popular NPM maintainer’s account and pushed malicious updates to 18 widely used packages. These packages are downloaded over 2 billion times each week. Thankfully, the quick response by the community limited the damage. Still, it highlights ongoing risks in open source security.

The Risks in Open Source Dependencies

The incident involved relatively simple malware, but even basic attacks can cause big problems. The attacker used phishing to hijack a maintainer’s account, which shows how vulnerable even well-known projects can be. Two-factor authentication has become more common, but a convincing phishing email can still trick someone into giving away access. This is especially true in ecosystems like JavaScript, where many small libraries depend on a handful of developers. A single compromised account can affect thousands of projects.

Just days after this incident, another threat emerged. A self-replicating worm called “Shai-Hulud” spread through packages by stealing author tokens and seeding back doors in CI systems. This attack wasn’t limited to one package but affected hundreds. It shows how attackers are moving beyond simple hacks to more sophisticated, propagating threats. These supply chain attacks are becoming a new normal, making it clear that relying on a single security measure isn’t enough.

Why Supply Chain Attacks Are So Hard to Stop

Developers have long known that dependency chains create vulnerabilities. Once an attacker compromises a single dependency, they can potentially access many applications that rely on it. This problem isn’t just about money; it’s about how fast attack surfaces grow and how difficult it is to patch every weakness. Static solutions like one-time funding or quick fixes often fall short because threats evolve quickly.

Funding open source work is crucial but isn’t a cure-all. Many core maintainers are unpaid or underpaid, doing essential work without much recognition. They keep the internet running, but most organizations don’t invest enough in supporting them. Improving funding mechanisms is part of the answer, but process improvements are equally important. Creating standards for package provenance, routine signing, and predictable responses can make a big difference over time.

What’s Working and What Still Needs Improvement

Some security measures have improved in recent years. For example, GitHub now requires two-factor authentication for maintainers of popular packages, making phishing attacks more costly. NPM supports package provenance through Sigstore, allowing users to verify where a package came from and how it was built. Community monitoring also helps catch suspicious releases quickly. Despite these steps, attacks like the Shai-Hulud worm show that once an attacker steals an author’s token, malware can spread rapidly through ecosystems.

Funding helps make security tools more accessible, supporting automation and key management that prevent many attacks. But money alone isn’t enough. Organizations need to actively manage their dependencies, sponsor critical maintainers, and adopt proven security practices. They should assume that some packages or people will eventually fail and plan accordingly. These practices turn checklists into real security muscle, making the ecosystem more resilient.

In the end, incidents like these should remind us of the importance of community transparency and collaboration. They also highlight how much we depend on under-resourced maintainers. Strengthening our security isn’t about quick fixes; it’s about consistent process improvements, better funding, and a proactive approach. If your organization relies on open source, it’s time to treat it like a critical supplier—invest in its security and support the people keeping it safe.

Inspired by

• https://www.infoworld.com/article/4060306/npm-attacks-and-the-security-of-software-supply-chains.html

Sources

• gmpg.org
• darkreading.com
• darkreading.com
• cloudnativenow.com
• github.blog