SAST und DAST in CI/CD-Pipelines

Application Security Testing identifiziert Schwachstellen, bevor Code in die Produktion gelangt. Zwei sich ergänzende Ansätze sind: SAST (statisch, ohne den Code auszuführen) und DAST (dynamisch, durch Testen einer laufenden Anwendung). Beide Ansätze lassen sich für eine frühzeitige Verankerung der Sicherheit in CI/CD-Pipelines integrieren.

SAST analysiert Quellcode, Bytecode oder Binärdateien auf Sicherheitslücken, ohne den Code auszuführen. Es kann bei jedem Commit ausgeführt werden und liefert dadurch schnelles Feedback.

Stärken: Erkennt Fehler frühzeitig, vollständige Codeabdeckung, keine laufende Umgebung erforderlich.

Schwächen: Hohe Rate an Falschpositiven, sprachspezifisch, erkennt Probleme der Laufzeitkonfiguration nicht.

SAST-Tools aus dem Open-Source-Bereich:

Beispiel für einen SAST-Schritt in GitHub Actions:

DAST testet eine laufende Anwendung von außen und simuliert dabei einen Angreifer. Es erkennt Schwachstellen, die nur zur Laufzeit sichtbar sind: Authentifizierungsprobleme, Fehler in der Sitzungsverwaltung und Fehler bei der Eingabevalidierung.

Stärken: Wenige Falschpositive, sprachunabhängig, erkennt Probleme der Laufzeitkonfiguration.

Schwächen: Eine laufende Umgebung ist erforderlich, möglicherweise werden nicht alle Codepfade erfasst.

DAST-Tools für CI/CD:

IAST instrumentiert die Anwendung zur Laufzeit mithilfe von Agents, die während funktionaler Tests die Codeausführung überwachen. Es verbindet die Genauigkeit von SAST mit der Abdeckung von DAST. Beispiele: Contrast Security, Seeker. Sprachspezifische Agents und die Ausführung von Tests sind erforderlich.

Shift left bedeutet, Sicherheitstests im Entwicklungszyklus früher durchzuführen – idealerweise bereits in der IDE der Entwickler und beim Commit statt als separate Prüfungsstufe vor der Veröffentlichung. Je früher ein Problem erkannt wird, desto günstiger ist seine Behebung.

Kostenmultiplikator: Ein Fehler in der Entwicklung kostet 1x, in der Staging-Umgebung 10x und in der Produktion 100x.

SAST-Tools erzeugen Falschpositive. So gehen Sie damit um:

• Verwenden Sie nosec (Bandit) oder Inline-Kommentare zur Unterdrückung, wenn es sich nachweislich nicht um ein Problem handelt
• Passen Sie die Regelsätze an den Anwendungskontext an
• Dokumentieren Sie die Begründung für Unterdrückungen in Kommentaren im Code
• Überprüfen Sie Unterdrückungen regelmäßig

Eine vollständige Sicherheitspipeline:

1. Pre-Commit-Hooks: Scannen auf Secrets (gitleaks), SAST (semgrep)
2. PR-Prüfungen: SAST-Ergebnisse, Scannen von Abhängigkeiten (Dependabot)
3. Bereitstellung in der Staging-Umgebung: DAST-Scan (ZAP baseline)
4. Produktion: Überwachung zur Laufzeit (RASP, WAF)

Wichtige AppSec-Kennzahlen in CI/CD:

• Durchschnittliche Zeit bis zur Behebung von Sicherheitsbefunden
• Anzahl der Befunde pro 1000 Codezeilen
• Rate der Falschpositiven (beeinflusst das Vertrauen der Entwickler)
• Rate der durchgerutschten Schwachstellen (in der Staging-Umgebung im Vergleich zur Produktion gefunden)

SAST analysiert Code statisch (frühes Feedback, viele Falschpositive), während DAST laufende Anwendungen dynamisch testet (Genauigkeit zur Laufzeit, Umgebung erforderlich). Beide Ansätze gehören in CI/CD-Pipelines. Durch die Verlagerung von Sicherheitstests nach links werden Schwachstellen erkannt, wenn ihre Behebung am günstigsten ist. Beliebte Tools: Semgrep, Bandit (SAST); OWASP ZAP, Nuclei (DAST). Passen Sie die Regelsätze an und dokumentieren Sie Unterdrückungen, um mit Falschpositiven umzugehen.