Safeguard
Supply Chain•

Does a dependency scan cover scripts loaded from a CDN?

A script tag pointing at a CDN never appears in package.json, so most dependency scans skip it. Learn how to inventory it and add integrity checks.

Safeguard Security Team
3 min read

Usually not. A dependency scan reads manifests and lockfiles, and a script tag that loads a library from a CDN appears in neither. To cover it you need to inventory those tags, record versions, and add Subresource Integrity so the browser rejects a changed file.

Why it falls outside

Package based scanning starts from files like package.json and a lockfile. A page that includes script src="https://cdn.example.com/lib.js" pulls code at load time from another host. No file in your repository names the library, its version or its hash.

MDN describes the exposure: when you load a script from a third party CDN, you trust that host to serve exactly the code you expect. If an attacker compromises the CDN, they can inject malicious code or replace the file, which is a supply chain attack.

What Subresource Integrity does

SRI lets you supply a cryptographic hash that a fetched resource must match. The integrity attribute holds one or more hashes, each prefixed with the algorithm (sha256, sha384 or sha512). If the hash does not match, the browser refuses to load the resource and returns a network error.

Cross origin resources need CORS. The CDN must send an Access-Control-Allow-Origin header and your markup must carry crossorigin="anonymous", or the browser cannot read the response to verify the hash.

SRI protects integrity, not freshness. A pinned file with a known flaw still loads. Hashes stop silent change, they do not tell you the library is vulnerable.

How to cover CDN scripts

  1. Inventory. Search templates and built pages for script and link tags with external sources. Record host, path and version in the URL.
  2. Pin versions. Avoid URLs that say latest or use a loose range, since they change under you.
  3. Add integrity. Generate a hash from the exact file and set the attribute. MDN suggests an openssl command piped through base64 for this.
  4. Look up advisories. Check each library and version against an advisory source. Some scanners can fingerprint front end libraries in a web page, so ask yours.
  5. Prefer self hosting for libraries you keep long term, and then they enter your lockfile.

What to ask a vendor

  • Can the tool scan a deployed page or a built bundle, not just source manifests?
  • Does it identify libraries by content fingerprint?
  • Is the CDN inventory included in coverage claims, or listed as out of scope?

Related: what manifest only scanning misses.

Safeguard's dependency scanning covers manifests and lockfiles, and its DAST web app scan examines a running site. The free scan is at https://gold.safeguard.sh/scan.

Quick check

Does SRI tell me a library is vulnerable?

No. It only ensures the file matches the hash you supplied. A known flawed version with a valid hash still loads.

Why does SRI need the crossorigin attribute?

Cross origin resources must use CORS so the browser can read the response and verify the hash.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.