Security Sast Dast

Security SAST/DAST

Purpose

Build a security scanning pipeline with static analysis rule sets, dynamic analysis scenarios, false positive management, and CI gating.

Agent Protocol

Trigger

Exact user phrases: "SAST", "DAST", "static analysis", "dynamic analysis", "code scanning", "SonarQube", "Semgrep", "Checkmarx", "Fortify", "OWASP ZAP", "Burp Suite", "security scan pipeline", "code quality gate", "scan results", "false positive".

Input Context

Before activating, verify:

• Programming languages and frameworks in the codebase
• CI/CD platform (GitHub Actions, GitLab CI, Jenkins, CircleCI)
• SAST tool preference or existing tool (Semgrep, SonarQube, CodeQL, Checkmarx)
• DAST target environment (staging URL, authentication method, API endpoints)
• Existing scan frequency and gate thresholds

Output Artifact

Security scanning pipeline configuration as YAML and rule set files.

Response Format

# SAST pipeline step
# Semgrep rules
# Quality gate thresholds

# DAST scan script
# CI integration snippet

No preamble. No postamble. No explanations. No filler/hedging/transitions. Compress output — why use many token when few do trick.

Completion Criteria

• SAST tool configured with language-appropriate rule packs
• Custom rules written for project-specific patterns
• False positive triage workflow defined
• DAST scan configured with authenticated session handling
• CI pipeline gates set with severity thresholds
• Scan results correlated between SAST and DAST findings

Max Response Length

300 lines of configuration and rules.

Architecture / Decision Trees

SAST Tool Selection Decision Tree

What is the primary goal?
├── Custom rule writing per project patterns → Semgrep
├── Deep interprocedural / variant analysis → CodeQL
├── Quality gates and tech debt tracking → SonarQube
├── Unified platform (code + deps + containers) → Snyk Code
└── Enterprise compliance reporting → Checkmarx / Fortify

Is the repo public or private?
├── Public → Semgrep (free) + CodeQL (free for public repos)
├── Private with GitHub Advanced Security → CodeQL included
└── Private without GHAS → Semgrep (free) + SonarQube Community (free)

What languages are in the codebase?
├── Python, JavaScript/TypeScript, Java, Go → Any tool works
├── C/C++, C#, Kotlin, Swift → CodeQL or Semgrep
├── Ruby, PHP, Rust → Semgrep (best coverage)
├── Scala, Kotlin → CodeQL or Semgrep
└── 10+ languages → SonarQube (broadest support)

What is the team size?
├── <10 developers → Semgrep + ZAP (free, effective)
├── 10-50 developers → Semgrep + SonarQube + ZAP
├── 50-200 developers → Semgrep + SonarQube + Burp Pro + ZAP
└── >200 developers → Enterprise suite (Checkmarx/Fortify + Acunetix)

DAST Tool Selection Decision Tree

What is the budget?
├── $0 → OWASP ZAP (full-featured, free)
├── $500-1000/year → ZAP + Burp Suite Community
├── $5000+/year → Burp Suite Professional
└── Enterprise budget → Acunetix or Burp Enterprise

What type of application?
├── Standard web app (HTML forms, links) → Any DAST tool
├── SPA (React, Angular, Vue) → ZAP (SPA-friendly crawler) or Burp
├── API-only (REST, GraphQL) → ZAP API scan (best for OpenAPI/GraphQL)
├── Mobile app backend → Burp (mobile proxy setup)
└── Internal enterprise app → Acunetix (macro auth)

What is the scan target?
├── CI/CD (automated, pipeline) → ZAP Docker (best CI integration)
├── Manual penetration testing → Burp Suite (best manual workflow)
├── Compliance scanning → Acunetix (comprehensive reporting)
└── Production passive scanning → ZAP baseline (safe, read-only)

SAST + DAST Correlation Strategy

Findings correlation matrix:

Vulnerability Class          │ SAST Covers        │ DAST Covers
───────────────────────────────────────────────────────────────
SQL Injection                │ Source + sink      │ Confirms exploitability
XSS                          │ Sink only          │ Confirms with payload
Command Injection            │ Source + sink      │ Confirms exploitability
Path Traversal               │ Source + sink      │ Confirms exploitability
SSRF                         │ Source (limited)   │ Confirms endpoint
Authentication Bypass        │ Logic patterns     │ Confirms via session
Authorization Issues         │ Missing checks     │ Confirms via access
CSRF                         │ Missing tokens     │ Confirms via request
Insecure Deserialization     │ Dangerous calls    │ Confirms via payload
Sensitive Data Exposure      │ Hardcoded secrets  │ Confirms in response
Security Misconfiguration    │ Config analysis    │ Confirms headers/CSP
XXE                          │ Parser config      │ Confirms with payload

Workflow:
├── SAST finds potential vulnerability with file/line reference
├── Map to DAST-affected endpoint (if applicable)
├── DAST confirms exploitability with live payload
├── If SAST flags but DAST cannot confirm → manual review
├── If DAST finds but SAST didn't flag → improve SAST rules
└── Both-positive findings: highest priority for remediation

SAST Tool Details

Semgrep

Semgrep is the recommended default SAST tool for most projects. It is fast, multi-language, and excels at custom rule writing. Rule packs come from the Semgrep Registry. Rules are written in YAML with a pattern-matching syntax that can detect code patterns across function boundaries. Semgrep supports all major languages (Python, JavaScript/TypeScript, Java, Go, Rust, Ruby, C#, PHP, Kotlin, Scala) and runs in CI with diff-aware scanning. Install via pip install semgrep or use the official GitHub Action. Key strengths: pattern-based matching that goes beyond regex, support for metavariables and ellipsis operators, community-maintained rule packs, and a built-in rule testing framework.

CodeQL

CodeQL is best for deep interprocedural analysis and variant analysis. Developed by GitHub, it uses a declarative query language (QL) to find vulnerabilities across the codebase. A single CodeQL query can find all variants of a vulnerability pattern (e.g., all paths where user input reaches a SQL query). CodeQL requires a compiled database of the codebase, which is built during the CI scan step. It supports C/C++, C#, Go, Java/Kotlin, JavaScript/TypeScript, Python, and Ruby. CodeQL is free for public repositories and included in GitHub Advanced Security for private repos. Key strengths: variant analysis, data flow tracking across function and file boundaries, and deep semantic understanding of the code.

SonarQube

SonarQube is the best tool for quality gates, technical debt tracking, and broad language support. It tracks code quality metrics over time: coverage, duplicated lines, code smells, bugs, vulnerabilities, and hotspots. The quality gate is a configurable policy that blocks PRs when predefined thresholds are exceeded. SonarQube can be self-hosted (Community Edition is free) or used as SonarCloud (SaaS). It supports 30+ languages. Key strengths: historical trend tracking, quality gates as a PR policy, security hotspots that require manual review, and broad ecosystem integrations.

Snyk Code

Snyk Code is a SAST tool integrated into the Snyk platform. It is particularly strong for finding vulnerabilities in open-source dependencies and container images combined with application-level code analysis. It uses deep semantic analysis and AI to find issues with low false positive rates. Snyk Code integrates with Snyk Open Source and Snyk Container for a unified vulnerability management experience. Key strengths: low false positive rate, IDE integration for real-time feedback, and unified platform with dependency scanning and container scanning.

DAST Tool Details

OWASP ZAP

OWASP ZAP (Zed Attack Proxy) is the recommended default DAST tool. It is free, open-source, and community-maintained. ZAP can be run as a desktop application, a daemon for CI integration, or a Docker container. Scan modes: automated scan (spider → passive → active), API scan (import OpenAPI/GraphQL schema), and baseline scan (passive-only, safe for production). ZAP supports authenticated scanning via context-based session management, bearer token injection, and form-based authentication. The HUD (Heads-Up Display) mode provides browser-based interaction for manual testing. Key strengths: free and open-source, extensive active scan rules, API scanning, and Docker-native CI integration.

Burp Suite

Burp Suite is the professional standard for web application security testing. The Community Edition includes an HTTP proxy, repeater, decoder, and scanner. The Professional Edition adds automated scanning, advanced vulnerability detection, and CI integration. Burp's scanning phases: crawl (discover all endpoints), audit (automated vulnerability checks), and intruder (targeted fuzzing). Extensions from the BApp Store extend functionality: Autorize for auth bypass detection, JSON Web Tokens for JWT manipulation, and ActiveScan++ for enhanced scan coverage. Key strengths: manual testing workflow, extensive extension ecosystem, and industry-standard tooling.

Acunetix

Acunetix is a commercial DAST tool with deep scanning capabilities. It is known for its comprehensive vulnerability database covering over 7000 vulnerabilities. Acunetix supports multi-step form authentication, macro recording for complex login sequences, and integration with issue trackers (Jira, GitHub Issues). Key strengths: deep scanning for complex vulnerabilities, macro-based authentication, and enterprise reporting.

Workflow

Step 1: SAST Tool Selection

Semgrep: best for custom rule writing, multi-language, fast. SonarQube: best for quality gates, technical debt tracking, broad language support. CodeQL: best for deep interprocedural analysis, variant analysis. Checkmarx/Fortify: enterprise-grade with compliance reporting. Default choice: Semgrep for SAST + SonarQube for quality gates.

Step 2: Rule Configuration

Enable built-in rule packs: Semgrep p/security-audit, p/owasp-top-ten, p/command-injection. Write custom rules for project-specific patterns: hardcoded secrets, dangerous function usage, missing authorization checks, SQL injection via ORM bypass. Rule severity: ERROR (must fix), WARN (should fix), INFO (suggested). False positives: tag with fp metadata and documented reason.

Step 3: CI Integration

SAST runs on every PR — diff-aware scanning for changed files only. Full scan on main branch daily. Quality gates: 0 ERROR severity findings, WARN count must not increase, coverage threshold for new code. DAST runs on staging deployment — weekly full scan, on-demand for critical releases. Pipeline blocks on critical findings.

Step 4: DAST Scanning

OWASP ZAP: automated scan with API context, authenticated session management via bearer token or form auth. Burp Suite: manual testing with targeted scope. Scan profile: spider (crawl all pages), active scan (inject payloads), fuzzing (parameter mutation). Exclude logout, password change, and high-volume endpoints from active scanning.

Step 5: False Positive Management

Triage workflow: automated deduplication → security review → mark as FP/WONT-FIX/ACCEPTED-RISK. Store decisions in .sast-fps.yml per project. Suppress known FP with reason comment and expiry date. Review suppressed rules quarterly.

Step 6: Custom Query Writing

Semgrep custom rules follow a standard pattern: rule ID in kebab-case, severity (ERROR/WARN/INFO), languages array, and patterns (match, exclude, condition). Test rules with positive and negative test cases annotated with ruleid: and ok: comments. Run semgrep --test to validate. Store custom rules in .semgrep/rules/ organized by vulnerability category. Each rule directory has a tests/ subdirectory with test files.

Step 7: Authenticated DAST Scanning

For applications requiring authentication, configure the scan context: define the login URL, authentication type (form-based, bearer token, OAuth), credentials, and session cookie name. ZAP uses a context file (.context) that defines the URL regex, authentication script, and session management. For API-focused applications, use API keys or bearer tokens in request headers. Test authentication before running a full scan by verifying the auth token/cookie is correctly injected into scan requests.

Step 8: Scan Scope Management

Define the DAST scan scope precisely to avoid scanning out-of-scope endpoints. In-scope: the application's own domains and subdomains. Out-of-scope: third-party CDNs, analytics endpoints, authentication providers, social login. Scope is defined as URL regex patterns in the scan tool. For API scanning, scope is defined by the OpenAPI/Swagger specification paths. Exclude destructive endpoints (DELETE, mass-update) from active scanning.

Step 9: Results Correlation

Map SAST findings to affected endpoints in DAST scope. Prioritize findings that appear in both analyses. Track finding age: 0-7 days (active), 7-30 days (aging), 30+ days (overdue). Generate weekly trend report by severity and category.

SAST Tool Comparison Matrix

DAST Tool Comparison Matrix

Scan Scheduling Matrix

Finding Severity Triage Flow

New Finding → Automated Dedup → Categorize Severity
  ├── CRITICAL: Immediate fix (24h SLA) → Hotfix PR required
  ├── HIGH: Fix in current sprint (72h SLA) → Bug ticket created
  ├── MEDIUM: Fix within 2 sprints → Backlog item
  └── LOW: Fix when convenient → Icebox
        │
        └── Review → Is it a real vulnerability?
              ├── Yes → Assign to team, create remediation ticket
              ├── FP → Add to .sast-fps.yml with reason
              └── WONT-FIX → Document accepted risk, get security team approval

Remediation SLA Matrix

Common Pitfalls

Pitfall 1: Running Full SAST on Every PR

Full codebase scans take 30-60 minutes, blocking CI pipelines. Use diff-aware scanning for PRs (Semgrep --baseline-commit, SonarQube new code analysis). Save full scans for nightly builds.

Pitfall 2: DAST on Production Without Care

Active DAST scanning sends malicious payloads that can corrupt data, trigger alerts, or crash services. Always target staging or a dedicated test environment. Production scans must be passive-only (ZAP baseline, read-only checks).

Pitfall 3: No False Positive Triage Backlog

Without a documented FP process, teams ignore scan results entirely. Create a .sast-fps.yml file per project, tag findings with rationale, and review quarterly.

Pitfall 4: Ignoring SAST-DAST Correlation

SAST finds code-level issues. DAST finds runtime issues. They complement each other but are often run in isolation. Correlate findings: SAST flags the source, DAST confirms exploitability. Prioritize correlated findings.

Pitfall 5: Overly Permissive Scan Scope

DAST scanning third-party endpoints, analytics services, or auth providers causes false positives and may violate terms of service. Define scope precisely with URL regex patterns.

Pitfall 6: No Authenticated DAST Scanning

Scanning only unauthenticated pages misses 80% of application logic. Always configure authenticated sessions. Test authentication injection before full scan execution.

Pitfall 7: Using Default Rules Only

Default rule packs are generic and miss project-specific patterns. Write custom rules for your framework, authentication model, and business logic.

Pitfall 8: No Severity-Based SLA

Without severity-defined SLAs, critical findings sit alongside low-priority ones. Set SLAs: CRITICAL 24h, HIGH 72h, MEDIUM 2 sprints, LOW per backlog.

Pitfall 9: Blocking CI on Everything

Blocking on WARN or INFO findings creates friction and leads to rule bypass. Block only on ERROR/CRITICAL. Use WARN to trend, not to block.

Pitfall 10: No Historical Trend Tracking

Without trend data, you cannot tell if security posture is improving or degrading. SonarQube tracks metrics over time. Generate weekly trend reports by severity.

Best Practices

• Run SAST on every PR diff (Semgrep --baseline-commit). Full scan nightly.
• Use multiple SAST tools in combination: Semgrep (custom rules, speed) + SonarQube (quality gates, trends).
• Run DAST on staging every full scan; quick baseline per deployment.
• Correlate SAST and DAST findings. Prioritize issues confirmed by both.
• Define severity-based SLAs with automated ticket creation.
• Store false positive decisions in version-controlled files with expiry dates.
• Write custom Semgrep rules for your framework and patterns. Test with semgrep --test.
• Write custom CodeQL queries for complex data-flow vulnerabilities.
• Test authentication injection before running full DAST scans.
• Exclude destructive and high-volume endpoints from DAST active scanning.
• Track finding age: 0-7d active, 7-30d aging, 30d+ overdue.
• Review false positive decisions quarterly. Remove stale entries.
• Generate weekly trend reports shared with the engineering team.
• Include SAST findings in code review PR template.

Compared With

Semgrep vs CodeQL

Semgrep is faster and easier for custom rule writing (YAML patterns, simple syntax). CodeQL provides deeper interprocedural analysis but requires a compiled database and QL query language. Choose Semgrep for quick custom rules, CodeQL for variant analysis and complex data-flow tracing.

Semgrep vs SonarQube

Semgrep focuses on finding vulnerabilities with custom patterns. SonarQube tracks overall code health: coverage, duplication, code smells, technical debt. They are complementary. Use Semgrep for SAST detection. Use SonarQube for quality gates and trends.

ZAP vs Burp Suite

ZAP is free, open-source, and CI-friendly (Docker, CLI). Burp Suite Pro offers better manual testing workflows and a rich extension ecosystem. Use ZAP for CI/CD automation. Use Burp for professional manual pentesting.

ZAP vs Acunetix

ZAP is free with community support. Acunetix is commercial with deeper scanning, macro auth recording, and enterprise compliance reporting. Use ZAP for regular CI scanning. Use Acunetix for quarterly compliance scans.

SAST vs DAST

SAST finds issues early in development (shift-left) with file/line precision. DAST finds runtime issues with exploitability confirmation. SAST has higher false positive rate. DAST has higher true positive rate but finds issues later. Use both for defense in depth.

Performance Considerations

• Semgrep diff scan: <5s for typical PR diff (100-500 lines). Full scan: 1-5min per 100K lines.
• CodeQL database build: 5-30min depending on language and codebase size. Query execution: 1-10min.
• SonarQube scan: 15-60min for full codebase. New code analysis: <5min for PR.
• ZAP baseline scan: 15-30min for typical app. ZAP active scan: 2-4h for medium app.
• Burp Suite scan: 4-8h for full audit of medium application.
• Acunetix scan: 2-6h for full deep scan.
• CI pipeline time budget: SAST <5min, DAST baseline <30min, DAST active (nightly).
• Resource usage: SAST tools need 1-4GB RAM per concurrent scan. DAST tools need 2-8GB.
• Parallel scans: run SAST + DAST in parallel in CI. SAST gates before merge, DAST reports after.
• Scan frequency: PR-level SAST, daily full SAST, per-deployment DAST baseline, weekly DAST active.

Semgrep Custom Rule Examples

Rule: Hardcoded AWS Credentials

# .semgrep/rules/security/aws-creds.yml
rules:
  - id: hardcoded-aws-creds
    patterns:
      - pattern-regex: (?:AWS_ACCESS_KEY_ID|AWS_SECRET_ACCESS_KEY)\s*=\s*['"](?!\{\{)
      - pattern-not-regex: \{\{.*\}\}
    message: "Hardcoded AWS credential detected"
    severity: ERROR
    languages: [generic]
    metadata:
      category: security
      technology: aws

Rule: SQL Injection via String Interpolation

# .semgrep/rules/security/sql-injection.yml
rules:
  - id: sql-injection-py
    patterns:
      - pattern: |
          cursor.execute(f"...$QUERY...")
      - pattern-not: |
          cursor.execute("...", ...)
    message: "SQL injection via f-string interpolation"
    severity: ERROR
    languages: [python]
    metadata:
      cwe: CWE-89
      owasp: A03:2021

Rule: NoSQL Injection

# .semgrep/rules/security/nosql-injection.yml
rules:
  - id: mongodb-nosql-injection
    patterns:
      - pattern: |
          $DB.find({ $KEY: { "\$where": $VAL } })
      - pattern-not: |
          $DB.find({ $KEY: { "\$where": literal($VAL) } })
    message: "NoSQL injection via $where operator"
    severity: ERROR
    languages: [javascript, typescript]

CI Pipeline Configuration Examples

GitHub Actions — SAST + DAST Pipeline

# .github/workflows/security-scan.yml
name: Security Scan
on:
  pull_request:
    branches: [main]
  push:
    branches: [main]
jobs:
  sast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Semgrep SAST
        uses: semgrep/semgrep-action@v1
        with:
          config: >-
            p/security-audit
            p/owasp-top-ten
            .semgrep/rules/
          auditOn: push
          generateSarif: true
      - name: Upload SARIF
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: semgrep.sarif
  dast:
    needs: deploy-staging
    runs-on: ubuntu-latest
    steps:
      - name: ZAP Baseline Scan
        uses: zaproxy/action-baseline@v0.12
        with:
          target: https://staging.example.com
          rules_file_name: .zap/rules.tsv
          cmd_options: '-a'

Quality Gate Configuration

# .github/security-gates.yml
quality_gates:
  sast:
    error_threshold: 0
    warn_threshold: 10
    block_on_error: true
    block_on_warn: false
  dast:
    high_findings_threshold: 0
    medium_findings_threshold: 5
    block_on_high: true
    block_on_medium: false

SAST/DAST Maturity Model

Level 1: Basic (Ad-hoc)

Manual scanning by security team. No CI integration. No defined SLAs. Findings tracked in spreadsheets. No correlation between SAST and DAST.

Level 2: Standardized (CI-Integrated)

SAST runs in CI on every PR. DAST runs weekly on staging. Basic severity-gated policy (block on CRITICAL). False positives tracked in YAML files. Weekly scan reports.

Level 3: Advanced (Automated)

Diff-aware SAST + full daily scan. DAST baseline per deployment + full DAST weekly. Custom rules for framework-specific patterns. SAST-DAST correlation with prioritized backlog. SLAs enforced with automated ticket creation.

Level 4: Optimized (Continuous)

Real-time scanning in IDE. AI-assisted false positive triage. Automated rule generation from incident patterns. Runtime verification correlates SAST findings with live behavior. Supply chain + SAST + DAST unified risk scoring. Self-healing: auto-rollback on critical findings in production.

SAST Anti-Patterns

Anti-Pattern: Blocking All Findings

Blocking CI on MEDIUM or LOW findings creates negative developer sentiment and leads to rule bypass. Block only on ERROR/CRITICAL/confirmed HIGH. Use lower severity for trends and education only.

Anti-Pattern: Running Only Default Rules

Default rule packs are generic and miss framework-specific vulnerabilities. Always add custom rules for your ORM, auth library, template engine, and serialization framework.

Anti-Pattern: No False Positive Feedback Loop

Without documenting and reviewing false positives, the same noise appears in every scan. Developers learn to ignore results. Create .sast-fps.yml with rationale, review quarterly.

Anti-Pattern: SAST Without DAST Correlation

SAST produces theoretical findings; DAST confirms exploitation. Running SAST in isolation generates high noise. Prioritize findings confirmed by both tools.

Anti-Pattern: DAST on Production

Active DAST scanning sends real attack payloads that can corrupt data, trigger security alerts, or crash services. Target staging or dedicated test environments. Production gets passive baseline only.

DAST Anti-Patterns

Anti-Pattern: Unauthenticated Scanning Only

Scanning only public pages misses 80-90% of the application attack surface. Always configure authenticated sessions with the appropriate user role. Test authentication injection before full scan.

Anti-Pattern: No Scope Definition

Scanning without URL scope includes third-party services, CDNs, and auth providers. This generates irrelevant alerts and may violate terms of service. Define scope with precise regex patterns.

Anti-Pattern: Ignoring API Endpoints

Modern applications have more API endpoints than UI pages. DAST must cover REST, GraphQL, and gRPC endpoints using OpenAPI/GraphQL schema imports. API-only scans with ZAP or dedicated API scanners.

Anti-Pattern: No Rate Limiting in DAST

Default scan speeds can overwhelm staging environments. Configure delays: -t for threads, -d for delay in ZAP. For API scanning, respect rate limits to avoid false network error findings.

SRE/Operations Considerations

• SAST runner memory: 2-4GB RAM minimum for full codebase scans. Diff scans need <1GB.
• ZAP Docker container: 2-4GB RAM for active scans, 1GB for baseline. CPU: 2-4 cores.
• Scan duration budgets: SAST diff <5min, SAST full <60min, ZAP baseline <30min, ZAP active <4h.
• Schedule full SAST and DAST scans during off-peak hours to avoid CI congestion.
• Store scan artifacts (SARIF, HTML reports, raw logs) for 90 days minimum for compliance.
• Parallel scan execution: SAST + dependency scan run in parallel. DAST runs after staging deployment.
• Cache SAST databases and dependency scan caches across CI runs for faster execution.
• Monitor scan infrastructure: disk space for reports, memory for ZAP active scans, network bandwidth for DAST.

Rules

• DAST targets staging only — never production
• Custom Semgrep rules stored in .semgrep/rules/ with tests
• False positives documented with rationale, not silently suppressed
• Quality gate blocks on any ERROR severity finding
• DAST excludes destructive endpoints (DELETE, mass-update)
• Scan results stored for 90 days minimum
• Container image scanning is handled by a separate skill

References

• references/dast-automation.md — DAST Automation
• references/dast-tools.md — DAST Tools
• references/sast-dast-advanced.md — Sast Dast Advanced Topics
• references/sast-dast-fundamentals.md — Sast Dast Fundamentals
• references/sast-rules-customization.md — SAST Rule Customization
• references/sast-tools.md — SAST Tools
• references/sast-tool-selection-integration.md — SAST tool selection and CI integration guide
• references/dast-scoping-execution.md — DAST scoping, execution, and reporting patterns

Handoff

security-api-security for API-specific scanning and protection rules devops-ci-cd for pipeline integration and deployment gates