guest@websec: ~/websec/17-dependencies-and-cves — zsh — 100×40 by SaKKo ENTH code:

guest@websec ~ % npm audit

17 · Dependencies and CVEs

An app pulls in hundreds of libraries, all running with full power. When one gets a known hole, attackers start scanning within days.

Nobody updates your dependencies for you

When a library ships a security fix, nothing changes in our app until we update. Until then, the lockfile keeps installing the old, vulnerable version.

Run bundler-audit and brakeman, turn on Dependabot, and stay on a Rails version that still gets security fixes.

CVEs and advisories, briefly

  • A CVE is just an ID for one known vulnerability.
  • Advisory databases say which versions are affected.
  • Severity scores help, but what matters is whether we actually use the broken code.

Updating safely: change as little as possible

Update just the broken package, not everything. A small change ships today; a big one turns into a week of fixing unrelated breakage.

ecosystemfind vulnerable packagesupdate one package conservatively
Ruby / Bundlerbundle auditbundle update --conservative rack
Node / npmnpm auditnpm update lodash or npm install lodash@4.17.21
Node / pnpm, yarnpnpm audit, yarn npm auditpnpm update lodash, yarn up lodash
Python / pippip-auditpip install -U "jinja2>=3.1.4" then re-freeze
Python / Poetry, uvpip-auditpoetry update jinja2, uv lock --upgrade-package jinja2
PHP / Composercomposer auditcomposer update guzzlehttp/guzzle --with-dependencies
anyOSV-Scanner, Snyk, TrivyDependabot / Renovate open one PR per update
sim: patching a transitive CVEillustrative versions and advisory

Version ranges decide what "update" means

Versions go MAJOR.MINOR.PATCH. Patches fix bugs, majors may break things. Your version range decides how far an update can move:

sim: which versions does this range allow?npm / Composer / Cargo semantics

Bundler's ~> 4.17 works like npm's ^4.17.

A dependency hygiene checklist

  • Commit the lockfile.
  • Automate it: Dependabot plus an audit step in CI.
  • Follow Rails security announcements.
  • Update little and often. A year behind is hard to patch in a hurry.
  • Be picky about new gems. Watch for look-alike names.
  • Install from the lockfile in CI and production.