SCA scanning blocks builds on critical CVEs
Demonstrate that SCA scanning tooling is configured to automatically block or fail builds when critical-severity CVEs are detected in software dependencies, preventing vulnerable code from reaching production environments.
Description
What this control does
Software Composition Analysis (SCA) scanning is integrated into the continuous integration/continuous deployment (CI/CD) pipeline to automatically detect known vulnerabilities (CVEs) in third-party libraries and dependencies. When critical-severity CVEs are identified during a build, the pipeline is configured to fail the build and prevent deployment to production or higher environments. This enforcement mechanism ensures vulnerable code cannot be promoted without remediation or explicit exception approval, reducing the window of exposure to known exploits in open-source and commercial components.
Control objective
What auditing this proves
Demonstrate that SCA scanning tooling is configured to automatically block or fail builds when critical-severity CVEs are detected in software dependencies, preventing vulnerable code from reaching production environments.
Associated risks
Risks this control addresses
- Deployment of applications containing critical-severity vulnerabilities with public exploits, enabling attackers to compromise systems using known attack patterns
- Inclusion of malicious or backdoored third-party libraries that could provide attackers with unauthorized access or enable supply chain attacks
- Exploitation of unpatched dependencies to achieve remote code execution, privilege escalation, or data exfiltration
- Compliance violations and regulatory penalties due to deployment of software with known critical vulnerabilities that could have been prevented
- Reputational damage and customer trust erosion following security incidents traced to preventable dependency vulnerabilities
- Increased incident response costs and business disruption when critical vulnerabilities are discovered post-deployment rather than pre-release
- Legal liability from breaches involving vulnerabilities listed in widely-known databases (NVD, KEV) that were not addressed prior to deployment
Testing procedure
How an auditor verifies this control
- Obtain and review the SCA tool configuration settings, including severity thresholds, build-blocking policies, and CVE data source integrations (e.g., NVD, vendor feeds).
- Identify a representative sample of 5-10 recent application builds across different repositories or projects that utilize the SCA scanning process.
- Review the CI/CD pipeline configuration files (e.g., .gitlab-ci.yml, Jenkinsfile, GitHub Actions workflows) to verify SCA scan stages are mandatory and positioned before deployment steps.
- Examine the SCA tool policy rules to confirm critical-severity CVEs trigger build failure with no automatic override or bypass mechanism available to developers.
- Review SCA scan reports and build logs from the sampled builds to identify instances where critical CVEs were detected and verify the corresponding builds failed.
- Interview DevOps or AppSec personnel to understand the exception approval process and request documentation of any waivers granted for critical CVE build blocks in the past six months.
- Conduct a controlled test by introducing a dependency with a known critical CVE into a non-production branch and initiating a build to observe whether the pipeline correctly blocks the build.
- Verify that SCA scan results are integrated with defect tracking or vulnerability management systems to ensure critical findings are tracked to resolution.
Where this control is tested