Code von der Agentur übernommen — wie packt man ein Secure Code Review an und wo fängt man an?

Allerhöchste Priorität: die Git-History bereinigen. Wenn ihr das Passwort nur im Code löscht und neu committet, steht es für immer in den alten Commits! Lasst einen Secret-Scanner über die komplette History laufen, schreibt die History neu, um die Keys komplett zu tilgen, und ändert die Passwörter sofort auf den Servern.

Lasst euren Entwickler direkt morgen den Audit-Befehl des Paketmanagers laufen lassen (z. B. composer audit / npm audit). Bei zwei Jahre alten Libs sind garantiert etliche kritische Advisories dabei. Allein das Update auf aktuelle, stabile Versionen eliminiert sofort die halbe Angriffsfläche.

Wir haben letztes Jahr bei einem übernommenen Projekt mit 30k Zeilen eine statische Codeanalyse gefahren. Tool hat 142 Warnungen ausgespuckt, nach genauerer Prüfung waren 8 davon brandgefährliche Lücken, über die man direkt die DB hätte abgreifen können. Die 8 Dinger zu fixen hat uns gerade mal drei Tage gekostet.

Verlass dich nicht zu sehr auf automatische Analyse-Tools, du kannst in hunderten Fehlalarmen ertrinken, die in einem Bericht mit tausenden Zeilen auftauchen. Die größten Datenlecks entstehen nicht durch Bibliotheks-Schwachstellen, sondern durch simple Session-Kontroll-Fehler, die der Agentur-Entwickler mit "wird schon keiner probieren" übersprungen hat. Leg den Schwerpunkt auf manuelles Logik-Testing.

die agentur die passwörter in den code eingebettet hat hat wahrscheinlich auch den datei-upload-teil nie angeschaut. ehrlich gesagt kann der kunde beim hochladen von dokumenten iwie ne datei hochladen die im hintergrund php ausführt? testet das dringend da ist die gefährlichste tür.

Erfassen Sie die festgestellten Befunde in einer unternehmensweiten Sicherheitsrisikomatrix. Bewerten Sie die Schwachstellen als kritisch, hoch und mittel. Wenn kritische Schwachstellen, die die Datenbank und die Kundenvertraulichkeit unmittelbar bedrohen, nicht geschlossen werden und das System im Live-Betrieb für die Kundennutzung offen bleibt, kann dies rechtlich zu erheblichen Haftungen führen.

Öffnen Sie noch einmal den Vertrag mit der Agentur und schauen Sie nach. In den meisten Verträgen gibt es eine versteckte oder offene Garantieklausel, dass der Code gemäß Branchenstandards und grundlegenden Sicherheitspraktiken geliefert wird. Passwörter in den Code einzubetten ist eine offensichtlich mangelhafte Dienstleistung, Sie könnten das Recht haben, die Agentur für die Korrekturen offiziell abzumahnen.

wie prüfen stattische Code-Analyse-Tools den Code, ohne ihn auszuführen? wie können diese Tools genau verstehen, dass eine Funktion eine Schwachstelle enthält ohne sie auf einem Live-Server zu installieren und sich mit der Datenbank zu verbinden?

Ich habe keinerlei Erfahrung mit Secure Code Review, deshalb frage ich. In den ersten drei Monaten läuft alles gut, die Probleme tauchen im vierten Monat auf.

Beginnt mit einem kleinen Test, bindet nicht gleich alles fest. Schreibt mir, wenn ihr Fragen habt, ich antworte so gut ich kann.

mich interessiert das auch.

Dieser Ansatz hat seinen Preis der aber nicht thematisiert wird. Wenn die Zwei-Faktor-Authentifizierung aktiv ist, reicht ein gestohlenes Passwort allein nicht aus.

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

Das hatte ich auch schon überlegt. Ein automatisierter Scan-Report ist kein Penetrationstest.

An deiner Stelle würde ich so vorgehen.

Das habe ich auch erlebt. Wenn wir ohne Messung entscheiden, landen wir immer wieder am selben Punkt.

Das war's, entschuldige, wenn ich zu lang war.

Das hatte ich auch schon überlegt. Wenn die Zwei-Faktor-Authentifizierung aktiv ist, reicht ein gestohlenes Passwort allein nicht aus.

Lösungen, die im kleinen Maßstab funktionieren, brechen bei Wachstum zusammen, das habe ich spät gelernt. Nur als Notiz, könnte nützlich sein.

beim Umsetzen gibt es drei Dinge zu beachten und menschen verteidigen nicht den Prozess sondern die Gewohnheit. übrigens der Widerstand kommt daher.

Ich bin in derselben Situation, deshalb frage ich. Wenn Genehmigung und Umfang nicht schriftlich vorliegen, darf der Test nicht starten.

Kein Prozess ohne Dokumentation verbessert sich weil man nicht weiß was man verbessern soll. Das ist meine Meinung, ich behaupte nicht dass es absolut richtig ist.

Bei mir war es genau umgekehrt, deshalb schreibe ich das. Fehler auf der Secure Code Review-Seite sind meist rückgängig zu machen, aber teuer.

Wenn der Benachrichtigungsweg lang ist, kommen keine Benachrichtigungen; keine Benachrichtigung bedeutet spät erkannte Vorfälle.

Meine Frage ist geklärt vielen Dank. Die Zeit, die ihr braucht, um ein Problem zu erkennen, bestimmt direkt dessen Kosten.

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