Software developers were already struggling to keep up with dependencies. AI coding is making it worse.
You may very well have a big problem and you don’t even know it.
Do you have complete control over the dependencies of your application? I’m guessing that you think you do, but then again, you might not.
Sure, you can go to your package.json and see all the dependencies. You can even make sure that they are all on the current version, but that might take a lot of work. It’s likely that you are running older versions because upgrading takes too much time — a commodity that you don’t have. And chances are, one of the reasons there is a newer version is a security patch.
But package.json doesn’t tell the whole story. What are the dependencies added to your application downstream from your direct dependencies? And what are the dependencies of those dependencies? And so on, and so on.
We’ve all seen this famous xkcd cartoon:
Falling behind
The problem, then, is you almost certainly don’t know — and you really don’t want to have to know — the status of the exponentially growing number of dependencies your app has. Coding with AI only makes this problem worse, as new packages may be added faster than you can check.
But of course, you do want to know the security status of those dependencies, because one false step and your app is wide open for exploitation by skilled hackers and AI attacks. And maybe some of those dependencies have been abandoned or forgotten, and at some point won’t actually work properly anymore.
The defense? Well, I’m guessing many folks apply the strategy of hoping that every single developer in your dependency chain is keeping an eye on every single CVE out there, and updating their software to deal with all known security issues. This is not a great approach. Hope is not a strategy.
Or you could painstakingly go through each dependency, all the way down, and make sure every security patch is applied. Of course, upgrading each package may or may not be possible. The newer, more secure version may break your application.
And let’s be honest. That deep, thorough review probably isn’t going to happen.
And therein lies your big problem.
Catching up
So, what to do? Well, you are probably going to have to get some help.
The first place you might start is by scanning your code for vulnerabilities. A company like Checkmarx or Snyk can scan your code repository and let you know what the vulnerabilities are within your software supply chain. They can let you know where the problems lie.
Then, you might accept that there are risky and bad dependencies in your software, and you need to keep them going regardless. In that case, you need someone who will take care of those old, unsupported packages. Aaron Mitchell, the CEO of HeroDevs, calls his company the “nursing home of the internet” — HeroDevs provides and maintains safe, updated, and secure versions of packages so you don’t have to. This lets you manage the timing on migrating away from problematic code.
Or, you might just want a low-level solution that removes much of the problem entirely. Chainguard provides container images that are stripped down, secured, and built nightly to eliminate the dependency problem. They can replace all that low-level code with hardened solutions that eliminate the problem at the operating system level.
So yeah, you have a big problem in your software supply chain. But it’s not intractable. You are not alone — there are approaches and solutions available to address those fears sparked by the words “software supply chain vulnerabilities.”
And you won’t have to rely on that one guy in Nebraska anymore.
