PCI Data Security Standard (PCI DSS) is the assurance under which all modern credit card transactions take place.
It is a global standard that provides a baseline of technical and operational requirements designed to protect account data. The requirements aim to safeguard the entire lifecycle of a credit card transaction, including storage, processing, transmission, and access.
The next evolution of PCI DSS is version 4.0 is based on feedback of over 200 companies. It has been few years in the making with theexplicit goals of security as continuous process, flexibility and enhancements in validation methods.
Version 3.2.1 retired on 31st March 2023, and compliance with Version 4.0 adds 64 new requirements.
13 of these requirements require immediate compliance, and the other 51 have an effective date of 31st March 2025.
While the standard does not describe an implementation mechanism, two requirements described as - Evolving Requirements - are best suited for compliance using SBOM.
An inventory of bespoke and custom software, and third-party software components incorporated into bespoke
and custom software is maintained to facilitate vulnerability and patch management.
Identifying and listing all the entity’s bespoke and custom software, and any third-party software that is incorporated into the entity’s bespoke and custom software enables the entity to manage vulnerabilities and patches. Vulnerabilities in third-party components (including libraries, APIs, etc.) embedded in an entity’s software also render those applications vulnerable to attacks. Knowing which third-party components are used in the entity’s software and monitoring the availability of security patches to address known vulnerabilities is critical to ensuring the security of the software.
Organizations can build SBOM for each library, application, or API developed in-house and require their tech vendors to provide SBOM for any library, application, or API that is part of the card processing.
This automatically builds an inventory of all components in use - whether internal or not. These SBOMs can be easily mapped to all known vulnerabilities using platforms such as Interlynk. In addition, Interlynk enables tracking exploitability and patching cadence, ensuring any organizational goal for patching can be managed from a single place.
Vulnerabilities that are either high-risk or critical (according to the entity’s
vulnerability risk rankings defined at Requirement 6.3.1) are resolved.
Identifying and addressing vulnerabilities promptly reduces the likelihood of a vulnerability being exploited and the potential compromise of a system component or cardholder data. Vulnerability scans conducted at least every three months provide this detection and identification.
Instead of waiting for the three-month scans, SBOM enables vulnerability monitoring on an ongoing basis. Platforms such as Interlynk track newly disclosed vulnerabilities and use SBOM inventory built in compliance with requirement 6.3.2 to notify when new vulnerabilities are discovered vulnerabilities against the inventories.
This makes it effortless to identify application vulnerabilities and their severity, check their exploit probabilities and status, and keep a record of their state across multiple versions of the product using VEX.
---
As PCI DSS v4.0 moves through adoption, Interlynk platform captures continuous security requirements directly from build pipelines and vendors, enriches underlying data to surface up-to-date security risks, enables collaboration between development and security teams to ensure always ready compliance and tracks comprehensive overview to keep stakeholders up to date.
As this is built entirely on SBOM, an immediate side-effect is compliance with related requirements such as the ones emerging from Cyber Resilience Act (CRA) or implementation of Executive Order 14028 (EO14028).
The countdown to PCI DSS 4.0 is on, and there are less than eight months left for compliance. Contact Interlynk to learn how we can help meeting these requirements.
