Vulnerable dependencies: the code you did not write
A typical web project ships far more third-party code than its own, much of it pulled in indirectly. A known vulnerability in any of it is a known vulnerability in your application.
Example
"node_modules/lodash": {
"version": "4.17.15"
}
// prototype pollution and command injection advisories apply"node_modules/lodash": {
"version": "4.17.21"
}
// one upgrade clears every advisory against 4.17.15How it happens
Packages are added once and rarely revisited; a lockfile keeps them pinned to the version installed that day. Advisories are published later against those exact versions. Transitive packages — dependencies of dependencies — are the majority and the least visible, and libraries copied into a site from a CDN often stay on the version from the day the page was built.
How to fix it
Upgrade by evidence, not by guesswork.
- Check the versions in the lockfile, not the ranges in the manifest
- Prefer the upgrade on your current major line that clears every advisory
- For transitive packages, upgrade the direct dependency that brings them in
- Replace packages that are deprecated or have no fixed release
How RepoVerse finds it
- HighFront-end library with known vulnerabilities
The page ships a library version that has published advisories; the vulnerable code runs in every visitor's browser.
website · CWE-1104
- LowThird-party script loaded without integrity check
If the CDN or the other site is compromised, the script it serves runs on your pages with full access — the supply-chain path behind several card-skimming attacks.
website · CWE-353
Questions
- Are development dependencies a risk?
- Less than runtime ones, because they do not ship to users, but they run on developer machines and CI. RepoVerse marks them so production risk is read first.
- How often should dependencies be checked?
- On every change to the lockfile and on a schedule, because new advisories are published against versions you already have.
Related
- Dependency vulnerability scanner that reads your lockfileCheck npm, yarn, pnpm, PyPI, Cargo, Composer and RubyGems lockfiles against the OSV vulnerability database. Exact installed versions, transitive paths and fixed releases.
- Find vulnerable JavaScript libraries on a live websiteFind outdated, vulnerable JavaScript libraries on any website — jQuery, lodash, Bootstrap, moment, DOMPurify, Next.js — even inside minified Vite and webpack bundles.
- GitHub security scanner for code, secrets and dependenciesScan a GitHub repository for injection flaws, leaked secrets and vulnerable dependencies. Data-flow traces from request to sink, lockfile-aware, with fixes.
Updated 2026-10-11