Software Supply Chain Security for Retail: A 90-Day Plan

Software supply chain security for a retailer or consumer brand comes down to three jobs: know every open source component inside the software you build (your storefront, checkout, mobile app, loyalty platform and store integrations), know which vendor maintains every system you buy (point of sale, payment terminals, order management, workforce and planning SaaS), and run both on a patch clock that someone owns and can prove to a PCI assessor, a regulator or a board. In retail the two halves meet at checkout, where your code, your vendors' code and third-party scripts all run in the same browser or the same store lane. A focused team can stand up the inventory, the release gates and the vendor evidence in about 90 days.

This guide covers the software, the US rules, three recent public incidents, the owners 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 Qualified Security Assessor (QSA) and your acquirer decide what applies to you.

Key takeaways

• Retail software is a mix of code you build (web storefront, checkout, apps, integrations) and systems you buy or are handed by a franchisor (POS, payment terminals, store back office, planning and workforce SaaS). The program has to cover both.
• PCI DSS v4.0.1 is the rule with the sharpest teeth. Its future-dated requirements took effect on 31 March 2025, including 6.3.2 (an inventory of bespoke and custom software), 6.4.3 (managing payment page scripts) and 11.6.1 (detecting unauthorized changes to payment pages).
• Retailers that issue their own credit card directly to consumers are named as an example of a financial institution in the FTC Safeguards Rule, which requires service provider oversight and notifying the FTC within 30 days of a notification event affecting 500 or more consumers.
• The three incidents below involve software retailers buy or build on, not code they wrote: an npm worm (September 2025), an exploited commerce platform flaw (July 2024) and ransomware at a supply chain SaaS provider (November 2024).
• Five roles own the problem, each with a different deadline: the CISO, digital engineering, GRC or PCI compliance, vendor risk, and store and franchise IT.
• 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, policies, gates and guardrails, autonomous remediation (ships switched off), SAST, DAST, license compliance, Third-Party Risk Manager (TPRM), the Compliance and GRC suite, Trust Center, Portal audit trails, the CLI and local runner, and on-prem, air-gapped and Zero AI deployment options.

What software retail runs

A supply chain program starts with a map. Retail runs a wide spread of systems, and most of them touch card data, customer accounts or loyalty balances.

In the store. Point of sale (POS) software runs on lane terminals, tablets and handhelds, with a payment application and a PIN entry device behind it. Around it sit self-checkout, the back office server, handheld inventory apps, electronic shelf labels, signage, in-store Wi-Fi and kiosks, each from a different supplier and often on a vendor-managed image the retailer never builds.

Digital commerce. The web storefront might be a SaaS platform, a self-hosted open source commerce platform, or a headless front end that calls a stack of APIs. Checkout and payment pages load scripts from your own build, from your payment provider and often from tag managers, analytics, chat, personalization and fraud tools. Search, reviews and buy online pick up in store usually come from separate services.

Mobile apps. Brand apps handle browsing, payments, loyalty, digital receipts and store mode. Each app bundles open source libraries plus third-party software development kits (SDKs) for analytics, crash reporting, payments and advertising, and you cannot pull a bad one back until users update.

Customer and loyalty. Loyalty, CRM, marketing, contact centre and gift card systems, mostly SaaS, holding identity, purchase history and stored value.

Supply chain and operations. Order management (OMS), warehouse management (WMS), demand planning, workforce scheduling, electronic data interchange (EDI) and managed file transfer with suppliers, mostly SaaS, with one provider often serving many competing retailers.

Franchise and multi-brand IT. A franchisor usually specifies the POS, the loyalty program and the online ordering platform, while each franchisee owns its own network, devices and, often, its own merchant account.

Why the retail supply chain is so wide

Three features make retail different from most industries:

1. Checkout runs other people's code in your customer's browser. Every third-party script on a payment page can read what the shopper types. PCI DSS v4.x added specific requirements for exactly this.
2. Shared SaaS creates shared failure. A planning, scheduling or file transfer provider serving many retailers can fail for all of them at once.
3. The store estate is vendor-managed and slow to patch. POS images and terminals update on the vendor's schedule, across many locations, some owned by franchisees.

The regulations and frameworks that apply

US rules lead, because that is where assessment and enforcement pressure on most retailers' software sits.

PCI DSS v4.0.1

Every card sale puts PCI DSS in play. According to the PCI Security Standards Council (PCI SSC) blog, 51 of the 64 new requirements in v4.0 were future-dated to 31 March 2025, and v4.0.1 was published in June 2024 as a limited revision with clarifications. All of them are assessed today.

The full v4.0.1 text sits behind a license agreement. The descriptions below come from the Council's public Summary of Changes from v3.2.1 to v4.0 and its blog; read the full text before quoting it in an assessment.

Two details matter for retail.

First, small e-commerce merchants that fully outsource payment pages often validate with Self-Assessment Questionnaire A (SAQ A). In January 2025 the Council removed requirements 6.4.3 and 11.6.1 (and 12.3.1, the targeted risk analysis supporting 11.6.1) from SAQ A and added an eligibility criterion that merchants "confirm their site is not susceptible to attacks from scripts" that could affect their e-commerce systems. The new SAQ A took effect on 31 March 2025, and standing behind that statement still means knowing what scripts your pages load.

Second, franchise models split PCI scope. In many franchise systems each franchisee is its own merchant with its own acquirer relationship, while the franchisor may act as a service provider for systems it hosts or mandates. The card brands, acquirers and payment facilitators, not PCI SSC, set validation requirements. Ask your acquirer which path applies to each brand, channel and franchise arrangement.

The FTC Safeguards Rule, for retailers that extend credit

The FTC Standards for Safeguarding Customer Information, 16 CFR Part 314, apply to financial institutions under the FTC's jurisdiction. The rule's own definitions give as its first example "a retailer that extends credit by issuing its own credit card directly to consumers." A retailer that issues its own store card should check whether it is in scope. Three sections matter most:

• 314.4(f), oversee service providers. Take reasonable steps to select and retain service providers capable of maintaining appropriate safeguards, require them by contract to implement and maintain those safeguards, and periodically assess them based on the risk they present.
• 314.4(i), report to the board. The qualified individual reports at least annually on the program, including risk assessment, service provider arrangements, results of testing and security events.
• 314.4(j), notify the FTC. A "notification event" is the acquisition of unencrypted customer information without authorization. If it involves the information of at least 500 consumers, the institution must notify the FTC as soon as possible and no later than 30 days after discovery.

Retailers outside the Safeguards Rule still answer to the FTC under Section 5 of the FTC Act, which prohibits unfair or deceptive acts or practices, including broken promises about how customer data is protected.

SEC cybersecurity disclosure rules

Listed retailers and consumer brands fall under the SEC's cybersecurity disclosure rules, adopted in July 2023, published in the Federal Register on 4 August 2023 and effective on 5 September 2023. A material cybersecurity incident is disclosed on Form 8-K under Item 1.05, generally within four business days of the company determining it is material. Regulation S-K Item 106 requires an annual description of the company's processes for assessing, identifying and managing material cybersecurity risks, including whether it has processes to oversee and identify material risks associated with its use of any third-party service provider. If the 10-K says you oversee third-party software risk, your program needs records that show it.

California's cybersecurity audit regulations

On 23 September 2025 the California Privacy Protection Agency (CPPA) announced that regulations covering cybersecurity audits, risk assessments and automated decisionmaking technology had been approved, effective 1 January 2026. Businesses required to complete cybersecurity audits must submit certifications to the CPPA by 1 April 2028 if they make over 100 million dollars, 1 April 2029 if they make 50 to 100 million dollars, and 1 April 2030 if they make less than 50 million dollars. Large consumer brands with California customers should confirm scope now, because the audit period runs before the certification date.

Every US state also has a breach notification law, and retail data (names, card data, loyalty accounts) triggers them often.

Federal guidance you can borrow for vendor and app requirements

No federal rule requires a retailer to collect a software bill of materials (SBOM), but these documents make good contract and engineering standards:

• CISA's 2026 Minimum Elements for a Software Bill of Materials, published on 29 July 2026 by CISA, the NSA, the FBI and international partners, updates and replaces the minimum elements NTIA published in 2021. CISA says the minimum elements apply to all software, and that some types, such as AI and software as a service in cloud environments, may need additional elements.
• NIST SP 800-218, the Secure Software Development Framework (SSDF) version 1.1, gives a vendor-neutral list of secure development practices to ask POS, commerce and SaaS suppliers about.
• The OWASP Mobile Application Security Verification Standard (MASVS) gives a published baseline for brand apps, organized into control groups for storage, cryptography, authentication and authorization, network, platform interaction, code, resilience and privacy.
• CISA's September 2025 npm alert (covered below) lists concrete steps for teams that ship JavaScript, which most storefronts and many apps do.

Real public incidents from the last three years

The three cases below come from US government alerts and a national CERT's published summary. They are described only as their sources describe them, with no conclusions about what any company should have done.

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

On 23 September 2025 CISA published an alert on a "widespread software supply chain compromise" involving npmjs.com, the largest JavaScript registry. CISA said a self-replicating worm publicly known as "Shai-Hulud" had compromised over 500 packages. After gaining initial access, the actor deployed malware that scanned for credentials, targeted GitHub personal access tokens and cloud API keys, exfiltrated them, and then authenticated to npm as the compromised developer to inject code into other packages and publish compromised versions.

CISA's recommendations include a dependency review of all software using npm, checking package-lock.json or yarn.lock files for affected packages "including those nested in dependency trees", searching artifact repositories and caches for affected versions, pinning dependency versions to known safe releases, rotating developer credentials, and enforcing phishing-resistant multifactor authentication on developer accounts.

What this shows for retail: storefronts, checkout front ends, headless commerce apps and many mobile apps are built from npm packages, mostly transitive ones. The first question on the day of an alert like this is "which of our builds resolved an affected version", and only a component inventory with lockfile-level detail answers it quickly.

An actively exploited flaw in an open source commerce platform (July 2024)

On 17 July 2024 CISA added CVE-2024-34102, an "Adobe Commerce and Magento Open Source Improper Restriction of XML External Entity Reference (XXE) Vulnerability", to its Known Exploited Vulnerabilities (KEV) catalog, based on evidence of active exploitation. Retailers that run either platform themselves, or through an agency, own that patch.

What this shows: when the platform itself is the vulnerable component, the patch has to reach every instance you run, including staging sites, regional storefronts and microsites an agency built years ago. A KEV listing turns a vulnerability from "schedule it" into "this week", and you can only meet that clock for instances you know about.

Ransomware at a supply chain planning SaaS provider (November 2024)

On 21 November 2024 Blue Yonder, an Arizona-based supply chain management software company, experienced outages in its hosted managed services environment that were determined to be the result of a ransomware attack, according to a summary published by INCIBE-CERT, Spain's national computer emergency response team. INCIBE-CERT said the company provides supply chain management for more than 3,000 large companies and that many affected customers were back up and running while it restored the rest. Planning and scheduling are core retail workloads, and the incident fell weeks before the US holiday peak.

What this shows: much retail operational software is a shared hosted service, and the supplier itself can be the incident. Continuity plans and contracts have to cover a provider being down for days, not only a vulnerable component.

What the three have in common

None began in code the affected retailers wrote. Each points to the same needs: a current map of components and vendors to systems and data, a clock for known exploited vulnerabilities, and evidence kept as the work happens.

The personas who own the problem

Supply chain security in retail has no single owner. Five roles carry a piece of it, and each one meets the problem on a different day.

The CISO

What they need: a defensible answer to "are we exposed, and how fast can we fix it" for the board or disclosure committee, in business terms: which stores, channels and brands, and how many customers.

When: the morning a KEV entry or npm alert lands, before the annual board review, before peak trading freezes, and the day a vendor reports an incident.

The VP or Director of Engineering for digital commerce

What they need: release speed through peak, one gate instead of four, and a short list of fixes that matter. Their teams own the storefront, checkout, APIs and apps.

When: every sprint, the week before a code freeze, and when a checkout script changes without a ticket.

The GRC or PCI compliance lead

What they need: evidence by requirement: the software inventory for 6.3.2, the script inventory and justifications for 6.4.3, the tamper detection records for 11.6.1, the TPSP list and responsibility matrix for 12.8 and 12.9, plus the risk assessment and service provider oversight records for the Safeguards Rule if the retailer issues its own card.

When: the QSA's fieldwork window, the annual Report on Compliance or SAQ, the acquirer's request after a change of scope, and the annual board report.

The procurement or vendor risk owner

What they need: coverage and continuity across the vendor list: which vendors are critical, what each contract requires, which ones have provided current evidence, and what to ask at renewal.

When: contract signature and renewal, quarterly reviews of critical vendors, and the day a vendor appears in the news.

Store IT and franchise operations

What they need: a patch standard every location can follow, visibility into which POS versions run where, and a clear split of duties between franchisor, franchisee and the POS reseller.

When: vendor release cycles, store openings, franchise renewals, and every incident that forces a store offline.

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

The plan assumes a mid-sized retailer with its own storefront, one or two apps, a vendor POS and a few critical SaaS systems. Each phase ends with something the CISO can show and the PCI lead can file.

Days 1 to 30: see what you run

1. List every system that builds, serves or touches checkout. Start from the PCI scope diagram and add what it misses: microsites, apps, APIs, tag managers, POS images and the SaaS behind loyalty, OMS and planning. Name an owner for each.
2. Generate an SBOM for each application you build. Use SPDX or CycloneDX, generated from lockfiles and build outputs rather than from a manifest alone, so transitive dependencies appear.
3. Inventory payment page scripts. For every payment page and every page that embeds one, record each script, its source, its purpose and who approved it. This is the working list for 6.4.3.
4. List your mobile SDKs. For each app, record every third-party SDK, its version and what data it can reach.
5. Build the vendor register. For each vendor: what it provides, which systems and data it touches, whether it is a TPSP for PCI, contract renewal date, and whether it has provided an SBOM, an attestation of compliance or a secure development attestation. Tier vendors as Critical, High, Medium or Low.
6. Map store versions. For POS, payment terminals and back office servers, record the software version by location and the vendor's support end date. For franchise locations, record who is responsible for updates.
7. Write the patch clock. Agree target timelines by severity and exploitation status, for example: KEV-listed in an internet-facing system within days, critical with a fix within two weeks, high within 30 days, others in the normal cycle. Write down who can grant an exception and for how long.

Day 30 output: a system list with owners, SBOMs for built applications, a script inventory, an SDK list, a tiered vendor register and a written patch clock.

Days 31 to 60: control what changes

1. Scan continuously, not once. Match every SBOM against vulnerability data that updates daily, so a new KEV entry is checked against existing builds without waiting for a new release.
2. Prioritize with exploitation data. Use CISA KEV and EPSS to sort findings, and where you can, add whether the vulnerable function is actually reachable from your code. Fix exploited and reachable findings first.
3. Add gates to CI in report mode first. Run checks on every pull request for two weeks without failing builds, measure what would have failed, then switch on blocking for the agreed categories.
4. Pin and review. Commit lockfiles, pin versions to known good releases, and require review for dependency changes in checkout and payment code. CISA's npm alert recommends pinning.
5. Protect developer credentials. Enforce phishing-resistant MFA on source control and registry accounts and rotate long-lived tokens, as CISA's alert recommends.
6. Put script changes under change control. Any new payment page script needs a ticket, a justification and an approver.
7. Send the first vendor evidence requests. Ask Critical vendors for an SBOM aligned with CISA's 2026 minimum elements, plus their PCI responsibility matrix where they are TPSPs, with a deadline.
8. Agree the franchise minimum. Publish minimum POS and terminal versions for franchise locations and the date by which each must comply.

Here is a decision table the engineering and GRC leads can adopt the same day:

Day 60 output: continuous scanning, gates in CI with agreed actions, an exception process, script change control, first vendor SBOMs requested and a franchise minimum version standard.

Days 61 to 90: prove it works

1. Run a tabletop on a supply chain alert. Take CISA's npm alert and time how long it takes to answer "which builds, apps and stores are affected".
2. Run a tabletop on a vendor outage. Assume a critical SaaS provider is down for five days in peak season. Who decides on manual processes, and who tells stores?
3. Map evidence to PCI DSS. For 6.3.1, 6.3.2, 6.4.3, 11.6.1, 12.8 and 12.9.2, name the record that proves it and where it lives. Fill the gaps before the QSA arrives.
4. Review exceptions. Close the expired ones, renew the justified ones and escalate the rest.
5. Report. Give the CISO a one-page view: exposure by brand and channel, KEV clock performance, open exceptions and critical vendors without current evidence. If the retailer issues its own card, feed the same data into the Safeguards Rule annual board report.
6. Update contract templates. Make SBOM delivery and vulnerability and incident notice terms standard at signature and renewal.

Day 90 output: two tabletop results with timings, a requirement-by-requirement evidence map, a reviewed exception register, a board-ready summary and updated contract templates.

Illustrative scenario: an npm alert on a Thursday before a holiday weekend

This is an illustrative scenario with invented round numbers. A retailer runs 40 web and app repositories. At 9 a.m. a public alert names a set of compromised npm package versions. Without an inventory, each team searches its own lockfiles and the answer arrives on Monday. With SBOMs stored per build and continuous matching, the security team sees by 10 a.m. that 6 repositories resolved an affected version, 2 of them in checkout builds deployed last week. Engineering pins the known good versions, rebuilds and redeploys those 2 before lunch, rotates the tokens of developers who installed during the affected window, and opens tickets for the other 4. The GRC lead files the timeline as evidence for 6.3.1.

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 connect repositories or container registries under Integrations, or upload files, and Safeguard creates the project and its SBOM. Continuous scanning re-evaluates existing projects when vulnerability data changes, so a newly listed KEV entry is matched against builds you already have.

If your source code may not leave your network, the local runner (GA) in the Safeguard CLI (GA) runs scans on your own machine and uploads only the SBOM and findings, never source code. 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 server, the docs show:

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

On-prem and fully air-gapped deployment (GA) and Zero AI mode (GA), in which the platform runs with no large language model in the loop, are available for teams with stricter rules.

2. Prioritize by exploitation and reachability

Vulnerability management (GA) enriches findings with EPSS scores and CISA KEV status, and reachability analysis and prioritization (GA) adds whether your application calls the vulnerable code. Together they fill the first column of the decision table above. SAST (GA) covers your own storefront, checkout and integration code, DAST (GA) tests web targets you have verified, such as a staging storefront, and license compliance (GA) flags license obligations in the components you ship in apps and web bundles.

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, drop --fail-on critical. The API 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, not through a gate action. Per the docs, a developer clicks Request Exception, selects the policy and finding, gives a justification and an expiration date, and submits; an approver decides, and the audit trail records it.

For findings you will not fix yet, the Mitigations tab records the mitigation type (Risk Acceptance, False Positive, Workaround Applied or Not Applicable), the justification, the approver, an optional expiry for risk acceptances, and supporting evidence. That becomes the GRC lead's exception register.

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.

6. Bring vendors inside the clock with TPRM

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

1. Vendors › Add Vendor records the company, contact, products used and risk tier (Critical, High, Medium, Low). CSV bulk import moves a register that started in a spreadsheet. Contract records hold dates, SLA terms, security requirements and SBOM obligations.
2. Request SBOM, or Bulk Request for many vendors at once, sends a request specifying SPDX or CycloneDX format, required fields and a deadline, with reminders as the deadline approaches.
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 reassessment can be triggered by contract renewals and security incidents. Reports export as PDF or Excel.

For a retailer, the Critical tier usually holds the POS and payment providers, the commerce platform, OMS and planning SaaS, and file transfer.

7. Map the evidence to PCI DSS

The Compliance and GRC suite (GA) holds frameworks, controls, evidence and tests. Per the docs, PCI DSS v4.0 is in the framework library: open it under Compliance › Frameworks, and its Connectors tab shows which connected systems feed its tests. The docs say a passing test 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 under Settings › Audit Logs and export as CSV, JSON or PDF for the assessment folder.

8. If you sell technology to retailers, answer your customers once

Trust Center (GA) publishes a page with your compliance status, controls, policies, subprocessors and documents. Per the docs, you manage it under Compliance › Trust Center and publish explicitly; nothing goes live on its own. Portal (GA) handles sharing the SBOMs you publish with customers.

What Safeguard does not do

• It does not monitor payment page scripts in the shopper's browser. Requirements 6.4.3 and 11.6.1 need a mechanism that sees what the browser actually receives. Safeguard's docs describe no browser-side script monitoring, so plan a separate control for those two requirements.
• It does not patch vendor software or store devices. A POS, payment terminal, back office or SaaS fix comes from that vendor. Safeguard can show exposure through vendor SBOMs; the vendor, your store IT team or your managed service provider applies the patch.
• It does not see inside vendor SaaS without the vendor's help. If a planning or loyalty provider will not deliver an SBOM, Safeguard cannot create one. TPRM tracks the request and its status; your contract is what gets the SBOM delivered.
• It does not decide PCI scope or compliance. Your QSA, acquirer and the card brands decide. A passing test in Safeguard is evidence toward a control, as the docs say, not a finding of compliance.
• It does not make disclosure decisions. SEC materiality, FTC notification under the Safeguards Rule, state breach notices and regulator contact belong to your counsel and executives.

Common mistakes

• Treating SAQ A as "nothing to do on scripts". The January 2025 change moved the obligation into an eligibility statement; it did not remove the need to know what your pages load.
• Scanning manifests instead of lockfiles. Most retail web and app exposure is transitive. An SBOM built from package.json alone misses the packages an npm alert names.
• Letting marketing own the tag manager with no change control. A tag manager can add a script to checkout without a code deployment. Bring payment page tags under the same approval as code.
• Blocking everything on day one. Gates that fail every build in the week before a freeze get switched off. Start in report mode and agree the block list.
• Assuming the franchisee knows. If the franchise standard does not name minimum versions and dates, store patch levels drift.

FAQ

What is software supply chain security for retailers?

It is the practice of knowing and controlling the third-party code inside the software a retailer builds, and the vendors behind the software it buys. In retail that covers storefront and checkout dependencies, payment page scripts, mobile app SDKs, POS and terminal software, and the SaaS that runs loyalty, ordering and planning, all tied to a patch clock and evidence for PCI DSS and other rules.

Does PCI DSS v4.0.1 require an SBOM?

Not by that name. Requirement 6.3.2, as described in the Council's Summary of Changes, requires an inventory of bespoke and custom software, and 6.3.1 makes clear that vulnerability management covers third-party software too. An SBOM in SPDX or CycloneDX is a practical way to keep that inventory, but confirm with your QSA what evidence they expect.

Do requirements 6.4.3 and 11.6.1 apply to merchants on SAQ A?

They were removed from SAQ A in January 2025, effective 31 March 2025, and replaced with an eligibility criterion that the merchant confirm its site is not susceptible to attacks from scripts that could affect its e-commerce systems. Merchants on other SAQs or a Report on Compliance still assess them directly.

Does the FTC Safeguards Rule apply to retailers?

It applies to financial institutions under the FTC's jurisdiction. The rule names a retailer that issues its own credit card directly to consumers as an example. Retailers whose store card is issued by a bank partner should ask counsel how the rule applies to them.

Who is responsible for PCI compliance in a franchise?

Often each franchisee is its own merchant and validates its own compliance, while the franchisor may act as a service provider for systems it hosts or mandates. The acquirer and card brands decide the validation path, so confirm the arrangement for each brand.

Which retail vendors should we ask for an SBOM first?

Start with Critical vendors: the POS and payment providers, the commerce platform, order management and planning SaaS, and file transfer. Ask for SPDX or CycloneDX aligned with CISA's 2026 minimum elements, and say how often you expect updates.

How should a retailer respond to an npm or open source package compromise?

Follow CISA's September 2025 recommendations: review dependencies, check lockfiles for affected versions including nested ones, search caches and artifact repositories, pin to known safe versions, rotate developer credentials and enforce phishing-resistant MFA. Then record what you did and when.

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

Yes. Per the docs, the local runner in the Safeguard CLI scans on your own machine and uploads only the SBOM and findings, never source code. On-prem and air-gapped deployment and Zero AI mode are also available.

Most of the exposure in this guide sits in open source packages inside storefronts, checkout front ends and apps that retail teams build and ship themselves. For those components, the section below sets out how Safeguard closes the gap between a published fix and a deployed one, and what happens when no fix exists yet.

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 storefront or checkout team would run the same flow on its own JavaScript repository after an npm 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 retail engineering team whose policy does not allow a cloud service to clone checkout or payment code.

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

The third demo is a real Android session: 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 on-call engineer who is away from a desk during a peak weekend.

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

Related reading: software supply chain security in retail and e-commerce, PCI DSS 4.0 requirement 6.4.3 for third-party JavaScript, securing the point of sale software supply chain, third-party risk management for retail and logistics software, the CVE-2024-34102 commerce platform KEV entry 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: 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
• eCFR: 16 CFR Part 314, Standards for Safeguarding Customer Information
• Federal Register (govinfo): SEC final rule, Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure (4 August 2023)
• California Privacy Protection Agency: California finalizes regulations (23 September 2025)
• CISA: 2026 Minimum Elements for a Software Bill of Materials
• NIST SP 800-218: Secure Software Development Framework version 1.1
• OWASP Mobile Application Security Verification Standard (MASVS)
• CISA: Widespread supply chain compromise impacting npm ecosystem (23 September 2025)
• CISA: CISA adds three known exploited vulnerabilities to catalog (17 July 2024)
• INCIBE-CERT: Ransomware attack against Blue Yonder
• 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

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.