Software Supply Chain Security for Adtech and Martech: A 90-Day Plan

Software supply chain security for an adtech or martech company comes down to three jobs: know every package, SDK, tag and pipeline component that touches the data you collect, know who controls each one and what it can send where, and run a patch and review clock that reaches the code in your bidders and data services, the SDKs you ship to publishers and apps, and the scripts your marketing team adds to live pages. The hard part in this industry is that most of the code that handles personal data runs somewhere you do not control: a publisher's page, a user's phone, a retailer's checkout, a partner's server. A focused team can build the inventory, the intake rules and the release gates in about 90 days.

This guide covers the software these companies run, the US rules that apply (with EU context), six recent incidents, the people who own each piece and a 30, 60 and 90 day plan that works with any tools. Safeguard appears only near the end. Nothing here is legal, regulatory or audit advice.

Key takeaways

• Adtech and martech code is your own services, plus open source from npm, PyPI, Maven and other registries, plus SDKs and tags written by other companies, plus whatever your build pipeline pulls in. The program has to cover all four, including the SDK versions still running on publisher pages and in installed apps.
• US enforcement treats data that leaves through third-party code as your responsibility. The FTC's April 2024 Cerebral action described tracking tools on a website and apps that sent sensitive data on nearly 3.2 million consumers to third parties for advertising.
• The FTC's January 2025 final orders against two location data brokers added a ban on collecting data from real-time bidding exchanges for any purpose other than taking part in the auction, and required a supplier assessment program to check consent upstream.
• California's updated CCPA regulations took effect on 1 January 2026, with cybersecurity audit certifications due from 1 April 2028 for the largest businesses. Under the Delete Act, data brokers have had to process deletion requests from the state's DROP platform since 1 August 2026.
• The US Department of Justice's Data Security Program has been in effect since 8 April 2025 and restricts some transactions involving bulk sensitive personal data, including geolocation, with countries of concern.
• Software risk lands in shipping code: a compromised GitHub Action (March 2025), an npm account takeover and a self-replicating npm worm (September 2025) all hit the JavaScript and build systems adtech runs on.
• Seven roles own the problem, from the CISO and engineering leaders to privacy, marketing operations, vendor risk and SRE.
• Safeguard capabilities covered in this post, all GA: SBOM generation and analysis, software composition analysis (SCA), vulnerability management with EPSS and KEV, reachability analysis and prioritization, continuous scanning, policies, gates and guardrails, autonomous remediation (ships switched off), license compliance, SAST, DAST, Third-Party Risk Manager (TPRM), the Compliance and GRC suite, Trust Center, Portal audit trails, the CLI, the local runner and the Safeguard mobile app (shown in the demos).

What software adtech and martech companies run

Adtech covers demand-side and supply-side platforms, exchanges, ad servers, measurement firms and data providers. Martech covers the tools marketers use to reach their own audiences: customer data platforms, email, analytics, attribution, personalization and consent tools. Many companies sit in both.

Bidders, exchanges and ad servers

Programmatic advertising runs on high-throughput services that receive bid requests, decide whether and how much to bid, and answer within a few tens of milliseconds. They are usually written in Go, Java, C++, Rust or Kotlin and pull in serialization, HTTP, compression and geolocation libraries. They see device identifiers, IP addresses and location signals on every request, so a vulnerable parsing library is exposed to untrusted input at enormous volume. Ad servers and creative delivery systems sit next to them, with web front ends built from npm packages.

SDKs and tags you ship to other people

This is where adtech differs from most industries. Many adtech and martech companies ship code that runs inside someone else's product:

• Web tags and pixels. A few lines of JavaScript that a publisher or advertiser pastes into their page, which then load a larger script from your servers or CDN.
• Mobile SDKs. Libraries for iOS, Android, Unity and cross-platform frameworks that app makers compile into their apps for ads, attribution, measurement or engagement.
• Connected TV and video SDKs. Players, ad insertion and measurement libraries for TV platforms. Industry standards such as IAB Tech Lab's Open Measurement SDK are themselves shared components that many vendors integrate.
• Server-side integrations. Client libraries and containers that partners run to send events to your APIs.

Each has its own dependency tree and a long tail of old versions on sites and devices you will never touch. When an npm dependency is compromised, the question is whether the bundle you served to publisher pages contained it.

Tag managers, consent tools and the marketing website

Marketing teams run their own deployment pipeline. A tag manager lets them change JavaScript on live pages without an engineering release, a consent management platform decides which tags may fire, and the marketing site often runs on a different stack owned by marketing operations or an agency. OWASP's Third Party JavaScript Management Cheat Sheet describes the core problem plainly: when a tag manager or vendor changes a script, the next browser that loads the page gets the changed code. We cover this in more depth in your tag manager is a second deployment pipeline.

Data platforms, analytics and messaging

Customer data platforms, identity graphs, clean rooms, attribution and measurement pipelines join first-party data with partner data. They run on Python, Spark, Kafka, dbt and Airflow plus a long list of connector packages and vendor SDKs, many holding credentials with broad access. Email, SMS, push and personalization integrations handle contact data and send on your behalf through open source template and rendering engines. Bid shading, fraud scoring and lookalike models add notebooks, model libraries and large language model SDKs, often installed straight from public registries on data scientists' machines.

The build and release pipeline

All of the above is built by CI systems that pull GitHub Actions or other plugins, run package installs, and publish SDKs to registries or CDNs. A compromised pipeline step can change what every publisher receives.

The regulations and frameworks that apply

Adtech and martech sit under privacy and consumer protection law more than under sector security rules. The rules below do not say "software supply chain", but each one makes you answerable for what code you run and where data goes. US rules lead; EU rules follow as context.

FTC Act Section 5 and the FTC's orders

The Federal Trade Commission enforces against unfair and deceptive practices, and its recent orders show how it treats data that leaves through third-party code.

In its 15 April 2024 announcement about the telehealth company Cerebral, the FTC said the company used or integrated tracking tools on its website and apps that gave sensitive information about nearly 3.2 million consumers to third parties such as LinkedIn, Snapchat and TikTok. The proposed order banned using or disclosing personal and health information for most advertising, required a comprehensive privacy and data security program and a data retention schedule, and imposed payments. The detail that matters for engineers: the data moved through code a marketing or growth function had added, not through a breach.

On 3 December 2024 the FTC announced proposed orders against Gravy Analytics and its subsidiary Venntel, which it said obtained consumer location information from other data suppliers, and against Mobilewalla. The FTC finalized both on 14 January 2025. The Gravy order requires a sensitive location data program and a supplier assessment program to check that consumers consented to the collection of the location data the companies buy. The Mobilewalla order bars collecting consumer data from real-time bidding exchanges for any purpose other than taking part in the auctions; the FTC said this was the first time it had alleged such collection to be an unfair practice.

The lesson for a supply chain program: a supplier assessment program is a supply chain control in legal form, and the same discipline applies to software suppliers.

California: the CCPA regulations and the Delete Act

California's privacy agency, which now brands itself CalPrivacy, announced on 23 September 2025 that the state's Office of Administrative Law had approved regulations on cybersecurity audits, risk assessments and automated decisionmaking technology, plus updates to the existing CCPA regulations. The regulations took effect on 1 January 2026, with later dates for some duties:

Which businesses must complete an audit depends on thresholds in the regulations; read them with counsel. For a company that sells or shares personal information at scale, these duties make an inventory of the code that processes it hard to avoid.

The Delete Act adds a duty for registered data brokers. The agency's data broker page says that beginning 1 August 2026, data brokers must access the Delete Request and Opt-Out Platform (DROP) at least once every 45 days and process consumer deletion requests, subject to limited exceptions. Deletion has to reach every system that holds the data, including the pipelines, connectors and partner feeds built from the components this guide covers.

Other states have their own privacy laws; we did not confirm each on its primary source for this post.

The DOJ Data Security Program

The Department of Justice's Data Security Program, issued under Executive Order 14117, went into effect on 8 April 2025. DOJ says it addresses access by countries of concern to Americans' bulk sensitive personal data, including geolocation, health and financial data; its due diligence and audit requirements for restricted transactions took effect in October 2025. If you sell or give access to location or device data, ask counsel how it applies, and treat your vendor and software supplier inventory as part of the answer.

PCI DSS for martech scripts on payment pages

Martech tags often end up on checkout pages. The PCI Security Standards Council's 10 March 2025 post on payment page security says PCI DSS v4.x Requirements 6.4.3 and 11.6.1 focus on making sure payment page scripts are authorized, checked for integrity and monitored for tampering, and that the Council does not decide whether an implementation complies; your acquirer or payment brand does. An analytics tag on a payment page is a payment page script like any other.

Industry frameworks and standards worth borrowing

• IAB Tech Lab. Its ads.txt, app-ads.txt and sellers.json specifications, which now live on GitHub, validate who may sell ad inventory; that is supply chain validation for inventory, not software. Its Open Measurement SDK is a shared component many vendors integrate; track its version like any third-party SDK.
• OWASP Third Party JavaScript Management Cheat Sheet. It names the risks (loss of control over client code changes, arbitrary code on client systems, disclosure of data to third parties) and defenses such as a server-direct data layer, sandboxing, Subresource Integrity and vendor agreements.
• W3C Subresource Integrity. SRI pins a script to a hash so a changed file fails to load; the SRI 2 document is a Working Draft dated 20 March 2026. It does not fit scripts that change by design; see can SRI protect a tag manager or analytics script.

EU context: GDPR and the ePrivacy Directive

The European Commission's GDPR guidance says a processor's duties must be set out in a binding contract, the processor must implement appropriate security measures, and it may sub-contract only with the controller's prior written authorisation. It adds that a sub-contractor using received data for its own marketing acts as a controller, and that direct marketing email must also follow the ePrivacy Directive. Every SDK or tag that receives personal data is a candidate processor, and the contract chain has to match the code chain.

Real public incidents from the last three years

These incidents come from official or primary reporting. We describe what the sources say and draw no conclusions about what any company should have done.

Tracking tools and an FTC order (April 2024)

On 15 April 2024 the FTC announced its proposed order against Cerebral, described above: tracking tools on a website and apps that provided sensitive information about nearly 3.2 million consumers to third parties for advertising. The code worked as designed; the problem was where it sent data.

Location data suppliers and two FTC orders (December 2024 and January 2025)

The FTC proposed orders against Gravy Analytics and Venntel, and against Mobilewalla, on 3 December 2024 and finalized both on 14 January 2025. The FTC said Gravy and Venntel kept using location data from suppliers after learning consumers had not given informed consent, and the Mobilewalla order reaches into the bid stream itself.

A compromised GitHub Action (March 2025)

CISA reported that the popular third-party GitHub Action tj-actions/changed-files, tracked as CVE-2025-30066, was compromised, allowing disclosure of secrets including access keys, GitHub personal access tokens, npm tokens and private RSA keys. CISA linked it to a compromise of reviewdog/action-setup (CVE-2025-30154) and advised organizations to identify secrets exposed by workflows that ran the malicious commit and rotate them immediately. An SDK team whose release workflow runs third-party actions holds exactly the tokens that publish code to every customer.

An npm account takeover reaching browser SDKs (September 2025)

On 15 September 2025 the GitHub Advisory Database published advisories stating that specific versions of widely used npm packages, including debug 4.4.2 and several color-handling packages, contained malware after an npm account takeover. A separate advisory the same day said a cryptocurrency wallet's browser SDK was indirectly exposed through the malicious debug dependency. That second advisory is the pattern adtech teams should study: a small utility deep in the tree, an SDK that ships to other people's pages, and exposure the SDK maker did not choose.

A self-replicating worm in the npm registry (September 2025)

On 23 September 2025 CISA reported a widespread supply chain compromise of npm in which a self-replicating worm, publicly known as Shai-Hulud, had compromised over 500 packages. CISA said the malware scanned for credentials, targeted GitHub personal access tokens and cloud API keys, exfiltrated them, and used compromised developers' npm access to inject code into other packages and publish new versions. CISA urged a dependency review, pinning npm dependencies to known safe releases, rotating all developer credentials and phishing-resistant multifactor authentication on developer accounts.

What the six have in common

None began in the victim's own application code. Some moved data through tags and suppliers that worked as designed; the rest moved through registries and pipelines adtech JavaScript depends on. In every case the first question was which products, versions and partners carry this component. The plan below is built to answer that within a day. The 2024 polyfill.io domain takeover, which turned a widely embedded script into a redirect, is the clearest example of the tag version of the same problem; our polyfill.io timeline covers it.

The personas who own the problem

Responsibility in adtech and martech is split between engineering, privacy and marketing in a way most industries do not see. Each role below needs something specific, and each has a moment when the need becomes urgent.

The CISO

Needs: a risk view that covers your services, the SDKs and tags you ship, and the third-party code on your own sites; an incident response that can name affected products and partners within hours; evidence for customer security reviews and audits.

When: a large advertiser or publisher's security questionnaire, a privacy regulator's inquiry, the planning cycle for California's cybersecurity audit, and every major registry compromise.

The CTO or VP of Engineering

Needs: a process that does not slow bidders or SDK releases, one place for findings instead of several, and a rollout that starts in report-only mode.

When: an SDK release that partners are waiting for, a latency budget review, and any incident that would force an unplanned release to every partner.

The head of product security or AppSec

Needs: a ranked backlog across services, SDKs and the marketing stack, and a way to tell which findings are reachable in the code that faces bid traffic or end users.

When: a KEV listing for a library in the bidder, an advisory for a package bundled into your web tag, and every customer pen test or audit request.

The privacy and GRC lead

Needs: a map from code to data flows, so the privacy notice, the data processing agreements and the actual tags and SDKs say the same thing; evidence for risk assessments and audits.

When: the CCPA risk assessment cycle, DROP deletion processing, a data broker registration renewal, a DPA renegotiation, and any FTC civil investigative demand.

Marketing operations and web owners

Needs: a way to add tags quickly without becoming the weak link; a clear rule on which pages may carry which tags.

When: a campaign launch, a new vendor trial, a checkout redesign, or a request from security to remove a tag.

Procurement and vendor risk

Needs: a vendor register that includes every martech and data vendor, with risk tiers, contracts and software evidence.

When: contract signature and renewal, a vendor incident, and any time a team wants to trial a new SDK or tag.

Platform engineering and SRE

Needs: scanning that fits inside existing CI and does not add latency to the hot path; rollback paths for bidder and SDK releases.

When: a fleet-wide dependency upgrade, an emergency patch, and on-call weeks.

Step by step: a 30, 60 and 90 day plan that works with any tools

This plan assumes several services, at least one SDK or tag you ship, a marketing site with a tag manager, and a data platform. It works with free tools, what you already own, or a platform like Safeguard.

Days 1 to 30: see what you ship

1. List products and owners. Every service, SDK, tag, data pipeline and website, with an engineering owner and a business owner, including every landing page domain.
2. Generate SBOMs for code you build. One SPDX or CycloneDX SBOM per service and per SDK release, from lockfiles. Keep old SDK release SBOMs, because partners run old versions for a long time.
3. Record what you cannot build. Binary SDKs, vendor scripts loaded from vendor domains and tag manager containers will not appear in your lockfiles. List them by hand with vendor, version, where they run and the data they receive.
4. Inventory live tags. Export the tag manager configuration and crawl your top pages to list every script, noting which load on login, account and checkout pages.
5. Check your pipelines. List every third-party action or plugin in CI, whether it is pinned to a commit hash, and which secrets each workflow can read. Give the SDK publishing workflow its own narrow credentials.
6. Pick a patch clock. For example, actively exploited criticals in internet-facing services and shipped SDKs fixed within days, other criticals within weeks, with a named exception approver.

Days 31 to 60: control what changes

1. Turn on SCA in CI in report-only mode for two to four weeks so teams can see the noise level.
2. Rank by exploitation and reachability. Use EPSS and CISA KEV, and start with reachable issues in services that parse bid requests and in SDK code that ships to partners.
3. Add a tag and SDK intake rule. No new script or SDK without a record naming the vendor, data received, where it runs, the contract or DPA and an owner. Payment and login pages carry only approved scripts.
4. Tier vendors. Put vendors that receive personal, location or health data, payment page scripts and build pipeline vendors in the top tier, and ask them for an SBOM and incident notice terms.
5. Set up an exception register with reason, compensating control, approver and expiry.

Days 61 to 90: prove it works

1. Move gates from Warn to Block for new criticals, keeping existing debt as dated exceptions.
2. Run two tabletops. First, a real registry compromise from the last year: time how long it takes to name every service, SDK version and partner affected and ship a fixed SDK. Second, a vendor script on checkout that changed without notice: time how long it takes to find, remove or pin it.
3. Reconcile code and paper. Compare the tag and SDK inventory with the privacy notice, subprocessor list and DPAs, and fix whichever is wrong.
4. Report on one page: inventory coverage, findings by severity and age, exceptions by expiry, vendor tiers with SBOM status and the tabletop times.

A checklist you can use today

• Every service and SDK release has an owner and its own SBOM, kept as long as partners may run it.
• Every third-party script and SDK has a record: vendor, version, where it runs, data received, contract, owner.
• Payment and login pages carry only approved scripts.
• CI actions are pinned to commit hashes, and the SDK publishing workflow has its own narrow credentials.
• Findings are ranked by EPSS, KEV and reachability; exceptions have an approver and an expiry.
• The privacy notice, subprocessor list and live tags agree.

A tag and SDK intake template

A decision table for an advisory in a shipped SDK or tag

Illustrative scenario: an npm compromise during a campaign launch

This is an illustrative scenario with invented round numbers. A martech company ships a JavaScript tag used on about 2,000 customer sites and has a large product launch the same week. An advisory says a widely used utility package published a malicious version two days earlier. Because it keeps an SBOM for every tag release, the SDK team finds within an hour that one recent release pulled the malicious version. They roll the CDN back, rebuild with the dependency pinned, rotate the publishing token and notify customers. Without per-release SBOMs they would be diffing bundles by hand during the launch.

How Safeguard does this

Everything above works without Safeguard. This section shows the same plan in Safeguard, using only flows from docs.safeguard.sh and capabilities in Safeguard's offering. Every capability named here is generally available (GA). Commands are copied as the docs show them; we did not run them for this post.

1. Inventory the code you build

Safeguard's Enterprise Software Supply Chain Manager (ESSCM, GA) generates SPDX and CycloneDX SBOMs (SBOM generation and analysis, GA) and runs software composition analysis (SCA, GA) across each project's full transitive dependency tree. Safeguard's offering lists npm, PyPI, Maven and Gradle, Go, Cargo, NuGet, Composer and Bundler among the ecosystems SCA covers, which takes in bidder services, data pipelines and the JavaScript in your tags. Per the docs, you connect repositories under Integrations, or use a file upload such as Upload Manifest File for a package.json or requirements.txt, and Safeguard creates the project and its SBOM. The docs also list an Upload APK integration for Android files.

Continuous scanning (GA) re-evaluates existing assets, including vendor SBOMs, when vulnerability feeds change, so a new KEV entry is matched against SDK releases you already shipped.

If your source code may not leave your network, the local runner (GA) in the Safeguard CLI (GA) scans on your own machine and uploads only the SBOM and findings, never your source code, per the docs. The docs show:

# macOS and Linux
curl -fsSL https://cli.safeguard.sh/install | bash

# start the interactive terminal, then type /login
safeguard

On a headless build machine, the docs show:

safeguard runner start --workspace ./path/to/repo
safeguard runner status

2. Prioritize by exploitation and reachability

Vulnerability management (GA) adds EPSS scores and CISA KEV status, and reachability analysis and prioritization (GA) adds whether your code calls the vulnerable function, so a reachable flaw in the bid request parser comes before an unreachable one in a build tool.

SAST (GA) covers your own service and SDK code. DAST (GA) tests running web applications for runtime issues; the docs name missing security headers, injection classes and misconfigurations. Per the docs, DAST runs only against targets you have verified you own (by DNS TXT record, uploaded file, meta tag or verified email domain), checks every request against an allow-listed scope, and leaves well-known third-party services unticked by default, to be tested only if you are authorized. License compliance (GA) flags obligations in open source you ship inside SDKs and tags, which matters when partners ask for attribution notices or a license list.

3. Turn the patch clock into policies and gates

Policies, gates and guardrails (GA) put the clock in the pipeline. Per the docs, you go to Settings › Policies, click Create Policy, define conditions such as severity, CVSS, EPSS, license, component age and maintenance in the visual builder or YAML, and choose an action.

The docs show this GitHub Actions workflow:

name: Safeguard
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - name: Safeguard scan
        env:
          SAFEGUARD_API_KEY: ${{ secrets.SAFEGUARD_API_KEY }}
          SAFEGUARD_INSTALL_DIR: ${{ runner.temp }}/safeguard-bin
        run: |
          set -eu
          curl -fsSL https://cli.safeguard.sh/install | bash
          "$SAFEGUARD_INSTALL_DIR/safeguard" ci scan --wait --fail-on critical

For the report-only weeks in days 31 to 60, the docs say to drop --fail-on critical. To fail on a policy gate instead of a severity, the docs say to add --fail-on-gate all. The API key is created under Settings › Developer with the scans:trigger and scans:read scopes. Keep the scan job separate from the job that publishes your SDK, in line with the pipeline step in the plan.

4. Run exceptions through a recorded approval

Approval runs through exceptions, not through a gate action. Per the docs, a developer clicks Request Exception, selects the policy and finding, gives a business justification and an expiration date, and submits; approvers are notified, an approver decides, and the audit trail records it.

For findings you will not fix yet, such as a vulnerable component inside a partner's binary SDK with no fixed release, the Mitigations tab on a project records the mitigation type (Risk Acceptance, False Positive, Workaround Applied or Not Applicable), the justification and the approver, with expiry dates for accepted risks. That record becomes the exception register the CISO and the privacy lead need.

5. Fix faster where a fix exists

Autonomous remediation (GA) opens fix pull requests that move a vulnerable dependency to a fixed version, for one repository or in bulk. It ships switched off, with every category set to Manual, so nothing changes in your repositories until your team turns it on. A merged pull request still has to go through your tests, your SDK release process and your partners' upgrade cycles.

6. Bring martech and SDK vendors inside the clock with TPRM

Third-Party Risk Manager (TPRM, GA) is where procurement and vendor risk can hold the tag and SDK vendor list. Per the docs:

1. Vendors › Add Vendor records the company, contact, products used and risk tier (Critical, High, Medium, Low), with CSV bulk import. Contract records hold dates, SLA terms, security requirements and SBOM obligations.
2. Request SBOM, or Bulk Request for many vendors, sends a request with SPDX or CycloneDX format requirements and a deadline, with automated reminders and escalation.
3. An arriving SBOM is validated for format and completeness and scanned for vulnerabilities; Request Revision sends back one that falls short.
4. Monitoring alerts on new critical vulnerabilities and CISA KEV additions that affect a vendor's SBOM, and re-assessment can be triggered by new disclosures, major version updates, contract renewals and security incidents.

Put SDKs that receive personal, location or health data, payment page scripts, data suppliers and build pipeline vendors in the Critical tier. A vendor SBOM is how a binary SDK's contents get into your inventory at all.

7. Keep the evidence in one place

The Compliance and GRC suite (GA) holds frameworks, controls, evidence and tests. Per the docs, you open a framework under Compliance › Frameworks, and its Connectors tab shows which connected systems feed its tests; a passing test is evidence toward a control, not proof that it is met. For CCPA risk assessments, cybersecurity audit preparation, DROP processing or FTC order obligations, check whether the framework you need is listed, and otherwise map the SBOMs, vendor records and exception logs above to your own control list.

Portal audit trails (GA) log SBOM activity, access and administrative changes. Per the docs, you view them under Settings › Audit Logs and export as CSV, JSON or PDF for the evidence binder.

8. If you sell to advertisers and publishers, answer them once

Trust Center (GA) publishes a public page with your compliance status, controls, policies, subprocessors and documents for the advertisers, agencies and publishers who keep asking. Per the docs, you manage it under Compliance › Trust Center, and publishing is always an explicit action. Keep its subprocessor list in step with your SDK and tag inventory.

What Safeguard does not do

• It does not monitor scripts in the browser. This guide covers code you build and vendor software you can get a manifest or SBOM for. Safeguard's offering does not describe watching live pages or tag manager containers for script changes, so a tag that changes on a vendor's server will not show up through the flows above. PCI DSS 11.6.1 style change detection on payment pages needs its own control.
• It does not see what is not declared. Binary SDKs and vendor-hosted scripts that do not appear in a manifest or lockfile will not show up unless you record them or the vendor supplies an SBOM through TPRM.
• It does not decide what data may flow. Safeguard does not run your consent management platform, decide a legal basis, or tell you whether a tag is allowed under a privacy law. Those are decisions for your privacy team and counsel.
• It does not ship your SDK or update partners. A merged fix still needs your release, your CDN or registry publication, and your partners' upgrades. Safeguard does not force an update on a publisher site or an installed app.
• It does not verify ad inventory. ads.txt, app-ads.txt and sellers.json checks are ad supply chain controls outside this product.
• It does not replace counsel or auditors. A passing compliance test is evidence toward a control; your auditor and counsel decide whether you meet a rule.

Common mistakes

• Treating the tag manager as a marketing tool, not a deployment path. Every change there is a production code change on pages that may handle logins or payments.
• Keeping only the latest SBOM for an SDK. Partners run old versions for months. When an advisory lands, you need the SBOM for the version they run, not the one on main.
• Letting the SDK publishing workflow share credentials with everything else. A leaked CI token that can publish your SDK reaches every customer at once.
• Scoring everything by CVSS. A critical in a build tool and a critical in the bid request parser are not the same risk. Use EPSS, KEV and reachability.
• Trusting the privacy notice as the inventory. The notice says what should happen. The tag manager, the SDK list and the network traffic say what does. Reconcile them on a schedule.
• Asking vendors for a questionnaire but not a component list. A questionnaire tells you about the vendor's process; an SBOM tells you what is in the code you ship.

FAQ

What is software supply chain security for adtech?

It is knowing, controlling and patching every component in the code an adtech company builds and ships, from bidders and data pipelines to the tags and SDKs on partners' pages and apps, and managing the vendors whose code you integrate.

Are companies responsible for what third-party tracking pixels send?

The FTC has acted against companies over data sent to third parties through tracking tools on their websites and apps, as in its April 2024 Cerebral announcement. Whether and how that applies to you is a question for counsel, but in practice you should know what every tag and SDK collects and where it sends it.

Does the FTC regulate real-time bidding data?

The FTC's January 2025 final order against Mobilewalla bars it from collecting consumer data from real-time bidding exchanges for purposes other than participating in the auctions. The order binds that company, but its reasoning matters to anyone handling bid stream data.

When are California cybersecurity audits due?

The California privacy agency's September 2025 announcement says businesses required to complete cybersecurity audits must submit certifications by 1 April 2028 if revenue is over 100 million dollars, 1 April 2029 if between 50 and 100 million dollars, and 1 April 2030 if under 50 million dollars. Which businesses must complete one depends on the regulations' thresholds.

Do PCI DSS script requirements apply to marketing tags?

PCI DSS v4.x Requirements 6.4.3 and 11.6.1 concern scripts on payment pages: that they are authorized, checked for integrity and monitored for tampering. If a marketing or analytics tag loads on a payment page, it is a payment page script. Your acquirer or payment brand decides how compliance is assessed.

How should an SDK vendor respond to an npm package compromise?

Find every SDK release whose build pulled the affected version, pull those releases, ship a clean build with the dependency pinned, rotate credentials the build could read, and notify partners per your contracts.

Does Safeguard monitor third-party scripts on live web pages?

No. Safeguard's documented flows cover code you build, vendor SBOMs through TPRM and dynamic testing of web targets you verify you own. Use a separate control for payment page script change detection.

Can Safeguard scan our bidder code without sending it to the cloud?

Yes. The local runner in the Safeguard CLI runs scans on your own machine and, per the docs, uploads only the SBOM and findings, never your source code. All traffic is outbound HTTPS that the runner opens.

The next section covers what to do once a vulnerable component is in your bidders, pipelines or SDK builds, whether or not a fix exists upstream. For adtech and martech teams, that is the gap between an advisory and a clean SDK release that partners can actually pick up.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real CLI session: ask "fix the lodash CVE in this repo", and the CLI reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. An SDK team would run the same flow on the npm dependencies of its web tag after an advisory.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with its device code, and scans from the terminal. It is the route for a company whose policy does not allow a cloud service to clone bidder or data pipeline code.

Click through it at your own pace, or open it full screen.

The third demo is a real Android session with the Safeguard mobile app: send work to a computer running the CLI and approve the command on the phone with Allow once, Allow for turn or Deny. It suits an engineer handling a fix during a launch week, away from a desk.

Click through it at your own pace, or open it full screen.

Related reading: your tag manager is a second deployment pipeline, can SRI protect a tag manager or analytics script, the polyfill.io takeover timeline, software supply chain security for e-commerce platforms and mobile advertising IDs explained.

Quick check

Sources

• FTC: Proposed order will prohibit telehealth firm Cerebral from using or disclosing sensitive data for advertising (15 April 2024)
• FTC: Action against Gravy Analytics and Venntel (3 December 2024)
• FTC: Final order banning Mobilewalla from selling sensitive location data (14 January 2025)
• California Privacy Protection Agency: California finalizes regulations (23 September 2025)
• California Privacy Protection Agency: Laws and regulations
• California Privacy Protection Agency: Data brokers and DROP
• US Department of Justice: Data Security Program
• PCI Security Standards Council: Payment page security and preventing e-skimming (10 March 2025)
• European Commission: Application of the GDPR
• IAB Tech Lab: ads.txt and app-ads.txt
• IAB Tech Lab: Open Measurement SDK
• OWASP: Third Party JavaScript Management Cheat Sheet
• W3C: Subresource Integrity
• CISA: Supply chain compromise of third-party tj-actions/changed-files and reviewdog/action-setup (18 March 2025)
• GitHub Advisory Database: debug 4.4.2 advisories (15 September 2025)
• CISA: Widespread supply chain compromise impacting npm ecosystem (23 September 2025)
• Safeguard docs: Generate SBOM
• Safeguard docs: Continuous Scanning
• Safeguard docs: Application Security Testing (SAST and DAST)
• Safeguard docs: Policies and Gates
• Safeguard docs: Mitigations
• Safeguard docs: GitHub Actions
• Safeguard docs: Local Runner
• Safeguard docs: TPRM Vendor Management
• Safeguard docs: TPRM SBOM Requests
• Safeguard docs: TPRM Monitoring
• Safeguard docs: Portal Audit Trails
• Safeguard docs: Trust Center setup

To try the flows in this guide, download Safeguard at https://safeguard.sh/download and read the documentation at https://docs.safeguard.sh/docs .

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.