Does your site load scripts from a host with a past security incident?
This check matches the hosts your pages load scripts from against hosts named in published supply-chain incident reports. A match is a reason to review that script, not proof of harm today.
What does this check look at?
It looks at whether a page loads a script from a host named in published supply-chain incident reports. OWASP names the single greatest risk of third-party scripts as a compromise of the third party JavaScript server.
MDN calls an attacker taking over a third-party host and changing its files a supply chain attack.
Pulse and Deep scans both run it. It applies only when the script host incident analyser is on, as it is by default.
What does a result mean?
| What the report shows | What it means | What to do |
|---|---|---|
| Medium finding | A script tag points at a host named in incident reporting. | Remove it if unused, or replace it with a maintained source or your own copy. |
A match does not prove the script ran or that the host serves harmful code today. A clean result means nothing was found in what the scan read. It does not prove the problem is absent from parts the scan never sees.
How serious is a finding?
Fix this soon. A finding of this kind needs a victim or a second step before it causes harm, so it ranks below anything someone could use directly. Confidence starts at medium, because it rests on a pattern in your content. The report lists what to fix by how directly someone could use it, not by the severity label.
What does a confirmed finding have to show?
| Part | For this check |
|---|---|
| Where it starts | A script host named in a published historical incident |
| The protection that should stop it | The page delegates script delivery to the named host |
| What is reached | A declared external script that a visitor browser may load |
| What follows | Browser-side changes if untrusted code is delivered and executed |
Fix it with your AI
Old template snippets are the usual cause, so start by finding where the tag comes from.
My site loads a script from a host named in past supply-chain incident reports: [paste the host from the report]. Find every template, layout, CMS setting or plugin that adds this script tag. Tell me what feature it provides. Remove it if nothing needs it, or replace it with a maintained package bundled with my site or a reviewed self-hosted copy. Test the pages that used it.How to check
Say Atlas, our example app at atlas.example, still has a polyfill tag in an old layout from a host that changed hands. The check names the host and the page.
Run a Pulse scan from your Lockpick account to see it for your site. Pulse or Deep explains what each scan reads, and the full list of checks shows the rest.
Questions people ask
Does this mean my visitors were attacked?
Not necessarily. The match shows the tag is there. Whether harmful code was ever served needs the host logs and the incident timeline.
The script still works. Why remove it?
A host that was compromised once, or changed owners, can change the file at any time. Your own copy only changes when you change it.
See what your site shows from outside
A quick check reads your homepage the way a visitor would and gives you a score. No account needed.
Check your siteSources
- How we rate findings Lockpick docs, read on October 7, 2026
- Subresource Integrity MDN Web Docs, read on October 7, 2026
- Third Party JavaScript Management Cheat Sheet OWASP Cheat Sheet Series, read on October 7, 2026