Overview of GitHub and SOC 2 audits
GitHub is a popular vendor that provides internet hosting for software development to its clients. Most start-ups use GitHub as their software development tool in order to develop their product and manage their changes through the software development life cycle (SDLC). It is important that the CTO and the VP of R&D understand the importance of a security-embedded SDLC process, especially when GitHub is supporting the SDLC process. This article will explore how to configure the GitHub environment to comply with SOC 2, and more importantly, strengthen the controls and security in the SDLC process.
Creating a Software Development Life Cycle process to support GitHub
Every organization, no matter what size, should have a proper SDLC process in place. Changes to the product should be controlled throughout the product’s lifecycle and its components.
The below points are some key controls to consider putting in place as part of the SDLC process in order to support the GitHub control environment:
- A SDLC policy and procedure document should be in place that describes the whole SDLC process and how it’s managed in GitHub and the company’s ticketing system.
- A ticketing system should be considered by the company. Tickets are used to document and prioritize change requests within the SDLC process. Pull requests and change tickets are linked to each other so the code change can be logged and tracked.
- SDLC procedures have clearly defined roles and responsibilities. The authorization of change requests is performed by the owner or business unit manager. Responsibilities in the SDLC process should be segregated as below:
– Develop the change
– Test the change
– Implement the change - Security reviews need to be performed on changes to determine the potential effect of the change on security, confidentiality, and privacy commitments and requirements throughout the SDLC process. There needs to be a defined risk associated with each change that would impact the security, confidentiality, and privacy commitments of the product. There are two ways in which the impact on security is checked:
– A security review checklist can be documented and included as part of the change ticket in the ticketing system; and
– You can also use the dependency review action in your GitHub repository, which will warn you about any associated security vulnerabilities. This forms part of the automated tests, which is discussed in more detail below. - Developers cannot have access to production or have access to deploy code into production. If it’s a small R&D team, then access should be monitored, or a process should be in place where temporary access is given for developers to work on production or to deploy the code into production.
- Separate environments of a system should exist:
– Development environment
– QA test environment
– Production environment
SOC 2 controls specific to the GitHub environment
GitHub touches on two criteria in the control framework: (1) Logical Access and (2) Change Management. There are a number of controls in these areas, but specifically for GitHub, the following needs to be implemented in order to ensure SOC 2 success from an SDLC point of view:
| # | Control Name | Sample Control Description |
| 1 | Access Control | Access to GitHub is performed using two-factor authentication and is restricted to authorized personnel. |
| 2 | Code Review | Code changes must be reviewed and approved in order to progress through the SDLC and deploy a version to production. |
| 3 | Code Vulnerability Scanning | Vulnerability scans for the source code are performed to identify security issues as part of the SDLC. High/critical issues are remediated in a timely manner. |
| 4 | Automated Tests | A successful test result is mandatory in order to continue with the SDLC process and deploy a version to the production environment. |
| 5 | Test Failure | In case test failures are detected, a notification is sent to relevant stakeholders. Any code change with a failed test, cannot be deployed into production. |
| 6 | Change Approval | All code changes need to be approved/authorized, prior to being deployed into production. |
Configuring GitHub for SOC 2 compliance
Access Control
All users who have access to GitHub or who are given access should have two-factor authentication enabled. The company’s access control policy and the process should drive this process. GitHub has multiple options to add a second source of authentication to user accounts. Users can configure two-factor authentication using a mobile app or via text message. The important thing is that the company should enforce all user accounts to have two-factor authentication enabled.
Code Review
All changes (pull requests) need to have a code review before being approved/merged into the master branch. Each repository administrator needs to enforce that an approving code review is performed before someone merges the pull request into the master branch. You can require approving reviews from people who write permissions in the repository or from a designated code owner. The company needs to enable required reviews so that collaborators can only push changes to a master branch via a pull request that is approved by the code reviewer with “write” permissions.
Code Vulnerability Scanning
Code Vulnerability Scanning has two parts to it: (1) code scanning to find security vulnerabilities and errors in the code for your project on GitHub and (2) ensuring that high/critical issues are remediated in a timely manner. We will focus on point 1 for this article. Code scanning is a feature in GitHub and a SOC 2 requirement that an organization needs to enable so that code in a GitHub repository can be analyzed to find security vulnerabilities and coding errors. The company can schedule scans for specific days and times or trigger scans before code is pushed into production. Any problems identified by the analysis will be shown on GitHub.
Automated Tests
Automated Code Tests can be set up using GitHub Actions via creating a continuous integration (CI) workflow to build and test the code. These tests can vary in nature and scope and are normally at the discretion of the VP of R&D or CTO of the organization. SOC 2 does not state a minimum or a maximum number of automated tests but it is required that at least some testing is performed on the code before being pushed into production. The tests can include code linters (which check style formatting), security checks, code coverage, functional tests, and other custom checks. Building and testing the code requires a server. You can build and test updates locally before pushing code to a repository or you can use a CI server that checks for new code commits in a repository.
Test Failure and Change Approval
The last two controls address failed tests and change approvals. Branch protection rules can be set up to prevent code from being merged into master if any tests have failed or if the change has not yet been approved. SOC 2 requires that no change can be merged into master prior to all automated tests having passed or the change being approved. More of these restrictions can be implemented in the branch protection settings in GitHub.
Master GitHub and get SOC 2 compliant
The SDLC process can be a very complicated and administrative process but by implementing the above controls in GitHub, you can be assured of having a solid and secure foundation upon which your SDLC process is built. Not only will you comply with the SOC 2 Change Management criteria but you will also have a well-oiled SDLC machine with an effective and secure GitHub control environment in the center of it.
Are you leading SOC 2 compliance at your organization? Complete the SOC 2 Academy and get certified as a Master SOC 2 Implementer!
