GitLab can help you with your PCI compliance
Compliance with the Payment Card Industry (PCI) Data Security Standard (DSS) helps to alleviate security vulnerabilities and protect cardholder data. The PCI DSS regulations are required of any enterprise handling credit card data.
Application security is a critical element for the enterprise wishing to be PCI-compliant. Application attacks compromise the logic flow and data handling from within the application, affording access to sensitive data and more. Identifying and removing vulnerabilities during development and testing is the most effective way to reduce these risks. With traditional application security solutions, the security scans find the vulnerabilities, but the details must be communicated to development, logged in an issue tracker, prioritized and followed. These are separate workflows, with separate systems, and distinct viewpoints.
With GitLab, every new code commit is automatically scanned for security vulnerabilities and also license compliance. The developer sees results immediately, within the merge request pipeline. Many can be resolved right away without ever involving security pros. For those not easily resolved, the developer can create an issue with one click. Both dev and app sec can track remaining vulnerabilities in the Security Dashboard. In addition, because security testing is embedded in the CI/CD workflow, ALL code can be tested, not just a subset that is affordable to test or most mission critical.
Using GitLab CI/CD can help you meet PCI DSS requirements, not only by surfacing the vulnerabilities, but also by helping the developers resolve them before the code leaves their workflow. GitLab’s single application includes the following application security scanning capabilities and automatically applies them to every code commit:
-
Static Application Security Testing (SAST) which analyzes the source code of an application for common security vulnerabilities. This automated code review helps developers identify and resolve issues right away within their development workflow.
-
Dynamic Application Security Testing (DAST) which scans working web applications for common security vulnerabilities. It is essentially automated penetration testing. With GitLab, DAST uses the review app, created by GitLab CI/CD, to test earlier in the life cycle than stand-alone security tools can accomplish.
-
Container Scanning which identifies known vulnerabilities in your Docker images. If you distribute your application with Docker, there's a chance that your image (reused code) is based on other Docker images that may in turn contain some known vulnerabilities that could be exploited.
-
Dependency Scanning which identifies open source code libraries, being used by your application, with known vulnerabilities. In the same manner as container scanning, you must test all of the third party code you use.
For more information on all of the GitLab security capabilities, including License Compliance, see the DevSecOps solution.
Now let's look at how GitLab applies to the PCI regulatory requirements. The PCI DSS requirements include 6 goals that are broken down into 12 requirements. The following section details the PCI DSS requirements that the GitLab capabilities cover, as well as guidance for assessors who may be evaluating these tools for compliance. The descriptions have been edited for brevity. For complete requirements, see the PCI Security Standards website or PCI DSS Reference Guide.
| PCI Requirement | GitLab Solution | Assessor Guidance |
|---|---|---|
| 1.4.5—Do not disclose private IP addresses and routing information to unauthorized parties. | * DAST can highlight areas in applications that expose private IP addressing. * Dependency scanning and Container scanning both look for use of third party code with known vulnerabilities, which may included this use case. |
Look for this finding in the DAST section of the Security Dashboard to see if it was detected and remains present. |
| 2.2.2—Always change vendor supplied defaults and remove or disable unnecessary default accounts. | * DAST can be used to validate that web applications do not have default passwords and accounts available for use. This is most useful for commercial off-the-shelf applications. * Dependency scanning and Container scanning both look for use of third party code with known vulnerabilities, which may included this use case. |
Use DAST to scan commercial off-the-shelf applications and internally developed applications to look for default accounts. Scans should be reviewed and remediated. |
| 2.2.6—Configure system security parameters to prevent misuse. | Both SAST and DAST, along with Container and Dependency scanning can test applications to find configurations that would be deemed insecure. An example would be connections to other systems or applications that use insecure protocols. | All of the GitLab security scans can be used in support of this requirement and should be deployed as part of the CI/CD process. |
| 3.7.1—Generation of strong cryptographic keys. | SAST analyzes situations whereby cryptographic keys are generated by an application using APIs. Misuse can be detected and highlighted for a developer to address. | In the case that crypto key generation is required, SAST will help ensure that the code generating those keys uses methods that will result in strong keys. |
| 4.2—Use strong cryptography and security protocols to safeguard sensitive data during transmission. | * SAST can detect usage of insecure cryptographic algorithms and protocols in the source code. * DAST scans applications to help ensure they are using secure protocols for their communications. These tests can be especially useful for applications that rely on software controls to enforce secure protocols and encryption. * Dependency scanning and Container scanning both look for use of third party code with known vulnerabilities, which may included this use case. |
Use SAST or DAST in conjunction with encryption tools to ensure applications are not relying on insecure protocols or algorithms. Note that the absence of strong cryptography at the source-code or application layer does not conclude the absence of it for the system. Mitigation may be applied for the entire system through a hardware-based control, which encrypts / decrypts all data leaving/entering the system. |
| 6.2.1—Develop internal and external software applications securely. | * GitLab security capabilities help you develop secure applications. * The GitLab application itself also enables secure code development via features such as two-factor authentication, merge request approvals and more. See how we secure GitLab and how GitLab can help you secure your development environment. |
With the new GDPR regulations, this requirement becomes even stronger. You must produce a secure app and also be accountable for that of the vendors you engage. |
| 6.2.3—Review custom code prior to release. | * SAST should be included in the go-live process for any custom code to help ensure that vulnerabilities are caught early. This process should augment existing code-review processes to bring scale to larger deployments. * DAST checks that web application code, when introduced into its deployed environment, does not have additional runtime issues only introduced there. |
SAST and DAST can be used to support this requirement as part of a larger program for custom code review. In addition, any business logic code that is intended to implement security-like functionality should be reviewed manually by domain experts. |
| 6.2.4—Address common coding vulnerabilities in software development processes. | * SAST and DAST scans identify common application vulnerabilities in the code and the working review app. * Dependency scanning and Container scanning both look for use of third party code with known vulnerabilities, which typically include the OWASP Top 10. * Specific tests vary by the scanning tool used, which is dependent upon the application's coding language. See GitLab documentation for specifics. |
* Vulnerabilities found by GitLab security testing should be reviewed and remediated by the developer whenever possible. Unresolved items can be reviewed on the Security Dashboard and turned into issues. Removing vulnerabilities early is far more efficient than later in the lifecycle. * Vulnerabilities can be resolved directly in the application or externally through additional controls like a Intrusion Detection and Prevention. |
| 6.2.4—Insecure communications. | SAST and DAST scan the code and the review app, respectively, to find potentially insecure communications, and then provide the developer with guidance on how to address the vulnerability. | Insecure communication can happen in multiple areas of the application. DAST and SAST can highlight obvious areas. However, security teams should also perform a manual review to ensure the data they consider sensitive is communicated securely. |
| 6.2.4—Improper error handling. | * With GitLab, SAST and DAST reports in the merge request show high-risk vulnerabilities, and then provide the developer with guidance on how to address them. * The Security Dashboard also indicates vulnerabilities with the greatest risk. |
Be sure that high-risk vulnerabilities are remediated or that issues are created for subsequent remediation efforts. |
| 6.2.4—Cross-site scripting (XSS). | SAST and DAST scan the code and the review app, respectively, to find potential cross-site-scripting flaws, and then provide the developer with guidance on how to address the vulnerability. | XSS enables attackers to inject script into web pages causing them to behave in a potentially malicious way. These vulnerabilities should be removed early during CI/CD via automated security scans. |
| 6.2.4—Improper access control. | SAST and DAST scan the code and the review app, respectively, to find improper access control, and then provide the developer with guidance on how to address the vulnerability. | Access control issues include things such as directory traversal, restricted URL access, and private IP leakage. Improper access control should be identified and removed early via SAST and DAST scans. |
| 6.2.4—Cross-site request forgery (CSRF). | SAST and DAST scan the code and the review app, respectively, to find potential cross-site request forgery, and then provide the developer with guidance on how to address the vulnerability. | In CSRF, malicious commands are transmitted from a user that the website trusts. Like XSS, it causes the web application to behave in an unexpected way. CSRF should be identified and removed early in the CI/CD process via SAST and DAST scans. |
| 6.2.4—Broken authentication and session management. | SAST and DAST scan the code and the review app, respectively, to find broken authentication and session management flaws, and then provide the developer with guidance on how to address the vulnerability. | These flaws should be identified and removed in the CI/CD process via SAST and DAST scans. |
| 6.3—Establish a process to identify security vulnerabilities. | Using GitLab for CI/CD will automatically run security scans for every code commit. No other vendor can, with a single application, run SAST and DAST this early in the lifecycle and also scan container images and dependencies all within a merge request pipeline. Each scan has its own use case and applicability to this requirement. | Processes should be put in place to ensure application security tools are applied consistently. Using GitLab for CI/CD makes it easy to prove that security scans are being applied to every application and every code commit. |
| 6.3.3—Ensure that all system components and software are protected from known vulnerabilities. | DAST will identify known vulnerabilities in protocols or implementations that may exist outside the code of the custom application. For example, an application that leverages an insecure method of communication would be flagged for follow-up. Dependency scanning will identify third party code with known vulnerabilities.Container scanning will identify vulnerable Docker images. | As open source code grows exponentially and containers simplify cloud transformation, it becomes increasingly important to scan your third party code. |
| 6.4.1—For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks. | DAST can be used to scan applications for this requirement. GitLab makes it easy to comply since the scan is automatically performed for every code commit. | Ensure all identified vulnerabilities are resolved or an issue created for subsequent sprints. |
| 6.5.6—Remove development, text and/or custom application accounts, user IDs, and passwords before applications become active. | SAST and DAST will scan for poor authentication methods, such as hardcoded or weak passwords, which could end up in a production application. | SAST should be used with other processes and methods, such as manual reviews of database entries, to help ensure that test or development credentials are do not end up in deployed code. |
| 7.3—Access to system components and data is managed via an access control system(s). | SAST identifies code that may override, weaken, or be vulnerable in ways that reduces the assumed level of access control in an application. | SAST should be used to help detect software vulnerabilities that could lead to weakened access control. |
| 8.2.8—If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session. | SAST and DAST can test session timeouts in applications to determine if this requirement is met. | Application settings add an extra layer of security to your environment by ensuring that the application times out even if the terminal does not. |
| 8.3.2—Using strong cryptography, render all authentication credentials (such as passwords/ phrases) unreadable during transmission and storage on all system components. | SAST and DAST can detect the misuse of cryptographic APIs that detect poor key management and stored passwords. They can identify storing sensitive information in clear text and storing sensitive information in storage locations that do not have strong crypto. | Weak cryptographic usage can spring from misconfiguration or outdated code. SAST validates that the application uses cryptographic code properly. |
| 10.2.1.4—Invalid logical access attempts. | SAST can advise developers when invalid access attempts do not result in a logged entry. For apps that are handling logical access control internally, this check can help ensure that the app is performing according to requirements by looking for log entries on invalid logical access attempts. | Malicious users often will try multiple ways to gain access to information or functionality they are not permitted to access. Early warning detection systems require valid log entries to detect bad behavior and alert on it. Assessors can use this evidence to verify this requirement is met. |
| 10.2.2—Success or failure indication. | SAST can help ensure that success and/or failure are properly logged as part of the normal event log. Oftentimes, developers log failed attempts but miss successful ones. | Log entries by themselves must indicate success or failure to assist in early detection and for compliance validation. Assessors can use this evidence to verify this requirement is met. |
| 10.3.2—Protect audit trail files from unauthorized modifications. | SAST can detect software issues that may allow log-forging attacks to be successful, which may allow unauthorized modification to occur. | Log integrity is critical if you need to use those logs to find a breach or an insider. An attack that modifies the audit trail can cover the tracks of an attacker. |
| 11.4.2—Perform internal penetration testing at least annually and after any significant infrastructure or application upgrade or modification. | When using GitLab, every code commit is automatically tested both statically and dynamically and dependencies and containers are checked for vulnerabilities. | Internal penetration testing groups may wish to review security reports and assess any challenges in the workflow processes. |
| 11.4.3—Perform external penetration testing at least annually and after any significant infrastructure or application upgrade or modification. | When using GitLab, every code commit is automatically tested both statically and dynamically and dependencies and containers are checked for vulnerabilities. | It is possible that GitLab security capabilities could be a valid compensating control though challenges are unknown. External penetration testing may still be required. |
| 12.3.2—Implement a risk-assessment process. | While GitLab security capabilities are not risk-assessment tools per se, they can all be used in support of a risk-assessment methodology. The GitLab Security Dashboard shows risk levels of specific vulnerabilities. | Outputs of these security scans should be incorporated into the risk-assessment process used to meet this requirement. |
THE INFORMATION PROVIDED ON THIS WEBSITE IS TO BE USED FOR INFORMATIONAL PURPOSES ONLY. THE INFORMATION SHOULD NOT BE RELIED UPON OR CONSTRUED AS LEGAL OR COMPLIANCE ADVICE OR OPINIONS. THE INFORMATION IS NOT COMPREHENSIVE AND WILL NOT GUARANTEE COMPLIANCE WITH ANY REGULATION OR INDUSTRY STANDARD. YOU MUST NOT RELY ON THE INFORMATION FOUND ON THIS WEBSITE AS AN ALTERNATIVE TO SEEKING PROFESSIONAL ADVICE FROM YOUR ATTORNEY AND/OR COMPLIANCE PROFESSIONAL.
Take GitLab for a spin
See what your team can do with a single platform for software delivery.
Get free trial