Was sind SAST, DAST und Software Composition Analysis (SCA)?
SAST analysiert Code ohne Ausführung, DAST prüft das Außenverhalten einer laufenden Anwendung und SCA erfasst Risiken aus Dritt- und Open-Source-Komponenten sowie ihren Abhängigkeiten.
Technische Einordnung: Static Application Security Testing (SAST) untersucht Quellcode oder analysierbare kompilierte Codeformen auf Sicherheitsfehler, ohne die Anwendung auszuführen. Dynamic Application Security Testing (DAST) sendet Testanfragen an eine laufende Anwendung und bewertet ihre von außen beobachtbaren Antworten. Software Composition Analysis (SCA) ist die auf Software bezogene Teilmenge der Komponentenanalyse. Sie inventarisiert und bewertet Fremdkomponenten und Abhängigkeiten unter anderem im Hinblick auf bekannte Schwachstellen, Aktualität, Herkunft und Lizenzen.
Wie unterscheiden sich SAST, DAST und SCA?
Die Verfahren nutzen verschiedene Evidenzquellen: SAST betrachtet eigenen oder zugänglichen Code, DAST das Verhalten einer erreichbaren Anwendung zur Laufzeit und SCA deren Zusammensetzung aus Dritt- und Open-Source-Komponenten.
- SAST: findet verdächtige Muster im Code frühzeitig, besitzt aber keinen vollständigen Laufzeitkontext.
- DAST: prüft die tatsächlich erreichbare Angriffsfläche von außen, sieht jedoch nicht die internen Abläufe der Anwendung.
- SCA: erfasst direkte und, soweit ermittelbar, transitive Abhängigkeiten. Ein SCA-Scan ist weder SAST noch DAST.
Für wen sind die Verfahren relevant?
Sie sind für Organisationen relevant, die eigene Software entwickeln oder betreiben beziehungsweise Dritt- oder Open-Source-Komponenten einsetzen. Der konkrete Anwendungsbereich hängt von der verfügbaren Prüfgrundlage ab.
SAST benötigt zugänglichen Quellcode oder eine analysierbare kompilierte Codeform. DAST benötigt eine laufende, für Tests erreichbare Anwendung. SCA benötigt eine belastbare Komponenten- und Abhängigkeitsinventur, die direkte und transitive Abhängigkeiten berücksichtigt.
Welche Voraussetzungen und Auslöser gelten?
SAST kann früh und wiederholt in Entwicklungsumgebung, Build oder Continuous Integration eingesetzt werden. DAST wird sinnvoll, sobald eine laufende Testinstanz autorisiert erreichbar ist. SCA beginnt mit der Erfassung oder Änderung eingesetzter Komponenten und Abhängigkeiten.
DAST sollte auf eine autorisierte Testumgebung und geeignete Testdaten begrenzt werden. SCA kann Dateien oder eine Software Bill of Materials (SBOM) auswerten; aussagekräftige Ergebnisse setzen jedoch eine korrekte Identifikation und Versionierung der Komponenten voraus. Eine vorhandene SBOM garantiert nicht, dass alle zur Laufzeit oder aus der Umgebung stammenden Abhängigkeiten vollständig erfasst sind.
Welche Grenzen haben SAST, DAST und SCA?
Keines der drei Verfahren liefert allein eine vollständige Sicherheitsbewertung. Toolbefunde müssen anhand von Anwendungskontext, Erreichbarkeit, Auswirkungen und vorhandenen Kompensationsmaßnahmen validiert und priorisiert werden.
SAST kann ohne Laufzeitkontext Fehlalarme erzeugen. DAST benötigt keinen Quellcode, deckt aber nur erreichbare Funktionen und Angriffsflächen ab und hat keine Innensicht. Ein SCA-Befund zu einer bekannten Schwachstelle belegt nicht automatisch deren Ausnutzbarkeit im konkreten Einsatz. Die Ermittlung einer Lizenz oder Lizenzinformation ersetzt weder eine vollständige Lizenzanalyse noch die Bewertung der konkreten Nutzung und ihrer Verpflichtungen.
Gibt es feste Fristen oder Schwellenwerte?
Aus den technischen Begriffen SAST, DAST und SCA folgt keine einheitliche Frist, kein universeller Startzeitpunkt und kein allgemeiner numerischer Schwellenwert. Taktung, Abdeckung, Freigabekriterien und Behebungsziele sind risikobasiert festzulegen.
Vertragliche, sektorale oder gesetzliche Vorgaben können für einzelne Organisationen eigene Fristen oder Schwellen bestimmen; solche Vorgaben ergeben sich nicht aus den drei Methodenbegriffen selbst.
Wie sollten SAST, DAST und SCA zusammenspielen?
Die Methoden sollten als ergänzende Kontrollen in einen sicheren Entwicklungs- und Schwachstellenmanagementprozess eingebunden werden. Ihre Auswahl, Frequenz und Abdeckung richten sich nach Risiko, Architektur und Einsatzumgebung.
Sie ersetzen weder fachliches Code Review noch Penetrationstests oder eine kontextbezogene Risikobewertung. Diese zusätzlichen Prüfungen ergänzen die automatisierten Werkzeuge um manuelle und kontextbezogene Bewertungen.
Häufige Fehlannahmen
Die folgenden Gleichsetzungen führen zu falschen Erwartungen an Reichweite und Aussagekraft der Verfahren:
- „SAST, DAST und SCA prüfen dasselbe.“ Tatsächlich untersuchen sie Code, Laufzeitverhalten und Softwareabhängigkeiten aus unterschiedlichen Perspektiven.
- „Jeder Toolbefund ist eine bestätigte Schwachstelle.“ Befunde benötigen fachliche Validierung, Kontext und Priorisierung.
- „Ein SCA-Treffer beweist die Ausnutzbarkeit.“ Eine bekannte Schwachstelle in einer Komponente sagt allein nicht, ob der betroffene Code im konkreten Einsatz erreichbar oder wirksam ist.
- „Eine SBOM ist automatisch vollständig.“ Zur Laufzeit oder aus der Umgebung bezogene Abhängigkeiten können in einer Inventur fehlen.
- „Eine erkannte Lizenz bestätigt die Lizenzkonformität.“ Lizenzinformationen ersetzen keine Bewertung der konkreten Nutzung und Verpflichtungen.
- „Automatisierte Scans ersetzen Code Review und Penetrationstest.“ Die Verfahren ergänzen diese Prüfungen, decken deren kontextbezogene und manuelle Perspektive aber nicht vollständig ab.
Was die Geschäftsleitung tun sollte
Technische Empfehlung: Die Geschäftsleitung sollte einen risikobasierten sicheren Entwicklungsprozess veranlassen und dessen Umsetzung nachvollziehbar steuern.
- Verantwortlichkeiten und Sicherheitsprüfkriterien für Entwicklung, Betrieb und Schwachstellenmanagement festlegen.
- SAST passend in Entwicklungsumgebung, Build oder CI einbinden und DAST nur gegen autorisierte, laufende Testinstanzen mit geeigneten Testdaten durchführen lassen.
- Eine aktuelle Komponenten- und Abhängigkeitsinventur beziehungsweise SBOM einschließlich ermittelbarer transitiver Abhängigkeiten pflegen.
- Auswahl, Frequenz, Abdeckung und Freigabekriterien der Prüfungen an Risiko, Architektur und Einsatzumgebung ausrichten.
- Für alle Befundarten eine dokumentierte Triage, Priorisierung, Behandlungsentscheidung und Nachverfolgung bestätigter Probleme einrichten.
Für die Geschäftsleitung
SAST, DAST und SCA decken unterschiedliche Prüfbereiche ab und sollten gemeinsam risikobasiert eingesetzt werden. Entscheidend sind klare Verantwortung, eine autorisierte und passende Prüfumgebung, eine belastbare Komponentenübersicht sowie nachvollziehbare Entscheidungen zu Befunden. Als Nachweis eignen sich dokumentierte Prüfkriterien, Scan- und Triage-Ergebnisse, Behandlungsentscheidungen und der gepflegte Stand der Komponenten- beziehungsweise Abhängigkeitsinventur.
Quellen
- OWASP: Source Code Analysis Tools – Definition sowie Stärken und Grenzen von SAST.
- OWASP DevSecOps Guideline: Dynamic Application Security Testing – Prüfung einer laufenden Anwendung.
- OWASP: Component Analysis – SCA, Komponenteninventur, geerbte Risiken und Lizenzen.
- OWASP Mobile Application Security Testing Guide – Abgrenzung statischer und dynamischer Analyse.
- OWASP DevSecOps Guideline: Interactive Application Security Testing – Grenzen und Abgrenzung von SAST und DAST.
- NIST SP 800-218: Secure Software Development Framework – risikobasierter Rahmen für sichere Softwareentwicklung.
