Ask for evidence, not promises: how the vendor secures access to its servers, how it monitors its own JavaScript for malicious changes, and what it tells you when something goes wrong. OWASP suggests requiring this evidence in agreements. Have your own counsel review the wording, since this post is not legal advice.
Why the contract matters for scripts
When your page loads a vendor script, the vendor can change what runs for your customers at any time. The OWASP Third Party JavaScript Management Cheat Sheet lists this among the major risks: loss of control over changes, execution of arbitrary code on client systems, and disclosure of sensitive information.
You cannot review code that changes without notice, and the code is often obfuscated. So the agreement is one of the few places where you can ask the vendor to carry part of the burden.
OWASP uses the term MarTechSec for this: the controls that reduce the risk from marketing JavaScript. It splits them into contractual controls for risk reduction, contractual controls for risk transference, and technical controls.
Questions to put to the vendor
| Topic | Question |
|---|---|
| Code integrity | How do you detect unauthorized changes to the script you serve? |
| Access | Who can publish to the servers or storage that host it, and how is that access protected? |
| Change notice | How and when do you tell customers about script changes? |
| Version pinning | Do you offer versioned URLs so we can pin a file? |
| Data collected | Exactly which page data does the script read and send? |
| Subprocessors | Which other parties receive data from your script? |
| Incident notice | How quickly will you tell us if your script was altered? |
| Exit | What happens to the script and domain if the service ends? |
OWASP states that the contract should include a requirement to show evidence of code security and code integrity monitoring. It also notes contracts could include a penalty for serving malicious JavaScript, which is a risk transference control. Whether that is realistic depends on the vendor's size and your leverage, so discuss it with counsel.
What evidence looks like
Ask for something you can read. A short description of the build and release process, the controls on who can change the hosted file, and a statement of how changes are logged is more useful than a generic security badge. If the vendor has a published security page, note its date and keep a copy.
Avoid taking any single certificate as proof that a script is safe. A report about an organization's systems does not describe the exact file your customers receive on a given day.
Pair the contract with technical controls
An agreement does not stop a bad script. Combine it with the technical measures you control: a versioned file with a Subresource Integrity hash, a Content Security Policy, and a tag register with an owner for each vendor. If you have a vendor review path for third-party scripts, use these questions as part of it.
Keep a record
Store the answers next to the contract and note the review date. Revisit them at renewal, and when the vendor changes ownership or hosting.
Where Safeguard fits
Safeguard supports compliance and evidence automation for your own software supply chain, and its SBOM and dependency scanning covers packages in your build. Vendor-served scripts need the contractual and page-level controls above. A free scan is at gold.safeguard.sh/scan.
Quick check
Is a vendor's security certificate enough?
No. It describes the organization's controls at some point in time, not the file served to your customers today. Ask about integrity monitoring and change notice as well.
Who should own the vendor questions?
Procurement runs the process, security writes the questions, and the tag owner records the answers.
Sources
Last reviewed: 19 October 2026.
