Mein Pentester, mein Feind? Entwickler verraten, was sie wirklich über Pentesting und Ergebnisse statischer Analysen denken

Entwickler in ihrem natürlichen Lebensraum sind oft hochkonzentriert anzutreffen, während sie unter engem Zeitdruck großartige Funktionen programmieren. Die Entwicklung von Features ist oft unser Lieblingsteil der Arbeit und im Grunde das fundamentale Ergebnis des Softwareentwicklungs-Lebenszyklus (SDLC).

Wie wir jedoch bereits besprochen haben, priorisieren viele von uns immer noch Funktionen gegenüber bewährten Sicherheitspraktiken. Schließlich ist es in den meisten Unternehmen so eingerichtet, dass dies die Aufgabe von jemand anderem ist, und eine angemessene Sicherheitsschulung für uns ist nur begrenzt verfügbar. Penetrationstests und statische Analysetools (besser bekannt als SAST) sind nur ein Teil des Gesamtprozesses zur Minderung von Sicherheitsrisiken und arbeiten weitgehend unabhängig von unserer Arbeit... bis der Code natürlich für Hotfixes zu uns zurückkommt.

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

Diese Interaktionen prägen oft ein Team und eine Kultur. Das Besorgniserregende ist, dass der Mangel an Kommunikation, Verständnis und allgemeiner Zusammenarbeit zu Spannungen geführt hat, zumindest aufseiten der Entwickler. Denken Sie einmal darüber nach: Stellen Sie sich vor, Sie hätten ein paar hundert Stunden damit verbracht, eine wunderbare Statue zu meißeln, und dann kommt jemand mit einem Hammer und schlägt Stücke davon ab, nachdem er Ihnen gesagt hat, dass das Fundament nicht den Anforderungen entspricht. Das ist die wahrgenommene Dynamik zwischen einem Tester und einem Entwickler – Letzterer sieht seine Software-Lieblinge von einem Außenstehenden zerlegt, der nicht mit ihm an dem Prozess gearbeitet hat; stattdessen hat er den Arbeitsaufwand erhöht und die Freude an der Auslieferung des Codes verzögert.

Da ich schon lange im Sicherheitsbereich tätig bin, kann ich beide Seiten der Geschichte verstehen. Und nein, Pentester hassen Entwickler nicht. Der Pentester ist höchstwahrscheinlich überarbeitet und steht unter großem Druck. Daher nimmt ein ständiger Strom häufiger Sicherheitslücken, die auf Code-Ebene recht einfach zu beheben wären, Zeit, Ressourcen und Aufmerksamkeit von den wirklich ernsten Problemen in Anspruch.

Ich habe Pentester immer als eine Art Elternteil gesehen. Sie wollen, dass man Erfolg hat, und wenn das nicht klappt... sind sie nicht wütend, sondern nur enttäuscht.

Nachdem ich Ihnen dieses (vielleicht etwas ungerechte) Bild vor Augen geführt habe, lassen Sie uns das etwas genauer untersuchen. Was hat dieses Weltbild bei Entwicklern verursacht?

"Natürlich gehe ich in die Defensive; sie sagen mir, wie ich meine Arbeit zu machen habe!"

Niemand mag das Gefühl, einen schlechten Job gemacht zu haben oder dass jemand seine Arbeit nicht mag. Leider fühlt es sich für Entwickler wie ein Zeugnis an, wenn Ergebnisse von statischen Analysen und Pentests zurückkommen. Sie haben schlechte Noten bekommen, aber letztendlich bewerten ihre Vorgesetzten sie nach den Funktionen, die sie gebaut haben, und der Zeit, in der sie diese geliefert haben, nicht danach, ob die Software anfällige Elemente enthielt oder nicht.

Für den armen Pentester ist das ein Fall von „Schießt nicht auf den Boten“. Es ist nichts Persönliches – sie haben den Auftrag, Fehler zu finden, und sie haben sie gefunden. Zugegeben, auf persönlicher Ebene sind manche Pentester vielleicht mürrischer als andere, aber sie sind nicht darauf aus (oder sollten es nicht sein), Entwicklungsteams fertigzumachen. Es wäre für beide Teams viel einfacher, wenn sie sich einig wären, was bewährte Sicherheitspraktiken ausmacht. Und von Entwicklern wird nicht erwartet, dass sie perfekt sind; realistischerweise ist das Testteam dazu da, sie davor zu bewahren, anfälligen Code auszuliefern.

"Sie haben mir gesagt, ich solle all diese kleinen Probleme beheben, wissen sie denn nicht, dass es wichtigere Prioritäten gibt? Und warum helfen sie mir nicht bei der Behebung, wenn ihnen so viel daran liegt?"

Es stimmt – die höchste Priorität eines Entwicklers wird immer der Bau von Funktionen sein, und in dieser verrückten Welt der schnellen Digitalisierung muss dies schnell geschehen. Während einige Programmierer ein persönliches Interesse an Sicherheit und sicherem Programmieren haben, ist die allgemeine Stimmung, dass Sicherheit „das Problem von jemand anderem“ ist, was zwangsläufig auch die Pentester einschließt.

Die meisten häufigen Schwachstellen sind tatsächlich leicht zu beheben – sobald sie bekannt sind, sind die Korrekturen für Dinge wie Cross-Site Scripting (XSS) und SQL-Injection einfach umzusetzen... das Problem ist, dass viele Entwickler gar nicht merken, dass sie diese überhaupt erst einführen, und diese scheinbar kleinen Probleme sind das kleine Zeitfenster, das ein Angreifer benötigt, um verheerende Probleme für ein Unternehmen zu verursachen. 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 eine bekannte Lösung gibt, ist das eine ernüchternde Statistik.

Einige Pentest-Teams unterstützen bei der Behebung von Sicherheitslücken, aber andere liefern nur einen Bericht mit den schlechten Nachrichten und erwarten von den Entwicklern, dass sie die Hotfixes abarbeiten, selbst wenn sie zu diesem Zeitpunkt bereits an einem anderen Projekt arbeiten. Und in manchen Fällen kann das Entwicklungsteam mit einem Bericht konfrontiert werden, der Fehler enthält, die sie nicht beheben können (oder von denen man nicht erwarten sollte, dass sie sie beheben) – das muss trotzdem Teil der Ergebnisse sein und sollte wiederum nicht persönlich genommen werden.

Der „goldene Mittelweg“ wäre, dass Pentester, Sicherheitspersonal und Entwicklungsleiter eher eine Mentorenrolle einnehmen, um sicherzustellen, dass das Team über effektive Schulungen und Tools verfügt. So erhalten die einzelnen Programmierer die besten Chancen, von Anfang an erfolgreich und sicher zu programmieren. Beide Teams sollten sich in der Mitte treffen, um sicherzustellen, dass Sicherheit von Anfang an als Teil einer gesunden DevSecOps-Praxis berücksichtigt wird.

"Ich habe viel mehr Sicherheitswissen, als mir zugestanden wird; diese Berichte enthalten meist Fehlalarme oder sind unwichtig."

Statische Analysen sind ein Element des Sicherheitsprozesses im SDLC, und statische Analysetools (SAST) spielen dabei eine grundlegende Rolle. Und ja, Fehlalarme sind ein Problem bei diesen und anderen Arten von Scannern (DAST/IAST/RAST). Es ist ein Ärgernis in einem ohnehin schon langsamen Prozess, das manuelle Code-Reviews erfordert und sowohl Entwickler als auch Pentester unter Druck setzt. Das Pentest-Personal hat sich die Zeit genommen, benutzerdefinierte Regeln akribisch einzurichten, um ungenaue Ergebnisse zu vermeiden und unternehmensspezifische Anleitungen bereitzustellen, doch einige falsche Meldungen schlüpfen durch und landen bei einem ratlosen Entwickler.

Dieser Prozess ist nicht perfekt, aber ein weiteres Problem ist, dass vielen Entwicklern das nötige Wissen fehlt, um viele gängige Schwachstellen konsequent zu beheben. Da Sicherheitsschulungen in der Hochschulbildung selten sind und die Effektivität von Weiterbildungen am Arbeitsplatz variiert, ist eine gewisse Selbstüberschätzung durchaus naheliegend (was nicht ihre Schuld ist – wir als Branche müssen sie besser mit dem nötigen Rüstzeug ausstatten).

„Ich wusste nicht, dass diese Anwendung getestet wird, aber jetzt bleibe ich auf den Nachbesserungen sitzen.“

Manchmal gehen überlastete Entwickler davon aus, dass Pentester nur darauf warten, eine Anwendung zu prüfen und dem Entwicklungsteam die Tour zu vermasseln. Sie testen zu viel, suchen das Haar in der Suppe und verursachen zusätzliche Arbeit.

Das Problem dabei ist nur, dass auch sie überlastet sind (tatsächlich sogar noch mehr – der Fachkräftemangel in der Cybersicherheit ist besorgniserregend und verschärft sich weiter) und schlicht keine Zeit für grundlose Tests haben. Sie entscheiden nicht allein über die Priorisierung; Tests können von der Geschäftsführung, Kunden, im Rahmen eines Audits oder durch ein Bug-Bounty-Programm angefordert worden sein.

Für Entwickler ist es ärgerlich, aus aktuellen Sprints für neue Funktionen abgezogen zu werden, um Sicherheitslücken zu beheben – besonders wenn der Code nicht von ihnen stammt. Vielleicht hat ein früheres Team oder ein externer Dienstleister das letzte Update durchgeführt. Sicherheit ist jedoch ein gemeinsames Anliegen. Das bedeutet nicht, dass jeder Entwickler für alle Sicherheitslücken geradestehen muss, aber Sicherheit muss als gemeinsame Verantwortung begriffen werden.

Wie geht es weiter?

Manchmal reicht ein Umdenken, um bei der Problemlösung entscheidende Fortschritte zu erzielen. Wir haben über die frostige Reaktion von Entwicklern auf negative Pentest-Ergebnisse gesprochen – aber was, wenn sie es als Herausforderung sähen? Vielleicht als freundschaftlichen Wettbewerb, bei dem man den Pentester schlagen kann. Ein sicherheitsbewusster Entwickler, der gängige Fehler schon beim Schreiben des Codes eliminiert, macht es dem Pentester schwer. Wer Sicherheit ignoriert, wird hingegen leichtes Spiel für den Pentester bieten.

Pentester und Entwickler werden vielleicht nicht immer einer Meinung sein, aber ihr Verhältnis lässt sich massiv verbessern, wenn ein Unternehmen Sicherheit zur Priorität macht und Teams – besonders Entwickler – mit dem richtigen Wissen und Werkzeugen ausstattet. Es kommt darauf an, ob eine positive, unternehmensweite Sicherheitskultur Priorität hat. Wenn wir den (derzeit) verlorenen Kampf gegen gängige Schwachstellen gewinnen wollen, sollte sie das definitiv sein.