- You are here:
- Financial Services Regulatory Compliance
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 and regulations
Examples of regulators include the following
- America: FEB in the US, also see the FFIEC IT Handbook
- Europe: FCA and PRA in the UK, FINMA in Switzerland
- Asia: MAS in Singapore and HKMA
Examples of relevant regulations include the following
- GLBA Safeguards rule requires that financial institutions must protect the consumer information they collect and hold service providers to same standards.
- Dodd-Frank’s purpose is to promote the financial stability of the United States by improving accountability and transparency in the financial system. It sets the baseline for what is “reasonable and appropriate” security around consumer financial data. You must be ready to prove your security controls and document them.
- Sarbanes Oxley (SOX) exists to protect investors by improving the accuracy and reliability of corporate disclosures made pursuant to the securities laws, and for other purposes. Advice for achieving this is augmented by other frameworks such as COBIT14 and the CIS Critical Security Controls.
- PCI DSS is intended to maintain payment security and is required for all entities that store, process or transmit cardholder data. It requires companies using credit cards to protect cardholder data, manage vulnerabilities, provide strong access controls, monitor and test, and maintain policy.
Specific controls common amongst these regulations are outlined below, along with features of GitLab that aid in their compliance.
Separation of duties
- To protect a system from unauthorized changes and fraud, more than one person is required to complete a task.
- 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.
- Protected branches
- Merge request approvals
- Unprotect permission
- Future: Approval jobs in CI pipelines
- Future: Two-person access controls
- Software needs to support evidence that data has not been modified.
- Role-based access and revocation of accounts.
- 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.
- 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.
- Dependency scanning
- Container scanning
- Security Dashboard
Also see our security paradigm for more information on why GitLab security tools work better.
- 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.
- One concept of a user across the lifecycle to ensure the right level of permissions and access
- Audit logs
- Audit events
- Container image retention
- Artifact retention
- Test result retention
- Future: Disable squash of commits
- Future: Prevent purge
Licensed code usage
- Third party and open source code use must comply with license constraints.
- To comply with license contraints, 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.
- License management
- All changes must be tracked. Sarbanes-Oxley specifically requires companies to notify the SEC of any material changes to the process that governs the flow of financial data.
- Change Management is required with changes tracked, reviewed and approved.
- 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.
- Automated deploy
- Revert button
- Review apps make it easy to visualize the changes in code review and ensure changes function in a legitimate manner.
State of art
- While not exactly a rule per se, State of the art comes to play in Tort liability.
- There are some thoughts out there, that by showing that you are using the state-of-the-art methods, you MAY help prove a point against negligence.
- GitLab is use in many large global financial services companies.
- Both relevant US regulators run GitLab themselves.
- 2,000 code contributors
- 100,000 organizations
- Millions of users
Reference articles of interest
Everyone can contribute
Please email suggestions
MRs are very welcome, assign to.