Software Supply Chain Security for Hospitality and Travel: A 90-Day Plan

Software supply chain security for a hotel group, booking platform, car rental brand or cruise line comes down to three jobs: know every component inside the software you build (your booking engine, mobile app and loyalty platform), know which vendor runs every system you buy (the property management system, point of sale, channel manager and file transfer tools), and put both on a patch clock that someone owns and can prove to a PCI assessor, a regulator or a board. Most of the risk in this industry sits with vendors, so the program is as much procurement as it is engineering. A focused team can stand up the inventory, the gates and the vendor evidence in about 90 days.

This guide covers the software the industry runs, the US rules that apply, three public incidents from the last three years, the people who own each part, and a 30, 60 and 90 day plan that works with whatever tools you have. 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

• Hospitality and travel software is mostly bought, not built, and franchise agreements often decide which property management system (PMS), point of sale (POS) or Wi-Fi vendor a property must use.
• 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 changes to payment pages).
• The FTC's final order against Marriott and Starwood (20 December 2024) requires an information security program and data retention limits.
• Two of the three incidents below came through a supplier's software: ransomware on systems supporting shared airport passenger processing (September 2025) and data theft through zero days in a vendor's file transfer platform (confirmed February 2025).
• Five roles own the problem: the CISO, the VP of Engineering for digital and distribution, the GRC or PCI compliance lead, the procurement or vendor risk owner, and property IT or franchise operations. Each one has a different deadline.
• 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 local runner and CLI, and on-prem, air-gapped and Zero AI deployment options.

What software hospitality and travel runs

Before anyone can talk about supply chain risk, they need a map of the systems. Hospitality and travel run an unusually wide spread of software, and most of it touches payment cards, identity documents or loyalty balances.

Property systems. The property management system (PMS) handles reservations on the books, check-in, room status, folios and guest profiles; modern ones are multi-tenant SaaS, older ones still run on a back office server. Point of sale (POS) covers restaurants, bars, spas and shops, and sits squarely in PCI DSS scope with its payment gateway and tokenization. Around them sit electronic door locks and mobile key, guest Wi-Fi and captive portals (often run by a managed service provider), kiosks, signage, in-room entertainment and building systems, each with firmware from a different supplier.

Distribution and revenue. The central reservation system (CRS) and internet booking engine run the brand's own booking path. A channel manager connects to online travel agencies and metasearch, global distribution system (GDS) connectivity serves agencies and corporate travel programs, and a revenue management system sets rates from demand data.

Guest-facing digital. Brand websites and payment pages, including the scripts that load in the guest's browser at checkout; mobile apps for booking, loyalty, mobile check-in and mobile key, which bundle many third-party software development kits; loyalty platforms holding points balances and member profiles; and contact centre and CRM platforms, usually SaaS.

Shared and operational systems. Check-in desks, gates and baggage handling at many airports run on common-use software shared by several airlines. Managed file transfer moves rate files, reservations, payroll and reports between hotels, brands, partners and processors. Car rental counter and fleet software and cruise ship onboard systems add their own stacks.

Why the supply chain is so wide here

1. Owners, managers and brands are different companies. A hotel may be owned by a fund, operated by a management company and flagged with a brand. The brand sets technology standards, the owner pays, the manager runs the systems, and contracts do not always say who patches what.
2. Brand standards mandate vendors. Franchise agreements often require an approved PMS, POS or Wi-Fi provider, so a property cannot always swap a vendor that falls behind.
3. Thin property IT. Many properties have no full-time IT person on site. Patching relies on the vendor, a regional team or a managed service provider.

The table below is a starting map. Assign each row an owner before you start the plan.

The regulations and frameworks that apply

US rules come first, because that is where most enforcement and assessment pressure on this industry's software sits.

PCI DSS v4.0.1

Nearly every booking, folio and restaurant bill involves a card, so PCI DSS is the rule most teams already live with. The PCI Security Standards Council (PCI SSC) retired v3.2.1 on 31 March 2024 and published v4.0.1 as a limited revision in June 2024. According to the Council's blog, 51 of the 64 new requirements in v4.x were future-dated to 31 March 2025, so all of them are assessed today.

The requirements below matter most for supply chain work. Descriptions come from the Council's summary of changes for v4.0; confirm wording against the full v4.0.1 text before you quote it in an assessment.

Two details deserve attention. First, the Council's January 2025 update to Self-Assessment Questionnaire A (SAQ A) removed 6.4.3, 11.6.1 and 12.3.1 from that questionnaire and added an eligibility criterion that the merchant confirm its site "is not susceptible to attacks from scripts" that could affect its e-commerce systems. The Council said the change affects reporting, not the underlying requirements. A hotel on SAQ A because its booking engine provider hosts the payment page still has to confirm that criterion. Second, the Council says using a PCI DSS compliant TPSP does not make an entity compliant or remove its own responsibility, which matters in an industry built on vendors.

PCI SSC does not set validation requirements; card brands, acquirers and payment facilitators do. Ask your acquirer which path applies to each property and sales channel.

The FTC Act and the Marriott and Starwood order

The Federal Trade Commission enforces Section 5 of the FTC Act against unfair or deceptive practices, which includes failing to provide the data security a company promises its customers. On 20 December 2024 the FTC finalized an order against Marriott International and its subsidiary Starwood Hotels and Resorts Worldwide. The FTC said the companies failed to implement reasonable data security, which led to three large breaches affecting more than 344 million customers worldwide.

Under the final order, the companies must establish a comprehensive information security program, keep personal information only as long as reasonably necessary, and give US customers a link to request deletion of personal information associated with their email address or loyalty account number. The Commission voted 3 to 0 to approve the final order, with two commissioners recused.

For a supply chain program, the lesson is that the FTC treats the whole information security program as the company's responsibility, and loyalty data is named in the order. If you acquire a brand or a portfolio, you acquire its software and vendors too.

SEC cybersecurity disclosure rules

Listed hotel groups, cruise lines, airlines, online travel agencies and car rental companies fall under the SEC's cybersecurity disclosure rules, adopted on 26 July 2023. A material cybersecurity incident goes on Form 8-K under Item 1.05, generally within four business days of the materiality determination. Regulation S-K Item 106 requires an annual description of how the company assesses, identifies and manages material cybersecurity risks. If your 10-K says you assess third-party software risk, your program needs records that show it.

State privacy and breach notification laws

Every US state has a breach notification law, and this industry notifies attorneys general often because it holds names, card data, driver's license numbers and passport details. The Hertz notice below was filed with the California Attorney General.

California adds a newer obligation. On 23 September 2025 the California Privacy Protection Agency (CPPA) announced approved regulations on cybersecurity audits, risk assessments and automated decisionmaking technology, effective 1 January 2026. Businesses required to complete cybersecurity audits must certify to the CPPA by 1 April 2028 (revenue over 100 million dollars), 1 April 2029 (50 to 100 million) or 1 April 2030 (below that). Check scope now, because the audit period runs before the certification date.

Federal guidance you can borrow for vendor requirements

No federal rule requires a hotel to collect a software bill of materials (SBOM), but two federal documents make good contract language.

• CISA's 2026 Minimum Elements for a Software Bill of Materials, released on 29 July 2026 with the NSA, the FBI and international partners, replaces the minimum elements the NTIA published in 2021. CISA says they apply to SBOMs for all software, including open source, AI software and software as a service, which matters where so much critical software is SaaS.
• NIST SP 800-218, the Secure Software Development Framework (SSDF) version 1.1 (February 2022), gives a vendor neutral list of secure development practices to ask suppliers about.

Real public incidents from the last three years

The three cases below come from official filings and regulator releases. They are described only as their sources describe them. None of them is a claim about what any company should have done.

Ransomware on systems supporting shared airport passenger processing (September 2025)

On 19 September 2025, RTX Corporation became aware of what it called a product cybersecurity incident involving ransomware on systems that support its Multi-User System Environment (MUSE) passenger processing software, according to a Form 8-K dated 24 September 2025. RTX described MUSE as software that lets multiple airlines share check-in, gate and baggage resources at airports, running on customer-specific networks outside the RTX enterprise network. The filing said affected customers shifted to backup or manual processes, with some delays and cancellations, and that the incident was not expected to have a material impact on RTX. A later RTX update said its Collins Aerospace business was continuing to restore the software for affected airlines.

What this shows: shared software is a single point of failure across many operators. Continuity planning for common-use or multi-tenant platforms has to assume the supplier itself can be the incident.

Data theft through a vendor's file transfer platform (October 2024 to April 2025)

In a notice filed with the California Attorney General in April 2025, The Hertz Corporation, on behalf of its Hertz, Dollar and Thrifty brands, said that Cleo Communications US, LLC is a vendor that provides a file transfer platform Hertz used for limited purposes. Hertz said that on 10 February 2025 it confirmed that Hertz data had been acquired by an unauthorized third party that it understood had exploited zero-day vulnerabilities within Cleo's platform in October 2024 and December 2024. Hertz completed its analysis of the affected data on 2 April 2025, reported the event to law enforcement and said it was reporting to relevant regulators.

Separately, on 13 December 2024 CISA added a Cleo vulnerability, CVE-2024-50623, described as a "Cleo Multiple Products Unrestricted File Upload Vulnerability", to its Known Exploited Vulnerabilities (KEV) catalog. The Hertz notice does not name specific CVE numbers, so do not assume which vulnerability applied in that case.

What this shows: a system used "for limited purposes" can still carry customer data, and a vendor zero day leaves nothing to patch on day one. Know which vendors run file transfer for you, and what passes through them.

The Marriott and Starwood FTC order (October and December 2024)

The FTC announced its proposed order in October 2024 and finalized it on 20 December 2024, as described above. The underlying breaches were older; the enforcement and its program, retention and deletion terms are recent. What this shows: regulators look at the whole program over time, including acquired systems, and an inventory plus a vendor register is what lets you answer "which systems hold guest data, and who maintains them".

What the three have in common

None began in code the affected brand wrote itself. Each involved software a supplier built or an acquired business had run, and each points to the same three needs:

1. A current list of which vendors and components sit in which systems, and which data each one touches.
2. A clock for acting on known exploited vulnerabilities, including in vendor software you cannot patch yourself.
3. Evidence, kept as the work happens, that you can hand to an assessor, a regulator or a board.

The personas who own the problem

Software supply chain security in hospitality and travel fails when it belongs to everyone. It works when five specific people each know their part and their deadline.

The CISO

Owns the overall risk across brands and properties, reports to the board and, at a listed company, informs the SEC materiality decision. Needs one view of third-party software risk, a short list of suppliers whose failure would stop operations, and an incident runbook that includes vendor incidents. Deadlines: quarterly board reporting, the annual 10-K, and the first hours of any supplier incident.

The VP or Director of Engineering for digital and distribution

Owns the booking engine, website, mobile and loyalty apps, and the integrations to the PMS, CRS and channel partners. Needs a component inventory for everything the team builds, a gate that stops known exploited vulnerabilities without slowing every release, and an owner for every payment page script. Deadlines: each release, peak season change freezes and each PCI assessment.

The GRC or PCI compliance lead

Prepares the Report on Compliance or self-assessment questionnaires, answers the acquirer, and increasingly owns state privacy audit readiness. Needs evidence mapped to 6.3.1, 6.3.2, 6.4.3, 11.6.1, 12.5.2 and 12.8, a scope document that reflects every vendor connection, and a record of exceptions with expiry dates. Deadlines: the annual assessment, the 12-month scope confirmation and the CPPA certification dates from 2028.

The procurement or vendor risk owner

Often split between brand procurement, which approves vendors for the franchise system, and corporate vendor management. Needs a tiered register of software vendors, the data each touches, contract clauses for SBOMs, vulnerability notification and patch timelines, and a renewal calendar. Deadlines: onboarding, renewal, any vendor appearing in a KEV entry or breach notice, and the TPSP monitoring cycle under 12.8.

Property IT and franchise operations

Regional IT managers, managed service providers and franchise operations teams carry the patch work on property systems. They need a clear split of what they patch versus what the vendor patches, a simple way to report a patch as done, and a route to escalate a late vendor. Deadlines: monthly patch windows, brand standard audits and any KEV addition affecting a property system.

Put names against each row of this table before you start.

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

The plan assumes a mid-sized hotel group or travel platform with a small security team and dozens of software vendors. It works with spreadsheets and open source tools as well as with a platform.

Days 1 to 30: see what you run

1. Name the owners. Put a person against each row of the persona table. Write down who decides on exceptions.
2. Build the vendor register. Start from accounts payable, the brand standards list and single sign-on applications. Record each product, the data it touches, PCI scope, who patches it and the renewal date.
3. Tier the vendors. A simple four tier scheme is enough: critical (operations stop without it, or it holds card or identity data at scale), high (significant guest data), medium (limited access) and low.
4. Inventory what you build. Generate a CycloneDX or SPDX SBOM for every repository and container image behind the booking engine, website, apps, loyalty platform and integrations, and store them where security can query them.
5. List payment page scripts. For every page that collects card data, or that hosts the iframe that does, list each script, its source, its purpose, who approved it and how its integrity is assured. This is the core of 6.4.3.
6. Map file transfer and integration platforms. List each one, which partners connect, and what data moves through it.
7. Check against CISA KEV. Compare your SBOMs and vendor product list against the KEV catalog. Anything that matches goes to the top of the list.

Days 31 to 60: control what changes

1. Set a patch clock. Write timelines by severity and exploitation, shortest for known exploited vulnerabilities in internet-facing systems. The decision table below is a template.
2. Gate your own builds. Add a CI step that fails on known exploited or critical vulnerabilities with a fix and warns on the rest. Run it report-only for two weeks first.
3. Write the exception process. Every delay needs a justification, an approver, compensating controls and an expiry date.
4. Send requests to critical vendors. Use the questionnaire template below, including an SBOM to the CISA 2026 minimum elements and the PCI DSS responsibility information that 12.9.2 obliges them to support.
5. Deploy payment page change detection that alerts on unauthorized changes to headers and content as the browser receives them (11.6.1).
6. Agree property responsibilities. For each on-property system, confirm in writing whether the vendor, a managed service provider or property IT applies patches.

Decision table: patch timing template

Adjust the timelines to your own targeted risk analysis under PCI DSS 12.3.1, and write the reasoning down.

Template: questions for critical software vendors

• Can you provide an SBOM for the product version we run, in SPDX or CycloneDX, meeting the CISA 2026 minimum elements? How often will you update it?
• How and how quickly will you notify us of a vulnerability in your product or its components that is in the CISA KEV catalog?
• What are your target remediation times by severity, and how do you report progress?
• Which PCI DSS requirements do you manage for us, which do we manage, and which are shared?
• Which of your own suppliers, including file transfer and hosting providers, process our guest data?
• How do you align your development practices to NIST SP 800-218?
• If your hosted platform has an incident, what are your restore objectives, and what manual fallback do you support?

Days 61 to 90: prove it works

1. Run the gate for real. Switch the CI gate from report-only to blocking for KEV-listed and critical reachable vulnerabilities with a fix.
2. Measure. Track open KEV findings, median time to fix by tier, exceptions past expiry, and vendors with a current SBOM. Keep the metric set small.
3. Rehearse a supplier incident. Run a tabletop where a critical vendor is the source. Test who calls whom, which manual processes start, and who makes the disclosure call.
4. Package the evidence. Put the inventory, patch standard, gate results, exception register, vendor responses and script records in a folder mapped to PCI DSS requirements.
5. Brief the board. One page: critical suppliers, open KEV exposure, trend, and the decisions you need.
6. Plan the next quarter. Extend the inventory to the next tier of vendors and the next set of brands or properties.

Illustrative scenario: a file transfer zero day on a Friday

This is an illustrative scenario with invented, round numbers. On a Friday afternoon a file transfer product is added to the KEV catalog. With the 30 day work done, the vendor register shows two instances: one run by the brand's operations team with 3 data flows, and one run by a payroll partner with 1. The internal instance goes offline and its 3 flows move to a fallback path; the partner is asked for status within hours, and its flow gets a documented exception with an expiry. Without the register, the same Friday goes on finding out whether the product is in use at all.

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 without a new build.

If a cloud service may not clone your 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

For a server without a terminal UI, the docs show:

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

Safeguard also offers 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.

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 row of the patch timing table. SAST (GA) covers your own booking engine and integration code, DAST (GA) tests targets you have verified, such as a staging booking site, and license compliance (GA) flags obligations in the components you ship.

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: Block for KEV-listed or critical vulnerabilities with a fix in internet-facing 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 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. Policy outcomes are switched on per workspace, so confirm yours first.

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 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, singly or in bulk. 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 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), with CSV bulk import for 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, sends a template setting SPDX or CycloneDX format, required fields and a deadline. Status moves from Sent to Validated or Rejected, with automated reminders around the deadline.
3. An arriving SBOM is validated for format and completeness and scanned for vulnerabilities; Request Revision returns one that falls short.
4. Monitoring alerts on new critical vulnerabilities and CISA KEV additions affecting a vendor's SBOM, and re-assessment can trigger on contract renewals and security incidents. Reports export as PDF or Excel.

The docs suggest quarterly SBOM updates for critical vendors and annual for high-risk ones, matching the 30 day tiering.

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. Tests run on schedule or with Run now on Compliance › Tests, once the Safeguard team switches automated tests on for your workspace. 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 as CSV, JSON or PDF for the evidence folder.

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

PMS, POS, booking engine and Wi-Fi vendors answer brand security questionnaires every week. Trust Center (GA) publishes a public 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.

What Safeguard does not do

• It does not patch vendor software you run. A PMS, POS, lock system or file transfer fix comes from that vendor. Safeguard can show the exposure through vendor SBOMs; your team or provider applies the patch.
• It does not replace payment page script monitoring. Requirements 6.4.3 and 11.6.1 need a mechanism that watches what the guest's browser receives. Safeguard's docs describe no such browser-side monitoring, so plan a separate control.
• It does not see inside vendor SaaS without the vendor's help. If a booking or contact centre vendor will not provide an SBOM, Safeguard cannot invent 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 card brands decide. Safeguard's docs say a passing test is evidence toward a control, not proof.
• It does not make disclosure decisions. Materiality under the SEC rules, state breach notices and regulator contact belong to your counsel and executives.
• It does not run property operations. Manual fallback for check-in, keys and payments during a supplier outage is an operations plan.

Common mistakes

1. Treating SAQ A as the end of the payment page question. The January 2025 change moved how SAQ A merchants report, not what the standard requires. You still need to confirm the eligibility criterion about script attacks.
2. Counting only the software you build. In this industry the vendor estate is larger and often more exposed. A program that inventories only the booking engine misses the PMS, POS, file transfer and contact centre platforms.
3. Assuming a compliant vendor makes you compliant. PCI DSS 12.8 says it does not. Get the responsibility matrix in writing.
4. Letting franchise structures blur ownership. If the brand, owner and manager each think another party patches the on-property server, nobody does. Write it down per system.
5. Asking for SBOMs without saying what good looks like. Point vendors to the CISA 2026 minimum elements and a format, or you will receive spreadsheets that cannot be scanned.
6. Blocking every release on day one. Start in report-only mode, then block only KEV and critical reachable findings.
7. Forgetting peak season. Agree in advance how an emergency patch gets through a holiday change freeze, and rehearse manual fallback for a supplier outage before you need it.

FAQ

What is software supply chain security for hotels?

It is the work of knowing which components and vendors make up the software a hotel group runs, keeping known exploited vulnerabilities on a patch clock, and keeping evidence of both. For hotels it covers the booking engine and apps you build and the PMS, POS, locks, Wi-Fi and file transfer systems you buy.

Does PCI DSS v4.0.1 require an SBOM?

Not by name in the requirements cited here. Requirement 6.3.2 asks for an inventory of bespoke and custom software, and an SBOM is a practical way to keep it at component level. Ask your QSA how they want it evidenced.

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

On 31 March 2025. According to PCI SSC, 51 of the 64 new requirements in v4.x were future-dated to that day, including 6.3.2, 6.4.3, 11.6.1 and 12.3.1.

Do hotels using a hosted booking engine still need to manage payment page scripts?

It depends on the page design and the questionnaire your acquirer accepts. Since the January 2025 update, SAQ A merchants no longer report against 6.4.3 and 11.6.1 but must confirm their site is not susceptible to script attacks. The requirements remain in the standard.

What did the FTC require of Marriott and Starwood?

The final order of 20 December 2024 requires a comprehensive information security program, a policy to keep personal information only as long as reasonably necessary, and a website link for US customers to request deletion of personal information tied to their email address or loyalty account number.

How should a travel company respond when a vendor has a zero day?

Find every instance of the product in your vendor register, including partners that run it for you, and the data flowing through each. Isolate or switch to a fallback where you can, ask the vendor for status, document an exception for the rest, and bring counsel in early if personal data may be involved.

Which vendors should we ask for an SBOM first?

Start with critical tier vendors: those whose failure stops operations, and those that hold card, identity document or loyalty data at scale. In hospitality that usually means the PMS, CRS, booking engine provider, payment integration, POS and file transfer platforms.

Does the California cybersecurity audit rule apply to hotels?

It applies to businesses that meet the CCPA thresholds and the audit criteria in the CPPA regulations, which took effect on 1 January 2026. Certification dates run from 1 April 2028 for businesses with revenue over 100 million dollars to 1 April 2030 for smaller ones. Ask counsel whether your company is in scope.

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

Yes. Per Safeguard's docs, the local runner built into the CLI runs scans on your own machine and uploads only the SBOM and findings, never source code. On-prem and air-gapped deployments are also available.

The incidents above involved software the affected brands did not write, but for the open source components inside the booking engines, apps and integrations you do build, the gap between a published fix and a deployed fix is yours to close. The section below explains how Safeguard helps close that gap, and what to do when no upstream 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 booking engine or loyalty app 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: the route for teams that will not give a cloud service repository access.

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 a regional IT lead who covers several properties.

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, payment page scripts for small merchants on SaaS, PCI DSS 4 requirement 6, securing the point of sale software supply chain and third-party risk management for retail and logistics software.

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
• FTC: final order with Marriott and Starwood (20 December 2024)
• SEC: SEC adopts rules on cybersecurity risk management and incident disclosure (26 July 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
• RTX Corporation Form 8-K dated 24 September 2025 (SEC EDGAR)
• RTX news: MUSE system update (24 September 2025)
• The Hertz Corporation notice of data breach filed with the California Attorney General (April 2025)
• CISA: CISA adds one known exploited vulnerability to catalog (13 December 2024)
• 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.