Let’s start with the old adage “free like a puppy”. Open source is free like a puppy. Using open source comes with responsibilities. Just like if you don’t pay attention to your puppy, you will come home to a torn up rug someday (or worse). If you don’t pay attention to your open source you’re going to have some sort of security incident eventually.
Right about now there is a subset of readers reaching for the comment section ready to tell us AI will solve any open source dependency problem you might have. Maybe AI can solve all of our open source problems (it can’t). Maybe it can just eliminate the need for open source by writing 100% of the code (also no)! Or what about writing secure code? (hahahahaha). AI doesn’t solve any open source problems for us. It does create some new ones, and maybe even makes the existing problems worse.
While there are many many attacks that have been happening lately for anyone using open source, I want to start with three easy to understand attacks.
Typosquatting
Typosquatting is an attack where you accidentally type the wrong name. You wanted to install react, but you typed reactt (two t’s) by accident. We all make typos all the time. Usually when you typo a package name, you’ll get some sort of error telling you the package name doesn’t exist. No big deal, just fix the typo and try again. But what happens if there is a package named “reactt”? What if the package named reactt was put there by someone with malicious intent hoping someone would make this exact typo?
It’s not hard to imagine how this works and why it’s dangerous. The attacker creates a malicious package, then just waits for someone to install it. AI can’t really solve this one for us. If we install our dependencies manually, we can still make typos. If we let the AI install things for us, well, AI makes typos too, and there’s a new special name for AI typosquatting, but we’ll get to that.
Out-of-Date or EOL Dependencies
Do you keep your dependencies up to date? How many are more than a year old? It’s OK if you don’t know, everyone has this problem no matter what they tell you. Keeping dependencies updated is hard to do. If you install all the dependency updates, everything breaks. So the easy solution is to never install an update and nothing will ever break! Well, until it does. How many of those dependencies you’re using are still under active development? How many of those dependencies have security vulnerabilities?
Like all software, open source can have an End of Life (EOL) date. It’s not always obvious when an open source project is EOL and when it’s not very active. Do we know which dependencies are EOL? Open source generally doesn’t have support policies. Maybe that package hasn’t been updated in 3 years because there hasn’t been a need to release an update. Or maybe it hasn’t been updated in 3 years because the open source developer decided they don’t want to work on it anymore.
Backdoored Dependencies
What happens if a legitimate dependency you’re using isn’t a typosquat, but has an attacker break in and replace good code with something malicious? The most obvious example of this problem was the xz-utils attack where the attacker managed to include a backdoor into the open source project itself. If you were using the actual real project, you were also using the real malicious code.
Backdoored dependencies is one of those attacks that scares everyone because a well executed attack will avoid most of the gates we have in place to detect malicious open source. When the real release has malicious code, any checks you might have in place to avoid bad updates will probably pass because it looks like a real update. It is a real update.
Bonus AI problems!
Against my better judgement, I’m going to say AI doesn’t solve any of the above problems. There are plenty of people making bold claims about what AI can do, but the evidence that AI somehow helps with dependency problems just doesn’t exist. It actually gives us some new problems related to the above.
Slopsquatting
One of my favorite new terms is Slopsquatting. This one is related to typosquatting, but takes on a special AI twist. The idea here is something similar to typosquatting, but instead of the name being a typo, the AI hallucinates a dependency name. This could be a similar name, or it could be something wildly different. In this case an attacker becomes aware of a dependency name that is being hallucinated by an AI system, then registers that name. The next time the AI hallucinates the package, the malicious code gets installed.
It’s the same basic problem as typosquatting, just a new way to get to the end state of installing attacker controlled packages. This one is so new we don’t know how widespread it might be. We do know hallucinated dependencies are a real thing.
Hidden Dependencies
This one doesn’t have a fancy name that I’m aware of (if it does, do let me know). But the idea is instead of the AI using an open source dependency, it decides to write some code to replicate the same functionality. Except because of how AI works, you don’t really get new greenfield code. AI was trained on the entirety of open source, so if you ask it to create functionality that exists in an open source package, you’re going to get something very similar to that open source package.
The danger is you have code that is basically a copy of an open source project, but you don’t know it’s a copy of an existing project. And since it’s mostly a copy, the security vulnerabilities that affect the open source project are also going to affect your generated code. Except you don’t have any visibility into what open source project(s) your generated code is really using. This is a blind spot in your ability to track and update your dependencies.
What Can We Do?
What can we do about all these supply chain problems? There’s no quick fix to any of this. The AI and non-AI problems are all functionally the same sort of issues. We have large, unwieldy supply chains. The people creating and maintaining much of that supply chain for us are volunteers. We don’t have support contracts or SLAs with open source projects. If that maintainer in Nebraska decides to walk away, it’s our problem, not theirs.
It is up to us to keep track of what we’re using. When you use open source you don’t have a supply chain, you are the supply chain. This means moving beyond vague “software inventories” and actually embracing tools like Software Bills of Materials (SBOMs). You need to know what is in your environment. It doesn’t matter if it was npm installed by a human, given to us by a vendor, or hallucinated by an LLM.
You’re going to need a combination of open source sustainability, good open source hygiene, automated tools, and a secure development program. Some sort of software inventory — especially of the open source you’re using — can help you figure out what might be EOL and what needs an update. Using AI doesn’t change how we interact with our open source dependencies. If anything, it highlights how important it is to properly care for the open source we use. It’s the whole “free like a puppy” idea.
Hard problems have hard solutions. They wouldn’t be hard problems if they were easy to solve.
