Wie fangen wir an, den Code vor dem Release mit unserem eigenen Team auf Sicherheit zu prüfen?

Auf der Automatisierungsseite ist Dependency-Scanning genauso kritisch wie statische Analyse. Richtet Open-Source-Abhängigkeitsprüfer ein, die bekannte Sicherheitslücken in euren externen Bibliotheken schon zur Build-Zeit erkennen. Macht außerdem Unit- und Integrationstests verpflichtend, die die Geschäftslogik auf Code-Ebene prüfen, um Autorisierungslücken zu verhindern; kein Code darf durchgehen, ohne dass die Übereinstimmung von Nutzeridentität und Datenobjekt getestet wurde.

Wenn ihr in einem Vier-Personen-Team die Sicherheitskontrolle auf eine einzige Person abwälzt, wird diese Person schnell zum Flaschenhals. Macht das Review nicht zu einer Strafe oder einem Genehmigungsmechanismus, sondern zu einer gemeinsamen Verantwortung. Wendet bei jedem Pull Request die Zwei-Augen-Regel an; nicht die Person, die den Code geschrieben hat, sondern die, die ihn reviewt, soll die Sicherheitspunkte einzeln abhaken. Selbst eine einfache Checkliste fängt die meisten Fehler schon in der Entwicklungsumgebung ab.

Ergänzung: Wurde unten schon gefragt, die Antwort habe ich im zweiten Beitrag geschrieben.

Der praktischste Schritt, mit dem ihr morgen früh sofort anfangen könnt ist, in eurer Pull-Request-Vorlage einen Sicherheitsabschnitt anzulegen. Der Entwickler soll, bevor er den Code einreicht, die Kästchen „Ich habe Nutzereingaben validiert" und „Ich habe eine Berechtigungsprüfung hinzugefügt" ankreuzen müssen. Allein diese zwei Fragen zwingen den Entwickler, vor dem Einreichen innezuhalten und nachzudenken.

bei uns im team war's ähnlich wir sind wegen externer bibliotheken auf die fresse geflogen. haben kostenlose open-source-scan-tools ans repo gehängt wenn die was finden, blokieren sie den merge. am anfang haben alle gemeckert, aber nach zwei wochen hatten wir uns dran gewöhnt und jetzt ist der kopf viel freier.

Wir haben letztes Jahr einen ähnlichen Prozess durchgemacht. Nachdem wir automatische statische Analyse und die Pull-Request-Checkliste etabliert hatten, sank die Zahl der kritischen Befunde im unabhängigen Sicherheitstest sechs Monate später auf null. Unsere Review-Zeiten verlängerten sich pro Pull Request um durchschnittlich nur 12 Minuten. Diese 12 Minuten, die wir investiert haben, haben uns Tausende Dollar an Notfall-Patch-Kosten erspart.

Ist die Autorisierungsumgehung im Penetrationstest-Bericht eures Kunden genau auf der API-Ebene aufgetreten oder auf der Ebene der Datenbankabfrage? Wenn es an den API-Endpunkten keine zentrale Berechtigungsschicht gibt, wird das einzelne Einbauen von Checks in jede Funktion später wieder Lücken erzeugen. Habt ihr in eurer Architektur eine zentrale Identitäts- und Zugriffskontrolle?

Verlasst euch nicht zu sehr auf automatische Scanner. Statische Analysewerkzeuge erkennen Bibliothekslücken oder einfache SQL-Lücken gut, aber Geschäftslogikfehler wie die Autorisierungsumgehung, die ihr erlebt habt, sehen sie niemals. Solange niemand den Test „Kann Nutzer A die Rechnung von B sehen" logisch durch Draufschauen auf den Code durchführt, kann euch keine automatische Software vor diesem Bericht bewahren.

Zusammengefasst ist die Roadmap klar: 1) Kostenlose automatische Tools ins Repo integrieren und Abhängigkeiten sowie grundlegende Lücken scannen lassen, 2) Für Pull Requests eine 5-Punkte-Review-Pflicht mit Fokus auf Autorisierung und Datenvalidierung einführen, 3) Geschäftslogikprüfungen der manuellen Review durch die Entwickler überlassen. Große Budgets braucht es nicht, Disziplin reicht.

Das habe ich auch erlebt.

Wir sind auch eine Zeit lang an derselben Stelle hängen geblieben. Schreibe bei Entscheidungen auch das Worst-Case-Szenario auf, nicht nur das Beste.

Wenn es jemand anders macht, würde mich das auch interessieren.

Vielen Dank ich werde es heute testen.

Gespeichert.

Ich stimme voll und ganz zu. Maßnahmen ohne vorherige Bestandsaufnahme lassen die Türen offen die man nicht sieht.

Bei uns war der größte Zeitfresser die Unklarheit darüber, wer entscheidet.

Ich schreibe das damit ihr denselben Fehler nicht macht. Ein nicht getestetes Backup ist kein Backup.

Die Zeit, die ihr braucht um ein Problem zu erkennen, bestimmt direkt dessen Kosten. Wenn es jemand anders macht würde mich das auch interessieren.

Dabei gibt es einen sehr häufigen Fehler. Der meiste Zeitverlust entsteht durch Arbeiten, die auf Freigaben warten.

Das ist meine Meinung, ich behaupte nicht, dass es absolut richtig ist.

Ich bin ein kleines Unternehmen, ich erzähle es aus meiner Sicht. Nur weil alle es tun, heißt es nicht, dass es richtig ist.

Scheut euch nicht zu fragen, wer nicht fragt, zahlt am Ende mehr.

meinne Frage ist geklärt vielen Dank.

Da verstehe ich etwas nicht ganz. Wenn ihr es zum ersten Mal macht, fangt klein an, die Skalierung kommt später.

Ein nicht getestetes Backup ist kein Backup. An deiner Stelle würde ich so vorgehen.