Wenn von Anwendungsfirewalls die Rede ist, werden oft viele verschiedene Dinge unter einem Begriff zusammengefasst. Aber nicht alle Firewalls sind gleich, und es ist wichtig, die Unterschiede zwischen ihnen zu verstehen, insbesondere wenn Sie herausfinden möchten, welchen Schutz Ihre Anwendung tatsächlich benötigt.
Lassen Sie uns das einmal genauer betrachten. Es gibt drei wichtige Ebenen der Anwendungssicherheit, die Sie kennen sollten: WAFs, In-App und In-Kernel. RASP und einige ADR sind In-App, während niedrigere Ebenen eBPF-basierter ADR In-Kernel sind. Sie alle haben das gleiche übergeordnete Ziel, nämlich zu verhindern, dass Ihrer App Schaden zugefügt wird, aber die Art und Weise, wie sie dies tun, ist sehr unterschiedlich. Kurz gesagt: WAF sieht die Anfrage, In-App sieht den Code und In-Kernel sieht das Betriebssystem.
Welches benötigen Sie? Wenn Sie die bestmögliche Sicherheitslage wünschen, wahrscheinlich mehr als eines. In diesem Artikel erklären wir Ihnen, was WAFs, RASP, ADR und eBPF sind, wofür sie jeweils am effektivsten sind, und helfen Ihnen bei der Entscheidung, welches Sie benötigen.
WAF VS RASP VS ASP: Wie funktionieren die drei Ebenen der Anwendungssicherheit?
Anwendungssicherheitstools arbeiten auf drei verschiedenen Ebenen, wobei jede Ebene Dinge erfasst, die die anderen nicht erfassen können.
WAF: Edge-Sicherheit
WAFs befinden sich vollständig außerhalb Ihrer Anwendung und überprüfen den eingehenden HTTP-Datenverkehr, bevor er Ihre Anwendung erreicht. Kein App-Kontext, aber ideal für Bedrohungen mit hohem Volumen.
In-App-Laufzeitsicherheit: innerhalb der App
In-App-Sicherheitsinstrumente werden direkt in Ihre Anwendung eingebunden. Sie greifen in die Ausführung Ihres Codes ein, verfolgen, wie Benutzereingaben durch Ihre App fließen, und können Angriffe genau an dem Punkt blockieren, an dem sie gefährlich werden, bevor eine bösartige Nutzlast Ihren Datenbanktreiber trifft oder eine Shell erzeugt. Da sie über einen vollständigen Anwendungskontext verfügen, sind sie präzise. RASP-Tools, eine Unterkategorie von ADR, fallen in diese Kategorie.
In-Kernel-Laufzeitsicherheit: unterhalb der App
In-Kernel-Laufzeitsicherheitstools befinden sich vollständig unterhalb Ihrer Anwendung, auf Betriebssystemebene. Anstatt sich in den Anwendungscode einzuklinken, überwachen sie jeden Systemaufruf, der von jedem Prozess auf dem Host ausgeführt wird. Sie haben keine Ahnung, was Ihre Anwendungslogik tut, aber sie sehen alles auf Betriebssystemebene, einschließlich dessen, was passiert, nachdem ein Angreifer bereits eingedrungen ist. eBPF-basierte ADR-Tools fallen in diese Kategorie.
Wir werden uns zunächst WAF ansehen, dann In-App und In-Kernel aus der Perspektive von RASP und ADR.
Was ist WAF?
Eine WAF (Web Anwendungs-Firewall) befindet sich außerhalb Ihrer Anwendung, am Rand. Bevor eine Anfrage Ihre Anwendung überhaupt erreicht, fängt die WAF sie ab und überprüft sie anhand einer Liste bekannter Angriffsmuster wie SQL-Injection-Strings, bösartige Header oder verdächtige URLs. Wenn etwas mit einem Muster übereinstimmt, wird es blockiert.
WAFs sind vor allem bei volumetrischen Angriffen wie DDoS-Traffic, Bot-Floods und Scrapers unersetzlich. WAFs sind für hochvolumige Brute-Force-Angriffe ausgelegt. Cloudflare beispielsweise ist extrem gut darin, groß angelegte Angriffe abzufangen, bevor sie überhaupt mit Ihrer Infrastruktur in Kontakt kommen. Außerdem sind sie einfach zu implementieren. Meistens handelt es sich um eine DNS- oder Proxy-Änderung, es muss kein Code geschrieben und nichts in Ihrer App installiert werden. WAFs sind außerdem sehr gut mit benutzerdefinierten Regeln, Zulassungslisten und Regelanpassungen konfigurierbar, und Sie können auch entscheiden, ob Sie etwas Verdächtiges blockieren oder nur erkennen möchten.
Der Haken dabei ist, dass eine WAF keine Ahnung hat, was passiert, sobald eine Anfrage durchkommt. Sie kann verdächtig aussehende Nutzdaten erkennen, aber sie kann Ihnen nicht sagen, ob diese Nutzdaten tatsächlich etwas Gefährliches bewirken werden, da sie keine Ahnung hat, was Ihre App tatsächlich mit einer Anfrage macht. Sie sieht den eingehenden Datenverkehr, gleicht ihn mit den konfigurierten Sperrkriterien ab und entscheidet, ob er blockiert werden soll.
Infolgedessen sind Fehlalarme ein echtes Problem, und es kann leicht zu einer Überblockierung von Anfragen kommen. Ein Benutzer kann nach etwas suchen, das zufällig wie SQL aussieht, und wird blockiert, während ein cleverer Angreifer seine Nutzlast anders verschlüsselt und durchkommt. Und wenn eine WAF einen böswilligen Benutzer stoppen will, blockiert sie dessen IP-Adresse. Dann kann ein Angreifer einfach ein VPN verwenden, um dies zu umgehen. Wenn Sie dann jedoch versuchen, den gesamten Datenverkehr aus dem VPN zu blockieren, blockieren Sie auch echte Benutzer.
Daher ist die WAF-Optimierung ein fortlaufender Prozess, bei dem Sie Regeln verschärfen, auf Fehlalarme achten und bei Bedarf lockern. Dies ist einer der Gründe, warum WAFs im Vergleich zu RASP sehr wartungsintensiv sein können. RASP erfordert weitaus weniger fortlaufende Optimierungen, da es über den App-Kontext verfügt, um ohne manuelles Eingreifen bessere Entscheidungen zu treffen.
Beispiele: Cloudflare, AWS WAF, Imperva
Open Source: ModSecurity (über OWASP)
Was ist RASP?
RASP (Runtime Application Self-Protection) und In-App-ADR sind Laufzeitsicherheitsfunktionen, die in Ihrer App integriert sind und diese während der Ausführung von innen heraus überwachen, anstatt wie ein WAP außerhalb Ihrer App den eingehenden Datenverkehr zu überprüfen.
Um zu verstehen, warum dies wichtig ist, müssen Sie etwas über Sinks wissen. Ein Sink ist eine Funktion – in Ihrem Code, einer Bibliothek oder einem integrierten Modul, in der Benutzereingaben nicht mehr als Daten behandelt, sondern als etwas Sinnvolles ausgeführt werden. Betrachten wir als Beispiel eine SQL-Injection. Ein Angreifer fügt bösartigen Code in ein Formularfeld ein, der durch Ihre Anwendung fließt und auf Ihren Datenbanktreiber trifft (einige db.query()), und an diesem Punkt hört es auf, Text zu sein, und wird zu einem Befehl. Diese Abfragefunktion ist die Senke. Was In-App-Sicherheitstools wie RASP tun, ist, sich in diese Senken einzuklinken und zu beobachten, wie die Eingabe durch die App fließt, und sie bis zur gefährlichen Funktion zu verfolgen.
Da diese In-App-Tools innerhalb Ihrer App ausgeführt werden, wissen sie, was eingegeben wird, woher die Eingabe stammt und wohin sie geht. Anstatt zu raten, ob ' ODER 1=1-- ist ein Angriff oder eine legitime Suchzeichenfolge, ein In-App-Tool weiß, dass diese bestimmte Zeichenfolge von req.body.userwurde ungesäubert verkettet und steht kurz davor, einen pg.query() Anruf. Blockieren Sie ihn!
Die Falsch-Positiv-Rate ist viel niedriger als bei WAF- und eBPF-basierten ADR-Lösungen, da es sich nicht nur um einen blinden Musterabgleich handelt. Es kann eine Benutzer-ID statt nur eine IP-Adresse blockieren, sodass ein Angreifer nicht einfach ein VPN verwenden kann. Und da es den Datenfluss verfolgt, anstatt bekannte Signaturen abzugleichen, kann es neue Angriffs-Payloads erkennen, die noch niemand zuvor gesehen hat. Solide Zero-Day-Abdeckung für Angriffe der Injektionsklasse!
RASP und In-App-ADRs decken auch Abhängigkeiten von Drittanbietern ab. Sie können Ihren eigenen Code perfekt bereinigen, aber wenn eine von Ihnen verwendete Bibliothek eine Schwachstelle aufweist, liegt dies außerhalb Ihrer Kontrolle (sofern Ihr SCA diese SCA ebenfalls entdeckt hat). RASP arbeitet auf Sink-Ebene, unabhängig davon, woher der Code stammt.
Die einzige wesentliche Einschränkung der In-App-Sicherheit besteht darin, dass die Hooks niemals ausgelöst werden, wenn ein Angreifer die Laufzeitumgebung vollständig umgeht, beispielsweise durch ein natives Add-on oder einen direkten Systemaufruf. Und sobald eine Shell gestartet wurde, erkennt RASP zwar den ursprünglichen Aufruf, aber nicht, was anschließend innerhalb dieser Shell geschieht. Hier kommt die dritte Ebene ins Spiel.
Beispiele: Aikido ( Open Source und kostenpflichtige Version)
Was ist ADR?
ADR (Application Detection and Response) ist die umfassendere moderne Kategorie, zu der RASP gehört. Alle RASP-Lösungen sind ADR-Lösungen, aber nicht alle ADR-Lösungen sind RASP-Lösungen. Der Begriff ADR umfasst alle Tools, die Angriffe zur Laufzeit überwachen und darauf reagieren, unabhängig davon, ob diese aus Ihrer Anwendung heraus oder vollständig darunter erfolgen.
In der Praxis werden ADR-Tools in zwei Arten unterteilt. In-App-ADR (wie es RASP schon immer war) befindet sich direkt in Ihrer Anwendung und verfügt über einen vollständigen Kontext auf Codeebene. Alles, was im obigen Abschnitt über RASP zur In-App-Sicherheit behandelt wurde, gilt auch hier. ADR hat auch einen breiteren Anwendungsbereich als RASP: Während RASP in erster Linie ein Blockierungstool ist, umfasst ADR auch Funktionen zur Erkennung, Sichtbarkeit und Reaktion auf Vorfälle. Nicht jedes ADR-Tool kann all dies, aber es ist die Richtung, in die sich diese Kategorie entwickelt.
Die andere Art von ADR, In-Kernel-ADR oder eBPF-basiertes ADR, verfolgt einen anderen Ansatz zum Schutz von Anwendungen. Anstatt sich in Ihre Anwendung einzuklinken, befindet es sich auf Linux-Kernel-Ebene und überwacht jeden Systemaufruf, der von jedem Prozess auf dem Host ausgeführt wird. Es weiß nichts über die Logik Ihrer Anwendung, sieht aber alles auf Betriebssystemebene.
Sobald ein Angreifer eine Shell gestartet hat, bietet In-Kernel-ADR die nächste Stufe der Sichtbarkeit nach der Ausnutzung, die In-App-ADR nicht sehen kann. In-Kernel-ADR sieht jeden Befehl, der innerhalb dieser Shell ausgeführt wird, wie z. B. Dateilesevorgänge, Netzwerkaufrufe und laterale Bewegungen. Wenn ein Angreifer die Laufzeit vollständig umgeht, sieht ADR dennoch die execve unabhängig davon, wie es ausgelöst wurde. In der Praxis ist das häufigste Szenario für Node.js-Anwendungen ein bösartiges natives Add-on, das durch einen Supply-Chain-Angriff eingeschleust wird (eine kompromittierte Abhängigkeit, die nativen Code enthält, den Ihre Laufzeitumgebung nicht überprüft).
eBPF (Extended Berkeley Packet Filter) ist die zugrunde liegende Kernel-Technologie, die ADR-Tools im Kernel unterstützt. Mit eBPF können Sie ein sicheres Überwachungsprogramm an den Linux-Kernel anhängen, das bestimmte Ereignisse auf Betriebssystemebene beobachten kann, ohne den Kernel selbst zu berühren. Wenn Sie eine benutzerdefinierte Überwachung oder Logik auf Kernel-Ebene hinzufügen möchten, müssen Sie normalerweise entweder den Quellcode des Kernels direkt ändern (riskant, komplex) oder ein Kernel-Modul schreiben (ebenfalls riskant, da ein Fehler das gesamte System zum Absturz bringen kann). eBPF umgeht dies, indem es Ihnen ermöglicht, kleine Programme in den Kernel einzuschleusen, die in einer Sandbox-Umgebung ausgeführt werden. Diese Programme beobachten bestimmte Systemaufrufe und melden sich beim ADR-Tool zurück, das dann entscheidet, ob die Aktion zugelassen oder blockiert wird.
Der Nachteil von In-Kernel-ADR, wie WAF, ist, dass es keinen App-Kontext hat. Es sieht rohe Systemaufrufe wie „Prozess 4821 hat ein Programm ausgeführt“, hat aber keine Ahnung, welche HTTP-Anfrage oder welcher Benutzer dies ausgelöst hat. Ohne diesen Kontext muss die Kernel-Sicherheit stattdessen mit Richtlinien arbeiten, also Regeln wie „Dieser Prozess darf niemals eine Shell erzeugen“ oder „Dieser container niemals in dieses Verzeichnis schreiben“. Das funktioniert zwar, um eindeutige Verstöße zu erkennen, macht das Ganze aber ziemlich binär, sodass es keine Nuancen gibt.
Bei Injektionsangriffen wie SQL-Injection ist ADR im Kernel so gut wie blind. Wenn der Angriff die Syscall-Ebene erreicht, ist die SQL-Nutzlast nur noch eine Reihe von Rohbytes in einem Netzwerkpuffer. Exploits zur Laufzeit sind ein weiterer blinder Fleck. Einige Angriffe werden vollständig innerhalb der Sprachlaufzeit ausgeführt, sodass sie keine ungewöhnlichen Vorgänge auf Betriebssystemebene auslösen, bis es zu spät ist.
Im Gegensatz zu herkömmlichen RASP-Tools erfordert diese Art von ADR keine Änderungen am App-Code, um sie einzurichten. Allerdings sind die Einrichtungsanforderungen höher als bei WAF oder RASP, da ADR-Tools in der Regel einen relativ modernen Linux-Kernel und erweiterte Systemrechte benötigen.
Beispiele: Tetragon, Falco, KubeArmor (Open Source)
Oligo ADR (kommerziell)
WAF, RASP, ADR, eBPF: Was brauche ich?
Bis jetzt haben wir viele Begriffe durchgenommen – WAF, RASP, ADR, eBPF, In-App, In-Kernel. Die kurze Antwort lautet, dass Sie Schutz auf mehr als einer Ebene wünschen. Die längere Antwort hängt davon ab, um welche Ebenen es sich handelt. Was RASP und ADR angeht, so ist RASP eine Unterkategorie von ADR. Die Frage lautet also: Möchten Sie In-App-Sicherheit, In-Kernel-Sicherheit oder beides?
Die verschiedenen Schichten ergänzen sich gegenseitig und stehen nicht in Konkurrenz zueinander, da jede Schicht Dinge erfasst, die die anderen nicht erfassen können. Deshalb lautet die Antwort auf die Frage „WAF oder RASP?“ in der Regel „beides“, und durch Hinzufügen von In-Kernel-ADR erhalten Sie die Post-Exploitation- und Kernel-Level-Abdeckung, die das Bild abrundet.
Die drei Ebenen stellen grundlegend unterschiedliche Fragen:
- WAF: „Entspricht diese HTTP-Anfrage einem bekannten Angriffsmuster?“
- In-App-Sicherheit (RASP und ADR): „Wird diese Benutzereingabe eine gefährliche Funktion in meiner App auslösen?“
- In-Kernel-Sicherheit (ADR): „Hat dieser Prozess gerade etwas getan, was er auf Betriebssystemebene nicht hätte tun sollen?“
TL;DR: Besorgen Sie sich zuerst eine WAF und ein In-App-Sicherheitstool. Wenn Sie eine spezifische Verarbeitung auf Kernel-Ebene benötigen, können Sie später ein eBPF-basiertes ADR hinzufügen.
In-App-Sicherheit wie RASP ist die einzige Ebene, die über Kontextinformationen darüber verfügt, wie die Daten mit der jeweiligen App interagieren, und daher die einzige Ebene, die wirklich präzise Blockierungen vornehmen kann. Daher weist sie im Vergleich zu den beiden anderen Ebenen natürlich die wenigsten Fehlalarme auf. Während Laufzeitschutz die meisten Angriffe auf Anwendungsebene oder Injektionsangriffe abwehren Laufzeitschutz , wird WAF für Angriffe mit hohem Volumen wie DDoS benötigt. Da WAFs außerhalb der Anwendung angesiedelt sind, können sie Tausende von Bot-Anfragen abwickeln, bevor sie Ihre Anwendung erreichen und auf diese Ressourcen zugreifen, und dafür sind keine umfangreichen Kontextinformationen erforderlich. Zusammen decken In-App-Sicherheitsmaßnahmen wie Aikido in Kombination mit WAF die überwiegende Mehrheit der Probleme ab, mit denen Sie konfrontiert werden.
Wenn Sie an einem Punkt angelangt sind, an dem Sie vollständige Transparenz nach der Ausnutzung benötigen, sich Gedanken über laterale Bewegungen machen oder die Durchsetzung von Richtlinien auf Kernel-Ebene über mehrere Prozesse hinweg benötigen, sollten Sie über die Einführung von In-Kernel-ADR nachdenken. Es ist das richtige Tool für eine ausgereiftere Sicherheitskonfiguration, wenn auch nicht unbedingt das erste Mittel der Wahl. Einige In-App-ADR-Tools decken mehr ab als andere. Aikido überwacht beispielsweise die ausgehenden Aktivitäten (SQL-Abfragen, Shell-Befehle, Dateilesevorgänge und ausgehende HTTP-Aufrufe) Ihrer App. Und im Vergleich zu einer komplizierteren In-Kernel-ADR-Konfiguration können Teams Zen mit einem einzigen npm install und eine Zeile Code.
Das Einzige, was In-Kernel-ADR über Zen hinaus abdeckt, ist das, was passiert, nachdem eine Shell bereits gestartet wurde und der Angreifer auf Betriebssystemebene operiert. Zen ersetzt also eBPF nicht, wenn Sie vollständige Transparenz nach der Exploitation und die Durchsetzung von Richtlinien auf Kernel-Ebene für alle Prozesse benötigen. Für die meisten Teams deckt es jedoch die wichtigsten Angriffsflächen ab (Injection-Angriffe, Zero-Days und Autorisierungslogik). Wenn Sie jedoch über ein anderes RASP verfügen, das die ausgehenden Aktivitäten und SQL-Injections nicht abdeckt, benötigen Sie möglicherweise eher eBPF.
Zen aus Aikido: Die moderne In-App-ADR
Obwohl sie ähnliche Ziele verfolgen, sind nicht alle In-App-Sicherheitstools gleich. Neue ADRs wie Zen, In-App-Firewall Aikido, gehören zum Bereich der In-App-Sicherheit, decken jedoch Bereiche ab, die ein Standard-RASP-Tool nicht abdeckt.
Zen bietet den vollständigen App-Kontext traditioneller RASPs, wie Taint Tracing, Sink-Level-Blocking, User-ID-Erkennung und geringe Fehlalarme. Als modernes ADR überwacht Zen jedoch auch ausgehende Aktivitäten, wie es auch In-Kernel-ADR tut. Dazu gehören alle SQL-Abfragen, Shell-Befehle, Dateilesevorgänge und ausgehenden HTTP-Aufrufe Ihrer App. Der Schwachstellenalgorithmus ist von der ersten Anfrage an deterministisch, sodass es keine Kaltstartprobleme und keine fortlaufende Regelpflege gibt, wie sie bei anderen RASPs auftreten.
Zen geht auch über Injection-Class-Angriffe hinaus. Es analysiert jede SQL-Abfrage zur Laufzeit mit einem vollständigen SQL-Parser (in Rust erstellt) und erzwingt automatisch die Mandanten-Scoping. Wenn in einer Abfrage ein Mandantenfilter fehlt oder die falsche Mandanten-ID verwendet wird, gibt Zen vor der Auslieferung eine Fehlermeldung aus. IDORs (unsichere direkte Objektreferenzen) sind die häufigste Ursache für mandantenübergreifende Datenlecks in Multi-Mandanten-SaaS-Anwendungen und in Code-Reviews bekanntermaßen schwer zu erkennen. Zen macht es unmöglich, sie versehentlich zu implementieren.
Weiterführende Literatur: Zero-Day-Angriffsprävention für Node.js mit Aikido
Häufig gestellte Fragen
Was ist eine WAF?
Eine WAF (Web Anwendungs-Firewall) befindet sich außerhalb Ihrer Anwendung und überprüft den eingehenden HTTP-Datenverkehr auf bekannte Angriffsmuster. Sie eignet sich besonders gut für die Abwehr volumetrischer Bedrohungen wie DDoS-Angriffe und Bot-Traffic, hat jedoch keinen Einblick in die tatsächliche Verarbeitung einer Anfrage durch Ihre Anwendung.
Was ist RASP-Sicherheit?
RASP (Runtime Application Self-Protection) ist ein Sicherheitstool, das innerhalb Ihrer Anwendung ausgeführt wird. Es überwacht, wie Benutzereingaben durch Ihren Code fließen, und blockiert Angriffe an der Stelle, an der sie gefährlich werden: dem Sink. Da es über den vollständigen App-Kontext verfügt, ist es bei Angriffen der Injektionsklasse viel genauer als eine WAF.
Was ist der Unterschied zwischen WAF und RASP?
Eine WAF befindet sich außerhalb Ihrer Anwendung und blockiert den Datenverkehr anhand von Mustern. Eine RASP befindet sich innerhalb Ihrer Anwendung und blockiert Angriffe anhand dessen, was Ihr Code tatsächlich mit den Benutzereingaben tun wird. WAFs sind einfacher zu implementieren und eignen sich hervorragend für volumetrische Bedrohungen. RASPs haben geringere Falsch-Positiv-Raten und bieten einen besseren Schutz vor Injektionsangriffen und Zero-Day-Angriffen.
Benötige ich sowohl eine WAF als auch eine RASP?
Ja, sie ergänzen sich, sie konkurrieren nicht miteinander. Eine WAF kümmert sich um den Schutz auf Edge-Ebene und den volumetrischen Datenverkehr. Eine RASP kümmert sich um Injection-Angriffe und Zero-Day-Angriffe, die von WAFs regelmäßig übersehen werden. Die meisten ausgereiften Sicherheitskonfigurationen verwenden beide.
Was ist ADR im Vergleich zu RASP?
Im Allgemeinen umfasst ADR Tools, die entweder In-App- oder In-Kernel-Sicherheit bieten. RASP bezieht sich auf In-App-Tools und ist eine Untergruppe von ADR. RASP und In-App-ADR sind technisch gesehen derselbe Ansatz, nur mit unterschiedlichen Bezeichnungen im Laufe der Zeit. Die Bezeichnung ADR ist neuer und weiter gefasst. Manchmal wird ADR als Abkürzung für oder synonym mit eBPF, kernelbasierten ADR-Tools, verwendet. Die Begriffe für RASP und ADR variieren leicht, je nachdem, wen Sie fragen. Beachten Sie dies, wenn Sie sich weiter mit diesem Thema befassen.
Was ist ADR/eBPF in der Anwendungssicherheit?
ADR (Application Detection and Response) deckt sowohl die Sicherheit innerhalb von Anwendungen als auch innerhalb des Kernels ab. In-Kernel-ARD-Tools wie Tetragon oder Falco arbeiten auf Linux-Kernel-Ebene und überwachen jeden Systemaufruf in jedem Prozess auf dem Host. Sie bieten eine gute Sichtbarkeit nach der Exploitation und erkennen Umgehungen auf Kernel-Ebene, verfügen jedoch über keinen App-Kontext, sodass sie eher eine Ergänzung zu RASP darstellen als einen Ersatz dafür. eBPF (Extended Berkeley Packet Filter) ist die zugrunde liegende Kernel-Technologie, die In-Kernel-ADR-Tools unterstützt.
Wenn Sie alle Eingaben korrekt bereinigen, brauche ich dann trotzdem noch RASP?
Ja. Es ist schwierig, die Bereinigung immer perfekt durchzuführen. Insbesondere wenn während der Entwicklung SAST Codequalitäts-Tools fehlen, können Sicherheitslücken in den Code gelangen. Betrachten Sie es weniger als Ersatz für gute sichere Codierungspraktiken, sondern eher als Laufzeit-Sicherheitsnetz für den Fall, dass diese Praktiken nicht perfekt sind (was in der Praxis natürlich nie der Fall ist). RASP verhindert auch Probleme, die durch Abhängigkeiten von Drittanbietern entstehen.
