What PCI Secure Software v2.0 Asks of Your Open Source Components

The PCI Secure Software Standard v2.0, published by the PCI Security Standards Council on 15 January 2026, expects a payment software vendor to know exactly what is inside each release: every third-party and open source component, its version, where it came from and whether it carries a known vulnerability. The practical answer is a bill of materials generated for every release, a monitoring process that catches new vulnerabilities in those components, a documented way to get fixes to the merchants running your software, and integrity data that proves the delivered build is the one you assessed. The exact requirement wording sits in the licensed standard, so read it there; this post shows how to build the evidence an assessor will sample.

Key takeaways

• Dates confirmed on the PCI SSC's own pages. Secure Software Standard v2.0 was announced on 15 January 2026, with a 12 month transition from v1.2.1 that starts once assessor training is available. The Secure Software Lifecycle (Secure SLC) Standard v2.0 followed on 28 September 2026.
• The two standards are separate. The Secure Software Standard looks at the product. The Secure SLC Standard looks at the vendor's lifecycle process. Neither requires an assessment to the other.
• Component evidence has to be per release. A one-off inventory built for the assessment will not survive the first patch release. Generate the bill of materials in the build, keep it with the release, and keep it current.
• Monitoring is a continuous duty, not a scan on assessment day. Track new vulnerabilities in shipped components, rank them, and show how a fix reaches merchants.
• Your merchants have their own clock. PCI DSS requirement 6.3.3 gives them one month from release to resolve critical vulnerabilities, so your fix and notice process feeds their compliance.
• Safeguard capabilities covered, with maturity labels: SBOM generation and analysis (GA); SCA and vulnerability management with EPSS and KEV (GA); reachability analysis (GA); policies and gates (GA, policy outcomes switched on per workspace); attestation and signing (GA); CSAF and VEX upload (GA); Portal, the SBOM publish and share product (GA); compliance and GRC suite (GA); license compliance (GA); CLI and local runner (GA); autonomous remediation (GA, ships switched off with every category set to Manual); Trust Center (GA); SAST (GA); fork and patch (GA).
• Safeguard is not a Secure Software Assessor. It does not validate, list or certify software, and it holds no PCI status of its own.

A note on what we could read

The PCI SSC publishes its standards in its Document Library behind a licence agreement, and direct requests for the Secure Software Standard v2.0 and PCI DSS v4.0.1 PDFs returned an access error to us on 25 October 2026. So this post states only what the Council's public pages and FAQs say about v2.0 (dates, documents, scope changes, transition) and does not quote v2.0 requirement or objective numbers. Commentary elsewhere says v2.0 makes a bill of materials mandatory under a core objective on software composition; treat that as a lead and confirm it in your licensed copy.

The evidence pack itself is built from public primary sources: NIST SP 800-218, CISA's 2026 Minimum Elements for an SBOM, the CycloneDX and SPDX specifications, SLSA, FIRST's EPSS, CISA's KEV catalog and OASIS CSAF. Your Secure Software Assessor works from the licensed standard; use it to decide what "done" means. None of this is compliance advice.

What the PCI Software Security Framework is today

The PCI Software Security Framework is, in the Council's own FAQ words, "a collection of related software security standards" with their own validation and listing programs. It replaced the old PA-DSS program for payment applications. Two standards sit inside it.

The Secure Software Standard

The Council's standard page says the Secure Software Standard gives security requirements for vendors so that payment software is designed and managed securely, protecting the integrity of payment transactions and the confidentiality of payment card data. The intended audience is vendors that build software to support or facilitate payment transactions.

The 2019 framework FAQ adds scope detail that still frames how vendors think about it. The standard is meant for payment software sold, distributed or licensed to third parties, including software installed on customer systems and software delivered as a service. It is not meant for software built in house for the developer's own use, or for software built for a single customer. Organisations building that kind of software are encouraged to follow the standard's principles anyway.

Version 2.0 is the first major revision. The Council's 15 January 2026 announcement lists what changed at a high level:

• A new companion document, the Sensitive Asset Identification document (often shortened to SAID), to help vendors identify and document the sensitive assets of their software.
• Software development kits are now eligible for assessment, including EMVCo 3DS SDKs. The Council describes v2.0 as an alternate path for 3DS SDK assessments that will eventually replace the separate PCI 3DS SDK Standard.
• Wildcards in version numbers to cover changes that do not affect security.
• A revised delta change process with a new change impact template.
• Portal access for vendors to submit annual attestations and administrative changes.

The documents released with it were the v2.0 standard, the Sensitive Asset Identification document, a Summary of Changes from v1.2.1, the Program Guide for v2.x and the PCI 3DS Data Matrix v1.2. The reporting templates (Report on Validation, Attestation of Validation and the Change Impact template) were expected in early February 2026.

The Request for Comments post of 10 July 2025 lists the revision's goals, including removing the "payment software" context, refining sensitive assets, making requirements more objective and adding an SDK module.

The Secure SLC Standard

The Secure Software Lifecycle Standard is about the vendor, not one product. The Council's 28 September 2026 post describes it as requirements and assessment procedures for vendors to build into their development lifecycles and to validate that secure lifecycle practices are in place. Version 2.0 aligns with Secure Software Standard v2.0, including the focus on sensitive assets, and adds requirements about "digital tools", which the Council says include artificial intelligence used in the vendor's lifecycle.

The same post is clear that neither standard requires an assessment to the other. Vendors with a validated Secure SLC who use it to build their products get program benefits for their listed Secure Software products. The 2019 FAQ described the main benefit at the time: qualified vendors could perform and self-attest their own delta assessments with less assessor involvement.

Dates and transition at a glance

Neither post gives a fixed end date, so confirm the date that applies to your submission with your assessor.

Who decides whether you need it

This catches many vendors out. The PCI SSC's FAQ on eligibility says whether an entity must use software validated to the Secure Software Standard is set by the payment brands, not by the Council. If a merchant, acquirer or partner tells you validation is required, the mandate comes from a brand program or a contract, and the Council points questions to the brands directly.

The validation process itself, as the framework FAQ describes it, runs like this. The vendor chooses a qualified Secure Software Assessor company from the Council's list and agrees scope and terms with it. The assessor tests the software against the standard. If the software meets all applicable requirements, the assessor writes a Report on Validation and an Attestation of Validation, which both the assessor and the vendor sign. The Council reviews the submission and, once it accepts it, adds the software to its list of validated payment software.

Which objectives cover third-party and open source components

Here we hit the licence wall. The v2.0 objective and requirement numbers are in the licensed text, and we will not guess them. What we can do is explain what the Council's public material says about the shape of v2.0 and what any reasonable reading of "document your components" requires in practice.

From the public posts:

• v2.0 is restructured around security objectives and security requirements. The RFC post mentions an informational outline of all draft v2.0 security objectives and requirements, plus a mapping from v1.2.1.
• Sensitive assets are central. The Sensitive Asset Identification document is a required companion that sets context for many requirements, with tables of example sensitive data, sensitive resources and sensitive functionality.
• Wildcard versioning is allowed for changes that do not affect security, and there is a revised delta change process with a change impact template.

Together, those sharpen the component question. If a wildcard version can cover non-security changes, someone must be confident that a change to a third-party component really is non-security impacting, and that needs a precise record of which components and versions ship in each build. The same record ties third-party code to the sensitive assets in your SAID work: a library that parses card data or handles keys is sensitive functionality, and a vulnerability in it is a security impacting change.

What "documented" should mean for each component

An assessor sampling components will ask questions only a structured record can answer. For each third-party or open source component in each release, keep:

Most fields are standard SBOM content; the last two are judgment calls only you can make.

What the SBOM needs to contain

Again, the exact SBOM clause (if v2.0 has a dedicated one) is in the licensed text. The public standards that define a good SBOM are open, and they line up well with what payment software assessors look for.

Content: start from CISA's 2026 Minimum Elements

On 29 July 2026, CISA, the NSA, the FBI and international partners published the 2026 Minimum Elements for a Software Bill of Materials. CISA's page says it updates and replaces the minimum elements the NTIA published in 2021, and that it reflects a 2025 public comment period and current SBOM tooling. CISA describes minimum elements as the baseline technologies and practices an SBOM should include, and notes that some software types, such as AI and cloud services, may need more.

For a payment software vendor, that is the most defensible baseline to point to. If you still cite the 2021 NTIA list, update your process documents; our post on which SBOM minimum elements to follow walks through the change.

Format: CycloneDX or SPDX

Two machine readable formats dominate, and both are open standards:

• CycloneDX, maintained under Ecma International's TC54, is published as the ECMA-424 standard. Its specification overview describes a modular, extensible model that covers components, services, dependencies and vulnerability data.
• SPDX, from the Linux Foundation, is an international open standard as ISO/IEC 5962:2021. The SPDX site lists 3.0 as the current version, with 2.3 still widely used.

Pick one primary format and use it for every release; inconsistency is what an assessor notices.

Scope: what the SBOM should cover

Cover what you ship, not just what is in one manifest:

• Application dependencies in every language the product uses, including transitive dependencies.
• Container base images and system packages if you deliver the software as an image or run it as a service.
• Vendored and copied code, which manifests miss. If someone copied a parsing library into your source tree three years ago, it is still a third-party component.
• SDKs you embed, and if you sell an SDK, the components inside it. v2.0 makes SDKs assessable, so an SDK vendor's own SBOM becomes part of its merchants' and integrators' evidence.

Cadence: one SBOM per release, kept with the release

NIST SP 800-218 task PS.3.2 asks producers to collect, safeguard, maintain and share provenance data for all components of each software release, and it names the SBOM as an example. Task PS.3.1 asks you to archive the files and supporting data for each release, including integrity verification information and provenance data.

That is the cadence an assessor expects to see: an SBOM generated in the build for every release, stored with the release artifacts, and retrievable later. Under v2.0's delta change and wildcard rules, it is also how you will show what changed between two versions. Diff the two SBOMs and you have the component half of a change impact analysis. Our post on producing an SBOM for every release under SSDF PS.3.2 covers the pipeline mechanics in more depth.

How to monitor components and get fixes to merchants

An SBOM that sits in a folder is an inventory, not a control. The value comes from watching it.

Monitoring: what the public frameworks say

NIST SP 800-218 task RV.1.1 asks producers to gather information from acquirers, users and public sources on potential vulnerabilities in the software and the third-party components it uses, and to investigate all credible reports. Task PW.4.4 asks you to verify that acquired commercial, open source and other third-party components comply with your requirements throughout their life cycles, with examples that include regularly checking for publicly known vulnerabilities and building automatic detection into the toolchain.

In practice, that means:

1. Re-match every shipped SBOM against vulnerability data on a schedule, not only at build time. A March release gains new CVEs by October without any code change.
2. Rank what you find. CVSS tells you how bad a flaw could be. FIRST describes EPSS as a model that estimates the probability a published CVE will be exploited in the wild in the next 30 days, published daily for every CVE. CISA describes its Known Exploited Vulnerabilities catalog as the authoritative source of vulnerabilities exploited in the wild and tells organisations to use it as an input to prioritisation. Use all three: severity for impact, EPSS for likelihood, KEV for confirmed exploitation.
3. Decide whether the vulnerable code is reachable in your product. A flaw in a function you never call is still worth fixing, but it is not the same urgency as one on your payment path.
4. Record the decision, including "not affected" decisions and why. Those records are what an assessor samples, and they are what your merchants need.

Getting fixes to merchants

Merchants running your software must also be able to act. Three pieces make this work:

• A security advisory channel that merchants actually subscribe to, with a stable format. OASIS's Common Security Advisory Framework (CSAF) 2.0 is the open standard for machine readable advisories, and its VEX profile lets you state whether a product is affected, not affected, fixed or under investigation for a given vulnerability.
• A release and versioning practice that maps to your listing. v2.0's wildcard and delta change rules exist so that you can ship routine changes without a full re-assessment. A dependency upgrade that fixes a vulnerability in a component that touches sensitive functionality is a security impacting change; plan for it in your change impact process.
• An updated SBOM with every fix release, so merchants and their assessors can confirm the vulnerable version is gone.

Why the merchant's clock matters to you

PCI DSS is the merchant's standard, not yours, but it sets the pace your customers work to. The PCI SSC's FAQ 1597 says requirement 6.3.3 sets time frames for installing security patches and updates, and that patches for critical vulnerabilities must be resolved within one month of release. Other applicable patches must be installed within time frames the entity sets from its own risk assessment, aligned with the risk rankings it assigns under requirement 6.3.1.

If you are slow to fix a critical flaw in a library your POS software ships, every merchant running it loses part of that month. Our post on the PCI DSS one month patch deadline covers the merchant side in detail.

What integrity protection the delivered software should carry

A payment software assessment assumes the software you deliver is the software that was assessed. Integrity evidence shows that.

The public frameworks are concrete here. NIST SP 800-218 task PS.2.1 asks producers to make software integrity verification information available to acquirers, with examples such as posting cryptographic hashes for release files and signing code through an established certificate authority. Task PS.3.1 asks you to archive integrity verification information and provenance data for each release.

The SLSA framework gives a vocabulary for build integrity. Its build track runs from L0 (no guarantees) through L1 (provenance exists) and L2 (a hosted build platform) to L3 (hardened builds). The levels page we read is for SLSA 1.0, which the site now marks as retired in favour of version 1.2; the build track levels are the same idea in both. Note that the current specification stops at Build L3.

For a payment software vendor, the practical integrity bundle per release is:

How v2.0 phrases its integrity requirements is in the licensed text; the bundle above is what NIST and SLSA describe.

How this relates to the merchant's PCI DSS duties

Vendors often blur these two worlds. Keep them apart.

The Software Security Framework FAQ answers this directly. Using software validated under the framework may support the security of an entity's cardholder data environment, but it does not make the entity PCI DSS compliant. Entities must still implement the software in a compliant way and include it in their own PCI DSS assessments. The FAQ also says validation under the framework does not imply validation to any other PCI standard.

For your merchants, two PCI DSS v4.0.1 requirements touch your components most:

• Requirement 6.3.2, which Safeguard's own PCI DSS framework page describes as a maintained inventory of the third-party components incorporated in bespoke and custom software. We could not read the licensed PCI DSS text to confirm the wording, so check it in your copy. Your merchants who customise or extend your software will want your SBOM as part of their inventory.
• Requirement 6.3.3, the one month clock for critical patches described in the Council's FAQ 1597.

Your SBOM and advisories are therefore inputs your merchants and their assessors will ask for, not just validation evidence. If your customers include banks and fintechs, our post on what a sponsor bank needs from a fintech on open source risk shows how the same evidence travels further up the chain.

A method you can run with your own tools

Everything above can be built with open source tooling and discipline:

1. Define the release unit (a tagged build, a container digest, an installer). Every artifact below hangs off it.
2. Generate the SBOM in the build, from the same lockfiles and images that produce the release, including transitive dependencies and image layers.
3. Validate the SBOM as CycloneDX or SPDX with the 2026 Minimum Elements fields. A malformed SBOM looks like evidence and is not.
4. Match and rank against CVE and advisory data with EPSS and KEV, recording a decision for each finding above your threshold.
5. Gate the release on what you have promised not to ship, with exceptions only through a recorded approval that expires.
6. Attest, sign and archive the SBOM, scan results, gate result, exceptions and provenance with the release, for as long as it is supported.
7. Re-scan shipped releases on a schedule, and publish advisories, VEX and a fixed release with a new SBOM when something lands.
8. Rehearse the assessor's sample. Pick a release at random and produce its full bundle within an hour. If you cannot, fix the archive first.

How Safeguard does this job

Safeguard covers the component half of this method: generating, analysing, gating, attesting and sharing the evidence per release. It does not cover secure design, code review or the assessor's own testing, and it is not a Secure Software Assessor. Everything below comes from Safeguard's documentation as of the review date.

Step by step

1. Connect the product's sources (SBOM generation and analysis, GA). In the Safeguard app, open Integrations and use Add Project/Product to connect a GitHub, GitLab or Bitbucket repository, a generic Git URL, or a container registry. When you add a repository you set the project name, branch or tag and version for each one. For a payment product, map one Safeguard project to each shippable component and use the version field to mirror your release numbers.

2. Generate an SBOM per release. The generate SBOM page lists the options: project name, version (auto-detected from git tags), branch or tag, whether to include development dependencies, and Deep Analysis. Turn on the On Release trigger so a scan runs when a new tag is created; the docs also list On Push and Scheduled triggers. Safeguard produces SPDX (JSON, XML, RDF) and CycloneDX (JSON, XML) output.

3. Or generate it from the CLI in your build (CLI, GA). The docs show the install and scan:

   # Install the CLI
   curl -fsSL https://cli.safeguard.sh/install | bash
   
   # Scan from the command line, writing results under ./output
   safeguard scan --dir .
   

   A scan from the interactive terminal while signed in uploads the SBOM and findings to the platform; the docs say your source never leaves the machine. The CLI also validates CycloneDX, SPDX and VEX documents with safeguard validate, which is a useful check before an SBOM goes into the release bundle. It takes a --scan-mode flag (fast, deep or progressive) if you want a quicker pass on pull requests and a deeper one on release builds. The local runner (GA) executes the platform's scan jobs on your own machine and uploads SBOMs and findings, never source.

4. Match components to vulnerabilities and rank them (SCA and vulnerability management, GA; reachability analysis, GA). Safeguard's SCA resolves the full dependency graph from manifests and lockfiles across npm, PyPI, Maven and Gradle, Go, Cargo, NuGet, Composer and Bundler, plus components inside container image layers. Each finding carries the component and version, CVE or GHSA identifiers, severity with EPSS and KEV context, the transitive path from your project root, a reachability verdict where available, and the safe upgrade target. Use EPSS, KEV and reachability to filter and order findings. Check the reachability page for your stack.

5. Check licences (license compliance, GA). The same scan flags licence obligations and incompatibilities across the graph, which feeds the licence field in your component record.

6. Set release gates (policies and gates, GA). Under Settings → Policies, create policies with the visual builder or YAML. The documented conditions include vulnerability severity, CVSS score, EPSS score, licence, component age, maintenance status and SLSA level. Each policy has an Action: Block fails the gate, Warn passes it with a warning naming the policy, Notify passes it and sends a notification. Link policies to a gate, then fail CI on it:

   safeguard ci scan --wait --fail-on-gate <gate>
   

   Two caveats from the docs: policy outcomes are turned on per workspace by Safeguard, and gates are evaluated on platform scans of connected repositories, so a purely local scan may not be gated. KEV and reachability are filters on findings, not listed gate conditions.

7. Record exceptions properly. When a finding must ship, use Request Exception: select the policy and finding, give a business justification, set an expiration date and submit for approval. The docs describe notification to approvers, a decision and an audit trail. Those exception records are exactly what an assessor wants when they ask "why did this release ship with a known vulnerability?"

8. Attest the build (attestation and signing, GA). The docs show a CI step that produces in-toto v1 attestations:

   - name: Attest build
     uses: safeguard/attest@v2
     with:
       artifact: ./dist/app.tar.gz
       predicates:
         - slsa-provenance
         - sbom-cyclonedx
         - vuln-scan
   

   The docs list five predicate types: SLSA Provenance v1, CycloneDX SBOM, SPDX SBOM, a vulnerability scan snapshot and a Griffin-generated Safeguard Review. Each attestation carries the artifact's SHA-256 digest, so any change to the artifact invalidates it. Attestations are signed with Safeguard's own key held in a cloud key management service and are not written to a public transparency log; you verify them with cosign against Safeguard's published public key. There is no CLI command for signing or verifying attestations and no public attestation API yet; attestation records show on the Attestation tab for projects, products and components in the app. For files, the docs show verification of a detached signature:

   KEY=cosign.pub   # Safeguard's published public key, saved from the URL in the attestation docs
   cosign verify-blob --key "$KEY" --insecure-ignore-tlog --signature <file>.sig <file>
   

9. Keep watching shipped releases. The generate SBOM docs describe continuous scanning of your projects to catch newly disclosed vulnerabilities, plus scheduled scans on the cadence you set, and you can rescan a project manually. That gives you the re-match step for every supported release, as long as each supported release stays a project or version in Safeguard.

10. Bring in advisories and VEX (CSAF and VEX upload, GA). Under Integrations → File Uploads, Upload CSAF/VEX takes CSAF or VEX files for analysis. Use it to load your own VEX statements, and supplier advisories for commercial components you embed, so "not affected" decisions sit next to the findings they explain.

11. Share the evidence with merchants and assessors (Portal, the SBOM publish and share product, GA). Portal publishing creates an immutable copy of an SBOM, and sharing distributes that copy as is. From Portal you can share directly with named recipients at View, Download or Full permission, or create a link with an expiration date, download limit, password protection and format restrictions. You can require NDA acceptance per SBOM, restrict sharing to approved domains, see who accessed what and revoke access immediately. For a customer base of merchants, Settings → Customer Portal lets you set up a branded portal, assign SBOMs to publish and invite customers to register. Portal exports SPDX and CycloneDX as well as spreadsheet and document formats.

12. Track the merchant-side mapping (compliance and GRC suite, GA). If you also run PCI DSS for a hosted service, Safeguard's PCI DSS 4.0 framework lists scan-decided checks such as a maintained component inventory (6.3.2) and patch applicability data (6.3.3). It covers PCI DSS, not the Secure Software Standard.

Requirement area, what Safeguard does, what you still own

Which evidence still comes from the vendor's process

Sensitive asset identification. The Sensitive Asset Identification document is a judgment exercise. A scanner can tell you that a library is present; it cannot tell you that the library sits on your PIN entry path. You and your architects own that mapping.

Secure design. Threat models, architecture decisions about where sensitive data lives, how it is encrypted and how sensitive functions are authenticated come from your engineering process. v2.0's tighter focus on sensitive assets makes this more important, not less.

Code review and testing of your own code. Your bespoke code is where most of the security logic in a payment product lives. SCA does not review it. Safeguard's SAST is generally available, so do not plan your assessment evidence around it.

The assessor's testing. The Secure Software Assessor tests the software. Your evidence makes their job faster; it does not replace it.

Lifecycle evidence. If you pursue a validated Secure SLC, its evidence (training, roles, change management, how your teams use digital tools including AI) comes from your organisation. Our post on the PCI Secure SLC Standard v2.0 for software vendors covers that side.

What Safeguard does not do

• It is not a PCI Secure Software Assessor and does not validate, list or certify software. Only qualified assessor companies assess, and only the PCI SSC lists. Safeguard holds no PCI status, has no PCI Attestation of Compliance of its own, and nothing it produces is a Report on Validation or an Attestation of Validation.
• It does not interpret the licensed standard for you. Safeguard's compliance suite includes a PCI DSS 4.0 framework, not a Secure Software Standard v2.0 framework. Mapping your evidence to v2.0 objectives is your job and your assessor's.
• It does not produce secure design, threat modelling or code review evidence. Component and pipeline checks are what it covers. SAST is GA but should not be presented to an assessor as coverage of code-level requirements.
• It does not sign your software with your key. Safeguard's attestations are signed with Safeguard's key and verified against Safeguard's published public key, without a public transparency log. Your own code signing of the delivered software, and the key management behind it, stay with you. There is no CLI or public API for attestations today.
• It does not enforce gates you have not switched on. Policy outcomes are turned on per workspace by Safeguard, and gates are evaluated on platform scans of connected repositories. A local scan on a developer machine may not be gated.
• It does not see components it is not given. Vendored code copied into the tree without a manifest, binaries dropped in by hand, or a build that differs from the scanned branch will produce an incomplete SBOM. SBOM accuracy depends on build inputs.
• The Trust Center is generally available. If you plan to publish posture to merchants through a public trust page, treat that as early access; Portal sharing is the GA route for SBOMs.

Common mistakes

Building the SBOM for the assessment, not in the build. An SBOM produced the week before the assessor arrives describes one moment. The assessor will pick a release from six months ago and ask for its SBOM. Generate it in the pipeline from day one.

Treating the SBOM as the control. The inventory only matters if someone watches it. Assessors and merchants both want evidence that new vulnerabilities were found, ranked and acted on, with dates.

Forgetting transitive and vendored components. Most of the code in a typical application arrives indirectly. Copied-in libraries are invisible to manifest scanners. Both are still third-party code you ship.

Using wildcard versioning without a component diff. v2.0's wildcards are for changes that do not affect security. A dependency bump that fixes a CVE in a library on a sensitive path is security impacting. Diff SBOMs between versions before you decide.

Confusing the two PCI worlds. Your validation does not make a merchant PCI DSS compliant, and their PCI DSS assessment does not validate your software. The FAQ is explicit on both points.

Leaving merchants to discover fixes. Your merchants face a one month clock for critical patches under requirement 6.3.3. If your fix notice is a line in release notes they do not read, you are spending their compliance window.

Overclaiming in the questionnaire. "Our software is PCI compliant" is not a thing. Software is validated to the Secure Software Standard and listed by the Council, or it is not. Use the Council's language.

FAQ

Does the PCI Secure Software Standard v2.0 require an SBOM?

Commentary on v2.0 says it requires a bill of materials for the software, under a core objective on software composition. The PCI SSC's public announcement does not quote that requirement, and the standard itself is licence-walled, so confirm the wording and scope in your copy. Either way, an SBOM per release is the most practical way to show the component documentation any version of the standard expects.

When was PCI Secure Software Standard v2.0 published?

The PCI SSC announced it on 15 January 2026, together with the Sensitive Asset Identification document, a Summary of Changes from v1.2.1 and the Program Guide for v2.x. The v2.x reporting templates were expected in early February 2026.

How long is the transition from v1.2.1 to v2.0?

The Council said a 12 month transition begins once v2.0 training is available. It expected computer based training in Q1 2026 and instructor led training in Q2 2026. Check the Document Library and your assessor for the effective end date.

What is the difference between the Secure Software Standard and the Secure SLC Standard?

The Secure Software Standard assesses a software product. The Secure SLC Standard assesses the vendor's lifecycle process. The Council says neither requires an assessment to the other, though vendors with a validated Secure SLC get program benefits for their listed products. Secure SLC v2.0 was published on 28 September 2026.

Is validated software required for merchants?

Not by the PCI SSC. Its FAQ says whether an entity must use validated software is decided by the payment brands, and it points questions to them. Contracts and acquirer programs can also require it.

Does using validated payment software make a merchant PCI DSS compliant?

No. The Software Security Framework FAQ says validated software may support the security of a cardholder data environment but does not make an entity compliant. The merchant must still implement it correctly and include it in their own PCI DSS assessment.

How fast must a merchant apply a critical patch from a software vendor?

The PCI SSC's FAQ 1597 says requirement 6.3.3 requires critical vulnerabilities to be resolved within one month of the patch's release, with other patches on time frames set by the merchant's risk assessment. Your release and notice process directly affects how much of that month your merchants keep.

Can SDKs be validated under the Secure Software Standard?

Yes, from v2.0. The Council says SDKs are now eligible for assessment, including EMVCo 3DS SDKs, and that v2.0 provides an alternate path for 3DS SDK assessments that will eventually replace the separate 3DS SDK standard.

Closing the gap before your merchants' clock runs out

Monitoring components only helps if a vulnerable version can be replaced fast enough for your merchants' one month clock. The section below describes how Safeguard shortens the time from a finding in a shipped component to a fixed release.

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 Safeguard CLI session. It installs the CLI, opens the interactive terminal with safeguard, and asks it to fix the lodash CVE in a repository. The assistant reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing, then shows /permissions, /model and /scan. For a payment software team, that is the same loop you would run when a monitored component in a supported release picks up a new CVE: find it, fix it on a branch, test, and generate the new SBOM for the fixed release.

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, then scans from the terminal. Payment software build environments are often locked down, and the runner is how the platform's scan jobs run there while only the SBOM and findings leave the machine.

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

To try this on your own product, download Safeguard at safeguard.sh/download and read the setup guides at docs.safeguard.sh/docs. For related reading, see how to prove every production release passed a security gate.

Quick check

Sources

• PCI SSC: PCI SSC Releases Version 2.0 of the PCI Secure Software Standard (15 January 2026)
• PCI SSC: Request for Comments, PCI Secure Software Standard v2.0 (10 July 2025)
• PCI SSC: PCI SSC Releases Version 2.0 of the Secure Software Lifecycle Standard (28 September 2026)
• PCI SSC: Secure Software standard page
• PCI SSC: Software Security Framework FAQs (January 2019)
• PCI SSC: Technical FAQs for Secure Software Standard v1.x bulletin (May 2023)
• PCI SSC FAQ 1540: What software is eligible for validation to the PCI Secure Software Standard?
• PCI SSC FAQ 1597: Risk ranking and resolving vulnerabilities (requirement 6.3.3)
• NIST SP 800-218, Secure Software Development Framework v1.1
• NIST SP 800-218 PDF
• CISA: 2026 Minimum Elements for a Software Bill of Materials
• CISA: Software Bill of Materials
• CycloneDX: Specification overview
• SPDX: Specifications
• SLSA: Security levels (v1.0)
• FIRST: Exploit Prediction Scoring System
• CISA: Known Exploited Vulnerabilities Catalog
• OASIS: Common Security Advisory Framework v2.0
• Safeguard docs: Generate SBOM
• Safeguard docs: Software Composition Analysis
• Safeguard docs: Policies and Gates
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: Attestation and Signing
• Safeguard docs: Portal
• Safeguard docs: Portal sharing
• Safeguard docs: PCI DSS 4.0 framework
• Safeguard docs: Safeguard CLI

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