Mein Pentester, mein Feind? Entwickler verraten, was sie wirklich über Pentesting und statische Analyseergebnisse denken

Ein Entwickler in seinem natürlichen Lebensraum wird oft in einem Zustand tiefer Konzentration gesichtet, während er unter Zeitdruck fantastische Funktionen programmiert. Das Erstellen von Funktionen ist oft unser liebster Teil der Arbeit, und tatsächlich ist es das grundlegende Ergebnis des Softwareentwicklungslebenszyklus (SDLC).

Doch wie wir bereits besprochen haben, geben viele von uns immer noch den Funktionen den Vorrang vor den Best Practices für die Sicherheit. Schließlich ist es in den meisten Organisationen so eingerichtet, dass es die Aufgabe von jemand anderem ist, und eine angemessene Sicherheitsschulung für uns ist begrenzt. Penetrationstests und Scanning-Tools für die statische Analyse (besser bekannt als SAST) sind nur ein Teil des Gesamtprozesses zur Minderung von Sicherheitsrisiken und arbeiten ziemlich unabhängig von dem, was wir tun... bis der Code für Hotfixes zu uns zurückkommt, natürlich.

Und genau in diesem Moment denken viele Entwickler:"Hassen mich die Pentester?".

Diese Interaktionen definieren oft ein Team, eine Kultur. Das Beunruhigende ist, dass der Mangel an Kommunikation, Verständnis und allgemeiner Zusammenarbeit zu Spannungen geführt hat, zumindest auf der Seite der Entwickler. Denken Sie darüber nach: Stellen Sie sich vor, Sie haben ein paar hundert Stunden damit verbracht, eine wunderbare Statue zu formen, und dann kommt jemand mit einem Hammer daher und fängt an, Teile davon zu zerschlagen, nachdem er Ihnen gesagt hat, dass das Fundament nicht in Ordnung ist. Das ist die wahrgenommene Dynamik zwischen einem Tester und einem Entwickler - letzterer lässt seine Software-Lieblinge von einem Außenstehenden abschlachten, der sich nicht mit ihnen durch den Prozess gearbeitet hat; stattdessen hat er die Arbeitslast verlängert und die Zufriedenheit mit der Auslieferung des Codes verzögert.

Da ich vor langer Zeit in den Sicherheitsbereich gewechselt bin, kann ich beide Seiten der Geschichte sehen. Und nein, Pentester hassen keine Entwickler. Der Pentester ist höchstwahrscheinlich überarbeitet und steht unter einer Menge Druck. Daher nimmt ein ständiger Strom von gewöhnlichen Sicherheitsfehlern, die recht einfach auf Code-Ebene behoben werden könnten, Zeit, Ressourcen und den Kopf von den wirklich ernsten Problemen weg.

Ich habe Pentester immer als eine Art von Eltern gesehen. Sie wollen, dass man gut abschneidet, und wenn man es nicht tut, sind sie nicht sauer, nur enttäuscht.

Nun, da ich Ihnen dieses (vielleicht etwas unfaire) Bild in den Kopf gesetzt habe, lassen Sie uns das ein wenig tiefer ergründen. Was hat diese Weltanschauung unter Entwicklern verursacht?

"Natürlich werde ich defensiv; sie sagen mir, wie ich meinen Job machen soll!"

Niemand mag das Gefühl, dass er schlechte Arbeit geleistet hat oder dass jemand seine Arbeit nicht mag. Leider kann es sich für Entwickler wie ein Zeugnis anfühlen, wenn sie die Ergebnisse der statischen Analyse und des Pentests zurückbekommen. Sie haben schlechte Noten bekommen, aber am Ende des Tages bewerten ihre Chefs sie nach den Funktionen, die sie gebaut haben, und der Zeit, die sie dafür gebraucht haben, und nicht danach, ob es anfällige Elemente in der Software gab oder nicht.

Für den armen Pentester ist das ein Fall von "don't shoot the messenger". Es ist nichts persönliches - sie sind damit beauftragt, Fehler zu finden, und sie haben sie gefunden. Zugegeben, auf einer persönlichen Ebene, sind vielleicht einige Pentester mürrischer als andere, aber sie sind nicht darauf aus (oder sollten es nicht sein), die Entwickler Teams zu kreuzigen. Es wäre viel einfacher für beide Teams, wenn sie auf der gleichen Seite wären, was die beste Sicherheitspraxis ausmacht. Und von den Entwicklern wird nicht erwartet, dass sie perfekt sind; realistisch betrachtet, ist das Test-Team dazu da, sie vor der Auslieferung von anfälligem Code zu schützen.

"Sie haben mir gesagt, dass ich all diese kleinen Probleme beheben soll, wissen sie nicht, dass es höhere Prioritäten gibt? Und warum helfen sie mir nicht, sie zu beheben, wenn sie sich so sehr sorgen?"

Es ist wahr - die höchste Priorität eines Entwicklers wird immer die Erstellung von Funktionen sein, und in dieser verrückten Welt der schnellen Digitalisierung muss dies mit Geschwindigkeit geschehen. Während einige Programmierer ein persönliches Interesse an Sicherheit und sicherer Codierung haben, ist die allgemeine Stimmung, dass Sicherheit "das Problem von jemand anderem" ist, was unweigerlich Pentester einschließt.

Die meisten häufigen Schwachstellen sind in der Tat geringfügig zu beheben - sobald sie bekannt sind, sind die Korrekturen für Dinge wie Cross-Site-Scripting (XSS) und SQL-Injection einfach auszuführen... das Problem ist, dass viele Entwickler gar nicht merken, dass sie sie überhaupt einführen, und diese scheinbar geringfügigen Probleme sind das kleine Zeitfenster, das ein Angreifer braucht, um einem Unternehmen verheerende Probleme zu bereiten. Laut Akamai machten SQL-Injection-Schwachstellen zwischen November 2017 und März 2019 65 % aller webbasierten Angriffsvektoren aus. Für eine Schwachstelle, für die es seit mehr als zwanzig Jahren einen bekannten Fix gibt, ist das eine ernüchternde Statistik.

Einige Pentest-Teams helfen bei der Behebung von Sicherheitsfehlern, aber andere liefern einen Bericht mit den schlechten Nachrichten und erwarten von den Entwicklern, dass sie Hotfixes abarbeiten, auch wenn sie zu dem Zeitpunkt, an dem dies geschieht, bereits zu einem anderen Projekt gewechselt haben. Und in manchen Fällen wird das Entwicklungsteam mit einem Bericht konfrontiert, der Fehler enthält, die sie nicht beheben können (oder von denen man nicht erwarten sollte, dass sie behoben werden) - es muss trotzdem ein Teil der Ergebnisse sein, und wieder, nicht persönlich genommen werden.

Der "goldene Mittelweg" hierfür wäre, dass Pentester, Sicherheitspersonal und Entwicklungsleiter eher in einer Mentorenrolle agieren, um sicherzustellen, dass das Team über das verfügt, was es in Bezug auf effektive Schulungen und Tools benötigt, um den einzelnen Programmierern die beste Chance zu geben, erfolgreich zu sein und von Beginn des SDLC an sicher zu programmieren. Beide Teams sollten sich wirklich auf halbem Weg treffen, um sicherzustellen, dass die Sicherheit von Anfang an berücksichtigt wird, als Teil einer gesunden DevSecOps-Praxis.

"Ich habe viel bessere Sicherheitskenntnisse, als man mir zugesteht; diese Berichte sind meist falsch positiv oder nicht wichtig".

Die statische Analyse ist ein Element des Sicherheitsprozesses im SDLC, und Scan-Tools für die statische Analyse (SAST) spielen eine grundlegende Rolle. Und ja, falsch-positive Ergebnisse sind ein Problem bei diesen und anderen Arten von Scannern (DAST/IAST/RAST). Es ist ein Ärgernis in einem ohnehin schon langsamen Prozess, der manuelles Code-Review erfordert und sowohl Entwickler als auch Pentester unter Druck setzt. Die Pentesting-Mitarbeiter haben sich die Zeit genommen, akribisch benutzerdefinierte Regeln aufzustellen, um ungenaue Messwerte zu vermeiden und unternehmensspezifische Anleitungen zur Verfügung zu stellen, dennoch schlüpfen einige falsche Messwerte durch und landen vor einem kopfschüttelnden Entwickler.

Dieser Prozess ist nicht perfekt, aber das andere Problem ist, dass viele Entwickler nicht genug Wissen haben, um viele häufige Schwachstellen auf einer konsistenten Basis zu entschärfen. Da Sicherheitstrainings in der Hochschulausbildung selten sind und das Training am Arbeitsplatz in seiner Effektivität variiert, ist es naheliegend, dass auch eine gewisse Selbstüberschätzung im Spiel ist (und es ist nicht ihre Schuld - wir als Industrie müssen sie besser mit dem ausstatten, was sie brauchen).

"Ich wusste nicht, dass diese Anwendung getestet werden würde, aber jetzt stecke ich mit den Aufgaben zur Behebung fest".

Manchmal wird von überlasteten Ingenieuren angenommen, dass die Pentester nur in den Startlöchern stehen und auf den richtigen Moment warten, um eine Anwendung zu testen und dem Entwicklungsteam in die Parade zu fahren. Sie testen zu viel, sie sind pingelig, sie verursachen zusätzliche Arbeit.

Das einzige Problem dabei ist, dass auch sie überarbeitet sind (sogar noch mehr - der Fachkräftemangel im Bereich Cybersicherheit ist katastrophal und wird immer schlimmer) und einfach nicht die Zeit haben, ohne Grund zu testen. Sie sind nicht die alleinigen Entscheidungsträger bei der Priorisierung von Tests; es könnte von der Unternehmensleitung, einem Kunden, als Teil eines Sicherheitsaudits oder sogar als Ergebnis eines Bug Bounty-Programms bestimmt worden sein.

Für einen Entwickler ist es ärgerlich, wenn er aus einem laufenden Sprint für die Erstellung von Funktionen abgezogen wird, um an Sicherheitskorrekturen zu arbeiten - besonders wenn es nicht seine Arbeit ist. Vielleicht hat ein früheres Team das letzte Update durchgeführt, oder ein anderer Anbieter. Wie auch immer, Sicherheit ist das Problem von jedem. Das bedeutet nicht, dass jeder Entwickler die Verantwortung für Sicherheitsprobleme übernehmen muss, als ob er sie alle selbst gemacht hätte, aber sie müssen mitmachen, wenn es darum geht, dass Sicherheit eine gemeinsame Verantwortung ist.

Wohin von hier aus?

Manchmal reicht eine Änderung der Denkweise aus, um bei der Lösung eines Problems einen bedeutenden Schritt voranzukommen. Wir haben über die eher frostige Reaktion eines Entwicklers auf ungünstige Pentestergebnisse gesprochen, aber was wäre, wenn sie es in eine Herausforderung verwandeln könnten? Vielleicht könnten sie den Pentester als einen freundlichen Konkurrenten betrachten; jemanden, den sie in ihrem eigenen Spiel schlagen können. Schließlich wird ein sicherheitsbewusster Entwickler, der häufige Fehler beim Schreiben von Code beseitigen kann, seine Arbeit sehr viel schwieriger machen. Im Gegensatz dazu wird ein Entwickler, der keinen Fokus auf Sicherheit legt, von seinem Pentester-Kollegen umfassend besiegt werden, wenn dieser seine Software leicht brechen kann.

Pentester und Entwickler harmonieren vielleicht nicht immer zu 100 % miteinander, aber ihre Beziehung kann erheblich verbessert werden, wenn ein Unternehmen die Sicherheit als Hauptpriorität behandelt und die Teams mit dem richtigen Wissen und den richtigen Tools ausstattet, um erfolgreich zu sein - insbesondere die Entwickler. Es kommt darauf an, ob eine unternehmensweite, positive Sicherheitskultur eine Priorität ist, und wenn wir den (derzeit) aussichtslosen Kampf gegen verbreitete Schwachstellen bekämpfen wollen, sollte sie das unbedingt sein.