Software supply chain security has a well-defined starting line. It has no finish line, even though most programs are built as if it does.
In recent years, organizations have made real progress here. SBOMs (Software Bill of Materials) are now a standard deliverable. Software Composition Analysis (SCA) tools run in CI/CD. Vendor security questionnaires are longer and more rigorous than ever. For Third-Party Risk Management (TPRM) teams, CISOs, and GRC leaders, this represents genuine program maturity.
But all of that maturity is concentrated in one phase of the vendor relationship: before deployment. The SBOM tells you what’s in the build. The questionnaire tells you what the vendor says they do with data. Neither tells you what happens after that vendor’s code goes live in a customer’s browser, because then it executes completely outside your CI/CD pipeline and pre-deployment security checks. It’s being loaded dynamically, often by a tag manager, often without a ticket, and often without anyone on your security team knowing it happened.
This isn’t a case of supply chain security doing its job wrong. It’s stopping one step too early.
What a Typical SBOM and Vendor Review Actually Covers
An SBOM is a snapshot of the components compiled into an application at build time: libraries, packages, versions, and known vulnerabilities (CVEs). Vendor risk assessments run in parallel: security questionnaires, SOC 2 reports, data processing agreements, sometimes a pen test summary. Both processes are thorough and occur at roughly the same moment in the vendor lifecycle: procurement and onboarding.
That timing is the point worth sitting with. An SBOM answers “What did we compile before shipping?” A vendor questionnaire answers “What did this vendor promise before we signed the contract?” Both are backward-looking artifacts, generated once (or refreshed periodically), that describe a historic state of the world at a specific point in time.
Neither one is built to answer a different, increasingly important question: what code is executing in the browser right now on the page where a customer is entering their name, card number, or health information?
What Happens After Deployment
Most third-party code that touches customer data on a live web page was never part of the initial build pipeline. It arrives through tag managers, SDK snippets, ad network pixels, chat widgets, analytics beacons, personalization engines, or increasingly, AI-powered services embedded by a vendor several layers removed from the one you actually assessed.
This code is injected client-side, at runtime, directly into the browser session. It executes after your CI/CD pipeline closes, your SBOM is generated, and the vendor questionnaire has been signed off and filed away. Once live and able to access the DOM, it can read form fields, access cookies and local storage, and call out to third-party domains, including 4th- and 5th-party domains unknowingly pulled in by the original vendor that were never named in any vendor contract.
Marketing adds a new tag. An approved vendor updates their SDK, and it now reads checkout fields and loads two additional scripts. An ad partner’s pixel is compromised upstream and starts skimming form data. None of these events show up in a dependency scan, because none of them touch a repository. They show up, if they show up at all, in the browser — which is exactly the layer most supply chain security programs don’t monitor.
This is the structural gap: organizations have detailed visibility into what they built, and reasonable visibility into who they contracted with, but very little visibility into what’s actually executing in front of their customers on any given day.
Why This Matters: Web-Skimming Attacks
The clearest illustration of this gap in practice is web-skimming attacks, also known as Magecart. This isn’t a single hacker group but rather a long-running category of attacks in which malicious JavaScript is injected into checkout and payment pages to skim card data directly from the browser in real time, as customers type it in.
Magecart-style skimming has compromised well over 70,000 sites, frequently by compromising a trusted third-party script rather than the retailer’s own code. British Airways, Ticketmaster, and Newegg are among the more publicized cases. Still, the pattern repeats constantly at a smaller scale: a legitimate, previously vetted vendor script is compromised upstream, and the malicious version is served to every site that loads it. No code change occurs on the retailer’s side, no vendor review fails, and there’s nothing for an SCA scanner or SBOM audit to flag, because the vulnerable component was never in the build to begin with.
This is what makes the gap between pre-deployment and runtime concrete rather than theoretical. The vendor passed assessment. The script was approved. The compromise happened entirely after that: in the browser, on the exact page where payment data is exposed.
The Missing Detection Mechanism
If the point of exposure has moved to runtime, detection has to move there too. The relevant question isn’t “did this vendor pass review”, it’s “is this script, right now, only doing what it is authorized to do?”
That’s a behavioral question, not a static one. A script approved to render a chat widget that now also reads a password field has drifted from its original purpose, regardless of whether its source domain is still on an approved list. A tag that suddenly starts sending data to a new endpoint, or a library that silently pulls in a new dependency after an update, is exhibiting a behavior change that no build-time scan or annual questionnaire will surface.
Behavioral drift — monitoring what scripts actually do in the browser over time in live sessions, not just what they were declared to do at onboarding — is the detection layer most TPRM and AppSec programs are currently missing. It’s also the layer that would have flagged Magecart-style compromises early, since the malicious version of a script behaves differently from the legitimate one long before the breach makes headlines.
From Visibility to Enforcement
Visibility is the necessary first step, but it isn’t sufficient on its own. Knowing that a script started behaving differently is only useful if there’s a mechanism to act on it before data leaves the browser.
That points toward two capabilities most organizations don’t yet have in place:
- Least-privilege script access: Third-party code should be scoped to only the data and page elements it actually needs, the same way least-privilege access is applied to internal systems and APIs. A chat widget doesn’t need read access to a card number field.
- Real-time blocking before exfiltration: When a script’s behavior drifts outside its expected scope, the response needs to happen in the session, not in a post-incident report. By the time a quarterly vendor review catches an issue, the data has already left.
Together, these shift third-party risk management from a point-in-time approval exercise into a continuous control that governs what vendor code is actually doing on an ongoing basis, not just what it was approved to do once.
Conclusion
Vendor assessments and SBOMs remain necessary. They establish the baseline of what should be running and who’s accountable for it. Closing that gap means extending supply chain governance past the build and past the questionnaire, into the runtime environment where third-party code actually touches customer data.
See what’s actually running on your site.
Get a real-time inventory of every script running on your web pages—including the ones that loaded after your last security review.
