Achieving PCI Compliance with Sonatype
Understand PCI DSS 4.0 standards, enhance software supply chain security, and ensure data privacy with Sonatype.
Safeguarding payment card data is of paramount importance in today's digital landscape. The PCI Security Standards Council, a prominent organization dedicated to enhancing the safety of electronic payments, has been steadfast in its efforts to fortify security measures. The Payment Card Industry Data Security Standard (PCI DSS) spearheads this endeavor by establishing a gold standard for entities handling cardholder data. Endorsed by major credit card companies, these standards play a pivotal role in mitigating data breach risks and ensuring a secure payment ecosystem. As the industry transitions to PCI DSS version 4.0, organizations are presented with new compliance challenges and obligations that must be met by March 2024. This underscores the urgency for prompt adherence and the implementation of robust security protocols.
At Sonatype, we have a deep understanding of the complexities of achieving and maintaining PCI compliance. Our software supply chain optimization technology is tailored to address crucial aspects of the PCI DSS, particularly in the domains of malware prevention and detection (section 5.2), identification and remediation of security vulnerabilities (section 6.3), and the maintenance of an accurate software component inventory (section 6.3.2.b), commonly known as a software bill of materials.
Focusing on Security and Transparency
Section 6.3 of the PCI DSS mandates the identification and timely remediation of security vulnerabilities within systems and applications that process payment data. Sonatype’s tools seamlessly integrate into your development and deployment processes, ensuring that vulnerabilities are promptly detected and addressed, reducing the risk of exploitable weaknesses within your systems.
Moreover, compliance with section 6.3.2.b requires organizations to maintain a comprehensive software bill of materials (SBOM). This not only aids in vulnerability management but also enhances transparency and control over the software components and their origins. Sonatype excels in this area by providing detailed tracking and reporting capabilities and continuous monitoring, enabling organizations to maintain an accurate and comprehensive SBOM facilitating easier compliance with PCI standards.
Ensuring Compliance Ahead of the Deadline
With the deadline for implementing the new PCI DSS 4.0 standards looming, Sonatype is committed to assisting your organization in navigating these changes smoothly and efficiently. Sonatype is available as a partner to guide you through the complexities of PCI compliance, ensuring that your organization not only meets but exceeds the industry standards for data security and privacy.
| PCI DSS Requirements v4.0 | Sonatype Response |
| Sonatype helps comply with Requirement 5,6 | |
| Requirement 1: Install and Maintain Network Security Controls | |
| 1.1 Processes and mechanisms for installing and maintaining network security controls are defined and understood. | |
| 1.1.1 All security policies and operational procedures that are identified in Requirement 1 are: • Documented. • Kept up to date. • In use. • Known to all affected parties. |
The Policy Engine in the Sonatype Platform can help you create, disseminate and automatically enforce open source security policy |
| 1.1.2 Roles and responsibilities for performing activities in Requirement 1 are documented, assigned, and understood. | The Sonatype Platform can help enforce mentioned roles and Responsibilities through a comprehensive RBAC system |
| Requirement 5: Protect All Systems and Networks from Malicious Software | |
| 5.2 Malicious software (malware) is prevented, or detected and addressed. | |
| 5.2.2 The deployed anti-malware solution(s): • Detects all known types of malware. • Removes, blocks, or contains all known types of malware. |
The Sonatype Repository firewall is able to prevent malware from entering via the software supply chain. Malicious attacks have been on an increase, and defending software developed besope and custom from malware is an increasing priority. This is a separate concern compared to Requirement 6 - and can be fulfilled via Sonatype |
| 5.3 Anti-malware mechanisms and processes are active, maintained, and monitored. | |
| 5.3.1 The anti-malware solution(s) is kept current via automatic updates. | Yes, The Sonatype Platform gets frequent updates to the code base and constant updates OTA to the knowledge base |
| 5.3.2 The anti-malware solution(s): • Performs periodic scans and active or real-time scans OR • Performs continuous behavioral analysis of systems or processes. |
Yes, the Sonatype Repository firewall performs continuous analsis of open source being published and is able to identify malicious packages on average in an hour from being published. Using a proprietary ranking system we are able to prevent developers gaining access to them unless known to be safe |
| 5.3.2.1 If periodic malware scans are performed to meet Requirement 5.3.2, the frequency of scans is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1. Applicability Notes This requirement applies to entities conducting periodic malware scans to meet Requirement 5.3.2. This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. |
Supply chain malware risk is evaluated on a continuous basis automatically. As new malicious components are identified they are made immediately available for ongoing scans, and existing SBOMS and software evaluations are continuously monitored for new violations. |
| 5.3.4 Audit logs for the anti-malware solution(s) are enabled and retained in accordance with Requirement 10.5.1. | Yes, The Sonatype Platform generates an audit log which can be stored using standard procedures and mined for information such as what policy was violated, who initiated the scan, affected SBOM etc. |
| 5.3.5 Anti-malware mechanisms cannot be disabled or altered by users, unless specifically documented, and authorized by management on a case-by-case basis for a limited time period. Applicability Notes Anti-malware solutions may be temporarily disabled only if there is a legitimate technical need, as authorized by management on a case-by-case basis. If anti-malware protection needs to be disabled for a specific purpose, it must be formally authorized. Additional security measures may also need to be implemented for the period during which anti-malware protection is not active. |
Yes, the Sonatype platform contains complete Role based access control, allowing restricting access. End users can request waivers which are timeboxed, which can only be granted by users with sufficient privileges |
| Requirement 6: Develop and Maintain Secure Systems and Software | |
| 6.2 Bespoke and custom software is developed securely. | |
| 6.2.1 Bespoke and custom software are developed securely, as follows: • Based on industry standards and/or best practices for secure development. • In accordance with PCI DSS (for example, secure authentication and logging). • Incorporating consideration of information security issues during each stage of the software development lifecycle. Applicability Notes This applies to all software developed for or by the entity for the entity’s own use. This includes both bespoke and custom software. This does not apply to third-party software. |
Yes, The Sonatype Platform allows complete coverage of secure software development as it pertains to the Software Supply Chain and 3rd party components integrated into the software. Sonatype are the leading supplier of solutions that help manage and mitigate security risk in the entire software supply chain. This is in accordance to industry standards such as ISO27001 and The SSDF Standard |
| 6.2.2 Software development personnel working on bespoke and custom software are trained at least once every 12 months as follows: • On software security relevant to their job function and development languages. • Including secure software design and secure coding techniques. • Including, if security testing tools are used, how to use the tools for detecting vulnerabilities in software. Applicability Notes: This requirement for code reviews applies to all bespoke and custom software (both internal and public facing), as part of the system development lifecycle. Public-facing web applications are also subject to additional controls, to address ongoing threats and vulnerabilities after implementation, as defined at PCI DSS Requirement 6.4. Code reviews may be performed using either manual or automated processes, or a combination of both. |
Yes, the Sonatype Platform Subscription comes with training and courses which can be used to fulfill this requirement. The product itself sends proactive code change suggestions to developers via pull requests and ide plugins ensuring continuous enablement of developers. |
| 6.2.3 Bespoke and custom software is reviewed prior to being released into production or to customers, to identify and correct potential coding vulnerabilities, as follows: • Code reviews ensure code is developed according to secure coding guidelines. • Code reviews look for both existing and emerging software vulnerabilities. • Appropriate corrections are implemented prior to release. |
The Sonatype Platform can automate code reviews for 3rd party components including open source, inner source, and unknown components. We are able to provide automatic code reviews and immediate feedback and remediation suggestions to each components issues directly in the development workflow, i.e. using automated pull requests, code suggestions or other alerting. Sonatype are one of the leading authorities producing vulnerability remediation guidance, which can be reviewed and prioritised based on risk, usage and direct/transitive risk |
| 6.2.3.1 If manual code reviews are performed for bespoke and custom software prior to release to production, code changes are: • Reviewed by individuals other than the originating code author, and who are knowledgeable about code-review techniques and secure coding practices. • Reviewed and approved by management prior to release. Applicability Notes Manual code reviews can be conducted by knowledgeable internal personnel or knowledgeable third-party personnel. An individual that has been formally granted accountability for release control and who is neither the original code author nor the code reviewer fulfills the criteria of being management. |
Yes, the Sonatype Platform workflow will enable this |
| 6.2.4 Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities for bespoke and custom software, including but not limited to the following: • Injection attacks, including SQL, LDAP, XPath, or other command, parameter, object, fault, or injection-type flaws. • Attacks on data and data structures, including attempts to manipulate buffers, pointers, input data, or shared data. • Attacks on cryptography usage, including attempts to exploit weak, insecure, or inappropriate cryptographic implementations, algorithms, cipher suites, or modes of operation. • Attacks on business logic, including attempts to abuse or bypass application features and functionalities through the manipulation of APIs, communication protocols and channels, client-side functionality, or other system/application functions and resources. This includes cross-site scripting (XSS) and cross-site request forgery (CSRF). • Attacks on access control mechanisms, including attempts to bypass or abuse identification, authentication, or authorization mechanisms, or attempts to exploit weaknesses in the implementation of such mechanisms. • Attacks via any “high-risk” vulnerabilities identified in the vulnerability identification process, as defined in Requirement 6.3.1. Applicability Notes This applies to all software developed for or by the entity for the entity’s own use. This includes both bespoke and custom software. This does not apply to third-party software. |
Sonatype is able to provide this information for 3rd party components and help mitigate attacks on any built into the software being developed leveragin the software supply chain via early detection and removal of any known vulnerabiltiies, known exploited vulnerabilities etc. |
| 6.3 Security vulnerabilities are identified and addressed. | |
| 6.3.1 Security vulnerabilities are identified and managed as follows: • New security vulnerabilities are identified using industry-recognized sources for security vulnerability information, including alerts from international and national computer emergency response teams (CERTs). • Vulnerabilities are assigned a risk ranking based on industry best practices and consideration of potential impact. • Risk rankings, at a minimum, identify all vulnerabilities considered to be a high-risk or critical to the environment. • Vulnerabilities for bespoke and custom, and third-party software (for example operating systems and databases) are covered. Applicability Notes This requirement is not achieved by, nor is it the same as, vulnerability scans performed for Requirements 11.3.1 and 11.3.2. This requirement is for a process to actively monitor industry sources for vulnerability information and for the entity to determine the risk ranking to be associated with each vulnerability. |
Sonatype is the industry leading source for known security vulnerabilities in 3rd party components, with over 70x more vulnerability coverage due to Sonatype's proprietary intelligence database. Vulnerabilities are assigned severity and a risk ranking based on the built-in policies shipping inside the Sonatype platform. Each vulnerability is ranked Low, Medium, High and Critical and actions can be automatically taken for each. The Sonatype knowledge base includes vulnerabilities for bespoke, custom and open source components including operating system packages and databases. Sonatype is validated by Forrester to be industry leading in this regard. |
| 6.3.2 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. Applicability Notes This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. |
The Sonatype Platform is able to accomodate both the creation and consumption of bespoke custom, third party software and components inventories by creating or consuming standardised Software Bill of Materials documents on a per application basis. This information is automatically stored in the platform and can be used as a basis for patching, vulnerability management, automated remediation via the DevSecOps toolkit, or other means. Additionally, new SBOM Manager functionality allows customers to extend this feature to SBOMS supplied to COTS software. |
| 6.3.3 All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows: • Critical or high-security patches/updates (identified according to the risk ranking process at Requirement 6.3.1) are installed within one month of release. • All other applicable security patches/updates are installed within an appropriate time frame as determined by the entity (for example, within three months of release). |
The Sonatype platform can facilitate this due to the mixture of contextual policy, targeted automated recommendations, vulnerability intelligence and patch recommendations for vulnerabilities served. Each vulnerability can be automatically patched with recommendations or waived for a given time frame, in support of the policy determined by the entity |
| 6.4 Public-facing web applications are protected against attacks. | |
| 6.4.1 For public-facing web applications, new threats and vulnerabilities are addressed on an ongoing basis and these applications are protected against known attacks as follows: • Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods as follows: • At least once every 12 months and after significant changes. • By an entity that specializes in application security. • Including, at a minimum, all common software attacks in Requirement 6.2.4. • All vulnerabilities are ranked in accordance with requirement 6.3.1. • All vulnerabilities are corrected. • The application is re-evaluated after the corrections OR • Installing an automated technical solution(s) that continually detects and prevents web-based attacks as follows: • Installed in front of public-facing web applications to detect and prevent web-based attacks. • Actively running and up to date as applicable. • Generating audit logs. • Configured to either block web-based attacks or generate an alert that is immediately investigated. Applicability Notes This assessment is not the same as the vulnerability scans performed for Requirement 11.3.1 and 11.3.2. This requirement will be superseded by Requirement 6.4.2 after 31 March 2025 when Requirement 6.4.2 becomes effective. |
The sonatype platform is able to facilitate this via automated and continuous monitoring of web-facing applications and their generated SBOMS for any new vulnerabilities on a continuous basis every 24hr. This process is automatic and does not require additional software to be installed on the servers. Each Vulnerability is ranked as according to 6.3.1 and remediation is automatically prioritised or proposed based on available issues. Once a correction is put into production, a new SBOM will be generated automatically to carry mitigation or remediation information. |
| 6.4.3 All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows: • A method is implemented to confirm that each script is authorized. • A method is implemented to assure the integrity of each script. • An inventory of all scripts is maintained with written justification as to why each is necessary. Applicability Notes This requirement applies to all scripts loaded from the entity’s environment and scripts loaded from third and fourth parties. This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. |
The Sonatype Platform is able to produce an inventory of all scripts in a standard SBOM Format |