Application Security Testing (AST): SAST, DAST, IAST and SCA

Application security testing is a systematic process for identifying security issues in software applications—before attackers do. No single method is comprehensive: SAST identifies code issues, DAST identifies configuration errors, IAST monitors runtime behavior, and SCA identifies known vulnerabilities in dependencies. Together, they form a comprehensive testing approach.

An Overview of the Four AST Methods

SAST (Static Application Security Testing)

SAST analyzes the source code or bytecode without executing the application. The analysis takes place early in the development cycle—ideally as soon as a commit is made in the CI/CD pipeline.

Advantages:

• Early detection (Shift Left!)
• Developer feedback directly in the IDE
• No running application required
• Covers logical errors (e.g., SQL injection in the code)

Disadvantages:

• Many false positives (40–60% according to Gartner)—the tool does not always understand the context
• Does not detect configuration errors
• Does not understand runtime behavior

Tools: Semgrep, SonarQube, Checkmarx, Fortify, Bandit (Python)

Typical Findings: SQL injection, path traversal, insecure deserialization, hardcoded secrets, insecure cryptography

DAST (Dynamic Application Security Testing)

DAST performs attacks against a running application—black-box testing without access to the source code. The ideal time to perform this is in the staging or pre-production environment.

Advantages:

• Finds what SAST misses (configuration, runtime behavior)
• No source code required—also works with third-party applications
• Realistic attack simulation

Disadvantages:

• Later in the lifecycle (more expensive to fix!)
• Does not find all code errors due to lack of source code access
• Slow—a full scan takes hours
• Can create database entries, send emails, etc.

Tools: OWASP ZAP, Burp Suite, Nessus (Web), StackHawk, HCL AppScan

Typical Findings: XSS, CSRF, open redirects, security misconfigurations, unauthorized endpoints, sensitive data exposure

IAST (Interactive Application Security Testing)

IAST places an agent within the running process that analyzes runtime behavior during functional and integration tests—passively and without separate test runs.

Advantages:

• High accuracy—the agent sees what is actually happening
• Few false positives (only code that is actually executed is evaluated)
• No separate test runs required (runs passively during existing tests)

Disadvantages:

• Available only for certain languages (Java, .NET, Python)
• Agent installation required
• Coverage depends on the quality of the test suite

Tools: Contrast Security, Seeker (Synopsys), Checkmarx CxIAST

Typical Findings: SQL injection (with concrete trace!), XSS, path traversal – all SAST findings confirmed by actual execution

SCA (Software Composition Analysis)

SCA analyzes third-party libraries and open-source components for known vulnerabilities. The analysis should run continuously – during development and in the CI/CD pipeline.

Advantages:

• Finds known CVEs in dependencies
• License compliance checking (GPL vs. MIT)
• SBOM generation

Disadvantages:

• Only known CVEs are detectable (not 0-days)
• Many transitive dependencies (A → B → C: C has the CVE)
• False positives: CVE affects a feature that isn’t even used

Tools: Dependabot, Trivy, Snyk, Black Duck, OWASP Dependency Check

Typical findings: Log4Shell, Spring4Shell, Struts vulnerabilities in dependencies

SAST in practice

Semgrep (Open Source)

# Installation
pip install semgrep

# Scan a Python project
semgrep --config=auto .
# auto: Semgrep Registry Rules for the detected language

SQL injection rule for Semgrep:

rules:
  - id: python-sql-injection
    patterns:
      - pattern: cursor.execute("..." + ...)
      - pattern: cursor.execute(f"...{...}...")
    message: "SQL Injection: String concatenation in SQL query! Use prepared statements."
    severity: ERROR
    languages: [python]

Custom Rule for Hardcoded API Keys:

rules:
  - id: hardcoded-api-key
    patterns:
      - pattern: |
          API_KEY = "..."
      - pattern: |
          api_key = "sk-..."
    message: "Hardcoded API Key detected! Load from environment variables."
    severity: WARNING
    languages: [python, javascript]

semgrep --config=custom-rules.yaml .

SonarQube Community (Open Source)

# Docker
docker run -d -p 9000:9000 sonarqube:community
# Interface: http://localhost:9000 (admin/admin)

# Scanner
sonar-scanner -Dsonar.projectKey=myproject \
  -Dsonar.sources=src -Dsonar.host.url=http://localhost:9000

Bandit (Python-specific)

pip install bandit
bandit -r ./src -f json -o bandit-report.json
# Output: Low/Medium/High Severity Findings

False Positive Management

SAST tools have a false positive rate of 40–60% (Gartner). The solution is suppression with justification:

query = "SELECT * FROM logs WHERE date = " + log_date  # nosec: no user input, only internal queries

The inline comment forces reflection: “Why is this safe?” All suppressions should be reviewed via pull request.

DAST with OWASP ZAP and Burp Suite

OWASP ZAP (Open Source)

Automated API scan in CI/CD:

# Docker-based
docker run -t zaproxy/zap-stable zap-api-scan.py \
  -t https://staging.firma.de/api/openapi.yaml \
  -f openapi \
  -r zap-report.html \
  -I  # ignores SSL errors in staging

# Exit code != 0 if High/Medium findings → Pipeline fails!

Full Spider + Active Scan:

docker run -t zaproxy/zap-stable zap-full-scan.py \
  -t https://staging.firma.de \
  -r zap-full-report.html \
  -m 5  # max 5 minutes for spider
# Duration: 20–60 minutes for full application

ZAP in GitHub Actions:

- name: ZAP API Scan
  uses: zaproxy/action-api-scan@v0.7.0
  with:
    target: 'https://staging.firma.de/api/openapi.yaml'
    format: openapi
    fail_action: false  # Warning, no fail (for startup)

Burp Suite Professional (commercial)

Burp Suite is the industry standard for manual penetration testing (~$499/year/user). Key modules:

• Proxy: Intercept and manipulate browser traffic
• Scanner: Automated scan (OWASP Top 10)
• Intruder: Brute-force and parameter fuzzing
• Repeater: Manual manipulation of individual requests
• Collaborator: Blind injection detection (SSRF, XXE, out-of-band)

API Security Testing

• REST APIs: OpenAPI/Swagger specification as the basis for DAST
• GraphQL: Specialized tools such as InQL or GraphQL Cop
• Authentication: Configure Bearer tokens in ZAP/Burp
• Rate Limiting: Use Burp Intruder for rapid requests
• Business Logic: Only manual testing possible—no tool can detect an "order with a negative price"

DAST Scope Definition

• Use a staging environment (never production!)
• Use test accounts (no real customer data)
• Observe rate limiting (otherwise the staging server will be overloaded)
• Inform the DBA: an active scan may create database entries
• Coordinate schedule: Scan outside of ongoing test periods

SCA and SBOM

The Log4Shell vulnerability (CVE-2021-44228, CVSS 10.0) demonstrated why dependency management is critical. An SBOM would have immediately shown: “We’re using log4j < 2.17 in 5 services!” Without an SBOM, this meant weeks of manual searching. With Dependabot or Trivy, you get an immediate alert plus a pull request with a fix.

Dependabot (GitHub)

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 10

Trivy (Aqua Security, Open Source)

# Scan container image
trivy image nginx:latest
# → Shows CVEs in the base image and installed packages

# Scan Git Repo (Dependencies + Secrets + Misconfiguration)
trivy repo https://github.com/firma/myapp
# Or locally:
trivy fs ./

# SARIF Output for GitHub Security Tab
trivy fs --format sarif --output trivy.sarif ./

Generate SBOM (Software Bill of Materials)

# Syft (Anchore)
syft ./  # Scans CWD and generates SBOM
syft nginx:latest -o spdx-json=sbom.spdx.json

# Grype (SBOM-based vulnerability scanning)
grype sbom:sbom.spdx.json

SBOM Requirement: U.S. Executive Order 14028 (2021) mandates SBOMs for software supplied to U.S. government agencies. The EU Cyber Resilience Act introduces similar requirements. NIS2 addresses software supply chain security.

OWASP Dependency Check

# Maven
mvn org.owasp:dependency-check-maven:check

# npm
npx owasp-dependency-check --project "MyApp" --scan ./node_modules
# → HTML/JSON report with CVEs in dependencies

Integrating AST into CI/CD

A complete DevSecOps pipeline combines all AST methods:

name: Security Testing Pipeline
on: [push, pull_request]

jobs:
  sast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Semgrep SAST
        uses: returntocorp/semgrep-action@v1
        with:
          config: "auto"
        env:
          SEMGREP_APP_TOKEN: ${{ secrets.SEMGREP_APP_TOKEN }}

      - name: Bandit (Python SAST)
        run: |
          pip install bandit
          bandit -r src/ -f json -o bandit.json
        continue-on-error: true

  sca:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Trivy Vulnerability Scan
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: 'fs'
          severity: 'CRITICAL,HIGH'
          exit-code: '1'

  secret-scanning:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 0
      - name: TruffleHog Secret Scan
        uses: trufflesecurity/trufflehog@main
        with:
          path: ./
          extra_args: --only-verified

  dast:
    runs-on: ubuntu-latest
    needs: [build]
    if: github.ref == 'refs/heads/main'
    steps:
      - name: ZAP API Scan
        uses: zaproxy/action-api-scan@v0.7.0
        with:
          target: 'https://staging.firma.de/openapi.yaml'
          fail_action: false

Security Gates - When to Block?

Security gates should be introduced gradually to avoid jeopardizing developer buy-in:

• Phase 1 (Start): Everything as a warning - no block
• Phase 2 (3 months): Block Critical/High SAST findings
• Phase 3 (6 months): DAST High blocks staging deployment
• Phase 4 (12 months): DAST Medium blocks production deployment

> Golden Rule: Never introduce a security gate without developer buy-in. Blocking too early will cause developers to disable the security checks.