Controls6 May 2026 8 min read

SOC 2 SDLC Controls: Secure Development Requirements

Implement SOC 2 SDLC controls for secure development. Covers CC8 change management, security code review, SAST/DAST, dependency scanning, and evidence collection.

Key Takeaways

SOC 2 CC8.1 and CC5.2 require a secure SDLC with security built into the development process.
SAST (static analysis) in CI/CD catches security vulnerabilities before production deployment.
DAST (dynamic analysis) tests the running application for vulnerabilities not caught by static analysis.
Code review with a security lens is a required CC8.1 control — peer review must happen before merging to main.
Security training for developers (OWASP awareness) is a CC1.4 competency control that also supports SDLC.

In this guide

SDLC and SOC 2 Criteria
Code Review as a Security Control
SAST: Static Application Security Testing
DAST: Dynamic Application Security Testing
Dependency and Container Scanning
Developer Security Training
SDLC Evidence Checklist

SDLC and SOC 2 Criteria

A Secure Software Development Lifecycle (SDLC) integrates security practices at every phase of development: design, code, test, deploy. For SOC 2, SDLC controls address CC8.1 (change management — all changes are developed, tested, and approved before deployment), CC5.2 (technology general controls — access to programs and data), and CC1.4 (competency — developers are trained in secure coding).

The goal is to catch security vulnerabilities in development rather than in production. A vulnerability found by a static analysis tool in a PR costs minutes to fix; the same vulnerability found by an attacker in production costs weeks of incident response, customer notification, and reputation damage.

Code Review as a Security Control

Peer code review is both a CC8.1 change management control and a security control. Reviewers should be trained to identify security issues: SQL injection patterns (string concatenation in queries instead of parameterized queries), XSS vulnerabilities (unescaped user input in HTML output), insecure deserialization, hardcoded credentials, excessive logging of sensitive data, and missing authentication/authorization checks.

For higher-risk code changes (authentication system, payment processing, data export functions), require review by a developer with security expertise — not just any team member. Document this requirement in your code review policy.

Configure branch protection in GitHub to require at least one approving review before merging. Add automated SAST as a required status check to run alongside the human review.

SAST: Static Application Security Testing

SAST tools analyze source code without executing it, identifying security vulnerabilities through pattern matching and data flow analysis. Integrate SAST into your CI/CD pipeline to run on every PR.

Popular SAST tools: Semgrep (open source, fast, supports custom rules), Checkmarx (enterprise), SonarQube (code quality + security), GitHub Advanced Security CodeQL (powerful, free for public repos, paid for private). For JavaScript/TypeScript, ESLint with security plugins (eslint-plugin-security) provides lightweight SAST.

Configure SAST to block merge on high-severity findings. Define which finding categories must be fixed before merge (OWASP Top 10 categories, hardcoded secrets, SQL injection) and which can be reviewed and suppressed with justification.

DAST: Dynamic Application Security Testing

DAST tools test the running application by sending requests and analyzing responses, finding vulnerabilities that can only be detected at runtime — authentication bypasses, session management flaws, business logic errors, and runtime injection vulnerabilities.

OWASP ZAP (open source, automatable) can be run in CI/CD against a staging environment on every deployment. Configure it in "active scan" mode to test for OWASP Top 10 vulnerabilities. Burp Suite Enterprise provides more comprehensive coverage and reporting suitable for compliance evidence.

Run DAST against your staging environment in the CI/CD pipeline: deploy to staging, run ZAP or equivalent, fail the pipeline on high-severity findings. For production, run DAST monthly or after major releases from a dedicated security scanner IP that is allowed in your WAF.

Dependency and Container Scanning

Application dependencies (npm packages, Python packages, Java libraries) are a significant vulnerability source — 70%+ of application code is third-party. Scan them continuously: Snyk Open Source, OWASP Dependency-Check, or GitHub Dependabot.

Configure Dependabot in GitHub to automatically open PRs for security updates to dependencies. This keeps your dependency tree current with security patches automatically. For critical security updates (CVSS 9+), configure Dependabot to create a PR immediately; for moderate updates, batch them weekly.

For containers: scan Docker images on every build with Snyk Container, Trivy, or AWS Inspector ECR scanning. Block image push on critical vulnerabilities. Build images from minimal base images (distroless, Alpine) to reduce the attack surface.

Developer Security Training

CC1.4 requires competency development. For developers, this means security training: understanding of OWASP Top 10, secure coding practices in the languages they use, and how to interpret SAST findings.

Practical security training for developers: OWASP WebGoat (vulnerable-by-design app for practice), Secure Code Warrior (gamified secure coding training), internal secure coding guidelines tailored to your stack.

Require annual security training for all developers and track completion records. Include a security module in your developer onboarding checklist. Document the training requirement in your security policy and retain completion evidence for CC1.4.

SDLC Evidence Checklist

(1) SDLC or secure development policy documenting security requirements at each phase. (2) GitHub branch protection configuration showing required SAST status check. (3) Sample PRs with SAST findings resolved before merge. (4) SAST tool configuration and sample scan results. (5) DAST scan reports from staging environment for the audit period. (6) Dependency scan results showing vulnerabilities and remediation (Snyk or Dependabot reports). (7) Developer security training completion records. (8) Pentest report (annual) as the comprehensive separate evaluation of application security.

Frequently Asked Questions

Is a penetration test required for SOC 2 SDLC compliance?

The AICPA criteria don't mandate it, but a penetration test is the most thorough separate evaluation of your application's security and is expected by virtually all SOC 2 auditors. Run an annual penetration test scoped to your customer-facing application and document the findings and remediation. This satisfies CC4.2, CC7, and demonstrates a mature SDLC.

Can we satisfy SAST requirements with just ESLint security plugins?

ESLint with security plugins provides lightweight SAST but misses data flow analysis and more complex vulnerability patterns. It's a good start but not sufficient on its own for a comprehensive SAST requirement. Supplement with Semgrep (free tier available, supports custom rules) or GitHub CodeQL for deeper analysis.

How do we handle SAST false positives that block developer productivity?

Configure SAST to block only on high-confidence, high-severity findings. Allow developers to suppress findings with a justification comment in the code (e.g., // nosemgrep: rule-id with reason). Track suppressions — a suppression list is evidence that findings were reviewed, not ignored. Review suppressions quarterly to confirm they are still valid.

Does our SOC 2 SDLC need to cover internal tools, or just customer-facing applications?

The scope of your SOC 2 system description determines what is in scope. Internal tools that access or process customer data should have SDLC controls. Internal tools with no customer data or production access can use a lighter process. Document the scope clearly in your SDLC policy.

What is threat modeling, and is it required for SOC 2?

Threat modeling is a design-phase security activity where you systematically identify threats to a system before building it. It's not explicitly required by SOC 2 criteria, but it's a strong CC3 (risk assessment) and CC5 (control selection) practice. For new features handling sensitive data, a lightweight threat model (STRIDE analysis) helps identify controls needed before code is written.