Wie gehen Sie an ein Secure Code Review heran?
Kurzantwort
Beginnen Sie damit, das Bedrohungsmodell der App zu verstehen und wo sie nicht vertrauenswürdige Eingaben, Geheimnisse, Authentifizierung und Autorisierung verarbeitet. Nutzen Sie SAST zum breiten Scannen und DAST gegen die laufende App, behandeln Sie die Tool-Ausgabe aber als Hinweise, nicht als Befunde — sortieren Sie False Positives aus. Verwenden Sie dann die menschliche Zeit auf die wertvollen, kontextabhängigen Bereiche, die Tools verpassen: Autorisierungslogik, Geschäftslogik, Krypto-Nutzung und Vertrauensgrenzen. Verfolgen Sie den Datenfluss von der Source bis zum Sink.
Secure Code Review ist der Ort, an dem sich AppSec verdient macht, weil es einen Fehler abfangen kann, bevor er je ausgeliefert wird. Interviewer fragen danach, um zu sehen, ob Sie Tools als Kraftverstärker nutzen können, ohne ihre Ausgabe mit der eigentlichen Arbeit zu verwechseln — die im menschlichen Urteil über den Kontext besteht.
Mit dem Kontext beginnen
Bevor Sie Code lesen, verstehen Sie die Anwendung: Was tut sie, welche Daten sind sensibel, und wo tritt nicht vertrauenswürdige Eingabe ein? Stützen Sie sich auf ein (oder erstellen Sie ein) schnelles Bedrohungsmodell. Das zeigt Ihnen, wo Sie Ihre begrenzte Aufmerksamkeit einsetzen — es gibt keine Zeit, alles mit gleicher Sorgfalt zu lesen, also zielen Sie auf die riskante Fläche.
Tools: Hinweise, keine Urteile
- SAST liest den Quellcode statisch und ist großartig für Breite: hartkodierte Geheimnisse, injektionsanfällige Sinks, unsichere Deserialisierung, schwache Krypto-APIs. Aber es erzeugt False Positives und kann die Absicht nicht verstehen.
- DAST beansprucht die laufende App von außen und bestätigt die Ausnutzbarkeit ganzer Bug-Klassen, hat aber eine flache Code-Sicht.
Nutzen Sie beide, um Hinweise zu erzeugen, und triagieren Sie dann. Rohe SAST-Ausgabe als Bugs einzureichen, ist der schnellste Weg, das Vertrauen der Entwickler zu verlieren — jeder False Positive, den Sie weiterleiten, untergräbt es.
Wo Menschen gewinnen
Setzen Sie den manuellen Aufwand auf das, was Tools strukturell nicht beurteilen können:
- Autorisierungslogik — kann Nutzer A die Daten von Nutzer B erreichen? Tools sehen den Code, nicht die dahinterliegende Zugriffskontroll-Absicht.
- Geschäftslogik — Missbrauch legitimer Funktionen (Bezahlschritt-überspringen-Bugs).
- Krypto-Nutzung — der richtige Algorithmus falsch verwendet (ECB-Modus, statische IVs, selbstgebaute Verfahren).
- Vertrauensgrenzen — wo Daten von nicht vertrauenswürdig zu vertrauenswürdig übergehen, validieren, dass sie tatsächlich bereinigt sind.
Die zentrale Technik ist das Verfolgen des Datenflusses von der Source bis zum Sink: die nicht vertrauenswürdige Eingabe vom Eintritt bis zur gefährlichen Operation verfolgen und jede Transformation unterwegs auf Validierung und Encoding prüfen.
Worauf Interviewer achten
Sie wollen einen vom Bedrohungsmodell geleiteten Fokus, SAST/DAST als triagebedürftige Hinweise behandelt, manuelle Aufmerksamkeit für Authz und Geschäftslogik und das Datenfluss-Denken von Source zu Sink — plus die Empathie, das Vertrauen des Teams durch das Filtern von False Positives zu schützen.
Wahrscheinliche Anschlussfragen
- Warum kann SAST Broken Access Control oder Geschäftslogik-Fehler nicht zuverlässig finden?
- Was bedeutet «von der Source zum Sink verfolgen» in der Praxis?
- Wie verhindern Sie, dass False Positives das Vertrauen des Teams in Ihre Reviews zerstören?