SOC 2 Auditors Probe CI/CD: Prove Your Code Reviews

The Proof Gap: When Controls Fail Audits

The first SOC 2 audit for an engineering team often goes sideways fast. Not because the CI/CD pipeline is flawed, but because the team cannot prove its controls are working. A common scenario: an auditor asks to see proof of a code review for a specific production deployment. The team knows the review happened, but they can’t produce the evidence. This gap between a functional control and a provable control is where many first-time SOC 2 audits falter, costing unexpected time and resources. It has less to do with inherent security and more to do with auditable processes.

Most teams build good pipelines. They might use trunk-based development, gate merges on passing tests, deploy on green builds, and manage infrastructure with tools like Terraform. These are robust engineering practices. However, SOC 2 demands more than just good practice; it requires demonstrable evidence that these practices are consistently applied and can be verified.

Key Auditor Questions and What Satisfies Them

Auditors approach CI/CD with a specific set of questions designed to verify security controls related to system operations and change management. The goal is to ensure that changes to systems are authorized, reviewed, tested, and deployed in a controlled manner. Here’s a breakdown of what they typically ask and what constitutes satisfactory evidence:

1. Access Control to Main Branch

What they ask: “Who can push directly to the main branch? Show me the policy and the evidence of enforcement.”

What satisfies them: Auditors want to see that direct pushes to main are restricted. This typically means using branch protection rules in your version control system (like GitHub or GitLab). Evidence includes screenshots of your repository settings demonstrating these rules are in place. They will also look for evidence that only authorized personnel or automated systems can merge code into main, usually after passing CI checks and code reviews.

2. Code Review Process

What they ask: “Show me the process for code reviews. Specifically, for the code deployed on [specific date], show me the review and approval records.”

What satisfies them: This is where many teams stumble. Auditors need to see that code is reviewed by at least one individual who did not author the code. Satisfactory evidence includes:

• Pull Request (PR) / Merge Request (MR) history: Demonstrating that a PR was opened, assigned to a reviewer, comments were addressed, and then approved by someone other than the author before merging.
• Automated Enforcement: If your platform enforces mandatory reviews, show the configuration. Tools like GitHub’s “Require pull request reviews before merging” setting, configured to require at least one approval from someone outside the author, are key.
• Workflow Tools: If you use project management tools integrated with your VCS, showing the link between a code change and its approval within that system can also be sufficient.

The critical point is not just having a policy, but having the logs or artifacts that prove the policy was followed for specific changes.

3. Build and Deployment Automation

What they ask: “How is code built and deployed? Show me the automation scripts and the logs demonstrating successful builds and deployments.”

What satisfies them: Auditors want to ensure that builds and deployments are automated and repeatable, reducing the risk of manual errors. Evidence includes:

• CI/CD Configuration Files: Show the configuration files for your CI/CD tool (e.g., Jenkinsfile, GitHub Actions workflows, GitLab CI YAML files).
• Build Logs: Provide logs showing that code was compiled, tested, and packaged successfully.
• Deployment Logs: Show logs from your deployment tool or process, confirming that the artifact built was successfully deployed to the target environment.
• Infrastructure as Code (IaC): If you use IaC (e.g., Terraform, CloudFormation), provide evidence of version-controlled configurations and their application, demonstrating that environment changes are managed systematically.

4. Testing and Quality Gates

What they ask: “What automated tests run as part of the pipeline? Show me the test results and how they gate deployments.”

What satisfies them: Auditors need assurance that code quality and functionality are validated before deployment. Evidence includes:

• Test Suite Configuration: Documentation or configuration showing the types of tests run (unit, integration, end-to-end, security scans).
• Test Execution Reports: Logs and reports showing the results of these tests.
• Branch/Merge Protection Rules: Demonstrating that the pipeline’s test results are linked to merge or deployment approvals. If tests fail, the merge or deployment should be blocked.

5. Rollback Procedures

What they ask: “What is your process for rolling back a failed deployment? Show me an example or the documented procedure.”

What satisfies them: A robust rollback strategy is crucial for business continuity and incident response. Evidence includes:

• Documented Rollback Plan: A clear, written procedure outlining the steps to revert to a previous stable version.
• Automated Rollback Scripts: If rollbacks are automated, show the scripts and their configuration.
• Incident Response Playbooks: If rollbacks are part of a broader incident response, show how they are triggered and executed.
• Post-Mortems: For past incidents where rollbacks occurred, post-mortem reports can serve as evidence of the process in action.

6. Secret Management

What they ask: “How are secrets (API keys, passwords, certificates) managed and injected into the pipeline and application? Show me your secrets management solution.”

What satisfies them: This is a critical security control. Auditors want to see that secrets are not hardcoded in source code or configuration files. Satisfactory evidence includes:

• Secrets Management Tool Configuration: Demonstrating the use of tools like HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or similar solutions.
• Pipeline Integration: Show how the CI/CD pipeline securely retrieves secrets at runtime or during deployment, rather than having them embedded in build artifacts.
• Access Controls for Secrets: Evidence that access to secrets is strictly controlled and audited.
• Secrets Rotation Policy: Documentation and evidence of regular rotation of secrets.

Beyond the Pipeline: The Human Element

While technical controls are paramount, SOC 2 also scrutinizes the human processes surrounding the pipeline. This includes ensuring that only authorized personnel have access to sensitive CI/CD functionalities, that access is regularly reviewed, and that there is clear accountability for changes made.

The most significant takeaway from a SOC 2 audit of a CI/CD pipeline is the absolute necessity of documenting and providing evidence for every control. A technically sound process is only half the battle; proving it consistently happened is the other, often more challenging, half. If you can’t show the proof, your control is effectively non-existent from an auditor’s perspective.