Last month, the Node.js project shipped security releases for versions 10, 12, and 14. If you’re running Node 6 in production—and I know some of you are—you got nothing.

Node.js 6 reached End-of-Life in April 2019. That was over a year ago. No more patches, no more backports, no more security fixes. The June 2020 releases addressed TLS session reuse vulnerabilities, HTTP request smuggling vectors, and DNS rebinding issues across the active release lines. Node 6? Exposed to all of them, with zero official remediation path.

I’ve been managing engineering teams long enough to know that “just upgrade” is rarely as simple as it sounds. But I’ve also seen what happens when you don’t.

The Real Cost of EOL #

Running an EOL runtime isn’t just a checkbox on some compliance audit. It’s a compounding risk. Every month that passes, the gap between your version and the last patched release grows. Vulnerabilities disclosed against Node 10, 12, or 14 often affect older versions too—but nobody’s checking anymore.

The June 2020 security releases (Node 10.21.0, 12.18.2, 14.5.0) fixed issues in the HTTP parser and TLS implementation. These are core modules. You can’t npm install your way around a vulnerability in the runtime itself.

And here’s what I think people underestimate: the CVE database doesn’t stop tracking vulnerabilities just because your version is unsupported. The vulnerabilities still exist; they just don’t get fixed.

npm audit Is Your Minimum Viable Defense #

If you’re on npm 6 or later, npm audit should be part of your CI pipeline. Not optional, not “we’ll get to it.” Right now.

npm audit

It scans your dependency tree against the npm security advisory database and reports known vulnerabilities by severity. It’s not perfect—it can’t catch zero-days or malicious packages that haven’t been reported yet—but it catches the known stuff, and the known stuff is what bites most teams.

npm audit fix

This attempts automatic resolution by bumping to patched versions within your semver ranges. For anything it can’t auto-fix, you’ll get a report of what needs manual intervention. In my experience, about 60-70% of advisories resolve with npm audit fix; the rest require you to actually look at the dependency and decide.

A few things I’ve learned running this across multiple services:

Run it in CI, not just locally. Developers forget. CI doesn’t.

Don’t ignore low-severity advisories forever. They accumulate, and some get reclassified. (I once saw a “low” get bumped to “critical” six months later when someone realized the exploit chain was way worse than initially thought. Fun times.)

Lock your lockfile. If package-lock.json isn’t committed, your audit results are meaningless because every install might resolve differently.

Schedule regular audit reviews. Once a week at minimum. I’ve seen teams set up Slack notifications from their CI runs, which works well enough—though honestly, after the third week of “47 vulnerabilities found” with nobody doing anything, people start tuning those notifications out. So maybe fix the vulnerabilities too.

Snyk and GitHub Security Advisories #

npm audit covers the npm advisory database, but it’s not the only source of vulnerability data. Snyk maintains its own database and often catches things earlier or provides more detailed remediation guidance. If you’re on GitHub, Dependabot already generates pull requests for vulnerable dependencies automatically—assuming you’ve enabled it (it’s on by default for public repos).

The combination of npm audit in CI plus Dependabot PRs gives you reasonable coverage without much ongoing effort. Snyk adds another layer if you want deeper analysis or if you’re dealing with container images and infrastructure-as-code alongside your Node dependencies.

None of these tools replace actually reading the advisories, though. Automated tools tell you what’s vulnerable; understanding whether it affects your specific usage still requires a human.

The Upgrade Conversation #

Look, if you’re still on Node 6, the conversation you need to have isn’t about which audit tool to use. It’s about when and how to migrate.

Node 12 is the current LTS. Node 14 just entered LTS candidacy and will become the active LTS line in October. Either is a reasonable target. The jump from 6 to 12 or 14 is significant—you’ll hit breaking changes in V8 (async/await is native now, Buffer constructors changed), native addon compatibility issues if you use any, and probably a few dependency upgrades that cascade.

My approach with teams has been to start with inventory. Know every service running Node 6. All of them. The one you forgot about will be the one that breaks—it always is.

Then start with the least critical service. Get one migration under your belt, document the gotchas, then parallelize. Don’t skip versions in testing. Even if you’re targeting Node 14, run your test suite against 12 first. It narrows down where breakage comes from.

And budget time for native module rebuilds. If you’re using anything with C++ bindings—node-sass was a classic offender, though thankfully less common now—expect friction. Lots of it.

NodeSource offers commercial extended support for EOL Node versions if you genuinely can’t migrate yet. That buys you time, not a solution. The migration still needs to happen.

Dependency Hygiene Beyond Audits #

Audits catch known vulnerabilities. What about everything else?

Keep your dependency tree shallow. Every transitive dependency is an attack surface you didn’t explicitly choose. Review what you’re pulling in. I’ve seen production services with 1,200+ packages in their node_modules for a simple API server. That’s not a dependency tree; it’s a liability. (I still remember the first time I ran npm ls on a project and the output scrolled for thirty seconds. Horrifying.)

Use npm ls --depth=0 to see your direct dependencies. If you can’t explain why each one is there, you’ve got cleanup to do.

Pin major versions in production. Semver is a social contract, not a guarantee. A minor version bump that introduces a vulnerability—or just a bug—can slide in silently if your ranges are too loose.

And audit your audit process. Are you actually acting on the results, or are they just noise in a CI log that nobody reads? I’ve worked on teams where npm audit ran every build and had 47 open advisories that nobody had looked at in months. That’s worse than not auditing at all, because it creates a false sense of security. Everyone thinks “oh, we’re covered, we have audits” while the vulnerabilities just… sit there.

The Bottom Line #

If you’re on a supported Node.js version with npm audit in your CI pipeline, Dependabot enabled, and a regular cadence of dependency reviews—you’re in decent shape. Not perfect, but decent.

If you’re on Node 6, none of that matters until you migrate. The runtime itself is the vulnerability. Everything else is secondary.

The June 2020 security releases were a reminder: the Node.js project moves fast, and staying current isn’t just about features. It’s about not being the team that gets hit by a patched vulnerability because you didn’t patch.