What PCI Secure Software v2.0 Asks of Your Open Source Components
PCI Secure Software Standard v2.0 came out on 15 January 2026. Here is the component and SBOM evidence a payment software vendor should have ready.
Deep dives, practical guides, and incident analyses from engineers who build Safeguard. No fluff, no vendor FUD — just what you need to ship secure software.
PCI Secure Software Standard v2.0 came out on 15 January 2026. Here is the component and SBOM evidence a payment software vendor should have ready.
Shipping SaaS on-prem makes you a distributor: review licenses in what ships, add notices, attach an SBOM per release and gate the artifact you hand over.
Inventory every in-house app, fix exploited flaws first on set clocks, gate patient-facing releases, and keep code inside the network where policy says so.
Write down the support promise, keep an SBOM per supported version, fix by exploitation and reachability, take safe upgrades and publish VEX for the rest.
Answer the same five questions per finding from primary data in a fixed order, record each answer once per component, and automate lookups, not decisions.
Have the target run the scan on its own machine and share only the SBOM, license and vulnerability results through a clean team, never the source code.
Fixed vulnerabilities return through lockfile churn, duplicate copies, reverts and stale images. Trace the path, block the bad range, scan every push.
Run a quick dependency scan on every pull request, a full transitive scan before release, and scheduled rescans after it, each with its own time budget.
Give the agency signed SLSA build provenance in in-toto format, a matching SBOM and exact verify commands, so it can check origin without trusting you.
Weekly insights on software supply chain security, delivered to your inbox.
Your first fix PR is minutes away.
No sales call required, even your agent can complete the purchase over MCP.