How GitLab can help you prepare for your SOC 2 audit

GitLab customers have found that using GitLab as their platform for DevSecOps has simplified the SOC 2 audit process. This blog reviews the SOC 2 standards and GitLab features that help customers with their SOC 2 audit.

Introduction to SOC 2

System and Organization Controls 2, or SOC 2, is a voluntary compliance standard that specifies how organizations should manage customer data. The SOC 2 audit report allows companies to provide attestation to the trustworthiness of software it offers to business customers.

Developed by the Association of International Certified Professional Accountants (AICPA), SOC 2 focuses on five Trust Services Criteria (TSC):

• Security - protecting customer data from vulnerabilities and unauthorized access
• Availability - ensuring systems are fault-tolerant and performant under high loads in order to meet availability service-level agreements
• Processing Integrity - systems function as designed without vulnerabilities, errors, or bugs
• Confidentiality - protecting confidential information such as application source code, usernames and passwords, credit card information, etc., so that only people who need access in order to do their jobs have access to it
• Privacy - safeguarding sensitive personally identifiable information (PII) against unauthorized users

Security is the only required criterion for every SOC 2 audit. The other criteria can be added to the audit in cases where they are deemed critical to the services being provided.

Security TSC

The security criterion pertains to not only the security of servers and physical systems, but also applications. Software vulnerabilities potentially open up an application to attackers, putting customers' data at risk, but this is an area where GitLab can help.

GitLab provides security scans to identify potential vulnerabilities in the applications a company builds, including the following:

• Static Application Security Scanning (SAST), which scans source code for potential bugs and vulnerabilities such as unsafe code that can lead to unintended code execution
• Dependency Scanning, which finds security vulnerabilities in the software dependencies of an application
• Container Scanning, which finds security vulnerabilities in the operating system dependencies of a containerized application
• Dynamic Application Security Scanning (DAST), which finds security vulnerabilities in a running web application that make it susceptible to an attack
• Infrastructure as Code (IaC) Scanning, which scans infrastructure as code configuration files, including Terraform, Ansible, AWS CloudFormation, and Kubernetes, to find security vulnerabilities

GitLab also provides a vulnerability report, which shows all known vulnerabilities, based on the scans above, in the current application. GitLab also provides a software bill of materials (SBOM) in standard CycloneDX JSON format, that shows all software-level and operating system-level dependencies and known vulnerabilities for them.

Having regular vulnerability scans and robust vulnerability reporting helps satisfy three Security criteria:

• CC7.1 – To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities.
• CC4.1 – COSO Principle 16: The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning.
• CC4.2 – COSO Principle 17: The entity evaluates and communicates internal control deficiencies in a timely manner to those parties responsible for taking corrective action, including senior management and the board of directors, as appropriate.

A crucial piece of security scans is governance and enforcement. GitLab provides features to ensure that scans are happening regularly and that software development teams are not able to circumvent them. These features include:

• Role-based access controls to limit who can make changes to project-level configuration settings
• Scan execution policies to enforce that scans run on each code repository
• Scan results policies to ensure that scan results are reviewed and approved by the appropriate security stakeholders so that newly found vulnerabilities are not being introduced into deployed software
• Compliance reports to show any changes to GitLab configurations that may violate security processes put in place

With these configurations in place, organizations can prove that software security is a top priority for their applications and security practices are being enforced.

Availability and Processing Integrity TSCs

GitLab can also help with Availability and Processing Integrity TSCs. These criteria focus on the quality and performance of the application itself. To support these criteria, GitLab provides:

• Unit test results and code coverage changes in the form of code coverage reports, which ensure that source code is being validated by a test suite
• Code quality, which analyzes the source code quality and complexity for ease of readability and maintainability

While the above software development practices are used early in the software development lifecycle to ensure high-quality, tested code, GitLab additionally provides templates for various types of automated tests for a running application to ensure it is working as expected. These tests include:

• Browser performance testing, which measures the load time for web sites during the development lifecycle to test the impact of any ocde changes on browser performance
• Load performance testing, which measures the system performance of an application's backend during the development lifecycle to test the impact of any code changes on performance
• Coverage-guided fuzz testing, which sends unexpected, malformed, or random data to an application and then monitors it for unstable behaviors and crashes
• Web API fuzz testing, which sends unxpected, malformed, or random data to API endpoints to look for bugs and security issues

By focusing on strong DevSecOps practices with GitLab to build high-quality, secure applications, organizations are able to more easily pass a SOC 2 audit to attest to the security of customer data.

More resources

• The benefits of transparency in a security audit
• What you need to know about a DevOps audit
• Glympse customer case study, which explains how GitLab made the audit process easier