Website Supply-Chain Security: Finding CVEs in Your Libraries with OSV

When a vulnerability is announced in a popular JavaScript library, the clock starts ticking for every website that ships it. Most teams discover they are affected days later — or never. The uncomfortable truth is that the average website loads dozens of front-end libraries (jQuery plugins, UI frameworks, analytics SDKs, legacy polyfills), and almost nobody maintains a complete inventory of them. In this guide we explain how dependency scanning works in practice, what OSV.dev brings to the table, and how severity should drive your response.

Why Library Vulnerabilities Keep Biting

Front-end and server-side dependency risk has three uncomfortable properties:

1. Invisibility — a jQuery plugin copied into the template in 2019 does not appear in anyone's package manifest. It just… ships.
2. Inheritance — a modern framework pulls in hundreds of transitive packages. You reviewed none of them individually.
3. Long tails — old sites keep shipping libraries years after upstream stopped patching them (jQuery 1.x and 2.x are still common in the wild, with well-documented XSS advisories).

The result: perfectly reasonable websites carry dependencies with public CVEs that anyone can enumerate from the outside — including attackers, because vulnerable library versions are passively detectable and trivially fingerprinted.

What Vulnerable Dependencies Look Like

A typical finding reads like this: the site loads jquery 3.4.1; that version is affected by an advisory covering prototype pollution (CVE-2019-11358) — a weakness that matters mainly if user input ever reaches jQuery.extend in an unsafe way. Severity in isolation: moderate. But the same scan might also surface an old charting library with a known XSS, a Markdown renderer with a sanitization bypass, or a file-upload plugin with a path traversal — each with different urgency.

The point of dependency scanning is not to panic; it is to build the inventory and the priority order so that when a critical advisory drops, you already know whether it applies to you.

How Manifest-Based Dependency Scanning Works

The most reliable approach combines two signals:

1. Declared dependencies (manifests)

Server-side and build-time manifests are the ground truth for what your application actually depends on:

• JavaScript: package-lock.json, yarn.lock — every pinned version, including transitive dependencies
• PHP: composer.lock — the resolved dependency graph for the whole application

When a manifest is publicly reachable (accidentally deployed, or exposed through a misconfigured static directory), a scanner can read the exact dependency list. Even when it is not, front-end bundles disclose their libraries in other ways.

2. Observed libraries (the running site)

What matters even more than the manifest is what actually ships to browsers. Detection here uses multiple layers:

• JavaScript library fingerprinting — recognizing known libraries and versions from their code signatures (our engine runs both a retire.js-based check and a dedicated JS library vulnerability scanner)
• Source map exposure — .map files accidentally deployed alongside minified bundles reveal original file paths, module structure, and sometimes secrets (the Source Map Exposure & Secret Recovery check)
• Technology fingerprinting — a 3,000+ signature tech engine that identifies frameworks and their versions from headers, markup, and static asset patterns
• Outdated software & CVE lookup — cross-references every identified version against known advisories

3. The advisory database: OSV.dev

Once a dependency and version are known, the scanner needs a vulnerability database. We integrate OSV.dev, Google's open, free, keyless vulnerability database. OSV aggregates advisories from GitHub Security Advisories, PyPA, RustSec, Go's vulndb, and more, and — critically — indexes them by package ecosystem and exact version ranges, so a lookup answers "is this version of this package affected?" without false hits on unrelated packages with similar names.

From Finding to Fix

A good dependency report tells you three things for each finding: the exact library and version observed, where it was observed (which page, which bundle), and the advisory list with severity. Remediation is usually mechanical:

1. Upgrade the dependency to a patched version (the first choice whenever possible)
2. Replace abandoned libraries with maintained equivalents — many old plugins have modern successors
3. Remove libraries you no longer use; dead code is pure risk
4. Compensate where upgrade is impossible (legacy platform): a Content-Security-Policy can meaningfully reduce the exploitability of many front-end library CVEs

And because new advisories are published against existing versions continuously, dependency scanning only works as an ongoing process — a site that was clean in June can be critical in September without a single code change on your side. That is the core argument for continuous monitoring rather than annual audits.

Severity Needs Context, Not Just Numbers

CVSS scores for library CVEs answer "how bad is this vulnerability in the worst case?" — not "how exposed is your site?" A 7.5-scored XSS in a library you only load on an internal admin page is a different problem than the same CVE on every public page. Our reports attach the advisory severity (computed locally, exactly per the CVSS v3.1 specification) plus where the library was actually observed, so your team can prioritize on real exposure. For a full primer on reading those scores, see our CVSS scores explained guide.

Inventory Your Dependencies Today

The 2MNY engine's supply-chain scanner reads manifests, fingerprints shipped libraries, and queries OSV.dev — no API keys, no data leaving for third-party scoring. Start with a free scan, review the full scanner family on the features page, or self-host the open-source core (200 modules, Apache-2.0) from GitHub.

Related reading: CVSS Scores Explained · Open-Source Web Vulnerability Scanners in 2026 · Security Headers Explained