SAST/DAST Pipeline Integration Guide

## ROLE
You are a DevSecOps engineer who has integrated security testing into CI/CD pipelines for organizations running [PIPELINE VOLUME: 50 / 200 / 1000+] builds per day. You understand the critical balance between security thoroughness and developer velocity — a security gate that blocks every build will be bypassed, while one that catches nothing provides false confidence.

## OBJECTIVE
Integrate SAST and DAST tools into the CI/CD pipeline for [ORGANIZATION NAME] running [CI PLATFORM: GitHub Actions / GitLab CI / Jenkins / CircleCI / Azure DevOps / Bitbucket Pipelines]. The codebase consists of [NUMBER] repositories in [LANGUAGES: JavaScript/TypeScript / Python / Java / Go / Ruby / C# / PHP / Rust] with [DEPLOYMENT FREQUENCY: continuous / daily / weekly] deployments to [ENVIRONMENT: Kubernetes / ECS / Lambda / VMs / PaaS].

## TASK

### SAST (Static Application Security Testing)

**Tool Selection for [PRIMARY LANGUAGE]:**

| Tool | Languages | Strengths | Integration |
|------|-----------|-----------|-------------|
| [SAST TOOL 1: Semgrep] | Multi-language | Custom rules, fast, low false positives | CLI, CI native, IDE |
| [SAST TOOL 2: SonarQube/SonarCloud] | Multi-language | Code quality + security, quality gates | CI plugin, PR decoration |
| [SAST TOOL 3: CodeQL] | Multi-language | Deep dataflow analysis, GitHub native | GitHub Actions, CLI |
| [SAST TOOL 4: Bandit/Brakeman/ESLint-security] | Language-specific | Focused, fast, well-maintained | CLI, pre-commit hooks |
| [SAST TOOL 5: Snyk Code / Checkmarx / Fortify] | Multi-language | Enterprise features, compliance reporting | CI plugin, IDE, API |

**Recommended Multi-Layer Approach:**
1. **Pre-commit (developer machine)**: [LIGHTWEIGHT TOOL: Semgrep / ESLint security rules / language-specific linter] — catches obvious issues before they enter the repository. Must complete in under [SECONDS: 10-30] seconds
2. **PR check (CI pipeline)**: [PRIMARY SAST TOOL] — full analysis on changed files with PR annotations showing exactly where the vulnerability is and how to fix it
3. **Main branch (scheduled)**: [DEEP ANALYSIS TOOL: CodeQL / SonarQube] — comprehensive analysis including cross-file dataflow that is too slow for PR checks

**SAST Pipeline Configuration for [CI PLATFORM]:**
```yaml
# Stage: SAST Scanning
[SAST_STAGE_NAME]:
  [TRIGGER: on pull request / on push to main / scheduled]
  steps:
    - name: Checkout code
      [CHECKOUT_ACTION]

    - name: Run SAST scanner
      [SCANNER_ACTION_OR_COMMAND]
      with:
        config: [CONFIG_FILE_PATH]
        severity-threshold: [THRESHOLD: error / warning / note]
        output-format: sarif
        output-file: sast-results.sarif

    - name: Upload results to [DESTINATION: GitHub Security / SonarQube / Defect Dojo]
      [UPLOAD_ACTION]
      with:
        sarif-file: sast-results.sarif

    - name: Quality gate check
      run: |
        # Parse SARIF and enforce thresholds
        CRITICAL=$([PARSE_SARIF_COMMAND] --severity critical)
        HIGH=$([PARSE_SARIF_COMMAND] --severity high)
        if [ "$CRITICAL" -gt 0 ]; then
          echo "SAST found $CRITICAL critical findings — blocking merge"
          exit 1
        fi
        if [ "$HIGH" -gt [MAX_HIGH_ALLOWED] ]; then
          echo "SAST found $HIGH high findings — exceeds threshold of [MAX_HIGH_ALLOWED]"
          exit 1
        fi
```

**Custom SAST Rules for [ORGANIZATION NAME]:**
Create organization-specific rules for patterns unique to your codebase:

```yaml
# Example Semgrep custom rule for [PATTERN]
rules:
  - id: [RULE_ID]
    patterns:
      - pattern: [CODE_PATTERN_TO_DETECT]
      - pattern-not: [SAFE_PATTERN_TO_EXCLUDE]
    message: |
      [DEVELOPER-FRIENDLY EXPLANATION OF WHY THIS IS A PROBLEM]
      Fix: [SPECIFIC REMEDIATION GUIDANCE]
      Reference: [INTERNAL_WIKI_LINK]
    severity: [ERROR / WARNING]
    metadata:
      category: security
      cwe: [CWE-NUMBER]
      confidence: [HIGH / MEDIUM / LOW]
```

**Common custom rules to create:**
- Hardcoded secrets patterns specific to [YOUR SECRET FORMATS]
- Unsafe deserialization of user input in [FRAMEWORK]
- Missing authorization checks on [SENSITIVE ENDPOINTS]
- Direct database queries bypassing the ORM in [ORM FRAMEWORK]
- Logging of sensitive fields: [FIELDS TO NEVER LOG]
- Deprecated internal API usage that has been replaced with secure alternatives

### DAST (Dynamic Application Security Testing)

**Tool Selection:**

| Tool | Type | Best For | Integration Complexity |
|------|------|----------|----------------------|
| [DAST TOOL 1: OWASP ZAP] | Open source | Comprehensive web app scanning | Medium (Docker, CLI, API) |
| [DAST TOOL 2: Nuclei] | Open source | Template-based, fast, extensible | Low (CLI, CI native) |
| [DAST TOOL 3: Burp Suite Enterprise] | Commercial | Deep crawling, advanced detection | Medium (API, CI plugin) |
| [DAST TOOL 4: StackHawk] | Commercial | Developer-friendly, CI-native DAST | Low (CI native, PR integration) |
| [DAST TOOL 5: Invicti/Acunetix] | Commercial | Enterprise compliance, scheduling | Medium (API, webhook) |

**DAST Pipeline Integration:**
DAST requires a running application to scan. Integration approach:

**Option A — Scan staging after deployment:**
```yaml
[DAST_STAGE_NAME]:
  [TRIGGER: after deployment to staging]
  steps:
    - name: Wait for deployment health check
      run: |
        for i in $(seq 1 [MAX_RETRIES]); do
          if curl -s -o /dev/null -w "%{http_code}" [STAGING_URL]/health | grep -q "200"; then
            echo "Application is healthy"
            break
          fi
          sleep [WAIT_SECONDS]
        done

    - name: Run DAST scan
      [DAST_SCANNER_COMMAND]
        --target [STAGING_URL]
        --config [DAST_CONFIG_FILE]
        --auth-type [AUTH_TYPE: form / bearer / cookie / header]
        --auth-config [AUTH_CONFIG_FILE]
        --exclude-urls [EXCLUDE_PATTERNS]
        --output dast-results.[FORMAT: json / sarif / html]

    - name: Process results
      run: |
        # Filter false positives using baseline file
        [FILTER_COMMAND] --baseline [BASELINE_FILE] --results dast-results.json --output filtered-results.json

        # Check against thresholds
        CRITICAL=$([PARSE_COMMAND] filtered-results.json --severity critical)
        if [ "$CRITICAL" -gt 0 ]; then
          echo "DAST found $CRITICAL critical vulnerabilities"
          [NOTIFICATION_COMMAND]
          exit 1
        fi
```

**Option B — Ephemeral environment per PR:**
```yaml
# Deploy PR-specific environment
- name: Deploy preview environment
  [DEPLOY_PREVIEW_COMMAND]

# Run DAST against preview
- name: DAST scan preview
  [DAST_SCANNER_COMMAND] --target [PREVIEW_URL]

# Tear down after scan
- name: Destroy preview environment
  [TEARDOWN_COMMAND]
```

**DAST Authentication Configuration:**
For scanning authenticated application areas:
```json
{
  "authentication": {
    "type": "[FORM / OAUTH / API_KEY / COOKIE]",
    "login_url": "[LOGIN_ENDPOINT]",
    "credentials": {
      "username": "[TEST_USER — never production credentials]",
      "password": "[FROM_SECRET_MANAGER]"
    },
    "verification": {
      "url": "[AUTHENTICATED_PAGE_URL]",
      "indicator": "[ELEMENT OR TEXT CONFIRMING LOGIN SUCCESS]"
    },
    "session_management": {
      "token_location": "[COOKIE / HEADER / BODY]",
      "token_name": "[TOKEN_NAME]",
      "refresh_strategy": "[RE-AUTHENTICATE / REFRESH_TOKEN]"
    }
  }
}
```

**DAST Scan Profiles:**
Define different scan profiles for different pipeline stages:
- **Quick scan (PR pipeline)**: Active scan of [TOP 10 VULNERABILITY CLASSES] only, [DURATION: 5-15 min] max, scan only new/changed endpoints
- **Standard scan (staging deploy)**: Full active scan excluding destructive tests (no delete operations, no form submission flooding), [DURATION: 30-60 min]
- **Comprehensive scan (weekly scheduled)**: Full crawl + active scan + fuzzing, [DURATION: 2-4 hours], run during [OFF-PEAK HOURS]

### False Positive Management

**Baseline and Suppression Strategy:**
- Maintain a [BASELINE FILE: .zap-baseline.json / .semgrep-ignore / suppressions.yaml] in each repository
- Each suppression must include: finding ID, justification, reviewer, expiration date
- Review all suppressions [FREQUENCY: quarterly] — expired suppressions re-alert
- Track false positive rate per tool: if exceeding [THRESHOLD: 20%], tune rules or switch tools

**Triage Workflow:**
1. New finding appears in PR check
2. Developer reviews with context (code snippet, vulnerability explanation, fix suggestion)
3. Developer either: fixes the issue → PR passes / marks as false positive with justification → security team reviews
4. Security team reviews false positive claims [FREQUENCY: within 24 hours]
5. Approved suppressions added to baseline, rejected ones must be fixed before merge

### Metrics and Continuous Improvement

**Track monthly:**
- SAST/DAST findings per scan (trend over time — should decrease)
- Mean time to remediate security findings by severity
- False positive rate by tool and rule category
- Pipeline impact: Additional time added by security scanning
- Developer satisfaction: Survey on security tooling friction [FREQUENCY: quarterly]
- Escaped vulnerabilities: Security findings discovered in production that SAST/DAST should have caught

**Quarterly tuning:**
- Disable rules with >50% false positive rate, investigate root cause
- Add custom rules for vulnerability patterns discovered in production
- Update DAST scan configurations for new application features
- Benchmark scan times and optimize for pipeline performance
- Review and update severity thresholds based on risk appetite changes