Stop 05 · Vulnerabilities & OWASP Top 10Topics · 10/11

Vulnerable & Outdated Components

Part of the Cybersecurity Roadmap

In short

Your app might have 30 direct dependencies and 800 hidden ones underneath. When a hole is found in any of them, it's your hole too, until you update.

Using libraries, frameworks, or dependencies with known vulnerabilities — often introduced unknowingly through transitive dependencies, making dependency scanning (Phase 10) essential.

The blob shines a torch at a rusty, sparking old fuse box on the wall while holding a new circuit breaker.

Think of it like this

Old wiring in a rented flat

You buy shiny new appliances, but the flat still runs on 20-year-old wiring behind the walls. One day it sparks. You didn't install that wiring, yet your home is the one at risk. Dependencies are that hidden wiring under your code.

Watch it happen

Where a known hole hides

your-app
web framework
image library
body parser
query parser
zip helper

1/5Your package.json lists only a couple of direct dependencies.

The big ideas

What you need to know

Know what you ship

A lockfile and an SBOM (software bill of materials) list every package and version in your build.

Scan automatically

npm audit, Dependabot, Snyk or OSV-Scanner compare your packages against databases of published vulnerabilities.

Small, frequent updates

Updating a little every week is easy. Jumping three major versions after two years is painful.

Remove what you don't use

Every unused package is extra risk with zero benefit. Delete it.

See it in code

Walk through the code

bash
1# Install exactly what the lockfile says2npm ci3 4# List known vulnerabilities in production dependencies5npm audit --omit=dev6 7# Fail CI only for high and critical issues8npm audit --audit-level=high9 10# See which package pulled in a vulnerable one11npm explain minimist

1/4npm ci installs the exact versions in package-lock.json, so CI and production match.

Commit your lockfile. Without it, two installs of the same project can pull different versions.

Save yourself the pain

Common mistakes

Oops

Running npm audit fix --force and pushing straight to production.

Do this instead

--force can install breaking major versions. Update on a branch, run tests, then merge.

Oops

Ignoring audit warnings because "it's only a dev dependency".

Do this instead

Dev tools run on your machine and CI. Judge each finding by where the package actually runs.

Your mission

Audit an old project

~30 min

Quick check

npm audit flags a package you never installed. What's the most likely explanation?

Go deeper

  1. 1Run a dependency scan on a sample project and review any flagged vulnerable libraries.
  2. 2Learn why a project can be vulnerable through a dependency it doesn't directly control.
  3. 3Understand why keeping dependencies updated is a simple but frequently neglected practice.

More topics at this stop

Stuck on this topic? Ask an Insider

Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.

Download
InsideEdge