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

Application Security Testing ist das systematische Vorgehen um Sicherheitsprobleme in Softwareanwendungen zu finden - bevor Angreifer sie finden. Keine einzelne Methode ist vollständig: SAST findet Code-Probleme, DAST findet Konfigurationsfehler, IAST beobachtet Laufzeitverhalten, SCA findet bekannte Schwachstellen in Abhängigkeiten. Die Kombination ergibt einen umfassenden Test-Ansatz.

Die vier AST-Methoden im Überblick

SAST (Static Application Security Testing)

SAST analysiert den Quellcode oder Bytecode ohne die Anwendung auszuführen. Die Analyse geschieht früh im Entwicklungszyklus - idealerweise bereits beim Commit in der CI/CD-Pipeline.

Vorteile:

• Frühe Entdeckung (Shift Left!)
• Developer-Feedback direkt in der IDE
• Keine laufende Anwendung nötig
• Deckt logische Fehler ab (z. B. SQL Injection im Code)

Nachteile:

• Viele False Positives (40-60% laut Gartner) - das Tool versteht den Kontext nicht immer
• Findet keine Konfigurationsfehler
• Versteht Runtime-Verhalten nicht

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

Typische Findings: SQL Injection, Path Traversal, Insecure Deserialization, Hardcoded Secrets, unsichere Kryptographie

DAST (Dynamic Application Security Testing)

DAST führt Angriffe gegen eine laufende Anwendung aus - Black-Box-Testing ohne Zugang zum Quellcode. Der ideale Zeitpunkt ist in der Staging- oder Pre-Production-Umgebung.

Vorteile:

• Findet, was SAST übersieht (Konfiguration, Laufzeitverhalten)
• Kein Quellcode erforderlich - funktioniert auch bei Drittanbieter-Applikationen
• Realistische Angriffssimulation

Nachteile:

• Später im Lifecycle (teurer zu fixen!)
• Findet nicht alle Code-Fehler mangels Quellcode-Zugang
• Langsam - ein vollständiger Scan dauert Stunden
• Kann Datenbankeinträge anlegen, E-Mails senden etc.

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

Typische Findings: XSS, CSRF, Open Redirects, Security Misconfigurations, unautorisierte Endpoints, Sensitive Data Exposure

IAST (Interactive Application Security Testing)

IAST platziert einen Agent im laufenden Prozess, der das Laufzeitverhalten während der Funktions- und Integrationstests analysiert - passiv und ohne separate Test-Läufe.

Vorteile:

• Hohe Genauigkeit - der Agent sieht, was tatsächlich passiert
• Wenig False Positives (nur tatsächlich durchlaufener Code wird bewertet)
• Keine separaten Test-Läufe nötig (läuft passiv während bestehender Tests)

Nachteile:

• Nur für bestimmte Sprachen verfügbar (Java, .NET, Python)
• Agent-Installation erforderlich
• Coverage abhängig von der Qualität der Test-Suite

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

Typische Findings: SQL Injection (mit konkretem Trace!), XSS, Path Traversal - alle SAST-Findings bestätigt durch tatsächliche Ausführung

SCA (Software Composition Analysis)

SCA analysiert Drittbibliotheken und Open-Source-Komponenten auf bekannte Schwachstellen. Die Analyse sollte kontinuierlich laufen - in der Entwicklung und in der CI/CD-Pipeline.

Vorteile:

• Findet bekannte CVEs in Dependencies
• License-Compliance-Prüfung (GPL vs. MIT)
• SBOM-Generierung

Nachteile:

• Nur bekannte CVEs erkennbar (0-Days nicht)
• Viele transitive Dependencies (A → B → C: C hat die CVE)
• False Positives: CVE betrifft ein Feature, das gar nicht genutzt wird

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

Typische Findings: Log4Shell, Spring4Shell, Struts-Lücken in Abhängigkeiten

SAST in der Praxis

Semgrep (Open Source)

# Installation
pip install semgrep

# Scan eines Python-Projekts
semgrep --config=auto .
# auto: Semgrep Registry Rules für die erkannte Sprache

SQL-Injection-Regel für Semgrep:

rules:
  - id: python-sql-injection
    patterns:
      - pattern: cursor.execute("..." + ...)
      - pattern: cursor.execute(f"...{...}...")
    message: "SQL Injection: String-Konkatenation in SQL-Query! Prepared Statements verwenden."
    severity: ERROR
    languages: [python]

Custom Rule für Hardcoded API Keys:

rules:
  - id: hardcoded-api-key
    patterns:
      - pattern: |
          API_KEY = "..."
      - pattern: |
          api_key = "sk-..."
    message: "Hardcoded API Key erkannt! Aus Umgebungsvariablen laden."
    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-spezifisch)

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

False Positive Management

SAST-Tools haben eine False-Positive-Rate von 40-60% (Gartner). Die Lösung ist Suppression mit Begründung:

query = "SELECT * FROM logs WHERE date = " + log_date  # nosec: kein User-Input, nur interne Abfragen

Der Inline-Kommentar erzwingt Nachdenken: „Warum ist das sicher?” Alle Suppressions sollten per Pull Request reviewed werden.

DAST mit OWASP ZAP und Burp Suite

OWASP ZAP (Open Source)

Automatisierter API-Scan in CI/CD:

# Docker-basiert
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  # ignoriert SSL-Fehler in Staging

# Exit-Code != 0 wenn High/Medium Findings → Pipeline schlägt fehl!

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 Minuten Spider
# Dauer: 20-60 Minuten für vollständige Anwendung

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, kein Fail (für Start)

Burp Suite Professional (kommerziell)

Burp Suite ist der Branchenstandard für manuelle Penetrationstests (~499 USD/Jahr/User). Die wichtigsten Module:

• Proxy: Browser-Traffic abfangen und manipulieren
• Scanner: Automatisierter Scan (OWASP Top 10)
• Intruder: Brute-Force und Fuzzing von Parametern
• Repeater: Manuelle Manipulation einzelner Requests
• Collaborator: Blind-Injection-Erkennung (SSRF, XXE, Out-of-Band)

API Security Testing

• REST APIs: OpenAPI/Swagger-Spezifikation als Basis für DAST
• GraphQL: Spezielle Tools wie InQL oder GraphQL Cop
• Authentication: Bearer Token in ZAP/Burp konfigurieren
• Rate Limiting: Burp Intruder für schnelle Anfragen
• Business Logic: Nur manuelle Tests möglich - kein Tool findet „Bestellung mit negativem Preis”

DAST Scope Definition

• Staging-Umgebung verwenden (nie Produktion!)
• Test-Accounts verwenden (keine echten Kundendaten)
• Rate-Limiting beachten (sonst Staging-Server überlastet)
• DBA informieren: aktiver Scan kann Datenbankeinträge erstellen
• Zeitplan abstimmen: Scan außerhalb laufender Testzeiträume

SCA und SBOM

Die Log4Shell-Schwachstelle (CVE-2021-44228, CVSS 10.0) hat gezeigt, warum Dependency Management kritisch ist. Ein SBOM hätte sofort gezeigt: „In 5 Services nutzen wir log4j < 2.17!” Ohne SBOM bedeutete das wochenlange manuelle Suche. Mit Dependabot oder Trivy gibt es sofort einen Alert plus Pull Request mit 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)

# Container Image scannen
trivy image nginx:latest
# → Zeigt CVEs im Base Image und installierten Packages

# Git-Repo scannen (Dependencies + Secrets + Misconfiguration)
trivy repo https://github.com/firma/myapp
# Oder lokal:
trivy fs ./

# SARIF-Output für GitHub Security Tab
trivy fs --format sarif --output trivy.sarif ./

SBOM generieren (Software Bill of Materials)

# Syft (Anchore)
syft ./  # Scannt CWD und generiert SBOM
syft nginx:latest -o spdx-json=sbom.spdx.json

# Grype (SBOM-basiertes Vulnerability Scanning)
grype sbom:sbom.spdx.json

SBOM-Pflicht: Der US Executive Order 14028 (2021) schreibt SBOMs für Software an US-Behörden vor. Der EU Cyber Resilience Act bringt ähnliche Anforderungen. NIS2 adressiert Software Supply Chain Sicherheit.

OWASP Dependency-Check

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

# npm
npx owasp-dependency-check --project "MyApp" --scan ./node_modules
# → HTML/JSON Report mit CVEs in Dependencies

AST in CI/CD integrieren

Eine vollständige DevSecOps-Pipeline kombiniert alle AST-Methoden:

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 - wann blockieren?

Security Gates sollten schrittweise eingeführt werden, um Developer-Buy-In nicht zu gefährden:

• Phase 1 (Start): Alles als Warning - kein Block
• Phase 2 (3 Monate): Critical/High SAST-Findings blockieren
• Phase 3 (6 Monate): DAST High blockiert Staging-Deployment
• Phase 4 (12 Monate): DAST Medium blockiert Production-Deployment

Goldene Regel: Ein Security-Gate nie ohne Developer-Buy-In einführen. Zu frühes Blockieren führt dazu, dass Entwickler die Security-Checks deaktivieren.