SAST vs. SCA

Der Unterschied auf einen Blick

	SAST	SCA
Steht für	Static Application Security Testing	Software Composition Analysis
Betrachtet	Ihren eigenen Quellcode	Open-Source- und Drittanbieterkomponenten
Findet	Injection, unsichere Eingabeverarbeitung, unsichere Muster	Bekannte Schwachstellen, Lizenzprobleme, veraltete Pakete
Stützt sich auf	Regeln oder Modelle dafür, wie schlechter Code aussieht	Datenbanken veröffentlichter Advisories
Ein Befund entsteht, wenn	sich Ihr Code ändert	sich eine Abhängigkeit ändert oder ein neues Advisory erscheint
Typisches Rauschen	False Positives bei Code, der eigentlich sicher ist	Echte Treffer, die Ihre Nutzung des Pakets nicht betreffen
Behebung	Code ändern	Komponente aktualisieren oder ersetzen

Was SAST macht

Ein SAST-Tool liest Quellcode, ohne ihn auszuführen, und verfolgt, wie Daten durch ihn fließen. Erreicht eine Benutzereingabe eine Datenbankabfrage, ohne bereinigt zu werden, meldet es Datei und Zeile. Weil es mit Ihrem Code arbeitet, kann es Fehler finden, die nie jemand veröffentlicht hat. Es ist auch die Quelle der Klagen über False Positives, denn es schließt darauf, was der Code tun könnte, nicht darauf, was er tut.

Was SCA macht

Ein SCA-Scan identifiziert die Komponenten eines Projekts und schlägt sie in Schwachstellen- und Lizenzdaten nach. Ihre Logik analysiert er nicht. Er weiß, dass eine Version einen veröffentlichten Fehler hat, seine Ergebnisse sind also meist faktisch korrekt, aber er sagt weniger darüber, ob der Fehler für Sie relevant ist, sofern das Tool nicht eine Erreichbarkeitsanalyse ergänzt. Das Gesamtbild finden Sie unter Was ist Software Composition Analysis.

Warum Sie beide brauchen

Die beiden Fehlerarten sind unabhängig voneinander. Eine Codebasis ohne SAST-Befunde kann trotzdem eine verwundbare Abhängigkeit ausliefern, und ein sauberer Abhängigkeitsbaum sagt nichts über eine SQL-Injection in Ihrem eigenen Handler.

Auch der Zeitpunkt unterscheidet sich. Ein SAST-Befund entsteht, wenn jemand Code ändert, deshalb fängt eine Prüfung im Pull Request die meisten davon ab. Ein SCA-Befund kann bei einem Release auftreten, das Sie vor Monaten ausgeliefert haben, an dem Tag, an dem ein neues Advisory erscheint, ohne einen Commit, der etwas auslöst. SCA braucht deshalb etwas, das das Ausgelieferte laufend weiter prüft.

Die Rolle von DAST

Dynamic Application Security Testing greift eine laufende Anwendung von außen an, so wie es ein echter Angreifer täte. Es findet, was sich erst zur Laufzeit zeigt, etwa Probleme bei Authentifizierung und Konfiguration, ohne den Code zu lesen.

	SAST	SCA	DAST
Braucht	Quellcode	Manifeste, Images oder eine Build-Aufzeichnung	Eine laufende Anwendung
Läuft	Bei Pull Requests	Bei Pull Requests, in Builds und nach dem Release	Gegen eine Testumgebung
Am besten bei	Fehlern in Ihrem Code	Bekannten Risiken in Abhängigkeiten	Laufzeit- und Konfigurationsfehlern

Was sollten Sie zuerst einführen?

Für die meisten Teams SCA. Es ist schnell eingerichtet, läuft in Sekunden bis Minuten und deckt den größten Teil dessen ab, was Sie ausliefern, denn eine moderne Anwendung besteht größtenteils aus Abhängigkeiten. Ergänzen Sie danach SAST bei Pull Requests und stimmen Sie es auf die Regeln ab, die für Ihren Stack zählen. Ergänzen Sie DAST, sobald Sie eine stabile Testumgebung dafür haben.

Eine Plattform oder mehrere Tools?

Plattformen wie Snyk, Checkmarx und GitHub Advanced Security bündeln SAST und SCA, das bedeutet einen einzigen Vertrag und einen einzigen Workflow. Separate Tools können im jeweiligen Bereich stärker sein. Wichtiger ist die Eingabe: Beide Arten von Scannern arbeiten mit dem, was deklariert oder geschrieben wurde, und keine sieht, was der Build tatsächlich geladen hat.

Was keines von beiden abdeckt

SAST und SCA lesen beide Dateien. Keines beobachtet den Build, sodass Code, den ein Install-Hook lädt, aus CI-Caches wiederhergestellte Pakete und die Build-Tools selbst unsichtbar bleiben können. Um diese Lücke geht es bei der Software-Lieferkettensicherheit.

CRACI deckt diesen Teil ab und überlässt das Code-Scanning den Tools, die dafür gebaut sind. SAST und Secrets-Scanning bietet es bewusst nicht an, und zahlreiche ausgezeichnete SAST-Tools arbeiten daneben. Es ist ein GitHub-Actions-Runner, der aufzeichnet, was jeder Job lädt, daraus eine SBOM erzeugt und die SBOMs des Ausgelieferten laufend mit neuen Schwachstellen abgleicht. Siehe die besten SCA-Tools und wo CRACI neben ihnen ansetzt.

SAST vs. SCA: häufig gestellte Fragen

Was ist der Unterschied zwischen SAST und SCA?

SAST analysiert den Code, den Ihr Team schreibt, auf Fehler wie Injection. SCA analysiert die Open-Source- und Drittanbieterkomponenten, von denen Sie abhängen, auf bekannte Schwachstellen und Lizenzprobleme.

Ersetzt SCA SAST?

Nein. Beide betrachten unterschiedlichen Code. SCA findet keinen Fehler in Ihrer eigenen Logik, und SAST sagt Ihnen nicht, dass eine Abhängigkeit eine veröffentlichte Schwachstelle hat.

Was ist der Unterschied zwischen SAST, DAST und SCA?

SAST liest Ihren Quellcode. SCA prüft Ihre Abhängigkeiten. DAST testet eine laufende Anwendung von außen. Jedes findet Probleme, die den anderen beiden entgehen.

Ist Snyk SAST oder SCA?

Beides. Snyk begann mit dem Scannen von Open-Source-Abhängigkeiten und bietet auch SAST sowie Scans von Containern und Infrastructure as Code.

Ist SonarQube SAST oder SCA?

SonarQube ist vor allem für die statische Analyse Ihres eigenen Codes bekannt, also SAST. Prüfen Sie bei den aktuellen Editionen, was sie sonst noch umfassen.

Was kommt zuerst, SAST oder SCA?

SCA bringt meist schneller Erfolg, weil es einfach einzurichten ist und den größten Teil dessen abdeckt, was Sie ausliefern. SAST erfordert mehr Feinabstimmung, um False Positives niedrig zu halten.