SAST, DAST, and SCA

The three primary disciplines of automated application security testing. Together they cover source code, running applications, and third-party dependencies — forming the quality-gate layer of a DevSecOps pipeline. Source: DevOps to DevSecOps in 9 Hours

The Three Disciplines

Discipline	Full Name	What It Tests	When It Runs	Strengths	Limitations
SAST	Static Application Security Testing	Source code / bytecode without execution	Build / compile time	Fast, finds injection flaws, secret leakage, logic errors	High false-positive rate; no runtime context
DAST	Dynamic Application Security Testing	Running application from the outside	Test / staging environment	Finds real exploitable endpoints, misconfigurations, XSS, SQLi	No source code visibility; late in SDLC
SCA	Software Composition Analysis	Open-source dependencies and libraries	Build time	Flags known CVEs, license violations, outdated packages	Only finds known vulnerabilities; zero-days undetected

SAST: Static Analysis

SAST tools parse source code to identify patterns associated with security vulnerabilities. They are the earliest automated control in the pipeline.

What SAST Finds

• Injection flaws: SQL injection, command injection, LDAP injection, XPath injection
• Insecure cryptography: Weak hashing algorithms (MD5, SHA1), hardcoded keys
• Secret leakage: API keys, passwords, tokens committed to source
• Input validation gaps: Missing sanitization on user-controlled data
• Insecure configuration: Verbose error messages, debug mode in production

SonarQube

DevOps to DevSecOps in 9 Hours uses SonarQube as the primary SAST platform. SonarQube provides:

• Quality gates: Fail builds when code coverage, duplication, or security severity thresholds are breached
• Issue tracking: Assign vulnerabilities to developers with remediation guidance
• Dashboards: Trend security debt over time
• Branch analysis: Compare feature branch quality against the main branch

Pipeline Integration

- name: SonarQube Scan
  uses: sonarsource/sonarqube-scan-action@master
  env:
    SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
    SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}

DAST: Dynamic Analysis

DAST tools attack the running application like an external adversary would. They require a deployed, functional instance (usually staging).

What DAST Finds

• Runtime misconfigurations: Exposed admin panels, default credentials, missing security headers
• Authentication weaknesses: Session fixation, weak password policies, brute-force susceptibility
• Client-side vulnerabilities: Cross-site scripting (XSS), cross-site request forgery (CSRF)
• Business logic flaws: Privilege escalation via parameter tampering, insecure direct object references (IDOR)
• API vulnerabilities: Missing rate limiting, excessive data exposure, broken authorization

OWASP ZAP

The course demonstrates OWASP ZAP (Zed Attack Proxy), an open-source DAST tool maintained by the Open Web Application Security Project. ZAP features:

• Automated scanning: Spider the application and active-scan for vulnerabilities
• Proxy mode: Manually intercept and modify requests for exploratory testing
• API scanning: OpenAPI/Swagger-driven automated REST API security tests
• CI/CD integration: Headless baseline and full scans via command line or Docker

# Baseline scan (fast, non-intrusive)
docker run -t ghcr.io/zaproxy/zaproxy:stable zap-baseline.py \
  -t https://staging.example.com
 
# Full active scan (thorough, potentially destructive — use on staging only)
docker run -t ghcr.io/zaproxy/zaproxy:stable zap-full-scan.py \
  -t https://staging.example.com -g gen.conf -r report.html

SCA: Composition Analysis

SCA tools inventory all open-source components and compare them against vulnerability databases (NVD, GitHub Advisory Database, vendor feeds).

What SCA Finds

• Known CVEs: Publicly disclosed vulnerabilities in specific library versions
• License compliance: GPL, AGPL, or proprietary conflicts that create legal risk
• Outdated dependencies: Libraries with unmaintained or deprecated status
• Transitive risk: Vulnerabilities in dependencies-of-dependencies

Integration Pattern

Most SCA is integrated into the build step because the dependency manifest (package.json, requirements.txt, pom.xml) is the source of truth:

# Snyk CLI example
snyk test --severity-threshold=high
 
# Trivy filesystem scan (also covers SCA)
trivy fs --scanners vuln .

The Layered Testing Strategy

No single discipline is sufficient. A mature pipeline runs all three:

Developer commits code
        ↓
   [SAST + SCA]  ← Build stage; fast feedback on code and dependencies
        ↓
   Unit / Integration Tests
        ↓
   Deploy to Staging
        ↓
   [DAST]  ← Test stage; runtime validation from an attacker's perspective
        ↓
   Manual Penetration Test (periodic)
        ↓
   Production
        ↓
   [Runtime Monitoring]  ← Falco, SIEM, anomaly detection

Quality Gates and SLAs

A typical DevSecOps quality gate policy:

Severity	SAST	SCA	DAST	Action
Critical	0 allowed	0 allowed	0 allowed	Block merge / deployment
High	≤ 2	≤ 2	≤ 1	Require security team approval
Medium	≤ 10	≤ 10	≤ 5	Create backlog ticket; fix in next sprint
Low	Tracked	Tracked	Tracked	Address during refactoring

Relationship to AI-Generated Code

As documented in AI Security, SAST and SCA are especially critical for AI-assisted development because LLMs may:

• Generate code with known vulnerable patterns (e.g., eval() on user input)
• Suggest outdated dependencies that contain CVEs
• Produce hardcoded credentials in generated snippets

SAST provides the deterministic safety net that catches these deterministic mistakes regardless of whether the code was written by a human or an AI.

See Also

• DevSecOps Fundamentals — The pipeline context for SAST, DAST, and SCA
• Shift Left Security — Why SAST and SCA run at build time rather than test time
• Container Security — Image scanning as a complementary fourth discipline
• Threat Modeling — Design-time risk analysis that drives testing priorities
• GitOps Security — Securing the pipeline that runs these scanners
• AI Security — Hybrid governance pattern combining SAST/SCA with LLM reasoning
• DevOps to DevSecOps in 9 Hours — Day 6: Practical demonstrations of SonarQube and OWASP ZAP in GitHub Actions

---

Tags: sast dast sca devsecops sonarqube zap pipeline security-testing quality-gates