Software Supply Chain Security for Payments and E-commerce: 90-Day Plan

Software supply chain security for a merchant, a payment service provider or a processor comes down to three jobs. Know every component inside the software you build and ship (your checkout, your payment APIs, the SDKs and plugins you hand to merchants), know every script and vendor that touches the payment flow, including the scripts that run in your customer's browser, and put both on a patch clock that someone owns and can prove to a Qualified Security Assessor (QSA), an acquirer or a regulator. A focused team can stand up the inventory, the gates and the evidence trail in about 90 days, and most of the work does not depend on which tools you buy.

This guide covers the software the industry runs, the rules (PCI DSS v4.0.1 first, then US regulators), recent public incidents, the people who own each part, 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; your counsel, your QSA and your acquirer decide what applies to you.

Key takeaways

• PCI DSS v4.0.1 is the only active version, and its future-dated requirements took effect on 31 March 2025. The supply chain ones are 6.3.2 (software inventory), 6.4.3 (payment page scripts), 11.6.1 (payment page change and tamper detection) and 12.8 (third-party service providers).
• Using a PCI DSS compliant provider does not make you compliant, so the vendor list is part of your own evidence.
• Commerce platforms are a live target: CISA's Known Exploited Vulnerabilities (KEV) catalog added Adobe Commerce flaws in 2024, 2025 and twice in September 2026, and an old SAP Commerce Cloud flaw in 2024.
• The developer toolchain is part of the payment supply chain, as CISA's September 2025 npm worm alert showed.
• Five people own the problem, each needing different evidence at a different moment. The plan: inventory in month one, gates and vendor evidence in month two, rehearsal and assessor-ready evidence in month three.
• Safeguard capabilities used in this guide, all generally available (GA): ESSCM, SBOM generation and analysis, software composition analysis, vulnerability management with EPSS and KEV, reachability analysis, SAST, DAST, license compliance, policies and gates, mitigations and exceptions, autonomous remediation (ships switched off), TPRM, the Compliance and GRC suite, Trust Center, Portal, the CLI and its local runner, the MCP server, on-prem and air-gapped deployment, and Zero AI mode.

What software payments and e-commerce runs

The industry splits into two groups that share one supply chain. Merchants sell things and take payments. Payment companies (gateways, processors, payment facilitators, acquirers' technology arms, wallets and money transmitters) move the money and sell software to the merchants. Each runs software of its own and buys a great deal more.

Merchants

• The storefront platform: a hosted commerce service, a self-hosted open source platform, or a headless front end calling commerce APIs. Self-hosting puts the platform's patch cycle on your desk.
• Extensions, plugins and themes: payment modules, tax and shipping engines, loyalty and reviews widgets, often from small marketplace vendors.
• The checkout and payment page: a page you serve, an embedded form or iframe from your provider, or a redirect to a hosted payment page. The choice drives much of your PCI scope.
• Payment page scripts: analytics, tag managers, consent banners, A/B testing, chat, fraud fingerprinting and the provider's own JavaScript. They load in the customer's browser at the moment of purchase and change outside your release process.
• Mobile apps that embed payment and wallet SDKs plus many open source libraries.
• Back office and store systems: order management, ERP, fulfillment, customer service, the file transfer tools that move settlement files, and point of sale software for physical stores.

Payment companies

• Gateway and API platforms, built mostly from open source frameworks, queues and libraries.
• Processing and switching software that connects to card networks, banks and real time payment rails.
• Tokenization and vault services, often with hardware security module integration code.
• Fraud and risk engines, increasingly with machine learning models and their serving libraries.
• Merchant onboarding and know your customer systems, a mix of built and bought.
• Software you ship to others: web and mobile SDKs, commerce plugins, terminal software and partner APIs. When thousands of merchants install your code, your dependency tree becomes theirs.

Why the supply chain is so wide here

Three things make payments and e-commerce different from most industries.

First, the browser is part of the payment flow. A payment page assembles itself at run time from your code, your provider's code and third-party scripts, and PCI DSS makes you authorize, justify and monitor those scripts, which pulls marketing technology into a security standard.

Second, a few platforms carry much of the market, so one flaw in a commerce platform, payment plugin or SDK lands on thousands of merchants at once.

Third, the money is direct. Card data and account access convert to cash quickly, and the KEV dates below show how fast commerce flaws get exploited.

The regulations and frameworks that apply

PCI DSS sets the floor for anyone who stores, processes or transmits card data or can affect its security. Behind it sit US regulators whose rules apply depending on what kind of company you are. Check status yourself before relying on any date below; this section summarizes primary sources as of October 2026.

PCI DSS v4.0.1

Status. PCI SSC published PCI DSS v4.0.1 in June 2024 as a limited revision with no new or deleted requirements. Per the Council, v4.0 was retired on 31 December 2024, leaving v4.0.1 as the only active version, and v3.2.1 was retired on 31 March 2024. An interview on the Council's blog counted 64 new requirements in v4.x, 51 of them future-dated to 31 March 2025. That date has passed, so every one of them is now required.

Who enforces it. PCI SSC is explicit that it does not set compliance validation requirements for anyone. The card brands, acquirers and payment facilitators do, and the Council calls them compliance enforcing entities. Your acquirer, not the Council, tells you whether you file a Self-Assessment Questionnaire (SAQ) or a Report on Compliance (ROC).

A note on sources. The full standard sits behind a license agreement on the PCI SSC document library. The descriptions below come from documents PCI SSC publishes openly: the Summary of Changes from v3.2.1 to v4.0 and the Council's blog. Read the requirement text and testing procedures in the standard itself before you design a control.

The requirements that carry the most supply chain weight:

The SAQ A change. In January 2025 PCI SSC removed 6.4.3, 11.6.1 and the supporting 12.3.1 analysis from SAQ A, the shortest questionnaire, used by merchants that fully outsource account data functions. In their place it added an eligibility criterion: the merchant must confirm its site is "not susceptible to attacks from scripts" that could affect its e-commerce systems. The Council stressed that this does not remove or diminish the underlying requirements in the standard. In practice a merchant on a hosted payment page still has to know what scripts run on the page that sends customers there, and why.

The FTC Safeguards Rule

Non-bank payment companies can fall under the Federal Trade Commission's Standards for Safeguarding Customer Information, 16 CFR Part 314. The rule's examples of financial institutions include businesses that sell money orders or make wire transfers for customers. It requires a written information security program run by a Qualified Individual, and three of its paragraphs matter here. Section 314.4(c)(4) requires secure development practices for in-house applications that handle customer information, plus procedures for evaluating, assessing or testing externally developed applications. Section 314.4(f) requires you to oversee service providers, starting with reasonable steps to select and retain capable ones. Section 314.4(j) requires notice to the FTC about notification events. Whether the rule covers your company is a question for counsel.

NYDFS Part 500 for licensed entities

Under 23 NYCRR 500.1, a covered entity is anyone operating under a license or similar authorization under New York's Banking Law, Insurance Law or Financial Services Law, which can include payment companies licensed in New York. Three sections matter here. Section 500.8 requires secure development practices for in-house applications and procedures for evaluating, assessing or testing externally developed ones. Section 500.11 requires a third-party service provider security policy. Section 500.13 requires a complete, accurate and documented asset inventory. Other states license payment companies too; check each license.

SEC cybersecurity disclosure for public companies

The SEC's rules on cybersecurity risk management, strategy, governance and incident disclosure, published in the Federal Register on 4 August 2023 and effective 5 September 2023, require public companies to disclose material cybersecurity incidents and to describe their processes for managing cybersecurity risk, management's role and board oversight. A vendor compromise that reaches a public merchant's or processor's payment flow can raise a materiality question.

Federal guidance you can borrow

Neither of these is binding on a private merchant, but both give you language and structure for vendor requirements and internal standards.

• NIST SP 800-218, the Secure Software Development Framework (SSDF) version 1.1, recommends practices for reducing vulnerabilities in the software you produce. It is a good checklist for your own engineering and a reasonable thing to ask payment software vendors to attest to.
• CISA's 2026 Minimum Elements for a Software Bill of Materials, published 29 July 2026, replaces the 2021 NTIA minimum elements as the US government reference for what an SBOM should contain. Use it as the field list when you ask vendors for SBOMs.

EU rules are outside this US-first guide; our post on DORA for fintech engineering teams covers that side.

Real public incidents from the last three years

These come from government and vendor primary sources. We describe what the sources say and draw no conclusions about what any affected organization should have done.

Adobe Commerce and Magento XXE, CVE-2024-34102 (June to August 2024)

The National Vulnerability Database (NVD) published CVE-2024-34102 on 13 June 2024, referencing Adobe security bulletin APSB24-40 for Adobe Commerce and Magento Open Source. CISA added it to the KEV catalog on 17 July 2024, describing an improper restriction of XML external entity reference that allows remote code execution, with a federal due date of 7 August 2024. For merchants running the platform themselves, that meant a vendor patch, their own release process and often an extension compatibility check, against an active threat.

SAP Commerce Cloud deserialization, CVE-2019-0344 (September 2024)

On 30 September 2024 CISA added CVE-2019-0344 to KEV. The flaw is a deserialization of untrusted data in SAP Commerce Cloud (formerly Hybris) that allows code injection, and it dates from 2019. A five-year-old vulnerability showing up as actively exploited is the clearest argument for requirement 6.3.2: if you do not know which old platform versions still run somewhere, a KEV entry tells you nothing actionable.

Adobe Commerce REST API account takeover, CVE-2025-54236 (September to November 2025)

NVD published CVE-2025-54236 on 9 September 2025, referencing Adobe bulletin APSB25-88. CISA added it to KEV on 24 October 2025, saying improper input validation "could allow an attacker to take over customer accounts" through the Commerce REST API, with a federal due date of 14 November 2025. Customer account takeover in a storefront sits squarely inside a payment security program.

Two more Adobe Commerce KEV entries (September 2026)

CISA added CVE-2026-75650, a template engine neutralization flaw that could allow code execution, on 8 September 2026, and CVE-2026-71362, an incorrect authorization flaw that could allow elevated access without user interaction, on 24 September 2026. Both entries reference Directive BOD 26-04, the risk-based directive that replaced BOD 22-01 for federal agencies, and both carried due dates three days after they were added. Private merchants are not bound by federal due dates, but three days is a useful reality check for any internal patch clock you write.

The npm worm known as Shai-Hulud (September 2025)

On 23 September 2025 CISA published an alert on a widespread supply chain compromise of npmjs.com. CISA said a self-replicating worm had compromised over 500 packages, scanned environments for credentials, targeted source code host tokens and cloud API keys, and spread by publishing compromised versions of other packages under the stolen developer identities. CISA's recommendations included a dependency review of everything built on npm, checking lockfiles for affected packages including nested ones, searching artifact caches, pinning to versions released before 16 September 2025, rotating developer credentials and requiring phishing-resistant multifactor authentication. Nearly every web checkout and many payment SDKs are built with npm, so this is a payments problem even though it did not target payments. Our explainer on the Shai-Hulud npm attack goes deeper.

What these have in common

• The first question was an inventory question: which stores run which platform version, which builds pulled which package, which caches still hold it. CISA's npm guidance starts with exactly that dependency review.
• The fix travelled through someone else's release first. The vendor or maintainer shipped it; each merchant still had to adopt, test and deploy it.
• Credentials were part of the blast radius. The npm worm went after developer and cloud credentials, and the 2025 Adobe flaw after customer accounts.
• Due dates were short. Federal KEV due dates here ranged from three weeks to three days.

Our earlier posts on the polyfill.io CDN compromise and payment processor dependency risks cover two more angles on the same pattern.

The personas who own the problem

No single person owns payment supply chain security. Here is who does what, what they need, and when they need it.

The CISO

The CISO answers to the board and, after an incident, to the acquirer and the card brands. They need a defensible answer to three questions: what software touches card data, how fast we fix what matters, and which vendors could hurt us. They need it before the ROC or SAQ sign-off, before each board meeting and within hours of a KEV entry for a platform the company runs. A one-page view of exposure, patch performance and open vendor risk helps; a feature list does not.

The head of application or product security

This person turns policy into engineering work: what blocks a release, what waits, and how to keep developers out of alert overload. They need a backlog ranked by exploitation and reachability, gates that fail only for things worth stopping, and a burn-down they can defend. Their triggers are quarterly scans, the annual penetration test, KEV entries and every new payment page script request.

The engineering lead for checkout and payments

The VP or director who owns checkout, payment APIs or merchant SDKs cares about release speed and conversion. A gate that blocks checkout for an unreachable finding costs revenue. They need one process for dependencies, platform upgrades and extensions, fix pull requests instead of tickets, and exceptions with expiry dates. Their triggers are platform end of life dates, major upgrades and incident weekends.

The PCI or GRC lead

The PCI lead lives inside the assessment calendar: scoping, evidence, QSA fieldwork, the ROC or SAQ and the Attestation of Compliance (AOC). They need evidence mapped to 6.3.1, 6.3.2, 6.4.3, 11.6.1, 12.3.1 and 12.8, and an exception register a QSA can sample. Their triggers are the assessment date, scope changes such as a new payment method, and acquirer requests after a suspected compromise. At an FTC-covered or NYDFS-licensed company they also own those program documents.

The procurement or vendor risk owner

The vendor risk owner needs a complete vendor list with risk tiers, each TPSP's compliance status and AOC date, the responsibility split under 12.8.5, SBOMs for critical software, and a signal when something in a vendor's software becomes exploited. Their triggers are new purchases, renewals, expiring AOCs and vendor breach notices.

Also at the table: the web team and developers

Requirement 6.4.3 puts whoever manages tags and scripts (often marketing technology or a web platform team) on the hook for evidence. They need a simple rule for adding scripts. Developers need exact instructions on the pull request: what failed, why, and the version that fixes it.

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

This plan assumes an existing PCI program and a team that can give the work real attention. Scale it down for a small merchant and up for a processor. Every step works with open source tools, spreadsheets and your current scanners; nothing here requires a particular product.

Days 1 to 30: see what you run

1. Draw the payment flow. For each channel (web, mobile, in store, partner API), sketch where card data enters and which systems touch it. Mark every point where third-party code runs.
2. List the software you build: every repository and container image that runs in or connects to the cardholder data environment, with an owner. This is the core of 6.3.2.
3. Generate an SBOM for each one in SPDX or CycloneDX, from the build or lockfile rather than by hand, and check the fields against CISA's 2026 minimum elements.
4. Record platform and extension versions. For self-hosted platforms, list the core version and every extension with its version and source; these often sit outside the main manifests.
5. Inventory payment page scripts. For every page that hosts a payment form, iframe or redirect, list each script the browser loads, its source, its owner and why it is needed, using the template below. Check the page as the browser receives it, because tag managers add scripts that never appear in your source.
6. Build the vendor list: every TPSP and software vendor in the payment flow, with a risk tier, latest AOC date and relationship owner.
7. Match against KEV. Anything in your SBOMs or platform versions that appears in the CISA KEV catalog is your first sprint.

Template: payment page script inventory (one row per script per page)

Keep the first version simple. A script nobody can justify is the cheapest risk you will ever remove.

Days 31 to 60: control what changes

1. Write the patch clock. Decide how fast each class of finding must be fixed and get it signed. A starting point:

2. Put the clock into CI. Scan dependencies and containers on every pull request and build of in-scope applications. Run report-only for two weeks, then block the top row.
3. Create an exception path: justification, owner, compensating control and expiry date, approved by someone other than the requester. Your QSA will sample these records.
4. Control new scripts through the same intake as code: owner, justification, integrity method. Remove scripts that failed justification in month one.
5. Collect vendor evidence: the current AOC, a responsibility matrix that matches 12.8.5, and an SBOM for software you run, using the questions below.
6. Lock down developer access. Following CISA's npm guidance, require phishing-resistant multifactor authentication on code hosting and registry accounts and rotate long-lived build tokens.

Questions for payment providers, platform vendors and extension developers

• Which PCI DSS requirements do you meet on our behalf, which do we meet, and which are shared? Please put it in writing.
• When does your current AOC expire, and will you send the new one without being asked?
• Can you provide an SBOM in SPDX or CycloneDX for the software we run, and how often will you update it?
• How will you notify us when a component in your product is added to the CISA KEV catalog, and within what time?
• For hosted payment pages and embedded fields, which scripts do you load in the customer's browser, and how do you control changes to them?
• How do you protect your own build and release pipeline and your package publishing accounts?

Days 61 to 90: prove it works

1. Rehearse a KEV day. Pick a component in your SBOMs and run the drill below, timing each step.
2. Measure: open findings by patch clock row, median time to fix, exceptions expiring in 30 days, unjustified scripts, and vendors without a current AOC or SBOM.
3. Map evidence to requirements. For 6.3.1, 6.3.2, 6.4.3, 11.6.1, 12.3.1 and 12.8, note where the evidence lives and who produces it. Show your QSA early and ask what is missing.
4. Report a one-page view to the CISO with next quarter's targets.
5. Schedule the cycle: quarterly script reviews, SBOMs on every release, vendor evidence at renewal and AOC expiry, and a scope check for every new payment method or vendor.

Illustrative scenario: a commerce platform KEV entry on a Friday

This is an illustrative scenario with round invented numbers, not a real organization. A merchant runs 3 self-hosted storefronts on one commerce platform and 12 internal services around checkout. On a Friday afternoon CISA adds a code execution flaw in that platform to KEV.

With the month one inventory in place, the AppSec lead finds 2 of the 3 storefronts on an affected version within 15 minutes. The vendor's bulletin names a fixed release. On staging, 1 of 20 extensions fails the compatibility check, so that storefront gets a recorded exception with a 7 day expiry and a compensating control from the vendor's guidance, while the other is patched on Saturday. The PCI lead files both records, the vendor risk owner asks the extension developer for a compatible release, and on Monday the CISO gets a one paragraph summary. Without the inventory, the first hours would have gone on working out which stores were affected.

How Safeguard does this

Everything above works without Safeguard. This section shows the same plan in Safeguard, using only flows from docs.safeguard.sh. 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 software 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. Per the docs, you open Integrations, connect repositories or container registries, or upload files, and Safeguard creates the project and its SBOM. Continuous scanning re-evaluates projects when vulnerability feeds change, so a new KEV entry is matched against existing SBOMs without a new build. That is the 6.3.2 inventory, kept current.

If a cloud service may not clone your payment repositories, the local runner (GA) built into the Safeguard CLI (GA) runs scan jobs on your own machine and uploads only the SBOM and findings, never source code, over outbound HTTPS. The docs show:

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

# start the interactive terminal, then type /login
safeguard

On a server, safeguard runner start and safeguard runner status run and check the runner, per the docs. Safeguard also offers on-prem and fully air-gapped deployment (GA) and Zero AI mode (GA), with no large language model in the loop, for processors that keep source code inside a segmented network.

2. Prioritize by exploitation and reachability

Vulnerability management (GA) enriches findings with EPSS and CISA KEV status, and reachability analysis and prioritization (GA) adds whether your application calls the vulnerable code path. Together they fill the top rows of the patch clock. SAST (GA) covers your own checkout and payment API code, DAST (GA) tests web targets you have verified, such as a staging checkout, and license compliance (GA) flags obligations in the components you ship inside merchant SDKs.

3. Turn the patch clock into policies and gates

Policies, gates and guardrails (GA) put the standard into the pipeline. Per the docs, you go to Settings › Policies, click Create Policy, define conditions (severity, CVSS, EPSS, license, component age, maintenance) in the visual builder or YAML, and set severity and actions.

Each policy has one action that decides what a failure does to the gate:

A reasonable mapping from the patch clock: Block for KEV-listed or critical reachable vulnerabilities in payment applications, Warn for high, Notify for the rest. 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

Drop --fail-on critical for report-only mode in the first two weeks, or add --fail-on-gate all to fail on a policy gate. The key is created under Settings › Developer with the scans:trigger and scans:read scopes.

4. Run exceptions through a recorded approval

Approval runs through exceptions. Per the docs, a developer clicks Request Exception, selects the policy and finding, gives a justification and an expiration date, and submits; approvers decide and the audit trail records it.

For findings you will not fix yet, the Mitigations tab records the type (Risk Acceptance, False Positive, Workaround Applied or Not Applicable), justification, approver, an optional expiry for risk acceptances, and evidence. That is the exception register the PCI lead hands to the QSA.

5. Fix faster where a fix exists

Autonomous remediation (GA) opens fix pull requests that move a vulnerable dependency to a fixed version, singly or in bulk across repositories. It ships switched off, with every category set to Manual, so nothing changes until your team turns it on.

6. Bring vendors inside the clock with TPRM

Third-Party Risk Manager (TPRM, GA) is where the vendor risk owner works. Per the docs:

1. Add Vendor records the company, contact, products and risk tier (Critical, High, Medium, Low), with CSV import. Contract records hold SLA terms, security requirements and SBOM obligations.
2. Request SBOM, or Bulk Request, sends a template setting SPDX or CycloneDX format and a deadline, with automatic reminders, and tracks status through validation.
3. Monitoring alerts on new critical CVEs and CISA KEV additions affecting a vendor, and re-assessment can trigger on contract renewals and security incidents. Reports export as PDF or Excel.

7. Map the evidence to PCI DSS

The Compliance and GRC suite (GA) holds frameworks, controls, evidence and tests. Per the docs, the library includes PCI DSS v4.0: open it on Compliance › Frameworks, and its Connectors tab shows which connected systems answer its tests. The docs say a passing result is evidence toward a control, not proof that it is met.

Portal audit trails (GA) log SBOM activity, access and administrative changes. Per the docs, you view them on Settings › Audit Logs and export them for the evidence folder.

8. If you sell payment software, answer merchants once

Gateways, plugin vendors and SDK publishers answer merchant security questionnaires every week. Trust Center (GA) publishes a page with your compliance status, controls, policies, subprocessors and documents. Per the docs, you manage it on Compliance › Trust Center and publish explicitly; nothing goes live on its own. Portal (GA) handles sharing the SBOMs you publish for your SDKs and plugins.

What Safeguard does not do

• It does not inventory or monitor payment page scripts in the customer's browser. Requirements 6.4.3 and 11.6.1 need a script inventory and a change and tamper detection mechanism that sees the page as the browser receives it. Nothing in Safeguard's offering covers that, so you need a separate control for it. DAST tests web targets you have verified; it is not a substitute.
• It does not perform or sign your PCI assessment. Your assessor decides whether a requirement is met; the docs say a passing test is evidence toward a control, not proof.
• It does not set your PCI scope. Scope comes from your data flows and your QSA. Safeguard covers only the projects, images and vendors you put into it.
• It cannot patch a hosted platform or a vendor's service. That fix comes from the vendor. TPRM tracks it; it does not ship it.
• It does not decide exceptions or notify anyone. Approvers, counsel and the incident lead own risk acceptance, regulator notices, SEC disclosures and card brand reporting.
• It does not replace credential hygiene. Token rotation and phishing-resistant multifactor authentication stay with your identity and platform teams.

Common mistakes

• Treating SAQ A as the end of script security. The January 2025 change moved the requirement into an eligibility criterion; it did not make scripts someone else's problem.
• Scanning source code and calling it the payment page. Tag managers and provider scripts load at run time. Inventory what the browser receives.
• Leaving platform extensions out of the inventory. Commerce extensions and themes often live outside the main package manifests, and they are where many flaws sit.
• Filing AOCs without reading the responsibility split. 12.8.5 asks which requirements each party owns. An AOC from a provider does not say what is left for you.
• Blocking every critical finding on day one. Teams route around gates that fire on unreachable code. Start in report-only mode.
• Exceptions without expiry dates. An exception that never expires is a risk acceptance nobody signed.
• Forgetting the SDKs you ship. Scan the client libraries merchants install, not only your platform.

FAQ

What is software supply chain security for payments and e-commerce?

Knowing and controlling every piece of third-party code in the payment flow: open source in your applications, platforms and extensions, payment SDKs, payment page scripts, and the vendors who run parts of the flow. PCI DSS v4.0.1 turns most of it into assessable controls.

Does PCI DSS v4.0.1 require an SBOM?

The PCI SSC summary describes 6.3.2 as maintaining an inventory of bespoke and custom software to support vulnerability and patch management. It does not name SBOM as a format. An SBOM per application is the most practical way to keep that inventory current and show it to an assessor; ask your QSA how they want to see it.

When did the PCI DSS 4.0 future-dated requirements take effect?

On 31 March 2025. Before that they were best practices. PCI DSS v4.0 itself was retired on 31 December 2024, so v4.0.1 is the version assessed today.

Do merchants on a hosted payment page still need to worry about scripts?

Yes, in a different form. Since the January 2025 SAQ A update, those merchants must confirm their site is not susceptible to script attacks that could affect their e-commerce systems, and PCI SSC said the underlying requirements remain in the standard.

Does using a PCI compliant payment provider make us compliant?

No. PCI SSC clarified that using a compliant third-party service provider does not make an entity compliant and does not remove its own responsibility. You still need the provider list, written agreements, monitoring of their status and the responsibility split.

What should we ask a payment or commerce vendor for?

Use the question list in the 60 day step: AOC and expiry, responsibility matrix, SBOM, KEV notification, script control and build pipeline security.

How fast should we patch a KEV-listed flaw in our commerce platform?

Read the patching timelines in PCI DSS requirement 6.3 with your QSA; federal KEV due dates do not bind private companies. Still, the September 2026 Adobe Commerce KEV entries carried federal due dates three days after listing, a useful benchmark for internet-facing payment systems.

Does the FTC Safeguards Rule apply to payment companies?

It applies to financial institutions under FTC jurisdiction, which can include non-bank payment companies. It requires secure development practices, evaluation of externally developed applications and oversight of service providers. Ask counsel whether it covers your company.

Can Safeguard scan our payment code without sending source code to the cloud?

Yes. The local runner (GA) in the Safeguard CLI scans on your own machine and uploads only the SBOM and findings. On-prem and air-gapped deployment and Zero AI mode (both GA) are also available.

The steps in this guide shrink the inventory and patch problem; they cannot remove the time before a fix exists. The section below, which is the same across this series, covers how Safeguard handles that gap for the open source components you build into checkout code and payment SDKs.

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. A checkout or payment SDK team would use the same flow on its own repository.

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 processor that will not give a cloud service access to repositories inside its segmented network.

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

The third demo connects Claude to the Safeguard MCP server (GA) with OAuth and shows how you choose which tools Claude can use. A PCI lead or AppSec engineer who already works in Claude can keep that tool list narrow, for example read-only access to projects and findings while preparing evidence.

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

Related reading: PCI DSS 4 requirement 6, securing the payment gateway software supply chain, retail and e-commerce software supply chain, the PCI DSS 4 software security evidence flow and, in this series, hospitality and travel.

Quick check

Sources

• PCI SSC: Summary of Changes from PCI DSS v3.2.1 to v4.0
• PCI SSC blog: Just published, PCI DSS v4.0.1
• PCI SSC blog: Now is the time to adopt the future-dated requirements of PCI DSS v4.x
• PCI SSC blog: Important updates for merchants validating to SAQ A
• CISA: Known Exploited Vulnerabilities catalog (JSON feed)
• NVD: CVE-2024-34102
• NVD: CVE-2025-54236
• 16 CFR 314.4, FTC Safeguards Rule elements (LII)
• 16 CFR 314.2, FTC Safeguards Rule definitions (LII)
• 23 NYCRR 500.1, definitions (LII)
• 23 NYCRR 500.8, application security (LII)
• 23 NYCRR 500.11, third-party service provider security policy (LII)
• 23 NYCRR 500.13, asset inventory (LII)
• Federal Register: SEC cybersecurity risk management, strategy, governance and incident disclosure (4 August 2023)
• CISA: Widespread supply chain compromise impacting npm ecosystem (23 September 2025)
• CISA: 2026 Minimum Elements for a Software Bill of Materials
• NIST SP 800-218: Secure Software Development Framework version 1.1
• Safeguard docs: Policies and Gates
• Safeguard docs: Mitigations
• Safeguard docs: Generate SBOM
• Safeguard docs: Continuous Scanning
• Safeguard docs: Third Party Risk Manager
• Safeguard docs: TPRM Vendor Management
• Safeguard docs: TPRM SBOM Requests
• Safeguard docs: TPRM Monitoring
• Safeguard docs: PCI DSS and connectors
• Safeguard docs: Local Runner
• Safeguard docs: GitHub Actions
• Safeguard docs: Portal Audit Trails
• Safeguard docs: Trust Center setup
• Safeguard docs: Application Security Testing
• Safeguard docs: Reachability Analysis

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.