Ask an AI coding tool to add a feature and it will, without asking permission, pull in whatever package makes that feature easiest to build. A form library here, an image processor there, an authentication helper somewhere else. By the time a small project is a few weeks old, it's often carrying fifty to a hundred packages nobody consciously chose one at a time, and almost nobody goes back to check whether any of them have a known problem.
Why "it's working" tells you nothing about this
A package with a known, publicly documented vulnerability keeps working exactly the same as one without it. There's no error message, no warning banner, no visible difference in behavior. The vulnerability sits there quietly until someone specifically goes looking for a way to exploit it, at which point "it's been running fine for months" turns out to have been true and irrelevant at the same time.
The check that actually catches this
Every major package ecosystem ships a free, built-in command for exactly this. If your project uses Node, it's npm audit. Python has pip-audit. Whatever you're using almost certainly has an equivalent, and it's worth knowing the name of yours.
Run it from your project's root folder. Within a few seconds you'll get a list: which packages have a known, publicly documented vulnerability, how severe it's rated, and usually a suggested fix, often just "update to this version." No account, no signup, no cost. It's already sitting in whatever toolchain you're using.
What to actually do with the results
- Sort by severity first. A critical or high finding in a package your app actually uses directly matters far more than a low-severity note buried three dependencies deep.
- Check whether the vulnerable code path is even reachable in how you use the package. Not every finding applies to every use case, but don't use that as an excuse to skip checking; verify it, don't assume it.
- Update what you can with the suggested fix. Most of the time it's a version bump with no other changes required.
- If a fix isn't available yet, note it somewhere you'll actually see again, and re-check in a week rather than forgetting about it entirely.
Why this is worth doing on a schedule, not once
New vulnerabilities get discovered and published in existing, unchanged packages constantly. A dependency that was clean when you first built the feature can become a documented risk months later without you touching a single line of your own code. Running the audit command isn't a one-time launch task any more than checking your database rules is. Both are worth rerunning any time you add a new package, and worth a five-minute pass on a regular basis regardless.
This is one of the few security checks on this blog that requires genuinely zero manual effort to run. The tool exists, it's free, and it's usually already installed. The only step that actually takes discipline is remembering to run it, and then not shrugging off what it tells you.