Financial Services Regulatory Compliance

• 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. Require merge request approval by code owners
7. Future: Approval jobs in CI pipelines

• 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. Merge Request approval rules

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

• 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

• 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

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.

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.

• 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

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.

• 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.

• 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. Disable squash of commits

• 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. Blackout periods to ensure production change freezes
6. Future: End-to-end traceability for merges
7. Future: Automated incident creation integration with Service Now

• 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 Compliance