For years the standard playbook has been: find the holes as fast as you can, rank them by how bad they are, then patch the critical ones before someone actually exploits them. And yeah, that process has gotten better. Automated tools and bots now push fixes faster than most teams could manage by hand. The numbers show critical bugs are getting closed 59% quicker than they were at the peak in January 2024. More than half of them are cleaned up in a single day. On paper that looks like progress.
In reality? We’re still mopping the floor while the faucet keeps running. The sheer volume of new apps (and all the dependencies they drag in) is growing faster than our ability to clean up after them. So even though we fix things quicker, the total number of vulnerabilities keeps climbing. Classic “treat the symptom, ignore the cause” situation.
AI made everything faster, and it’s including the bad decisions
Now we’ve got AI that can spit out code and pull in libraries at a speed no human can match. That’s useful. It’s also a problem. Developers have always been lazy about dependencies — “whatever is popular or already in the package manager” is the usual approach. AI doesn’t fix that habit. It just makes it worse. It’ll happily recommend a library that hasn’t been touched in three years or already has known issues if that’s the quickest way to make the feature work.
The real cost shows up later as rework. You only discover the bad dependency after the code is written, tested, and sometimes already live. Then you’re ripping things out and putting safer versions back in. Pure waste. The safer option was usually sitting there from the beginning — someone just never showed it at the moment of decision.
Make the safe choice the easy one
The answer isn’t more heroic patching at the end of the pipeline. It’s making the secure option the path of least resistance when the dependency is first chosen. Think of it like food labels in a cafeteria: if one option has a clear “safe / maintained / no known critical issues” badge and the other doesn’t, most people will grab the safe one without needing a lecture.
Four things that actually need to happen
- Show the risk at selection time, not after the fact.
When a developer (or an AI) is picking a library, the risk info has to be right there in the IDE or package manager. Waiting for the vulnerability scanner to run later is already too late. - Hold AI to the same rules as humans.
If your company has approved lists, license policies, or minimum maintenance standards, the AI tools have to respect them. Letting the model ignore policy because “it works” is how you end up with the exact same mess, just generated faster. - Don’t just warn — give the safe path.
A notification that says “this package has issues” is only half useful. Pair it with an already-vetted alternative or an automated upgrade path that’s been tested. Otherwise people just click through the warning and keep going. - Measure what comes in, not only what goes out.
Tracking how fast you close vulnerabilities is necessary but incomplete. If the rate of new high-severity issues entering the system keeps rising, your process is still broken upstream. You need both numbers.
None of this has to slow teams down. Done properly, it removes the expensive rework that currently eats time later in the cycle.
Every vulnerability you stop at the decision point saves far more effort than the fastest patch process ever will. We’ve spent years getting better at cleaning up. The next real improvement isn’t another scanner or another bot. It’s fixing the moment the bad dependency gets chosen in the first place.
AI is only going to keep accelerating how fast we write software. That just raises the cost of bad early decisions. So instead of getting better at mopping, maybe it’s finally time we turn the damn faucet off.