PO.3.3 / PW.7.1 / PW.8.2 NIST SP 800-218 SSDF

SAST on every PR

Demonstrate that automated static application security testing runs on every pull request and prevents merge of code containing security vulnerabilities above an established severity threshold.

Description

What this control does

Static Application Security Testing (SAST) is automatically executed on every pull request (PR) before code can be merged into protected branches. The SAST tool scans source code for security vulnerabilities such as injection flaws, authentication bypasses, hardcoded secrets, and insecure configurations without executing the code. This control ensures vulnerabilities are identified and remediated during the development phase rather than in production, enforcing security as a gating function in the continuous integration pipeline.

Control objective

What auditing this proves

Demonstrate that automated static application security testing runs on every pull request and prevents merge of code containing security vulnerabilities above an established severity threshold.

Associated risks

Risks this control addresses

Introduction of injection vulnerabilities (SQL, command, LDAP) into production code through unreviewed or untested pull requests
Hardcoded credentials, API keys, or secrets committed to the codebase and exposed in version control history
Insecure cryptographic implementations or use of deprecated algorithms merged without security review
Authentication and authorization bypass flaws introduced during feature development that evade manual code review
Cross-site scripting (XSS) or other client-side vulnerabilities merged into web application codebases
Use of vulnerable third-party libraries or components with known CVEs integrated without detection
Path traversal, insecure deserialization, or other code-level vulnerabilities reaching production environments

Testing procedure

How an auditor verifies this control

Obtain the list of all code repositories in scope and identify which contain application source code subject to SAST requirements
Review branch protection rules for primary branches (main, master, production) to verify SAST checks are configured as required status checks that must pass before merge
Select a representative sample of 10-15 recent pull requests across different repositories and development teams
For each sampled pull request, review the CI/CD pipeline execution logs to confirm SAST scans executed automatically upon PR creation or update
Examine SAST scan results for sampled pull requests to verify findings are reported with severity classifications and remediation guidance
Identify at least two pull requests where SAST detected vulnerabilities above the established threshold and confirm merge was blocked until remediation
Review configuration of the SAST tool to verify enabled rulesets, severity thresholds, and scanning scope align with organizational security policies
Interview development and DevSecOps personnel to confirm process for handling SAST findings, escalation paths, and any approved exception workflows

Evidence required Configuration exports from version control system showing branch protection rules with required SAST status checks. CI/CD pipeline configuration files (e.g., GitHub Actions workflows, GitLab CI YAML, Jenkins pipelines) demonstrating SAST tool integration. Screenshots or exports of pull request status checks showing SAST execution results, including at least two examples where vulnerabilities blocked merge. SAST tool configuration showing enabled rules, severity thresholds, and scanning parameters.

Pass criteria SAST scans execute automatically on 100% of sampled pull requests, findings are visible to developers before merge, and at least one example exists where high or critical severity findings prevented merge until remediation was completed.

Where this control is tested

Audit programs including this control

SAST / DAST / Secret Scanning in CI

The three scanners every CI/CD should run, with finding triage and trend tracking.