Jeff Williams, Gründer von OWASP und Gründer & CTO von Contrast Security – Interview-Serie

Jeff Williams, Gründer von OWASP und Gründer & CTO von Contrast Security, gilt als einer der einflussreichsten Figuren in der modernen Anwendungssicherheit. In den letzten Jahrzehnten hat er maßgeblich dazu beigetragen, wie Organisationen sich der sicheren Softwareentwicklung, der Verwaltung von Schwachstellen und des Schutzes von Anwendungen während der Laufzeit nähern. Williams spielte eine zentrale Rolle beim Aufbau von OWASP von einer kleinen ehrenamtlichen Initiative zu einer global anerkannten Non-Profit-Sicherheitsstiftung und hat an wegweisenden Projekten wie der OWASP Top Ten, WebGoat, ESAPI, ASVS und der XSS-Präventions-Cheat-Sheet mitgewirkt. Bevor er 2014 Contrast Security gründete, gründete er auch Aspect Security, eines der ersten Unternehmen, das sich ausschließlich auf Anwendungssicherheitsberatung, -schulung, -penetrationstests und sichere Entwicklungsmethoden für Unternehmen spezialisierte.

OWASP ist eine Non-Profit-Stiftung, die sich auf die Verbesserung der Software-Sicherheit durch Open-Source-Projekte, globale Gemeinschaftszusammenarbeit, Bildung und Industriestandards konzentriert. Gegründet im Jahr 2001, ist die Organisation zu einer der wichtigsten Autoritäten in der Anwendungssicherheit geworden, mit Hunderten von lokalen Kapiteln, Tausenden von Mitwirkenden und weit verbreiteten Ressourcen, die von Entwicklern, Sicherheitsfachleuten, Unternehmen und Regierungen weltweit genutzt werden. OWASP ist vor allem für Projekte wie die OWASP Top Ten bekannt, die die kritischsten Web-Anwendungssicherheitsrisiken identifiziert, sowie zahlreiche Sicherheitsframeworks, Testtools, Dokumentationsprojekte und Schulungsinitiativen. Die Organisation arbeitet mit einer vendorneutralen Philosophie und macht ihre Bildungsressourcen und Sicherheitsleitfäden kostenlos für die globale Technologiegemeinschaft zugänglich.

Contrast Security ist ein Unternehmen für Anwendungssicherheit, das sich auf den Schutz von Software von innerhalb der laufenden Anwendung selbst konzentriert, anstatt sich ausschließlich auf externe Scanning-Tools zu verlassen. Die Plattform des Unternehmens verwendet Laufzeitinstrumentierungstechnologie, um Echtzeit-Einblicke in Schwachstellen, Angriffe, APIs, Open-Source-Abhängigkeiten und Anwendungsverhalten in Entwicklungsumgebungen und Produktionsumgebungen zu gewährleisten. Die Angebote des Unternehmens umfassen Bereiche wie interaktive Anwendungssicherheitstests (IAST), Anwendungs-Erkennung und -Reaktion (ADR), Laufzeit-Anwendungsschutz (RASP) und Softwarezusammensetzungsanalyse. Contrast Security hat sich um die Integration von Sicherheit direkt in moderne DevSecOps-Workflows positioniert, um es Entwicklern, AppSec-Teams und Sicherheitsoperationsteams zu ermöglichen, Schwachstellen schneller zu identifizieren und zu beheben, während sie gleichzeitig schnelle Softwarelieferzyklen aufrechterhalten.

Nachdem Sie durch Ihre Arbeit mit dem Open Web Application Security Project (OWASP) die moderne Anwendungssicherheit mitgestaltet haben, was war die Lücke in der Branche, die Sie dazu veranlasste, Contrast Security zu gründen, und wie hat sich diese ursprüngliche These im Laufe der Zeit entwickelt, als die Sicherheitsprobleme sich weiterentwickelten?

Die Branche ertrank in theoretischen statischen Ergebnissen und konnte sich nicht auf die Probleme konzentrieren, die wirklich zählten. Sicherheitsteams hatten Scanner, die massive Rückstände generierten, ohne zu wissen, welche Schwachstellen erreichbar, ausnutzbar oder in der Produktion angegriffen wurden. Wir gründeten Contrast auf einer einfachen Idee: Sicherheitsentscheidungen sollten aus der direkten Beobachtung laufender Anwendungen stammen, nicht aus Vermutungen von außen.

Letztendlich hoffe ich, dass die Branche so weit fortschreitet, dass wir uns von dem Hamsterrad, Probleme zu finden, zu beheben und immer wieder neue zu finden, befreien. Ich hoffe, wir können beginnen, Software zu erstellen, die eine starke Sicherheitsarchitektur und ein echtes Argument dafür hat, dass sie die richtigen Verteidigungen für die erwarteten Bedrohungen hat. Die Kombination aus Laufzeit-Sicherheit und KI hat das Potenzial, aber wir sind noch Jahre entfernt.

Sie haben die Entstehung von “Mythos-level-Schwachstellen” beschrieben. Was definiert diese neue Klasse von Risiken, und warum sind sie so schwierig für herkömmliche Sicherheitstools zu erkennen?

Mythos-level-Schwachstellen sind Fehler, die aus der Komplexität moderner Software-Stacks entstehen. Die Interaktion zwischen Framework-Verhalten, Abhängigkeiten und Architekturmuster ist so komplex, dass Entwickler oft nicht vollständig verstehen, was passiert. Herkömmliche Tools sind noch immer auf relativ einfache bekannte Muster und beobachtbare Ereignisse optimiert. Mythos-Style-Schwachstellen erfordern oft ein tieferes Verständnis von Anwendungsverhalten, Ausführungsfluss und Laufzeitkontext.

Warum scheitern ganze Kategorien von Schwachstellen daran, Alarme in modernen Security-Operations-Center-(SOC)-Umgebungen auszulösen, und was sagt das über die Art und Weise, wie Sicherheitsteams derzeit Risiken messen?

Die meisten SOCs sind um beobachtbare Ereignisse herum aufgebaut: Logs, Signaturen, Netzwerkverkehr, Endpunktaktivität. Aber viele Angriffe auf die Anwendungsebene produzieren keine nützlichen Signale in diesen Systemen. Der Entwickler wusste nicht, dass es eine Schwachstelle gab, und hat keine Protokollierung hinzugefügt, die einen Ausnutzungsversuch offenlegen würde. Die meisten Angriffe auf die Anwendungsebene sind also völlig unsichtbar in den Protokollen. SOC-Teams können nur auf das reagieren, was sie sehen können. Wenn also die Anwendungs- und API-Ebene immer wichtiger wird, ist es entscheidend, dass wir sie mit Sicherheitssensoren instrumentieren, die anomales Verhalten erkennen und melden können.

Wie sind moderne Anwendungsarchitekturen wie Microservices, APIs und serverlose Systeme im Vergleich zu herkömmlichen Sicherheitsansätzen?

Diese Architekturen haben das alte Perimeter-Modell zerschlagen. Anfragen durchlaufen jetzt Dutzende von Diensten, ephemere Funktionen, APIs, Warteschlangen und Abhängigkeiten von Drittanbietern, bevor sie eine Transaktion abschließen. Die meisten Erkennungssysteme sehen immer noch Fragmente anstelle des vollständigen Ausführungspfads. Sie können Pakete oder Protokolle untersuchen, aber sie können nicht verstehen, was passiert, ob gefährlicher Code tatsächlich ausgeführt wurde oder nicht. Sicherheit ist Kontext, also müssen wir ein Modell, ein digitales Zwilling, unserer Anwendungsinfrastruktur aufbauen, das es uns (oder KI-Agenten) ermöglicht, über das zu urteilen, was wir sehen.

Warum persistieren Risiken wie unsichere Designentscheidungen und verletzliche Komponenten trotz weit verbreiteter Bekanntheit und Tooling?

Bewusstsein allein behebt nicht die Anreize oder die Komplexität. Die meisten Organisationen messen Erfolg noch immer an der Scannummer, der Ticket-Schließrate oder Checklisten für die Einhaltung von Vorschriften, anstatt an der tatsächlichen Reduzierung der Exposition.

Gleichzeitig sind Software-Lieferketten in ihrer Größe explodiert. Entwickler montieren Anwendungen aus Tausenden von Komponenten, die sie nicht selbst geschrieben haben und sicherlich nicht auf Sicherheit überprüft haben. Sicherheitsteams sind überfordert, wenn sie versuchen, theoretische Risiken zu priorisieren, und können sich nicht auf die 1-2% konzentrieren, die wirklich zählen. Ohne Laufzeitbeweise bricht die Priorisierung zusammen. Und mit dem Aufkommen leistungsfähiger KI-Modelle und -Harnische nimmt das Volumen exponentiell zu.

Wie sollten Organisationen ihre Abhängigkeit von Protokollen und Alarmen neu bewerten, wenn einige der kritischsten Schwachstellen keine beobachtbaren Signale hinterlassen?

Protokolle sind Beweise dafür, was Anwendungen berichten, nicht unbedingt Beweise dafür, was tatsächlich passiert ist. Das ist ein gefährlicher Unterschied. Organisationen müssen von indirekter Beobachtung zu direkter Beobachtung wechseln. Anstatt zu hoffen, dass ein Ausnutzungsversuch ein erkennbares Artefakt erzeugt, sollten Sicherheitssysteme das verletzliche Verhalten und das Ausnutzungsverhalten während der Laufzeit identifizieren. Wenn gefährlicher Code ausgeführt wird, sollte das System es sofort erkennen — unabhängig davon, ob ein Protokolleintrag existiert oder nicht.

Sie haben Laufzeit-Sichtbarkeit als Lösung befürwortet. Was bedeutet wahre Laufzeit-Sichtbarkeit in der Praxis, und wie ändert sie die Art und Weise, wie Sicherheitsteams täglich arbeiten?

Wahre Laufzeit-Sichtbarkeit bedeutet, zu verstehen, was die Anwendung tatsächlich in der Produktion tut: welche Routen exponiert sind, welche Bibliotheken aktiv sind, wo sensible Daten fließen, welcher Code ausgeführt wird und ob ein Angriff verletzliche Funktionen erreicht hat. Operativ ändert es die Sicherheit von einer reaktiven Jagd in eine präzise Disziplin. Teams hören auf, massive Schwachstellen-Rückstände zu jagen, und konzentrieren sich auf den kleinen Prozentsatz der Expositionen, die erreichbar, kritisch und aktiv angegriffen sind. Das verbessert dramatisch das Signal-Rausch-Verhältnis und die Reaktionsgeschwindigkeit. Im Durchschnitt werden nur 38% der Open-Source-Bibliotheken, die in einer Anwendung verpackt sind, tatsächlich in den Speicher geladen und ausgeführt. Und nicht all der Code in diesem Subset wird verwendet. Also ermöglicht Laufzeit-Sicherheit einfach, sich auf den Code zu konzentrieren, der tatsächlich läuft, und nicht auf alle ungenutzten Bibliotheken und Funktionen, die mit einer Anwendung einhergehen.

Wie vergleicht sich die instrumentationsbasierte Sicherheit mit herkömmlichen Ansätzen wie SAST, DAST oder Perimeter-Überwachung in Bezug auf Effektivität und Skalierbarkeit?

Herkömmliche Tools schließen Risiken aus der Außenperspektive. Instrumentierung beobachtet die Realität, indem sie den tatsächlichen Code beobachtet, während er läuft. Instrumentierung kann tatsächliche Ausführungspfade, Framework-Verhalten, Authentifizierungskontext, Datenfluss und Erfolg von Ausnutzungsversuchen in Echtzeit sehen. Sie eliminiert enorme Kategorien von Falschpositiven und deckt Schwachstellen auf, die Perimeter-Tools vollständig verpassen.
Im großen Maßstab wird diese Präzision kritisch. Organisationen können nicht mehr manuell Millionen von theoretischen Ergebnissen priorisieren. Laufzeit-Beweise werden zum einzigen nachhaltigen Filter. Laufzeit arbeitet in Echtzeit, also ist sie ein besserer Match für Entwicklung und CI/CD-Pipelines als Scannen und Priorisieren. Und Laufzeit ist kontinuierlich, also sind Sie nicht auf einen Momentaufnahme-Blick auf die Sicherheit beschränkt.

Wenn KI-Systeme und autonome Anwendungen häufiger werden, werden diese unsichtbaren Schwachstellen gefährlicher, und wie sollten Teams sich vorbereiten?

KI macht unsichtbare Schwachstellen viel gefährlicher, weil sie beide Seiten des Problems beschleunigt. Entwickler generieren Software schneller, und Angreifer finden und ausnutzen Schwachstellen schneller. Aber die meisten Sicherheitsprogramme verlassen sich noch immer auf menschliche Prozesse, die nicht mit KI-Geschwindigkeit arbeiten können. Teams sollten sich auf zwei Arten vorbereiten. Erstens sollten sie stärkere Laufzeit-Verteidigungen aufbauen, die Angriffe in der Produktion erkennen, blockieren und eindämmen können, während Schwachstellen behoben werden. Das gibt Organisationen Luftschutz. Zweitens sollten sie KI und Automatisierung nutzen, um sicherere Code zu schreiben — mit besserer Design, Test, Überprüfung und Verifizierung. Andernfalls erstellen wir Risiken schneller, als wir sie verwalten können.

Wenn Sie einem modernen Sicherheitsoperations-Center-(SOC)-Leiter heute beraten würden, welche konkreten Schritte sollten sie als Erstes unternehmen, um diese Sichtbarkeitslücke zu schließen, bevor sie zu einem großen Datenleck führt?

Erstens sollten sie akzeptieren, dass Perimeter-Telemetrie allein für die moderne Anwendungssicherheit unzureichend ist. Tatsächlich ist es unmöglich, viele Angriffe auf die Anwendungsebene und APIs am Perimeter zu sehen oder zu stoppen. Das SOC benötigt Sichtbarkeit innerhalb laufender Anwendungen, nicht nur die Infrastruktur, die sie hostet. Zweitens sollten sie Laufzeit-Beweise priorisieren gegenüber theoretischen Ergebnissen. Konzentrieren Sie sich auf Schwachstellen, die in aktivem Code sind, identifizieren Sie aktive Angriffspfade und exponierte Dienste, die tatsächlich in der Produktion ausgeführt werden. Schließlich sollten sie Anwendungssicherheit und Erkennungstechnik vereinen. Die Zukunft des SOCs kann Anwendungen nicht länger als undurchsichtige Black-Boxes behandeln. Anwendungen sind jetzt die primäre Angriffsfläche, und sie benötigen eine erste-Klasse-Sichtbarkeit während der Laufzeit.

Vielen Dank für das großartige Interview. Leser, die mehr erfahren möchten, sollten OWASP oder Contrast Security besuchen.