#open source compromise

As I approach the first full year of writing this blog, I am reflecting upon how much the reports I present have changed. When I began, I thought it would mostly be coverage of malware and the threat actors who depoloy it. Instead, it rapidly became apparent that there is so much more to cover than those two things alone. I’ve published opinion pieces, summarized software advancements, updates, and their issues, various topics purely for education, the emergence of AI tools and their pitfalls, and open source vulnerabilities.

The supply chain has become a notable vector for compromise, and in the last year has grown at an exponential rate. 1440% from 2024 to 2025. To put that in clearer terms, between 2022 and 2024, around 15K total packages were found to be malicious. In 2025 alone, that number soared to almost 190K, with npm having the highest amount of malicious packages found in November after a single month surge up to 142K, according to an Open Source Security Foundation (OpenSSF) graph. Mandiant, as part of the Google Threat Intelligence Group, has published these findings in an article on why this is happening and what to do about it.

The good news is, traditional software supply chain compromise, the manipulation of source code or update/distribution mechanisms, is still rare. That is not where these compromises are happening, generally speaking. The incidents that were involved with traditional cyberespionage were few and far between and amount to the barest handful in comparison. In fact, the article only points out three incidents of note, the web3 intrusion by UNC4899 with the purpose of eventually pulling off a cryptocurrency theft; the compromise of hosting infrastructure serving updates of Notepad++ from June to December 2025, activity GTIG attributes to UNC6688; and the early 2026 compromise of DAEMON Tools installers by UNC6863 to perform broad-spectrum reconnaissance and filter for targets of strategic interest using SLICKDEMON.

The bad news vastly overshadows these: compromise of code repositories, software dependencies, and developer tools. Topics I’ve covered time and time again in recent months. These compromises offer attackers the same (or greater) scale, stealth and efficiency of more traditional incidents, with the added bonus of taking less time to organize and less skill and resources to execute. And they are frequently enhanced and automated with AI tools. Once infiltrated, the supply chains disrupt everything they touch downstream, carrying out far reaching and lasting damage to software development and release. Names like Shai-Hulud, Glassworm, and TeamPCP have become recognizable at first glance (and off the top of my head). Social engineering is responsible for much of the spread of these campaigns, with spoofing, artificial inflation of download numbers to put the compromised packages at the head of repository lists, and trust abuse being among the highest techniques employed to distribute these packages to users and mods alike. I’ve used the tags #github, #supply chain, and #npm so often in my cross platform sharing that I can filter for them.

So what can we do about it? It really all comes down to oversight and risk management. Mandiant recommends maintaining tiered, continuous inventories of all applications, third-party vendors, and services based on operational importance to detect single points of failure and security risks. Keep an automated Software Bill of Materials for all internal and third-party software packages as well as an Action Bill of Materials to keep track of pipeline vendors and development utilities. Use risk management tools like the Wiz SDLC Infrastructure Threat Framework (SITF) and maintain a risk register to track domain threats. Education of staff and quality control of the finished product, vetting of vendors to make sure they legitimate, verification of the published tool and not just the repository it comes from, and provisions for security in contracts. It sounds like a lot, and perhaps it is. But these steps were once part and parcel of any software supply chain, and should never have been stopped. I’ve said it before, and no doubt I’ll say it again. You can do it fast, or you can do it correctly. You can’t do both.