Mein Pentester, mein Feind? Entwickler verraten, was sie wirklich von Pentests und statischen Analyseergebnissen halten

Ein Entwickler in seinem natürlichen Lebensraum wird oft in einem Zustand hoher Konzentration beobachtet und programmiert tolle Features innerhalb knapper Fristen. Das Erstellen von Funktionen ist oft unser Lieblingsteil der Arbeit, und in Wirklichkeit ist es das grundlegende Ergebnis des Softwareentwicklungszyklus (SDLC).

Wie wir bereits besprochen haben, räumen viele von uns Funktionen jedoch immer noch den besten Sicherheitsmethoden vor. Schließlich ist es in den meisten Organisationen so eingerichtet, dass es die Aufgabe von jemand anderem ist, und angemessene Sicherheitsschulungen für uns sind begrenzt. Penetrationstests und Tools zum Scannen statischer Analysen (besser bekannt als SAST) sind nur ein Teil des Gesamtprozesses zur Minderung von Sicherheitsrisiken. Sie arbeiten ziemlich unabhängig von dem, was wir tun... bis der Code natürlich für Hotfixes zu uns zurückkommt.

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

Diese Interaktionen definieren oft ein Team, eine Kultur. Das Besorgniserregende ist, dass der Mangel an Kommunikation, Verständnis und allgemeiner Zusammenarbeit zu Spannungen geführt hat, zumindest auf der Seite des Entwicklers. 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 und fängt an, Teile davon abzuschlagen, nachdem er Ihnen gesagt hat, dass die Fundamente nicht mehr auf dem neuesten Stand sind. Das ist die wahrgenommene Dynamik zwischen einem Tester und einem Entwickler. Letztere lassen ihre Software-Lieblinge von einem Außenstehenden abschlachten, der den Prozess nicht mit ihnen durchgearbeitet hat. Stattdessen haben sie die Arbeitsbelastung erhöht und die Erfüllung des Versandcodes verzögert.

Da ich vor langer Zeit in den Sicherheitsbereich gezogen bin, kann ich beide Seiten der Geschichte sehen. Und nein, Pentester tun das nicht Hass Entwickler. Der Pentester ist aller Wahrscheinlichkeit nach überarbeitet und steht unter großem Druck. Daher nimmt ein ständiger Strom gängiger Sicherheitslücken, die auf Codeebene recht einfach behoben werden könnten, Zeit, Ressourcen und Headspace weg von den wirklich schwerwiegenden Problemen.

Ich habe Pentester immer als Eltern gesehen. Sie wollen, dass es dir gut geht, und wenn du es nicht tust... sind sie nicht sauer, nur enttäuscht.

Nachdem ich Ihnen dieses (vielleicht etwas unfaire) Bild in den Sinn gebracht habe, lassen Sie uns das etwas genauer untersuchen. Was hat dieses Weltbild unter Entwicklern verursacht?

„Natürlich werde ich defensiv; sie sagen mir, wie ich meinen Job zu machen habe!“

Niemand mag das Gefühl, einen schlechten Job gemacht zu haben oder dass jemand seine Arbeit nicht mag. Leider kann es sich für Entwickler wie ein Zeugnis anfühlen, wenn ihnen statische Analysen und Pentest-Ergebnisse vorliegen. Sie haben schlechte Noten bekommen, aber am Ende des Tages ihr Chefs beurteilen sie nach den Funktionen, die sie entwickelt haben, und nach dem Zeitpunkt, zu dem sie sie bereitgestellt haben, und nicht danach, ob die Software anfällige Elemente enthielt oder nicht.

Für den armen Pentester ist das ein Fall von „Schieß nicht auf den Boten“. Es ist nichts Persönliches - sie haben die Aufgabe, Fehler zu finden, und sie haben sie gefunden. Zugegeben, auf persönlicher Ebene sind einige Pentester vielleicht mürrischer als andere, aber sie sind nicht darauf aus, Entwicklungsteams zu kreuzigen (oder sollten es nicht sein). Es wäre für beide Teams viel einfacher, wenn sie mit den bewährten Sicherheitsmethoden auf derselben Wellenlänge wären. Und von Entwicklern wird nicht erwartet, dass sie perfekt sind. Realistischerweise ist das Testteam dazu da, sie davor zu schützen, anfälligen Code zu versenden.

„Sie haben mir gesagt, ich solle all diese kleineren Probleme lösen, wissen sie nicht, dass es höhere Prioritäten gibt? Und warum helfen sie mir nicht, sie zu beheben, wenn sie sich so sehr darum kümmern?“

Es ist wahr — die höchste Priorität eines Entwicklers wird immer die Entwicklung von Funktionen sein, und in dieser verrückten Welt der schnellen Digitalisierung muss dies schnell geschehen. Einige Programmierer haben zwar ein persönliches Interesse an Sicherheit und sicherer Codierung, aber die allgemeine Meinung ist, dass Sicherheit „das Problem eines anderen“ ist, was unweigerlich Pentester einschließt.

Bei den häufigsten Sicherheitslücken handelt es sich in der Tat um kleinere Probleme, die behoben werden müssen — sobald sie bekannt sind, sind die Fixes für Dinge wie Cross-Site Scripting (XSS) und SQL-Injection einfach auszuführen... das Problem ist, dass viele Entwickler nicht wissen, dass sie sie überhaupt einführen, und diese scheinbar geringfügigen Probleme sind das kleine Zeitfenster, das ein Angreifer nutzt, um verheerende Probleme für ein Unternehmen zu verursachen. Laut Akamai waren zwischen November 2017 und März 2019 SQL-Injection-Schwachstellen dafür verantwortlich 65% aller webbasierten Angriffsvektoren. Für eine Sicherheitslücke, für die seit mehr als zwanzig Jahren ein Fix bekannt ist, ist das eine ernüchternde Statistik.

Einige Pentest-Teams helfen bei der Behebung von Sicherheitslücken, aber andere melden die schlechten Nachrichten und erwarten, dass Entwickler Hotfixes durcharbeiten, auch wenn sie zu diesem Zeitpunkt zu einem anderen Projekt gewechselt sind. Und in einigen Fällen kann das Entwicklungsteam mit einem Bericht konfrontiert werden, der Fehler enthält, die sie nicht beheben können (oder sollten nicht erwartet werden) — sie müssen trotzdem Teil der Ergebnisse sein und auch hier nicht persönlich genommen werden.

Die „goldene Mitte“ dafür wären Pentester, Sicherheitspersonal und Entwicklungsmanager, die eher eine Mentorenrolle spielen, um sicherzustellen, dass das Team über das verfügt, was es an effektiven Schulungen und Tools benötigt, sodass einzelne Programmierer die besten Erfolgschancen haben und von Beginn des SDLC an sicher programmieren können. Beide Teams sollten sich wirklich auf halbem Weg treffen, um sicherzustellen, dass Sicherheit im Rahmen einer gesunden DevSecOps-Praxis von Anfang an berücksichtigt wird.

„Ich habe weitaus bessere Sicherheitskenntnisse, als mir zugeschrieben wird. Diese Berichte sind meistens falsch positiv oder nicht wichtig“.

Die statische Analyse ist ein Element des Sicherheitsprozesses im SDLC, und statische Analysescanning-Tools (SAST) spielen eine grundlegende Rolle. Und ja, falsch positive Ergebnisse sind ein Problem mit diesen und anderen Scannertypen (DAST/IAST/RAST). Es ist ein Ärgernis in einem ohnehin langsamen Prozess, der eine manuelle Codeüberprüfung erfordert und sowohl Entwickler als auch Pentester unter Druck setzt. Die Mitarbeiter von Pentesting haben sich Zeit genommen, um akribisch benutzerdefinierte Regeln aufzustellen, um ungenaue Messwerte zu vermeiden, und haben unternehmensspezifische Anleitungen gegeben. Dennoch rutschen einige falsche Messwerte durch und enden vor einem Entwickler, der sich den Kopf kratzt.

Dieser Prozess ist nicht perfekt, aber das andere Problem ist, dass es vielen Entwicklern an Wissen mangelt, um viele häufig auftretende Sicherheitslücken konsistent zu beheben. Da Sicherheitsschulungen in der Hochschulbildung selten sind und die Ausbildung am Arbeitsplatz in ihrer Effektivität unterschiedlich ist, liegt es auf der Hand, dass auch eine gewisse Selbstüberschätzung im Spiel sein kann (und das ist nicht ihre Schuld — wir als Branche müssen besser darin werden, sie mit dem auszustatten, was sie benötigen).

„Ich wusste nicht, dass diese Anwendung getestet werden sollte, aber jetzt bin ich bei den Korrekturaufgaben hängen geblieben“.

Manchmal gehen überarbeitete Ingenieure davon aus, dass Pentester nur in den Startlöchern stehen und darauf warten, dass der Moment kommt, um zuzuschlagen, indem sie eine Anwendung testen und dem Entwicklungsteam einen Strich durch die Rechnung machen. Sie testen zu viel, sie sind pingelig, sie schaffen zusätzliche Arbeit.

Das einzige Problem dabei ist, dass auch sie überarbeitet sind (noch mehr — der Fachkräftemangel im Bereich Cybersicherheit ist auf einem schlimmen Niveau und es wird immer schlimmer) und haben einfach nicht die Zeit, ohne Grund zu testen. Sie sind nicht die einzigen Entscheidungsträger bei der Priorisierung von Tests. Sie könnten von der Geschäftsleitung, einem Kunden, im Rahmen einer Sicherheitsüberprüfung angefordert oder sogar als Ergebnis eines Bug-Bounty-Programms festgestellt worden sein.

Für einen Entwickler ist es ärgerlich, von aktuellen Sprints zur Feature-Erstellung abgezogen zu werden, um an Sicherheitsupdates zu arbeiten — vor allem, wenn es nicht seine Arbeit ist. Vielleicht hat ein vorheriges Team das letzte Update durchgeführt, oder ein anderer Anbieter. Sicherheit ist jedoch jedermanns Problem. Das bedeutet nicht, dass jeder Entwickler die Verantwortung für Sicherheitslücken übernehmen muss, als ob er sie alle selbst gemacht hätte, aber sie müssen zur Partei kommen, um sicherzustellen, dass Sicherheit eine gemeinsame Verantwortung ist.

Wohin geht es von hier aus?

Manchmal reicht eine Änderung der Denkweise aus, um bei der Lösung eines Problems erhebliche Fortschritte zu erzielen. Wir haben über die eher frostige Reaktion eines Entwicklers auf weniger als günstige Pentest-Ergebnisse gesprochen, aber was wäre, wenn er daraus eine Herausforderung machen könnte? Vielleicht könnten sie sich den Pentester als einen freundlichen Konkurrenten vorstellen; jemanden, den sie in ihrem eigenen Spiel schlagen können. Schließlich wird ein sicherheitsbewusster Entwickler, der häufig auftretende Fehler beim Schreiben von Code beheben kann, seine Arbeit erheblich erschweren. Im Gegensatz dazu wird ein Entwickler, der sich nicht auf Sicherheit konzentriert, von seinen Pentester-Kollegen umfassend übertroffen, wenn sie ihre Software leicht kaputt machen können.

Pentester und Entwickler sind vielleicht nicht immer zu 100% harmonisch miteinander verbunden, aber ihre Beziehung kann erheblich verbessert werden, wenn ein Unternehmen Sicherheit als oberste Priorität betrachtet und Teams mit den richtigen Kenntnissen und Tools ausstattet, um erfolgreich zu sein — insbesondere Entwickler. Es kommt darauf an, ob eine unternehmensweite, positive Sicherheitskultur Priorität hat, und wenn wir den (derzeit) verlorenen Kampf gegen häufig auftretende Sicherheitslücken führen wollen, sollte dies unbedingt der Fall sein.