Financial Services Regulatory Compliance

Learn how GitLab can help solve your compliance challenge.

Contact Sales

GitLab is used extensively to achieve regulatory compliance in the financial services industry. Many of the world's largest financial institutions are GitLab customers. This page details the relevant rules, the principles needed to achieve them, and the features in GitLab that make that possible.

Regulators

Examples of regulators include the following:

Regulations

Examples of relevant regulations include the following:

Common controls

Specific controls common amongst these regulations are outlined below, along with features of GitLab that aid in their compliance.

Control Rule Principles How GitLab helps
Segregation of Incompatible Duties (SODs) To protect a system from unauthorized changes and fraud, organizations must establish organization-defined duties and roles, document separation of duties of these individuals and roles, and define associated system access authorizations to support these separation of duties.
  • You never merge your own code.
  • All code needs to be peer reviewed.
  • Only authorized people can approve the code.
  • You need a log of who approved it.
  1. Defined Project Permissions
  2. Protected branches
  3. Protected environments
  4. Merge request approvals
  5. Unprotect permission
  6. Future: Approval jobs in CI pipelines
  7. Future: Two-person access controls
  8. Future: Require merge request approval by code owners
Identity and Access Approval Controls to Ensure Proper SODs Separation of duties addresses the potential for abuse of authorized privileges and helps to reduce the risk of malevolent activity without collusion.
  • Divide mission functions and information system support functions among different individuls/roles.
  • Segregate configuration management, programming, system management, quality assurance functions.
  • Only authorized people can approve the code.
  • Only authorized roles can merge code.
  1. Role-Based Access Controls (RBAC) within protected branches and environments prevent unauthorized users from deploying to labeled environments.
  2. Future: Enable Multiple rules for merge request approvals Code
  3. Future: Prevent merge request and commit authors from self-approving
  4. Future: Identity API
Configuration Management NIST's Configuration Management control as outlined in NIST 800-53, Rev. 4: CM-2 establishes that baseline configurations are documented, formally reviewed and agreed-upon. As baseline configurations serve as a basis for future builds, releases, and/or changes to information systems, it is critical for organizations to have the ability to control changes and evidence the integrity of the deployment process.
  1. Baseline CI/CD configurations are stored and tracked.
  2. Automated configuration management is employed to remove manual, error-prone processes.
  3. Changes to configurations are approved.
  4. Logs of changes are maintained.
  1. CI/CD configurations
  2. Future: Approval jobs in CI pipelines
Configuration Change Control Configuration Change Control is outlined in NIST 800-53, Rev. 4: CM-3: the organization implements approved configuration controlled changes to the information system and retains a record of the configuration controlled-changes - and changes to deployment configurations.
  • All changes to baseline orchestration configurations are stored and tracked.
  • Changes to configurations of protected branch and environment configurations are stored and tracked.
  • Logs of changes are maintained.
  1. CI/CD pipeline configuration management
  2. Audit Events
Access Restrictions for Changes to Configurations and Pipelines ISO 27002 9 (Access Controls) and NIST 800-53, Rev. 4: CM-5 and AC-3 (Logical Access Enforcement) dictate that organizations define, document, approve, and enforce logical access restrictions associated with changes to the information system. Any changes to the software can potentially have significant effects on the overall security of the systems. Therefore, organizations permit only qualified and authorized individuals to access information systems for purposes of initiating changes, including upgrades and modifications.
  • Controls exist to prevent initiation of pipelines without requisite approvals.
  • Only authorized users can deploy to production.
  1. Protected branches
  2. Protected environments
  3. Merge request approvals
Security

Both the NIST and the ISO security frameworks outline requirements related to developer security testing and evaluation. NIST 800-53, Rev. 4: SA -11 establishes that organization must require the developers of the information system, system component, or information service to implement a security assessment plan, produce evidence of execution of security testing, and correct flaws identified.

As a result, business application software needs to support the following:

  • Evidence that data has not been modified.
  • Auditing and logging of events in systems that process sensitive data.
  • Log system changes in a way that those logs are resistant to tampering and accessible only to privileged users.

Note: Application Security Testing can help identify vulnerabilities that enable unauthorized access to data, logic, and reporting.

  • Scan applications regularly for vulnerabilities.
  • Establish criteria for the prioritization of vulnerabilities and remediation activities.
  • Pay special attention to internally or custom developed applications with dynamic and static analysis.
  • Establish secure coding as a culture, and provide qualified training on secure coding.
  • Establish and document a secure development life-cycle approach that fits your business and developers.
  • Combine functional testing and security testing of applications: Assess for operational bugs and coding errors.
  1. SAST
  2. DAST
  3. Dependency Scanning
  4. Container Scanning
  5. Security Dashboard
  6. Security Paradigm
  7. Future: Show Dependency Scanning results in Groups Security Dashboard

In addition to Application Security Testing to help you deliver secure apps, GitLab's own application has security to prevent unauthorized access to the application code as well as audit and logging capabilities of changes to the code.

Operations Security via Protections on Branches and Environments Organizations need to evidence the integrity of their production environments and critical code branches.
  • Changes to configuration of protections for branches and environments are tracked and logged.
  • Organizations must have access to readily available, human-readable audit trail of all actions taken to label and protect environments.
  • Controls exist to prevent unauthorized parties from running deployment jobs labeled as protected.
  1. Granular user-based and role-based (RBAC) access controls for branches, environments and Kubernetes clusters supply operators the ability to determine who can deploy and to what environments.
  2. Protected branches allow you to protect your production code pipeline.
  3. Protected environments allow you to protect your environments by preventing deployments to them by certain individuals.
Auditing Systems must have clear audit logs to trace changes to the data and also to the logic flow.
  • Auditability of the production application: Software systems must generate all of the necessary logging information to construct a clear audit trail that shows how a user or entity attempts to access and utilize resources.
  • Auditability of the software itself to detect changes in logic flow: Whether urban legend or not, the example is relevant of the developer who pockets rounding errors to his own bank account
  • Logs must be resistant to tampering and accessible only to privileged users.
  1. One concept of a user across the lifecycle to ensure the right level of permissions and access
  2. Audit logs
  3. Audit events
  4. Container image retention
  5. Artifact retention
  6. Test result retention
  7. Future: Disable squash of commits
  8. Future: Prevent purge
Change Management All changes must be tracked. Compliance with Sarbanes-Oxley mandates that publicly traded companies report any material changes to the processes and systems that govern the flow of financial data so as to reduce the risk of material misstatement of financial statements.
  • Systems used to support change management procedures must retain records of changes made, of who reviewed and approved changes, and the sequence in which they were performed.
  • Changes should be made in such a way that they can be rolled back to a previous version quickly and easily. Here are two examples as to why: Flash Crash and TSB Bank Disaster.
  • Source control systems should prevent unauthorized changes using access control or, at least showing changes for a clear audit trail.
  1. Automated deploy
  2. Revert button
  3. Review apps make it easy to visualize the changes in code review and ensure changes function in a legitimate manner.
  4. Issues Boards that enable integration of project management tools into your change management procedures.
  5. Future: End-to-end traceability for merges
  6. Future: Blackout periods to ensure production change freezes
  7. Future: Automated incident creation integration to support change management policies
License Code Usage Third party and open source code use must comply with license constraints.
  • To comply with license constraints, you must track license expiration and usage. This is important to manage risk from legal costs for license agreement violations and risk to your reputation.
  1. License Management