SAST & DAST

Status: Complete
Category: Security
Default enforcement: Soft
Author: PushBackLog team

Tags

• Topic: security, quality
• Skillset: backend, frontend, devops
• Technology: generic
• Stage: execution, review

Summary

Static Application Security Testing (SAST) analyses source code for known vulnerability patterns without executing the code. Dynamic Application Security Testing (DAST) tests a running application by sending crafted HTTP requests and observing responses. Both belong in the CI/CD pipeline: SAST runs early, at commit time; DAST runs against a deployed application, typically in a staging environment. Together they provide complementary coverage of security defects that neither can find alone.

Rationale

Security testing must be automated and continuous

Manual security reviews find real vulnerabilities — but they are expensive, infrequent, and performed by specialists who are not present for every code change. An automated security gate in CI finds a subset of vulnerabilities on every commit, before code is deployed, at a cost that scales with team size rather than security budget. SAST and DAST are the principal tools for this automation.

SAST and DAST have different blind spots

SAST can never execute code — it reasons about code paths statically. It produces false positives (code that appears vulnerable but is not) and cannot detect vulnerabilities that only manifest at runtime (race conditions, environment-specific configuration flaws, injection via complex data flows). DAST executes against a real application but only sees the HTTP layer — it cannot introspect internal code logic or catch vulnerabilities that require understanding the codebase structure.

Running both provides layered coverage: SAST catches structural problems early; DAST validates runtime behaviour after deployment.

Guidance

SAST: static analysis in CI

SAST tools scan source code, dependency manifests, and infrastructure-as-code for patterns associated with known vulnerability classes.

Tools by category

Example: GitHub Actions with CodeQL

# .github/workflows/security.yml
name: Security Scan
on: [push, pull_request]

jobs:
  codeql:
    runs-on: ubuntu-latest
    permissions:
      security-events: write
    steps:
      - uses: actions/checkout@v4
      - uses: github/codeql-action/init@v3
        with:
          languages: typescript
      - uses: github/codeql-action/autobuild@v3
      - uses: github/codeql-action/analyze@v3

  sca:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm audit --audit-level=high

Managing SAST alerts

• Triage all findings — do not dismiss alerts without investigation
• Fix or suppress with justification — inline suppressions require an explanation comment
• Track open findings — unresolved SAST findings should be tracked as technical debt items
• Set a blocking threshold — critical and high findings should block merge; medium findings should alert but not block

DAST: dynamic testing against running application

DAST tools send HTTP requests (crawling, fuzzing, known attack payloads) to a running application and observe responses for signs of vulnerability.

Tools

Example: OWASP ZAP in CI (baseline scan)

# .github/workflows/dast.yml
dast:
  runs-on: ubuntu-latest
  services:
    app:
      image: myapp:${{ github.sha }}
      ports: ['3000:3000']
  steps:
    - name: ZAP Baseline Scan
      uses: zaproxy/action-baseline@v0.12.0
      with:
        target: 'http://localhost:3000'
        rules_file_name: '.zap/rules.tsv'
        fail_action: true

Integration into the development lifecycle

SAST and DAST replace neither architecture review for security nor specialist penetration testing — they are the automated, continuous, low-cost layer of defence.