Wir haben ein internes Sicherheits-Code-Review versucht und stecken fest – was sind typische Fallen?

Konfiguriert die Taint-Analyse in euren Scannern sauber. Schaut genau hin, ob Daten vom Nutzer bis zur Datenbank-Query oder dem Systembefehl wirklich ungefiltert durchkommen. Schaltet die Regeln ab, die jedes normale String-Concatenating direkt als SQL-Injection einstufen – damit seid ihr zwei Drittel der nervigen Meldungen sofort los.

Einem Entwickler ohne Security-Schulung den eigenen Code auf Sicherheit prüfen zu lassen, ist reine Formsache. Wer den Code geschrieben hat, sieht die eigenen Designfehler nicht. Wenn das Budget knapp ist, lasst nicht das ganze System prüfen, sondern holt euch lieber ein fokussiertes externes 2-3-Tage-Audit rein für Authentifizierung und Bezahlmodule – das ist deutlich günstiger und effektiver.

Macht nicht nochmal den Fehler, 12.000 Zeilen auf einmal zu reviewen. Teilt die Security-Reviews auf Pull Requests auf. Pro Merge nicht mehr als 300 Zeilen Code und auf der Checkliste maximal 5 kritische Sicherheitspunkte. Das muss passieren, während der Code geschrieben wird, nicht erst kurz vor Sprintende.

Wir hatten beim ersten Scan 410 Warnungen. Das ganze Team hat zwei Wochen lang nur damit gekämpft. Dann haben wir den Filter auf die Top 10 der kritischsten Web-Schwachstellen eingegrenzt – zack, waren es nur noch 19. Und von diesen 19 Funden stellten letztlich nur 4 ein echtes Risiko dar, das behoben werden musste.

automatisierungstools checken doch gar nicht was der code macht die matchen nur patterns. wenn ihr in db-queries parametrisierte libraries nutzt, räumt ihr das meiste an sql-injection-risiken eh schon automatisch ab. übrigens verbeißt euch nicht grundlos in jede warnung vom tool.

Bei unserem ersten Produkt haben wir tagelang im Team über komplexe Regex-Validierungen diskutiert und uns gefreut, wie gründlich unser Secure Code Review doch war. Am dritten Tag nach dem Go-live hat ein Kunde einfach die ID in den URL-Parametern geändert und die Finanzdaten einer fremden Firma gezogen. Genau das sind die Logikfehler, die kein Tool auf der Welt sieht.

Ihr tappt da in drei klassische Fallen: 1) Tool-Outputs als absolute Wahrheit nehmen und stundenlang False Positives jagen, 2) Das Security-Review wie eine Leistungsbeurteilung des Entwicklers wirken lassen und dadurch Abwehrhaltungen erzeugen, 3) Code-Style und echte Sicherheitslücken durcheinanderwerfen.

Unterm Strich lässt sich das so zusammenfassen: Schwellenwerte bei automatischen Scannern hochschrauben, um den Noise zu reduzieren, Reviews in kleine Häppchen teilen und Logikfehler bei der Autorisierung, die kein Tool findet, manuell mit realistischen Szenarien abklopfen.

das hatte ich auch schon überlegt und also wenn wir ohne Messung entscheiden landen wir immer wieder am selben Punkt.

jeder nicht schriftlich festgehaltene Punkt ist einer an den sich beide Parteien später unterschiedlich erinnern. nur als Notiz, könnte nützlich sein.

Bei mir war es genau umgekehrt, deshalb schreibe ich das. Sicherheit ist nicht absolut; es bedeutet den Angriff so aufwendig zu machen, dass er sich nicht lohnt.

Wenn deine Situation anders ist, ändert sich das natürlich.

ich sitmme zu.

Kurzfassung für Neueinsteiger: Änderungen an Zahlungsdaten werden niemals über den Kanal bestätigt über den sie eingehen.

Sicherheit ist nicht absolut; es bedeutet, den Angriff so aufwendig zu machen dass er sich nicht lohnt. Viel Erfolg.

Bei uns war es so. Ein nicht getestetes Backup ist kein Backup.

Wenn ihr das Ergebnis hier postet, hilft es auch anderen.

Du hast recht, ich bin denselben Weg gegangen. Menschen verteidigen nicht den Prozess, sondern die Gewohnheit. Der Widerstand kommt daher.

Viel Erfolg.

Ich stimme voll und ganz zu. Schreibe bei Entscheidungen auch das Worst-Case-Szenario auf, nicht nur das Beste.

Schreibt mir, wenn ihr Fragen habt, ich antworte so gut ich kann.

Ich fasse das Thema mal zusammen, da es mehrere unterschiedliche Antworten gab. Menschen verteidigen nicht den Prozess, sondern die Gewohnheit. Der Widerstand kommt daher.

ich bin in derselben Situation deshalb fage ich. wenn ihr es zum ersten Mal macht fangt klein an, die Skalierung kommt später.

wenn man Fehlalarme anschreit meldet sich danach niemand mehr. das ist meine Meinung, ich behaupte nicht dass es absolut richtig ist.

Nichts vergessen: Der meiste Zeitverlust entsteht durch Arbeiten, die auf Freigaben warten.

Beginnt mit einem kleinen Test bindet nicht gleich alles fest. Viel Erfolg.