Was Penetration Testing mich über besseren Code gelehrt hat
Acht Monate lang habe ich meine Zeit zwischen offensiver Sicherheit bei RNP, mit Adversary Emulation und Schwachstellenbewertungen, und Full-Stack-Entwicklung bei Bridge Laboratory aufgeteilt, mit Features in React, TypeScript, Kotlin und Spring Boot. Diese beiden Tätigkeiten passen normalerweise nicht in denselben Kopf. Sie haben verändert, wie ich Code schreibe.
Pentesting trainiert eine bestimmte Gewohnheit: bevor man ein System anfasst, fragen, wo ein Angreifer Hebelwirkung bekommt. Nicht "funktioniert dieses Feature", sondern "was passiert, wenn diese Eingabe fehlerhaft ist, dieses Token wiederverwendet wird, dieser Endpoint ohne Authentifizierung aufgerufen wird". Diese Frage verschwindet nicht, wenn man vom Angreifen zum Bauen wechselt.
Der klarste Übertrag ist Eingabevalidierung. Nach genug Zeit mit dem Finden von Injection-Points und kaputten Auth-Checks in fremden Systemen habe ich aufgehört, Validierung in meinen eigenen Pull Requests als Formalität zu behandeln. Jeder Endpoint bekommt dieselbe Frage wie ein Pentest-Einsatz: was ist die schlimmste Eingabe, die dieser Parameter erhalten könnte, und übersteht der Code sie.
Dependency-Hygiene ist die zweite Gewohnheit. Schwachstellenbewertungen verbringen echte Zeit mit veralteten Paketen mit bekannten CVEs, weil das oft der tatsächliche Einstiegspunkt ist, kein raffinierter Zero-Day. npm audit oder Äquivalent vor einem Release laufen zu lassen war irgendwann keine Checkbox mehr, sondern Routine.
Authentifizierung und Session-Handling bekommen ebenfalls mehr Aufmerksamkeit. Die Arbeit mit Kali Linux und Adversary-Emulation-Tools macht Token-Replay, Session-Fixation und Privilege-Escalation zu konkreten Fehlermodi statt abstrakten Punkten auf einer OWASP-Liste. Die Frage im Code-Review ändert sich von "funktioniert der Login" zu "was passiert, wenn dieses Token nach dem Logout wiederverwendet wird".
Die Spannung ist real. Entwicklung optimiert fürs Ausliefern, Sicherheit optimiert für weniger Angriffsfläche. Eine Pentest-Denkweise kann ein Team ausbremsen, wenn jede Entscheidung wie ein Incident behandelt wird. Die Gewohnheit, die sich wirklich lohnt, ist nicht Paranoia, sondern die Angreiferfrage früh zu stellen, in der Design-Phase, wenn eine Korrektur nichts kostet, statt nachdem das Feature live ist.
Der Bau dieses Portfolios und seines Blog-Systems war ein kleiner Testfall dafür. Die Daten liegen in Supabase hinter Row Level Security, das Blog-CMS validiert und bereinigt jedes Feld, bevor es die Datenbank erreicht, und Bild-Uploads laufen über einen begrenzten Storage-Bucket statt beliebiger Dateischreibvorgänge. Nichts davon ist exotisch. Es ist dieselbe Checkliste, die ein Pentest-Einsatz abarbeitet, nur angewendet während der Code noch geschrieben wird, statt nachdem jemand versucht hat, ihn zu brechen.
Full-Stack-Engineering und offensive Sicherheit kreisen immer wieder um dieselbe Frage: was habe ich angenommen, das eigentlich nicht garantiert ist. Das früher zu beantworten kostet weniger als es während eines Incidents zu beantworten.