SAST, SCA und Secret-Scanning

Kurz: Drei automatische Prüfungen für den Code eines Projekts: SAST sucht Sicherheitsfehler im eigenen Code, SCA sucht bekannte Schwachstellen in fremden Bibliotheken, Secret-Scanning sucht versehentlich veröffentlichte Passwörter und Schlüssel.

Genauer:

• SAST (Static Application Security Testing) liest den Quelltext und meldet gefährliche Muster wie ungefiltertes HTML, Kommandoaufrufe mit Nutzereingaben oder unsichere Dateizugriffe.
• SCA (Software Composition Analysis) gleicht die Abhängigkeiten (package.json, Lock-Datei) mit Datenbanken bekannter Schwachstellen (CVE) ab.
• Secret-Scanning findet Zugangsdaten, API-Schlüssel und .env-Dateien im Repository (siehe .env-Dateien).

Kontext bei uns: Emzett lässt das Repository mit Aikido scannen. Ein SCA-Fund war eine kritische Lücke in einer älteren Next.js-Version, die durch ein Patch-Update behoben wurde; SAST-Funde werden einzeln geprüft (echtes Risiko oder Fehlalarm). Zusätzlich hilft npm audit. Der Hosting-Anbieter Vercel liefert keine dieser Prüfungen mit — er schützt Plattform und Netzwerk, nicht den Code.

Im Detail

Umgang mit Funden

1. Erreichbarkeit prüfen: Läuft der betroffene Code überhaupt im Live-Betrieb? Mitgelieferte Build-Werkzeuge sind selten angreifbar.
2. Priorisieren: kritisch und hoch zuerst, dann mittel; niedrige Funde bündeln.
3. Beheben oder begründen: Update, Umbau oder bewusst als „nicht zutreffend“ markieren — mit Begründung.
4. Nachscannen: Nach dem Deploy neu scannen, sonst zeigt die Liste alte Stände.

Grenzen

Scanner melden auch Fehlalarme, verstehen nicht jede Absicht im Code und finden keine Logikfehler (z. B. fehlende Berechtigungsprüfung). Sie ersetzen weder Code-Review noch Penetrationstests, sondern liefern eine günstige Grundabdeckung.

Siehe auch: XSS, SQL-Injection, .env-Dateien, WAF