GitLab
A single application for the entire DevOps lifecycle
GitLab Professional Services
Accelerate your software lifecycle with help from GitLab experts
Popular GitLab use cases
Remote Work Continuous Integration (CI/CD) Source Code Management (SCM) Out-of-the-box Pipelines (Auto DevOps) Security (DevSecOps) Agile Development Value Stream Management
GitLab
A single application for the entire DevOps lifecycle
GitLab Professional Services
Accelerate your software lifecycle with help from GitLab experts
Popular GitLab use cases
Remote Work Continuous Integration (CI/CD) Source Code Management (SCM) Out-of-the-box Pipelines (Auto DevOps) Security (DevSecOps) Agile Development Value Stream Management
PCI is the shorthand for the Payment Card Industry's Data Security Standard (PCI-DSS) as defined by the PCI security standards council. The PCI-DSS defines the requirements of businesses that accept or facilitate credit card payments based on type or amount of transactions accepted or facilitated.
A full list of of the PCI DSS glossary, abbreviations, and acronyms.
| Term | Definition |
|---|---|
| ASV | Acronym for “Approved Scanning Vendor.” Company approved by the PCI SSC to conduct external vulnerability scanning services. |
| Card Verification Code or Value | Also known as Card Validation Code or Value, or Card Security Code. Refers to the printed security features. * For Discover, JCB, MasterCard, and Visa payment cards, the second type of card verification value or code is the rightmost three-digit value printed in the signature panel area on the back of the card. For American Express payment cards the code is a four-digit unembossed number printed above the PAN on the face of the payment cards. The code is uniquely associated with each individual piece of plastic and ties the PAN to the plastic. The following list provides the terms for each card brand: * CID - Card Identification Number (American Express and Discover payment cards) * CAV2 - Card Authentication Value 2 (JCB payment cards) * PAN CVC2 - Card Validation Code 2 (MasterCard payment cards) * CVV2 - Card Verification Value 2 (Visa payment cards) |
| Cardholder Data (CHD) | Any personally identifiable information (PII) associated with a person who has a credit or debit card. This data is, at a minimum: * Primary account number (PAN) - this is the credit card numberAnd can additionally include: * Card Verification Code * Cardholder name * Expiration date * Magnetic Stripe Data/Track Data * PIN * Sensitive Authentication Data * Service Code If any combination of these are stored, processed, or transmitted with the PAN, they must be protected in compliance with PCI DSS requirements. |
| CDE | Acronym for cardholder data environment. The people, processes and technology that store, process, or transmit cardholder data or sensitive authentication data |
| Cloud Service Provider ("Provider") | It is the entity providing the cloud service. It acquires and manages the infrastructure required for providing the services, runs the cloud software that provides the services and delivers the cloud services through network access |
| Cloud Service Customer ("Customer") | The entity subscribing to a service provided by a Provider. May include merchants, service providers, payment processors and other entities utilizing cloud services |
| Cloud Service User | Person, or entity acting on his or her behalf, associated with a Customer that uses cloud services. Note: Examples of such entities include devices and applications. |
| Magnetic-Stripe Data | See Track Data below. |
| PAN | Acronym for primary account number and also referred to as account number. Unique payment card number (typically for credit or debit cards) that identifies the issuer and the particular cardholder account |
| PIN | Acronym for personal identification number. Secret numeric password known only to the user and a system to authenticate the user to the system. The user is only granted access if the PIN the user provided matches the PIN in the system. Typical PINs are used for automated teller machines for cash advance transactions. Another type of PIN is one used in EMV chip cards where the PIN replaces the cardholder’s signature. |
| Sensitive Authentication Data | Security-related information (including but not limited to card validation codes/values, full track data (from the magnetic stripe or equivalent on a chip), PINs, and PIN blocks) used to authenticate cardholders and/or authorize payment card transactions |
| SAQ | Acronym for Self-Assessment Questionnaire. Reporting tool used to document self-assessment results from an entity’s PCI DSS assessment |
| Scoping | Process of identifying all system components, people, and processes to be included in a PCI DSS assessment. The first step of a PCI DSS assessment is to accurately determine the scope of the review. |
| Server | Computer that provides a service to other computers, such as processing communications, file storage, or accessing a printing facility. Servers include, but are not limited to web, database, application, authentication, DNS, mail, proxy, and NTP. |
| Service Code | Three-digit or four-digit value in the magnetic-stripe that follows the expiration date of the payment card on the track data. It is used for various things such as defining service attributes, differentiating between international and national interchange, or identifying usage restrictions. |
| Service Provider | Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity. This also includes companies that provide services that control or could impact the security of cardholder data. Examples include managed service providers that provide managed firewalls, IDS and other services as well as hosting providers and other entities. If an entity provides a service that involves only the provision of public network access—such as a telecommunications company providing just the communication link—the entity would not be considered a service provider for that service (although they may be considered a service provider for other services). |
| Track Data | lso referred to as full track data or magnetic-stripe data. Data encoded in the magnetic stripe or chip used for authentication and/or authorization during payment transactions. Can be the magnetic-stripe image on a chip or the data on the track 1 and/or track 2 portion of the magnetic stripe |
| Transaction Data | Data related to electronic payment card transaction. |
| Truncation | Method of rendering the full PAN unreadable by permanently removing a segment of PAN data. Truncation relates to protection of PAN when stored in files, databases, etc. See Masking for protection of PAN when displayed on screens, paper receipts, etc. |
| Trusted Network | Network of an organization that is within the organization’s ability to control or manage. |
| Untrusted Network | Network that is external to the networks belonging to an organization and which is out of the organization’s ability to control or manage. |
| VLAN | Abbreviation for virtual LAN or virtual local area network. Logical local area network that extends beyond a single traditional physical local area network. |
PCI data refers to the cardholder data, which is what the PCI DSS was created to protect. The following data values identify cardholder data in any combination:
Descriptions of each are available in the above Glossary section
Wherever any of these data values are stored is in-scope for PCI compliance along with any system connected-to that storage location.
Please Note: Storage of cardholder data (CHD) is permissable but will expand the number of requirements to be PCI compliant beyond what is listed here.
| Data Element | Storage Permitted | Render Stored Data Unreadable per Req. 3.4 |
||
|---|---|---|---|---|
| Account Data |
Cardholder Data |
Primary Account Number (PAN) | Yes | Yes |
| Cardholder Name | Yes | No | ||
| Service Code | Yes | No | ||
| Expiration Date | Yes | No | ||
| Sensitive Authentication Data |
Full Track Data (data on chip) | No | Cannot store per Req. 3.2 | |
| CAV2/CVC2/CVV2/CID | No | Cannot store per Req. 3.2 | ||
| PIN/PIN Block | No | Cannot store per Req. 3.2 |
PCI Req. 3.4
PCI Req. 3.2
There are data values defined as part of CHD listed in sections above, that by themselves, are not considered CHD outside of being stored with the PAN:
Please Note: Even though they are not identified as cardholder data without the associated PAN, some data values are still PII and must be securely stored.
One of the primary goals of a tokenization solution should be to replace sensitive PAN values with non-sensitive token values. For a token to be considered non-sensitive, and thus not require any security or protection, the token must have no value to an attacker.
Examples:
| PAN | Token | Comment |
|---|---|---|
| 3124 005917 23387 | 7aF1Zx118523mw4cwl5x2 | Token consists of alphabetic and numeric characters |
| 4959 0059 0172 3389 | 729129118523184663129 | Token consists of numeric characters only |
| 5994 0059 0172 3383 | 599400x18523mw4cw3383 | Token consists of truncated PAN (first 6, last 4 of PAN are retained) with alphabetic and numeric characters replacing middle digits. |
To be considered out of scope for PCI DSS, both the tokens and the systems they reside on would need to have no value to an attacker attempting to retrieve PAN, nor should they in any way be able to influence the security of cardholder data or the CDE.
At GitLab we fully outsource our payment processor to a third-party and will not retain or have access to customer PAN or tokens.
Additional information - PCI DSS Tokenization Guidelines
APIs and other public interfaces should be designed to prevent both accidental misuse and malicious attempts to bypass security controls.
Examples of controls that should be in place to protect these interfaces:
GitLab is an open core solution that provides both a free and tiered paid plans that primarily utilizes credit card payments for subscriptions. Because of the low number of credit card transactions GitLab is involved with and the fact that we use a third-party payment processor, GitLab is currently a level 4 merchant for PCI. Level 4 merchants are required to complete an annual self-attestation questionnaire (SAQ) and since we fully outsource payment processing, specifically the SAQ-A. Quarterly scanning of our PCI systems must also be performed by an approved scanning vendor (ASV), GitLab uses Tenable.io.
GitLab has completed an SAQ-A form and regularly performs scans of our in-scope PCI systems by an ASV. The SAQ-A form (and associated Attestation of Compliance (AoC)) and the results of our ASV scans are available upon request. Please send an email to security@gitlab.com to request these documents.
Determining how a system may interact with the payment processing system is important when defining which systems are in-scope for PCI compliance. The following diagram demonstrates in-scope (connected-to) vs. out-of-scope (not connected-to) when defining the PCI environment:
Please Note:
Once any layer of the cloud architecture is shared by CDE and non-CDE environments, segmentation becomes increasingly complex. This complexity is not limited to shared hypervisors; all layers of the infrastructure that could provide an entry point to a CDE must be included when verifying segmentation.
The Customer (GitLab) is responsible for the proper configuration of any segmentation controls implemented within its own environment (for example, using virtual firewalls to separate in-scope VMs from out-of-scope VMs), and for ensuring that effective isolation is maintained between in-scope and out-of-scope components.
When determining if a system or data is in-scope for PCI, ask yourself the following questions: (refer to glossary section above for definitions)
shared services (i.e. SIEM, security logging, directory services, NTP, or DHCP) of the cardholder data environment (CDE) or connected-to systems through a firewall and/or jump box?If you answered yes to any of these questions, the system is in-scope for PCI compliance.
GitLab's payment processing system is customers.gitlab.com which hosts a Zuora iFrame to collect payment information from a customer which creates/updates a subscription account managed by Zuora which passes the customers credit card information to Stripe to process the payment. Once the payment is successful, the number of licenses a customer paid for will be generated to allow use of GitLab's feature tier selected. customers.gitlab.com is the centerpoint of credit card payment processing where PCI begins at GitLab.
| System | Purpose | Location | Scope | Reasoning |
|---|---|---|---|---|
| customers.gitlab.com | GitLab system for providing customers the ability to create and pay for tiered product subscriptions with a credit card | Azure | PCI | Displays the Zuora iFrame to create/manage subscriptions and to process credit card payments using Stripe |
| dev.gitlab.org | GitLab system that hosts the GitLab team member OAuth | Azure | Connected-To PCI | Provides GitLab team members secure access to customers.gitlab.com to maintain and support |
| Chef Server | GitLab system for configuration management | Digital Ocean | Connected-To PCI | Provides configuration management for customers.gitlab.com |
| gitlab-pci | GitLab system for external logging of customers.gitlab.com (fully segmented GCP project) | GCP | Connected-To PCI | Logs of customers.gitlab.com must be shipped off the system in a secured environment |
| license.gitlab.com | GitLab license management system | AWS | Connected-To PCI | Generates licenses that allows customers to run GitLab instances |
| SalesForce | Third-party customer resourcee management platform | SalesForce | Connected-To PCI | Ingests customer subscription information from customers.gitlab.com |
| Stripe | Third-party payment processor | Stripe | PCI | Payment processor |
| Zuora | Third-party subscription management platform | Zuora | PCI | Subscription management platform |
| Shopify | Third-party payment processor and swag.gitlab.com host | AWS | PCI | Hosts swag.gitlab.com |
This is a list of service providers who handle credit card transactions on behalf of GitLab:
| Company/Product Name | Service Provided | Risk Assessment | Data Shared | Data Encryption Used | Written Agreement | PCI Validation | Expiration Date | Requirements Responsible For |
|---|---|---|---|---|---|---|---|---|
| Shopify | E-Commerce Platform | Shopify Risk Acceptance | email address, first and last name, shipping address, phone number, and credit card information | in-transit: TLS 1.2+, at-rest: Merchant and customer data is encrypted at rest and sensitive information is further encrypted at the application layer. | Shopify ToS | Shopify AOC | 2019-7-21 | 6 and 7 |
| Stripe | Payment Processor | Stripe DPIA | in-transit: TLS 1.2; at-rest: AES-256 | Stripe SSA | Stripe AOC | 2020-2-29 | 6, 7, 11 and 12 | |
| Zuora | E-Subscription Platform | Zuora DPIA | in-transit: AES 256 TLS; at-rest: server-side encryption (SSE) with AWS Key Management Service (SSE-KMS) | Zuora MSA (on file) | Zuora AOC | 2019-6-27 | 5, 6, 7, 10, 11 and 12 |
The following table correlates each column of data back to its specific control:
| Column | Control |
|---|---|
| Company/Product Name | TPM.1.01 - Third Party Assurance Review |
| Service Provided | |
| Risk Assessment | TPM.1.02 - Vendor Risk Management |
| Data Shared | |
| Data Encryption Used | |
| Written Agreement | TPM.2.02 - Vendor Non-Disclosure Agreement |
| PCI Validation |
TPM.1.04 - Vendor Compliance Monitoring |
| Expiration Date | |
| Requirements Responsible For |
PCI Requirement 11.2 requires periodic unauthenticated scanning of a merchants externally-facing in-scope PCI environment to identify vulnerabilities that can potentially be exploited. The PCI-DSS council certifies Approved Scanning Vendors (ASV) to provide the ability to scan a merchants external PCI environment and provide an independent review of potential risk. ASV scanning is conducted on a quarterly basis and must demonstrate results that pass a third-party assessment which is completed by the ASV. For GitLab that is Tenable.io.
Each quarter the merchant must submit to the ASV scan results to validate the external PCI environment is in compliance by the report not containing "High" or "Medium" severity vulnerabilities or any features or configurations that conflict with PCI-DSS. Vulnerability severity levels are based on the National Vulnerability Database (NVD) and Common Vulnerability Scoring System (CVSS).
Report submissions for ASV attestation will occur on the following dates each year(coinciding with the GitLab fiscal calendar):
{-Please Note-}: First submission will be made by 2020-06-01 to allow for remediation timeframe to be completed.
The four previous passing scans will be submitted to requesting PCI acquirer with the latest PCI SAQ-A in the month of February.
Vulnerability reports must be able to demonstrate compliance on two levels:
The scan report must have the following three sections:
A completed scan has one of four results:
This is the only result that will be accepted to comply with quarterly external ASV requirementThe scan customer may dispute the findings in the ASV scan report including, but not limited to:
A dispute must be submitted in writing and can include screen captures, configuration files, system versions, file versions, list of installed patches, etc.
Another method of results dispute is demonstrating the use and implementation of compensating controls of identified scan results by the ASV.
The GitLab security compliance team can help with any questions relating to PCI.
