The Vendor Question Nobody Can Answer: How Would You Know Your CDN Was Compromised?

Ask a SaaS vendor how they would detect that a third-party script on their application had been modified. Most answers fall into three groups.

“We only use reputable vendors.” That is vendor selection, not detection.

“We have a CSP.” A CSP permits that origin. The modified script arrives from exactly where the policy says scripts may come from.

“We review our dependencies.” That covers what you build, not what a CDN serves at runtime.

The honest answer, for most vendors, is that they would not know.

Why this attack passes every usual control

Walk through what happens when a CDN serving your analytics or support widget is compromised and begins serving modified JavaScript.

Control	Status during the attack
TLS	Valid. The connection is properly encrypted.
CSP script-src	Passes. The origin is allowlisted.
Authentication	Unaffected. The user is legitimately logged in.
WAF	Sees nothing. The request goes browser to CDN, never touching your infrastructure.
Dependency scanning	Sees nothing. This is not in your package.json at build time.
Pentest from last quarter	Tested the script that was there in June.

The script runs in your origin, with access to your DOM, your forms and any token reachable from JavaScript. It is a credible path to mass credential theft, and it has been used that way repeatedly.

The reason it evades everything is structural: every control above validates provenance or transport, and none validates content.

The control that does validate content

Subresource Integrity. You publish the hash of the file you approved, the browser computes the hash of what it received, and a mismatch means the script does not execute.

<script src="https://cdn.example.com/widget.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
        crossorigin="anonymous"></script>

This works, and it has one flaw that has nothing to do with cryptography: it is opt-in per tag. The script someone adds next quarter without an integrity attribute is unprotected, and partial SRI protects nothing, because an attacker needs only one unprotected script.

Coverage decays by default. That is not a discipline problem, it is what happens to any control that depends on everyone remembering it forever.

Making it structural

Integrity-Policy moves the requirement from the tag to the page. The browser then blocks any script arriving without integrity metadata, including the one added next quarter.

Integrity-Policy: blocked-destinations=(script), endpoints=(integrity-endpoint)
Reporting-Endpoints: integrity-endpoint="https://example.com/_reports/integrity"

The catch worth planning for: there is no first-party exemption. Your own bundles need integrity metadata too, which is a build-pipeline change rather than a header change. Deploy Integrity-Policy-Report-Only first, treat the resulting violation list as your inventory, and enforce once it is empty.

The full deployment path and browser support.

Answering the question in a questionnaire

The difference between a weak and a strong answer here is unusually large, because most competitors give the weak one.

Weak: “We use reputable third-party providers and review them annually.”

Strong:

Third-party scripts are pinned with Subresource Integrity hashes generated at build time. Integrity-Policy is enforced at the browser, so any script served without integrity metadata is blocked rather than silently executed, including newly added ones. Violations report to an internal endpoint and are alerted on. Our CSP uses nonce plus strict-dynamic rather than an origin allowlist, so a compromised allowlisted origin is not automatically trusted.

Four separate mechanisms, each verifiable, and it directly answers the detection question rather than the selection question.

The obligation behind the question

This is not only a good-practice matter. Supply chain security is an explicit obligation:

• NIS2 Article 21(2)(d), supply chain security, including security-related aspects of relationships with direct suppliers. Where most vendors have a gap.
• NIS2 Article 21(2)(g), basic cyber hygiene.
• ISO/IEC 27001:2022 A.5.21, managing information security in the ICT supply chain, and A.8.28, secure coding.
• DORA Article 28, ICT third-party risk, where the requirement is contractual as well as technical.

The regulatory framing has shifted from “choose good suppliers” toward “demonstrate you would detect a supplier failing”. SRI enforcement is one of very few controls that answers the second phrasing with a technical mechanism rather than a process document.

How this fits with an SBOM

An SBOM tells you what you depend on. Integrity enforcement tells you that what shipped is what you approved. They are complementary and frequently confused.

An SBOM would not have detected a compromised CDN, because the dependency list was correct the whole time. The file at that URL changed.

The short version

A compromised third-party script passes TLS, CSP, authentication, your WAF and your dependency scanner, because all of those check where code came from and none check what it contains.

SRI checks content. Integrity-Policy makes SRI impossible to forget. Together they are the only answer to “how would you know” that is a mechanism rather than a hope.