4.1.3.1. SCA, SAST, and DAST: Security Scanning in Pipelines

4.1.3.1. SCA, SAST, and DAST: Security Scanning in Pipelines

Security scanning in CI/CD pipelines catches vulnerabilities before they reach production. Dependency scanning (Software Composition Analysis — SCA) identifies known vulnerabilities in third-party packages by comparing dependency versions against advisory databases. GitHub Advanced Security (GHAS) provides CodeQL for semantic code analysis and secret scanning for leaked credentials. Dependabot alerts and security updates are not part of GHAS — they are free on every repository, which matters when you are costing a rollout. SonarQube extends beyond security to code quality: bugs, code smells, and technical debt metrics. Microsoft Defender for Cloud DevOps Security provides a unified dashboard across Azure DevOps and GitHub, correlating security findings with deployment context. DAST (Dynamic Application Security Testing) tests running applications for vulnerabilities like SQL injection and XSS that static analysis can't detect. The scanning pipeline should fail builds on Critical/High findings while tracking Medium/Low for remediation.

Static Application Security Testing (SAST) analyzes source code for vulnerabilities without executing it. CodeQL (GitHub Advanced Security) performs semantic analysis — understanding data flow through the application to detect injection vulnerabilities, authentication bypasses, and sensitive data exposure. SAST rules are language-specific; CodeQL supports 10+ languages with growing query libraries.

Software Composition Analysis (SCA) scans dependency manifests (package.json, pom.xml, requirements.txt) against vulnerability databases (NVD, GitHub Advisory Database). Dependabot (GitHub) automatically raises pull requests to update vulnerable dependencies. GitHub Advanced Security for Azure DevOps reports vulnerable dependencies but does not open update pull requests, so remediation there is driven by the team. The challenge: transitive dependencies. Your app uses Library A, which depends on Library B, which has a critical CVE. The fix might require Library A to release a new version — outside your control.

Secret scanning detects committed credentials — API keys, connection strings, tokens — in repository content and history. GitHub secret scanning partners with service providers to automatically revoke detected tokens. Push protection blocks commits containing known secret patterns before they enter history, which is far better than detection after the fact.

DAST (Dynamic Application Security Testing) tests running applications by sending malicious inputs and observing responses. OWASP ZAP integration in pipelines deploys the application to a test environment, runs the ZAP spider and active scanner, and fails the pipeline if high-severity findings are detected. DAST catches runtime vulnerabilities (SQL injection, XSS, CSRF) that SAST misses because they depend on deployment configuration.

The scanning pipeline should define clear policies per severity: Critical findings block the build immediately, High findings block within 7 days (allowing time for investigation), Medium findings create tracking work items, and Low findings are logged for quarterly review. This graduated response prevents security fatigue while maintaining urgency for genuine risks. False positive management is equally important — maintain an exceptions list with justifications and review dates.

Software Bill of Materials (SBOM) generation creates a machine-readable inventory of all components in a deployed artifact. SPDX and CycloneDX formats are industry standards. SBOMs enable rapid vulnerability response — when a new CVE is published, query your SBOM database to identify which applications are affected without scanning every repository.

Vulnerability triage workflows prevent alert fatigue. Not every CVE requires immediate action. Severity (Critical/High/Medium/Low) combined with exploitability and exposure determines priority.