Automatischer Schwachstellencheck in der Softwareentwicklung

Schwachstellen aufgrund schlecht entwickelter Software sind für Unternehmen nach wie vor ein großes Einfallstor für Hackerangriffe. Daher empfehlen Security-Experten, mit Pentesting die eigene Software auf Schwachstellen hin zu prüfen. Eine Stufe früher setzt die Lösung eines Start-up-Unternehmens aus Bonn ein. Code Intelligence begleitet quasi die Entwickler beim Coden und sucht laufend nach Fehlern.

Philip, eure Idee, Code schon im Entwicklungsprozess auf Schwachstellen zu checken, scheint neu zu sein. Was ist eure Idee hinter der Lösung?

Philip Betzler: Im Grunde machen wir Application Security Testing, vergleichbar einem automatischen Pentesting. Jedes Mal springt unsere Lösung an, wenn ein Entwickler neuen Code auf seinem Code Repository abgelegt hat. Da unsere Lösung meistens in die CI/CD – Continuous Integration/Continuous Development – integriert ist, wird der Schwachstellencheck automatisch angestoßen. Die Technik hinter unserer Lösung nennt sich „White-Box-/Smart- oder Feedback-based Fuzzing“ und unterscheidet sich deutlich vom älteren Ansatz „Blackbox-/Dumb Fuzzing“.

Und wenn eure Lösung eine Schwachstelle findet, dann repariert sie den Code an dieser Stelle?

Nein, die Lösung zeigt dem Entwickler aber genau die Stelle, an der die Schwachstelle gefunden wurde und welche Eingabe verantwortlich war. Er kann sie dann sofort schließen. Und wenn eine kritische Schwachstelle gefunden wird, verhindert unsere Lösung, dass der neue Code automatisch deployed wird und damit eine angreifbare Version in Benutzung wäre.

Was sagen die Entwickler dazu?

Die finden das Prinzip gut, denn viele Entwickler können sehr gut programmieren, aber haben wenig Erfahrung mit Security. Wenn sie genau gezeigt bekommen, wo sie was falsch gemacht haben, können sie daraus lernen? Denn wir zeigen, wo das Problem auftritt, klassifizieren die Schwachstellen nach Kritikalität und stellen weiterführende Links bereit, über die sie sich informieren können, wie sie mit der jeweiligen Schwachstelle umgehen können.

Damit bekommen sie ganz nebenbei auch noch eine Art Fortbildung.

Das ist nicht unsere Hauptintention, aber ein positiver Nebeneffekt. Ich habe selbst entwickeln gelernt. Aber wie man richtige IT-Sicherheit-Tools bei der Entwicklung einsetzt, haben wir nie gelernt. Das lief eher nebenbei. Du weißt also nicht, dass es eigentlich ein Automatismus sein sollte, Security-Tools zu integrieren, die regelmäßig deine Arbeit scannen.

Aber es gibt doch schon Pentesting, mit dem sich Schwachstellen finden lassen?

Der große Unterschied ist, dass wir genau sagen können, welche Zeilen des Codes überprüft worden sind und welche nicht. Und wir laufen mit dem Entwicklungszyklus mit, während ein Pentest erst am Ende der Entwicklung gemacht wird. Bis dann ein Ergebnis vorliegt, sind schnell sechs Monate vergangen, und die Entwickler erinnern sich nicht mehr daran, was und warum sie Monate vorher welchen Code geschrieben haben. Das spiegeln uns zumindest unsere Kunden als Vorteil unsere Lösung.

Ihr macht also nicht das Gleiche wie ein Pentester. Braucht man daher Pentests zusätzlich?

Wir finden knapp 80 Prozent von dem, was Pentests finden. Daher sollte am Schluss trotzdem ein Pentest gemacht werden. Aber da wir den Coding-Prozess begleiten, gibt es nicht nur deutlich weniger Schwachstellen, sondern man spart auch eine ganze Menge an Wiederholungen. Denn wenn der Pentest Fehler findet, müssen die erst gefixt werden. Dann muss nochmal getestet werden. Das kostet Zeit und Geld und währenddessen läuft die Software bereits mit Schwachstellen oder kann nicht deployed werden.

Ist es kompliziert, eure Lösung in den Coding-Prozess zu intergieren?

Du kannst wirklich mit drei Befehlen unseren Fuzztest komplett aufsetzten und laufen lassen. Das ist nicht kompliziert und müssen auch keine weiteren Parameter eingestellt werden. Danach testet unsere Lösung viele tausend Eingaben pro Sekunde.

Dann gibt doch eigentlich für Unternehmen fast keinen Grund, eure Lösung nicht einzusetzen, weil sie ganz einfach ein Grundprobleme löst?

Unsere Lösung kommt an. Zu unseren Kunden gehören unter anderem schon Bosch, Continental, VW/CARIAD, Toyota/Woven Planet und Google. Die nutzen unsere Lösung fast alle noch on prem. Wir bauen aber derzeit unserSaaS-Modell stärker aus. Eine weiter verbreitete Möglichkeit ist Static Application Security Testing, die aber den Code testen, ohne ihn auszuführen. Die finden auch viele Fehler, haben aber viele False positiv-Meldungen. Wir haben dagegen keine False Positives.

Wer hatte denn die Idee für eure Lösung?

Die ersten Fuzzing-Ansätze gibt es schon seit den 1980er Jahren. Da waren die Fuzzer noch blackbox und das Testen glich dem Herumtasten im Dunkeln. Seitdem hat sich einiges getan, da unter anderem große Firmen wie Google die Technologie weiterentwickelt haben. Aber das große Problem dahinter war, dass die Technologie schwer einzusetzen und zu integrieren ist. Deswegen war unsere ursprüngliche Idee anfangs, die Technologie überhaupt erst einmal benutzbar zu machen. Durch unsere Weiterentwicklung ist es jetzt genauso einfach, die Technologie zu nutzen wie Unit Tests – einfache, grundsätzliche Funktionalitäts-Tests – zu schreiben. Inzwischen nutzt selbst Google unsere Fuzzer benutzt und bezahlt uns, um wichtige Open Source Projekte zu testen. So haben wir auch hier bereits heftige Schwachstellen gefunden.

Seht ihr eure Lösung eher bei den Entwicklern oder bei den Security-Leuten?

Wir fokussieren uns mit unserer Sicherheitslösung auf Entwickler. Mit unserem Ansatz, dass wir den Entwicklern helfen, machen wir den Entwicklungsprozess sehr viel schneller. Und die Entwickler werden aus Sicherheitssicht immer besser, was den Unternehmen Zeit und Geld spart. Wenn man unsere Lösung mit dem Bau eines Hauses vergleicht, helfen wir den Maurern, dass die Mauer gleich richtig hochgezogen wird, während sich andere Security-Tools das Haus erst anschauen, wenn es fertig ist. Und dann gibt es Fehler, die nur mit großem Aufwand behoben werden können.

Philip Betzler

ist Solution Engineer bei Code Intelligence.