In diesem Artikel erläutere ich, warum es immer noch Probleme mit der Anwendungssicherheit (AppSec) gibt und warum traditionelle Anwendungssicherheitstools insbesondere in der modernen, agilen Entwicklung für Entwickler:innen keinen Mehrwert bieten. Und wenn Sie dachten, KI würde uns retten, dann lesen Sie weiter und entdecken Sie einen besseren Weg, Anwendungen zu sichern.

In diesem Artikel wird detailliert beschrieben, wie diese Tools den Projektablauf stören und dazu führen können, dass Entwickler:innen stark demotiviert werden, möglicherweise einen Burnout erleiden oder die IT-Branche ganz verlassen. Es wird erklärt, wie moderne, sensorbasierte Laufzeitsicherheitstools die Entwickler – die Einzigen, die Schwachstellen beheben können – wirklich dazu befähigen können, Verantwortung zu übernehmen, Probleme zu lösen, bevor sie sich ausbreiten, und vor allem, wie bessere Werkzeuge die volle Freude am Programmieren zurückbringen.

Warum ist AppSec ein Problem?

Als ich vor 24 Jahren meine erste dynamische Internetanwendung schrieb, waren die Wörter „Schwachstelle“ und „Sicherheit“ noch sehr weit weg. Sicherheit? Das betraf meine Kolleg:innen in den Netzwerkteams, es war kein Thema für mich. Heute bin ich froh, dass alles, was ich damals entwickelt habe, inzwischen ersetzt wurde, denn ich weiß, dass SQL-Injection-Sicherheitslücken in meinem Code wohl eher die Regel als die Ausnahme waren. Es dauerte einige Jahre, bis ich allmählich einen vorsichtigeren und sichereren Umgang mit Datenbanken, Dateisystemzugriffen und der Behandlung von Eingabeparametern entwickelte.

Anscheinend starten viele Entwickler:innen mit einer ähnlichen Unbekümmertheit in ihre Karriere. Anders kann ich mir nicht erklären, dass Injektionsprobleme auf Platz 3 der OWASP Top Ten stehen. Die meisten Entwickler:innen sind wahrscheinlich konstruktive, kreative Optimisten: Wenn etwas funktioniert, dann ist es gut. Seien wir ehrlich – ist das nicht der größte Spaß? Einfach etwas bauen? Etwas, das funktioniert, möglicherweise gut aussieht, hoffentlich gut funktioniert und einen Mehrwert bietet?

Von Anfang an alles ganz wasserdicht zu bauen, gehört selten zu den Anforderungen oder Prioritäten. Abgesehen von einem Feature-First-Fokus liegt oft schon in der Ausbildung ein Problem, und selbst mit dem richtigen Training ist es leicht, Fehler zu machen – wir sind schließlich alle Menschen.

Wir sind jedoch an einem Scheideweg angelangt. Als Entwickler:innen und als Produktverantwortliche haben Sie folgende Möglichkeiten:

1. Sie können weiterhin nichts tun und akzeptieren, gehackt zu werden, die IT verlassen oder Ihre Identität ändern.

2. Sie können weiterhin veraltete Sicherheitstools verwenden, was zu Ineffizienz und hohen Kosten durch den zusätzlichen Zeitaufwand für Sicherheitsmaßnahmen führt. Dadurch müssen Sie eine zunehmende Zahl potenzieller Schwachstellen in Kauf nehmen, die in die Produktion gelangen, und die Abwanderung von Entwickler:innen in andere Bereiche akzeptieren.

3. Sie können weiterlesen und einen Weg entdecken, die Dinge anders anzugehen.

Option 1 ist eindeutig eine schlechte Idee, es sei denn, Sie möchten tatsächlich Ihre Identität ändern und das Unternehmen rebranden. Scherz beiseite, es gibt durchaus Firmen, die einen erfolgreichen Angriff nicht oder nur schwer überlebt haben. Zum Beispiel musste das Unternehmen Travelex im Januar 2020 Insolvenz anmelden, nachdem es am Silvesterabend Opfer eines Cyberangriffs geworden war [1].

Meistens wurde Option 2 gewählt. Entwickler:innen mussten lernen, den ständig wachsenden Schmerz der Anwendungssicherheitsberichte zu ertragen. Seien wir ehrlich, wer mag schon die Berichte über mögliche Schwachstellen, die die typischen SAST- und DAST-Tools produzieren? Für Entwickler:innen ist das ungefähr so erfreulich wie eine korrigierte Prüfung zu erhalten, bei der Fehler zwar markiert, nicht aber erklärt werden. Für die Kolleg:innen in der Security bedeuten die langen Berichte harte Arbeit, denn es gibt viel zu erklären und kaum Zeit, alle Berichte zu analysieren, geschweige denn, die nötigen Änderungen von den Entwickler:innen umsetzen zu lassen. Eine kleine Anzahl von Sicherheitsexpert:innen muss dann eine große Anzahl von Entwickler:innen überzeugen und schulen. Agile, iterative Entwicklung trifft auf klassische Wasserfall-Sicherheitsprozesse, was oft zu Frustration und immer längeren Sicherheits-Backlogs führt.

Wenn Sie sich an dieser Stelle nicht sicher sind, was mit den traditionellen Tools nicht stimmt oder wenn Sie denken, dass die KI uns retten wird, lesen Sie weiter.

Warum versagen traditionelle AppSec-Tools in der modernen Entwicklung?

Aus der Sicht eines Sicherheitsadmins sind Entwickler:innen wie Kinder mit Streichhölzern auf einem Pulverfass. Das klingt dramatisch, aber Fakt ist, dass Anwendungen oft privilegierten Zugriff auf wichtige Backend-Systeme haben. Wenn Entwickler:innen nicht vorsichtig sind, wie sie den Zugriff auf diese Systeme implementieren, dann ist wirklich die Hölle los.

<SARKASMUS AN> Zum Glück gibt es unzählige entwicklerfreundliche Sicherheitstools und Mechanismen, die sicherstellen, dass Entwickler:innen nicht gleich die Welt in Schutt und Asche legen. Zum Glück haben Entwickler:innen unendlich viel Zeit und lieben es, sich durch Schwachstellenberichte aus mehreren Quellen zu wühlen. Nichts bereitet ihnen mehr Freude, als alle Warnungen zu analysieren und den Sicherheitsexpert:innen gegenüber zu erklären, dass es sich nur um Features handelt und alles so bleiben kann. Und natürlich verstehen die Product Owners (POs) und Product Managers (PMs), dass Entwickler:innen ihre Arbeit unterbrechen müssen, um zusätzliche Sprints für das Triaging von Schwachstellenberichten und die notwendige Behebung von Problemen in den Zeitplan aufzunehmen. Alle Stakeholder sind zutiefst beeindruckt, wie ernst wir das Thema Sicherheit nehmen, und akzeptieren sogar vermasselte Go-to-Market-Ziele bereitwillig. </SARKASMUS AUS>.

Die Wirklichkeit sieht anders aus. Jetzt, da die Anwendungssicherheit immer ernster genommen wird, geben immer mehr Tools Einblick in eine Situation, die nicht gerade erfreulich ist. Kein Entwickler will unsicheren Code schreiben. Kein Sicherheitsingenieur will die Entwickler schikanieren. Zumindest die meisten nicht.

Fakt ist: Viele Organisationen ertrinken in Tausenden von Schwachstellenreports und müssen trotzdem dafür sorgen, dass die eigenen Daten und Kundendaten vor Hackern sicher sind. Immer mehr Tools werden angeschafft und trotzdem wird die Situation nicht wirklich besser. Das erinnert mich an die Geschichte „Angst und Schrecken in Las Vegas“, in der Hunter S. Thompson und sein Freund in großen Mengen eine unglaubliche Vielfalt illegaler Produkte konsumieren, um ihren Horizont zu erweitern, und trotzdem nicht weiterkommen. In der IT scheint sich die Anwendungssicherheit dank des Einsatzes einer Vielzahl von Anwendungssicherheitsprodukten leicht zu verbessern, aber macht das Leben in DevSecOps, insbesondere für Entwickler:innen, noch Spaß? Ich bezweifle es.

Es sollte uns zu denken geben, wenn immer mehr IT-Mitarbeiter:innen einen Burnout erleben, die Reißleine ziehen und zu Tischlern oder Köchen umschulen. Wo ist der Spaß geblieben? Die Menge an Arbeit oder der Stress sind nicht unbedingt der Hauptfaktor für eine innere Kündigung (das sogenannte Quiet Quitting), die in „Dienst nach Vorschrift“ endet, oder gar für ein reales Verlassen der IT. Stress wird positiv erlebt, solange das, was man tut, Spaß macht. Sonst würden nicht so viele Entwickler:innen am Wochenende weiter coden [2].

Wenn wir erst einmal verstehen, warum traditionelle Werkzeuge uns im Stich lassen, können wir sicher eine Lösung finden. Dafür sind Entwickler:innen schließlich da.

Im Detail: Warum reichen SAST, DAST, SCA und WAF nicht mehr aus?

Wer schon einmal traditionelle Application Security Tools benutzt hat, kennt wahrscheinlich die Probleme, die sie verursachen. Die meisten haben eine Gemeinsamkeit: Die Sicherheit einer Anwendung wird nicht kontinuierlich analysiert, sondern zu einem bestimmten Zeitpunkt. Das Ergebnis ist ein Bericht über die gesamte Anwendung oder deren Codebasis, nicht nur über den Teil, an dem man gerade arbeitet. Der Bericht landet mit gewisser Verzögerung auf dem Schreibtisch des Entwicklers, meist zu einem Zeitpunkt, an dem schon längst an etwas anderem gearbeitet wird. Das führt zu Mehrarbeit und unerwünschten Unterbrechungen.

Diese Probleme ergeben sich aus der Art und Weise, wie traditionelle Tools funktionieren – sie analysieren die Software von außen:

• SAST (Static Application Security Testing): Die statische Analyse von Quellcode, selten auch die Analyse von Binärdateien, arbeitet mit einer Art virtuellem Modell der App, das „von außen“ durch die Analyse des Codes erzeugt wird. Die App wird nicht ausgeführt. Die Analyse erfolgt also ohne Kontext. Deshalb gibt es 30 bis 60 Prozent sogenannte False Positives: gemeldete Schwachstellen, die eigentlich gar keine sind. Die Folge ist ein ständig wiederholter Aufwand, um die irrelevanten Ergebnisse auszusortieren.

• DAST (Dynamic Application Security Testing): Dynamische Attacken von außen auf eine laufende Anwendung imitieren die Benutzung einer App, bombardieren sie aber nur mit bekannten Angriffen. Deshalb werden viele echte Schwachstellen von DAST-Tools nicht gefunden. Wenn die Angriffe erfolgreich sind, hat man ein sogenanntes True Positive, wenn sie aber nicht erfolgreich sind, dann war der Exploit vielleicht einfach nicht gut genug. Die Anwendung kann immer noch verwundbar für andere, bessere Exploits sein. Die Qualität der Ergebnisse hängt stark von der Qualität des Crawlers ab. Die Anpassung dieser Tools ist sehr aufwendig. Man investiert also viel Zeit in die Konfiguration und Pflege der DAST-Skripte, aber das Endergebnis ist bestenfalls ein falsches Gefühl von Sicherheit. Die False-Negative-Rate ist bei DAST typischerweise sehr hoch.

• Statische SCA (Software Composition Analysis): SCA ist oft der erste Schritt zu einer sicheren App. Bibliotheken sind meistens schuld, oder? Schließlich hört man in den Nachrichten Horrorgeschichten über Zero-Day-Schwachstellen und solche, die durch Dependencies verursacht werden. Ja, das ist ein wichtiger Aspekt, aber bei Weitem nicht der einzige. Ein großes Problem ergibt sich daraus, dass viele der deklarierten oder auch nur geladenen Bibliotheken nicht aktiv genutzt werden [3]. Wenn eine Bibliothek ausnutzbare Schwachstellen enthält, der Code aber nie von der App ausgeführt wird und somit für Hacker nicht zugänglich ist, dann kann sie auch nicht gehackt werden. Warum also in den oft unnötigen Panikmodus verfallen? Warum sollte man sich Regressionsprobleme in seine Projekte holen und Entwickler:innen mit unnötigen Updates beschäftigen? Es ist an der Zeit, sich auf die wirklich wichtigen Probleme zu konzentrieren.

• WAF (Web Application Firewalls): Aus dem produktiven Umfeld sind WAFs nicht mehr wegzudenken. Sie dienen als erste Verteidigungslinie, indem sie eingehenden Datenverkehr auf bekannte Angriffsmuster überprüfen. Sie sind relativ einfach zu implementieren und bieten Schutz vor gängigen Bedrohungen. Ihre Schwäche liegt jedoch darin, dass sie nur den Inhalt der Anfrage analysieren und keinen tieferen Einblick in die Anwendungslogik haben. Das macht sie anfällig für komplexere Angriffe und führt oft zu Fehlalarmen, die die legitime Nutzung blockieren. Zudem bieten WAFs keinen Schutz vor Zero-Day-Angriffen, da sie auf vordefinierte Signaturen angewiesen sind.

Warum sind traditionelle Sicherheitstools, insbesondere während der Softwareentwicklung, nicht mehr ausreichend? Die Art und Weise, wie Software entwickelt wird, hat sich verändert und die meisten Sicherheitstools haben nicht Schritt gehalten. Erfolgreiche, agile IT-Projekte beruhen auf drei Säulen: maximaler Flow, schnelles Feedback und eine iterative Projektkultur. Diese drei Punkte sind laut dem Buch „The Phoenix Project“ [4] die drei Wege zum Erfolg und die traditionellen Tools stehen dem im Weg:

• Flow: SAST, DAST und statische SCA unterbrechen den Flow, da sie alle auf ihre eigene Weise ungenau sind (SAST gibt zu viele False Positives, DAST verpasst viele relevante Ergebnisse und SCA gibt Feedback zu echten Schwachstellen, die aber auch False Positives sind, wenn sie die App zur Laufzeit nicht betreffen).

• Kurze Feedbackschleifen: Vor allem SAST und DAST sind relativ langsam und liefern die Ergebnisse nicht nur zu spät, sondern erfordern auch eine große Portion Zuwendung, um für Entwickler:innen überhaupt umsetzbar zu sein (bei SAST fehlen Informationen zu Endpoint und Payload, mit dem ein Problem reproduziert werden kann, bei DAST fehlt der Einblick in die Codeschritte, mit denen das Problem behoben werden muss).

• Iterative Verbesserungen als Kultur: Die Art und Weise, wie diese traditionellen Tools arbeiten, verhindert, dass Entwickler:innen sich kontinuierlich zum bestmöglichen Zeitpunkt verbessern. Wie kann man verhindern, dass sich Schwachstellen ausbreiten, wenn man erst zu spät erfährt, dass die letzte interne Best Practice doch nicht so gut oder der geniale Code des Kollegen doch nicht so brillant ist?

Die Lösung, Teil 1: Alle Macht den Entwickler:innen!

Es mag für Nichtentwickler:innen verrückt klingen, dass von Entwickler:innen hier Hilfe kommen soll. Schließlich haben sie doch jene Schwachstellen entwickelt, oder? Richtig! Und sie sind auch die Einzigen, die sie effizient beheben können – wenn man sie lässt. Ich persönlich kenne keine Person, die in der Entwicklung absichtlich schlechten Code schreibt und bewusst Schwachstellen in den Code einbaut. Wir sind alle Menschen, wir machen Fehler und die meisten von uns lernen daraus. Die meisten Menschen verbessern gerne ihre Fähigkeiten, wenn man sie lernen lässt.

Es reicht nicht aus, zu bestimmten Zeitpunkten Schulungen anzubieten, die meiner Erfahrung nach entweder zu früh oder zu spät kommen und nicht auf die individuellen Bedürfnisse des Entwicklers zugeschnitten sind. Alle Entwickler:innen haben ganz unterschiedliche Wissensstände. Eine gute Schulung muss genau dort ansetzen, wo die Wissenslücken sind, sonst ist sie langweilig bzw. Zeit- und Geldverschwendung.

Das Problem liegt aber nicht nur im Bereich der Schulung, sondern auch der Verantwortung. Wer Code entwickelt, muss für die Sicherheit seines Codes verantwortlich sein. Diese Verantwortung kann man aber nur übernehmen, wenn man auch die Mittel zur Verfügung gestellt bekommt, Schwachstellen im Code effizient zu beseitigen, sobald sie auftreten. Und was braucht man dafür?

• sofortiges Feedback beim Testen des Codes

• einen vollständigen Überblick über die Schwachstellen im eigenen Programm (vom Einstiegspunkt über jeden einzelnen Codeschritt, bis hin zum Backend-Aufruf, inklusive reproduzierbarer Requests und Stacktraces).

• einen Remediation Guide und eventuell sogar Links zu spezifischen Schulungseinheiten

• die Garantie, dass die Berichte genau und vollständig sind

Schnelle und präzise Tools sind der Schlüssel, damit Entwickler von Sicherheitswerkzeugen profitieren. Wenn ich als Entwickler sofort Feedback erhalte, das mir hilft, meine Fähigkeiten und meinen Code umgehend zu verbessern, wenn ich meine gewohnten Bugfixing-Skills einsetzen und sicher sein kann, dass mein Code sauber ins Repository gelangt, dann wird dieses Tool mein bester Freund. Vor allem, wenn ich zur richtigen Zeit etwas Neues lernen kann.

Die Lösung, Teil 2: Sensoren ermöglichen agile Sicherheit für agile Entwicklung

Egal, wie inflationär das Wort „agil“ benutzt wird, Agilität in Softwareprojekten hat es ermöglicht, dass Softwareprojekte Schritt für Schritt mit einer gewissen Flexibilität und permanentem Feedback mit dem Endkunden zusammen entwickelt werden können. Ziel des ständigen Feedbacks ist, dass das Produkt nach und nach so angepasst wird, dass es am Ende trotz eines veränderten Markts oder neuer Bedürfnisse passt. Agile Entwicklung hat den Projektfortschritt transparenter gemacht und Raum für das notwendige, ständige und rechtzeitige Feedback gegeben.

In anderen Branchen ist es gang und gäbe, Monitoring und Sensoren einzusetzen, um sofortiges und genaues Feedback von innen heraus zu erhalten. Ein Pilot bekommt ständig Feedback von Tausenden von Sensoren über die Leistung der verschiedenen Teile des Flugzeugs. Rennteams erhalten permanent Rückmeldungen von Hunderten von Sensoren, mit denen sie die Leistung ihres Autos optimieren können.

Auch die Fahrer normaler Autos erhalten relevante Warnmeldungen in Echtzeit, wenn die Motortemperatur zu hoch oder der Reifendruck zu niedrig ist. Piloten und Rennfahrer könnten nicht im richtigen Moment die richtigen Entscheidungen treffen, wenn sie sich ausschließlich auf externe Kontrollen verlassen würden, die nur zu einem bestimmten Zeitpunkt durchgeführt werden.

Der springende Punkt ist, dass wir unser Verhalten viel schneller und präziser anpassen können, wenn wir kontinuierlich in Echtzeit Informationen von innen erhalten.

Sicherheitsprodukte wie IAST (Interactive Application Security Testing) oder RASP (Runtime Application Self-Protection) platzieren über Instrumentierung Sensoren in Anwendungen. Diese Sensoren ermöglichen es, dass ein laufendes Programm kontinuierlich analysiert wird. IAST ermöglicht sofortiges Feedback, wenn Schwachstellen in den Code eingebracht wurden.

RASP geht noch einen Schritt weiter und kann in den Programmablauf eingreifen, um Exploits solcher Schwachstellen zu stoppen. Klingt das wie ein Zukunftstraum? Solche Runtime-Security-Tools gibt es schon seit zehn Jahren und ich bin überzeugt, dass sie die Zukunft sind.

Diese modernen Tools sind nicht unbedingt mit allen Entwicklungen kompatibel, aber wer Runtime-Security nutzen kann, wird nicht mehr durch veraltete Tools ausgebremst oder frustriert. Endlich kann die Softwareentwicklung mit den sensorbasierten Best Practices gleichziehen, die in anderen Branchen schon lange üblich sind.

Mit den richtigen Werkzeugen kann die Verantwortung für die Anwendungssicherheit an die Entwickler:innen übergeben werden, während die Kontrolle über deren effektive Umsetzung weiterhin bei den Sicherheitsteams bleibt. Wenn die Schwachstellenanalyse weitgehend automatisiert ist und das Triaging nahezu eliminiert werden kann, gewinnen auch die Sicherheitsteams wertvolle Zeit zurück. Dadurch können sie sich auf interessantere Aufgaben wie Threat Modelling oder gezieltes Sicherheitstraining für Entwickler:innen konzentrieren, die zusätzliche Unterstützung benötigen.

Im Detail: Wie funktioniert Runtime-Security?

Bevor wir loslegen: „Runtime“ heißt nicht „Produktion“. Wir sprechen von ausgeführten Programmen, egal ob sie in der Entwicklung, in der QA oder in der Produktionsumgebung laufen.

Bevor wir zum Hauptthema kommen, ein Wort in eigener Sache. Jeff Williams, Mitgründer und langjähriger Vorsitzender von OWASP, erkannte vor zehn Jahren, dass sich trotz der OWASP Top Ten, Schulungsprojekten wie WebGoat und vieler weiterer Initiativen hinsichtlich Sicherheit nicht viel verändert hatte. Trotz all der Energie, die er in seine Mission investiert hatte, „Software, die wichtige Aspekte unseres Lebens und unsere persönlichen Daten verwaltet, sicherer zu machen“, schien sich die Anwendungssicherheit im Kreis zu drehen.

Die OWASP Top Ten sehen heute noch sehr ähnlich aus wie die erste Version. Vor zehn Jahren gründete Jeff Williams schließlich Contrast Security, um unsere Softwarewelt tatsächlich sicherer zu machen. Wie? Mit einem revolutionären Ansatz, Anwendungen besser zu durchleuchten, indem man eine Art Kontrastmittel injiziert. So entstand Contrast Security.

Das Schlüsselwort lautet „Instrumentierung“ oder „Profiling“. Moderne Programmiersprachen bieten oft Observability APIs, die es ermöglichen, den Code beim Starten einer App zu erweitern. Die Technologie ist bekannt und wird seit langer Zeit von vielen Application-Performance-Monitoring-Tools genutzt. Seit zehn Jahren bietet Contrast Security nun Tools an, die sich den Sensoransatz der Instrumente im Flugzeug zu eigen machen (daher der Begriff Instrumentierung). Die Platzierung echter Sensoren in einer App geht weit über die Injektion eines medizinischen Kontrastmittels hinaus, das immer noch auf externe Scanner angewiesen ist, denn bei echtem passivem Interactive Application Security Testing sind keine externen Scans mehr erforderlich. Contrast Security ist natürlich nicht der einzige Anbieter solcher Tools, aber er ist der einzige, der von Anfang an als Priorität in Runtime-Security-Produkte investiert hat, die den gesamten Softwareentwicklungslebenszyklus (SDLC) von der Entwicklung bis zur Produktion abdecken.

Was kann Runtime Security für uns tun?

Wir können drei große Bereiche unterscheiden:

• Analyse von Custom Code (IAST)

• Analyse von Bibliotheken (Runtime SCA)

• Schutz in der Produktion (RASP)

Interactive Application Security Testing

IAST ist die sensorbasierte Methode, mit der Programme während ihrer aktiven Nutzung von innen beobachtet werden. Die Vorteile dieser Methode liegen auf der Hand:

1. Es wird das wirklich ausgeführte Programm getestet – nicht ein Modell wie bei SAST.

2. Tests mit normalen Werten reichen für die komplette Analyse eines Datenflusses aus – Angriffe wie bei DAST sind nicht notwendig. Eventuell vorhandene automatisierte, funktionale Tests genügen, um eine App auf Schwachstellen hin zu untersuchen. Es ist also sinnvoller, in funktionale Tests, die automatisch zu Sicherheitstests werden, zu investieren als in DAST-Tests.

3. Sofort während des Testens wird sehr genau Feedback geliefert – nicht erst am Ende eines langwierigen Scans in der Pipeline. Ebenso produzieren manuelle Entwicklertests umgehend Feedback mit einem niedrigen Anteil von Fehlmeldungen.

4. Es gibt viele Einblicke in die Schwachstellen, da der gesamte Programmablauf beobachtet wird. Alle Schritte vom Request bis zum Zugriff auf Backend-Systeme sind detailliert nachvollziehbar.

Runtime SCA

Wer programmiert, nutzt in der Regel Bibliotheken oder ähnliche Module. Der Vorteil liegt in der Wiederverwendung vorhandener Funktionalitäten und derer zentraler Weiterentwicklung. Der Nachteil ist, dass man sich mit solchen Bibliotheken manchmal auch Schwachstellen in die eigene Software holt. Wer eine große Anzahl von Bibliotheken verwaltet, weiß, dass es aufwendig sein kann, Bibliotheken aufgrund öffentlich bekannter Schwachstellen auszutauschen. Programmierschnittstellen ändern sich, Regressionstests müssen durchgeführt werden und oft sind Anpassungen des eigenen Codes notwendig, um Regressionsprobleme zu beheben. Auch wenn es längst Best Practice ist, mit Bibliotheksupdates Schritt zu halten und die notwendigen Tests zu automatisieren, kann es aufwendig sein, das für alle benutzten Bibliotheken einzurichten. Wenn man also unnötige Updates, vor allem von weniger wichtigen Bibliotheken, vermeiden kann, ist das eingesparte Zeit, die man anderweitig besser einsetzen kann.

Runtime SCA hat mehrere Vorteile. Nicht nur kann Runtime SCA auch Bibliotheken analysieren, die dynamisch hinzugefügt und nicht unbedingt statisch deklariert werden, Runtime SCA kann auch sehen, welche Klassen von welchen Bibliotheken tatsächlich benutzt werden. Der Vorteil liegt auf der Hand: Ich kann mich als Entwickler um die Schwachstellen kümmern, die meine Programme tatsächlich verwundbar machen und andere ohne schlechtes Gewissen ignorieren.

Es gibt noch weitere Vorteile: Wenn Runtime SCA über den gleichen IAST-Agenten läuft, wie es bei Contrast Security der Fall ist, kann man über ein zentrales Dashboard jederzeit sehen, welche Bibliotheken von welchen Anwendungen genutzt werden. Wenn es also ein Problem mit einer verwundbaren Bibliothek (wie zum Beispiel Log4j) gibt, kann man schnell erkennen, welche Anwendungen auf welchen Servern sie tatsächlich nutzen.

Runtime Application Self-Protection

Als ich Contrast Protect zum ersten Mal in Aktion sah, war ich tatsächlich sprachlos. Ich konnte sehen, wie eine Anwendung, die ich gerade gehackt hatte, das im Protect-Modus verhindern konnte. Ohne jegliche Programmänderungen. Fantastisch!

RASP ist die logische Weiterentwicklung von IAST. Wenn wir schon in der Lage sind, Schwachstellen genau zu erkennen, warum nicht auch das Programm sauber stoppen, wenn eine Schwachstelle ausgenutzt wird? Dass RASP hier einen weit besseren Job machen kann als eine Web Application Firewall, liegt auf der Hand. Warum? Weil RASP Teil der Anwendung ist und somit einen Einblick hat, was ein Eingabewert in der Anwendung tatsächlich auslösen wird. WAFs können nicht beobachten, was in der Anwendung passiert.

RASP schützt erfolgreich vor der Ausnutzung von bisher unbekannten Schwachstellen durch:

• Attribution Analysis, die, ähnlich wie eine WAF, bestimmte Quellen wie Bots schon vorab abfangen kann

• Input Classification, die relativ offensichtliche Exploit-Versuche erkennt

• Semantic Analysis, die verschiedene Injektionsprobleme erkennt

• Hardening, womit u. a. Headerfehlkonfigurationen korrigiert werden können oder Session Encryption aktiviert werden kann

• Sandboxing, das die effektive Ausführung von Injektionen oder ähnlichen Exploit-Versuchen nach der Deserialisierung eines Eingabeparameters verhindert

Tatsächlich kann RASP auch erfolgreich vor der Ausnutzung unbekannter Schwachstellen und vor Zero-Day-Attacken schützen, da nicht nur die Signatur eines Angriffs, sondern auch das Verhalten von Daten in der Anwendung selbst beobachtet und analysiert wird.

Beispiel: Contrast Security blockt mehr als 180 000 Angriffe pro Woche in mit RASP instrumentierten Anwendungen ab – alles Angriffe, die von einer vorgeschalteten WAF nicht abgefangen wurden.

Es gibt eine große Anzahl von Cyber-Security-Reports, die darauf hinweisen, dass Angriffe immer komplexer und ausgefeilter werden. Ich bin überzeugt, dass eine WAF heutzutage nicht mehr ausreicht, es sei denn, man hat eine hohe Anzahl von Sicherheitsexperten, die sie permanent präzise einstellen. Aber selbst wenn man WAFs feintunen kann, wird man gegen Zero-Day-Angriffe in dem Moment, in dem sie passieren, nicht gewappnet sein. RASP ist effizienter, da ein solches Tuning nicht notwendig ist, weil es die Anwendung genau versteht. Instrumentierung bettet Anwendungssicherheit in die Anwendung ein, ist Teil der Anwendung und schützt permanent.

Aber sollte uns nicht die KI retten?

Noch liefert die KI hier keine Lösung. Ein Marktführer im SAST-Bereich hat in seinem jährlichen State-of-Software-Security-Report [5] bestätigt, dass

• fast 46 Prozent der Unternehmen kritische Security Debt im Backlog haben,

• mehr als 94 Prozent aller Apps fehlerhaft und/oder sicherheitstechnisch problematisch sind und

• 70 Prozent der Apps Sicherheitsprobleme aufgrund von Drittanbietercode (Bibliotheken) haben.

Und was ist mit KI? Laut dem Report produziert KI derzeit unsicheren Code „at scale“. KI scheint keinen besseren Code zu schreiben, sondern produziert mehr unzureichend sicheren Code. Wir sollten uns also erst einmal selbst retten und der KI eine bessere Trainingsgrundlage liefern, indem wir sichere Anwendungen schreiben.

Fazit

Softwareentwicklung kann immer noch Spaß machen. Sicherheit muss weder ignoriert noch als Einschränkung oder Zwang empfunden werden. Software wird sicherer, wenn Entwicklungs- und Sicherheitsteams als ein Team zusammenarbeiten. Sicherheit sollte ein integraler Bestandteil der Anwendungsentwicklung sein, ähnlich wie eingebaute Sicherheitsfeatures in Autos, wie selbststraffende Sicherheitsgurte oder Airbags, die durch Sensoren ausgelöst werden und kaum noch hinterfragt werden. Sicherheit sollte im Hintergrund mitlaufen und erst dann eingreifen, wenn es wirklich nötig ist.

BMW demonstriert, dass sich Freude am Fahren mit Sicherheit vereinbaren lässt: Mit Contrast ließ sich die MTTR (Mean Time to Resolution: die durchschnittliche Zeit zwischen dem Finden und Beheben von Schwachstellen) von fünf Monaten auf einen Tag reduzieren. Eine absolut bemerkenswerte Leistung [6].