Dienstleister schlägt statische Code-Analyse statt Pentest vor – reicht das als Ersatz?

Statische Analyse liest nur den geschriebenen Text. Ein falsch konfigurierter Server-Port, ein veralteter Webserver-Dienst oder versehentlich öffentlich freigegebene Cloud-Datenbanken stehen nicht im Code. Solche Schwachstellen lassen sich nur am lebenden Objekt per Pentest aufspüren.

Den Fehler haben wir damals bei unserer E-Commerce-Infrastruktur in Kasan auch gemacht. Dienstleister hat uns einen Scan-Report gegeben, wir haben ihn an den Kunden weitergereicht. Dessen Security-Audit hat innerhalb von zwei Stunden unbefugten Zugriff aufs Admin-Panel gehabt. Ergebnis: zwei Monate Projektverzögerung und wir mussten Hals über Kopf 400.000 Rubel für externe Pentester nachschießen.

Wie lautet die genaue Formulierung im Lastenheft bzw. Vertrag mit eurem Kunden? Wenn dort ausdrücklich von Penetrationstest oder unabhängigem Sicherheitsaudit die Rede ist, schmettert deren Rechtsabteilung oder Revision einen simplen statischen Code-Scan sofort ab. Habt ihr die Klausel geprüft?

Die Kernunterschiede auf den Punkt gebracht: 1) Statische Analyse prüft toten Text ohne Ausführung; Pentests laufen dynamisch am Produktivsystem. 2) Scanner verstehen keine Business-Logik, der Pentester attackiert mit Verstand und Kreativität. 3) Firmenaudits akzeptieren fast immer nur unabhängige Pentest-Reports als offiziellen Nachweis.

Das Angebot des Dienstleisters klingt für mich faul. Statische Code-Analyse heißt meist: Code in ein Standard- oder Open-Source-Tool werfen und nach ein paar Stunden einen automatischen Report exportieren. Für einen Klick auf den Start-Button dann 120.000 Rubel zu verlangen, ist schlichtweg Wucher.

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

Schreibt den technischen Ansprechpartner eures Kunden direkt per E-Mail an. Fragt schriftlich nach ob ein Bericht zur statischen Quellcodeanalyse akzeptiert wird. Zu neunzig Prozent werden sie sagen, dass ein Pentest Pflicht ist. So spart ihr euch die 120.000 Rubel die ihr sonst sinnlos an den Dienstleister abdrücken würdet.

Entwickler drücken sich oft vor einem unabhängigen Penetrationstest weil dann ein fremdes Tech-Team kommt und dem Chef ihre Arbeit samt Schlampereien beim Server-Setup schwarz auf weiß vorlegt. Meiner Meinung nach geht es denen nicht ums Budget, sondern darum, dass ihre eigenen Fehler nicht auffliegen.

bei unserem projekt gabs auch nen statischen scan kamen seitenweise unnoetige warnungen aber die eigentliche rechte-luecke hat er uebersehen. ein enterprise kunde akzeptiert das niemals verbrennt nicht unnoetig euer geld.

Ich spreche mal aus der Gegenperspektive ich bin auf der Lieferantenseite. In den ersten drei Monaten läuft alles gut, die Probleme tauchen im vierten Monat auf.

Meine Frage klingt vielleicht etwas naiv, entschuldigt bitte. Ein automatisierter Scan-Report ist kein Penetrationstest.

In den ersten drei Monaten läuft alles gut, die Probleme tauchen im vierten Monat auf. Viel Erfolg.

Die Diskussion ist abgeschweift, ich fasse mal zusammen. Scheut euch nicht zu fragen, wer nicht fragt, zahlt am Ende mehr.

Nach diesem Erlebnis hat sich meine Sichtweise geändert. In den ersten drei Monaten läuft alles gut, die Probleme tauchen im vierten Monat auf.

Ein automatisierter Scan-Report ist kein Penetrationstest. Das ist meine Meinung, ich behaupte nicht, dass es absolut richtig ist.

Ich schreibe mal meine Erfahrung auf. Kein Prozess ohne Dokumentation verbessert sich, weil man nicht weiß, was man verbessern soll.

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

Meine Frage ist geklärt, vielen Dank. Entscheidend ist nicht die Zahl, sondern worauf sie sich bezieht.

Viel Erfolg.

Ich würde sagen, lass uns nichts überstürzen. Entscheidend ist nicht die Zahl, sondern worauf sie sich bezieht.

Das allein zu versuchen, ist der teuerste Weg. Nur als Notiz, könnte nützlich sein.

Da stimme ich zu. Wenn Genehmigung und Umfang nicht schriftlich vorliegen, darf der Test nicht starten.

Fehler auf der statische Code-Analyse-Seite sind meist rückgängig zu machen, aber teuer. Wenn deine Situation anders ist, ändert sich das natürlich.

Teilweise stimme ich zu, teilweise nicht. Schaut zuerst, welche Daten ihr bei der Entscheidungsfindung zur Hand habt.

Nur weil alle es tun, heißt es nicht, dass es richtig ist. An deiner Stelle würde ich so vorgehen.

Da stimme ich zu. Schaut zuerst, welche Daten ihr bei der Entscheidungsfindung zur Hand habt.

Das war's entschuldige wenn ich zu lang war.