How to Fix Outdated & Vulnerable Dependencies

You didn't write the vulnerable code, but you shipped it anyway - a known CVE sitting in a dependency (often one you never installed directly) is one of the most common ways production applications actually get breached.

Why This Keeps Happening

Lockfiles get committed once and rarely revisited.A dependency pinned at install time doesn't update itself - if nothing in your workflow prompts a review, it just sits there.
Most of the risk is transitive.A CVE in a package three levels deep in your dependency tree still runs in your app, and you likely have no direct awareness it's even installed.
Upgrade fear.Bumping a major version risks breaking changes, so teams delay - and the gap between "vulnerable" and "patched" widens.

How to Find What's Actually Vulnerable

Start with your package manager's built-in audittypescript

1npm audit
2# or
3yarn audit
4# or
5pnpm audit

This surfaces known CVEs by severity, along with the vulnerable version range and (when available) the patched version to upgrade to.

A Practical Triage Process

1. Sort by severity and reachability, not just count

A hundred low-severity findings in a devDependency matter less than one critical finding in a package your production request path actually calls into.

2. Fix the minimum version bump that resolves it

Target the patched version directly instead of jumping to latesttypescript

1npm install some-package@^2.4.1   # the version the advisory says is fixed

3. Re-test after upgrading

A version bump that fixes a CVE can still introduce a regression - run your existing test suite before shipping the update, not just the audit re-check.

4. Automate this instead of doing it quarterly

Wire a dependency scan into CI on every pull request so a new CVE in an existing dependency (or one introduced by a new package) gets caught before merge, not discovered months later during a cleanup pass.

How Scanverra Detects This

Scanverra's repo scanner parses your project's dependency manifests and lockfiles, cross-references every direct and transitive package against known CVE data, and reports each vulnerable dependency with its severity and the version that resolves it - as part of the same scan that also runs SAST, secrets detection, and code quality checks.

FAQ

Frequently asked questions

Do I need to worry about vulnerabilities in devDependencies?

Less urgently than production dependencies - a vulnerable devDependency isn't shipped to users or running in production, but it can still matter if it's a build-time tool that processes untrusted input (a linter plugin, a bundler loader) or if your CI environment itself is a target.

What's a transitive dependency, and why does it matter more than it seems like it should?

It's a dependency of your dependency - something you never installed directly and often don't even know is in your tree. A CVE in a transitive package still ships in your bundle and runs in your app; npm audit and similar tools walk the full tree specifically because direct dependencies alone miss most of the real exposure.

Is upgrading to the latest version always the right fix?

Not automatically - a patch or minor version bump that fixes the CVE is usually safe; a major version bump can include breaking changes that need actual code changes and testing. Check the vulnerable version range in the advisory and upgrade to the minimum version that resolves it, then evaluate a further upgrade separately.

What if there's no fixed version available yet?

Check if the vulnerable code path is actually reachable in your usage - some CVEs only apply to specific functions or configurations you may not use. If it is reachable and unfixed, look for an actively maintained fork or alternative package rather than shipping with a known, unpatched vulnerability.

Scan your dependencies for free

Run a repo scan and see every vulnerable dependency, direct or transitive, before it ships.

Run free audit