Pentests-Lüge: Warum Scanner allein keine Hacker fangen

Mythos oder Realität: Automatisierte Pentests für schnell agierende Entwicklerteams.

In der Welt der hochdynamischen CI/CD-Pipelines und der „Ship it yesterday“-Mentalität werden Penetrationstests oft als das ultimative Hindernis angesehen. Synack erläutert, warum dies nicht so sein muss.

Zusammenfassung (TL; DR):

• Automatisierte Scans in CI/CD-Pipelines dienen nur als Basis, da sie komplexe Logikfehler oft übersehen.
• Menschliche Pentester sind entscheidend, um kontextbezogene Risiken zu bewerten und konkrete Proof-of-Concepts für Entwickler zu liefern.
• Statt starrer Prozesse sollten Unternehmen auf kontinuierliche Mikro-Tests setzen, die Sicherheit nahtlos in den agilen Sprint integrieren.

Sicherheitsingenieure befinden sich oft zwischen zwei Welten – dem Bedürfnis, eine strenge Sicherheitsposition aufrechtzuerhalten, und der Realität von Entwicklungsteams, die bis zu 50 Mal am Tag „deployen“. Wer den Konflikt zwischen Pentests und Geschwindigkeit spürt, sollte Penetrationstests nicht mehr nur als Aufgabe zum Abhaken betrachten, sondern sie als spezialisierte technische Feedbackschleife behandeln.

Pentests: Der Mythos der „vollständigen Automatisierung“

Eine der wichtigsten Feststellungen ist, dass Schwachstellenscans keine Penetrationstests sind. In einer schnelllebigen Umgebung ist die Versuchung groß, sich ausschließlich auf DAST/SAST-Tools (Dynamic/Static Application Security Testing) zu verlassen, die in die Pipeline integriert sind. Zwar sind diese unverzichtbar, um „niedrig hängende Früchte“ zu ernten, denn sie fungieren als automatisiertes Sicherheitsnetz. Sie sind jedoch bekanntermaßen schlecht darin, logische Fehler, Wege zur Rechteausweitung und komplexe Kettenangriffe aufzudecken.

Um über das bloße „Herausfiltern von Rauschen“ hinauszugehen, gilt es, den Einsatz manueller Arbeit weiterzuentwickeln: Automatisierte Tools bearbeiten die sich wiederholenden Schwachstellen mit bekannten Signaturen. Wenn ein manueller Penetrationstest eine Schwachstelle aufdeckt, die von einem Tool hätte erkannt werden können, muss die Behebungsmaßnahme eine Aktualisierung des Regelsatzes des automatisierten Scanners beinhalten. Dies stellt sicher, dass der Mensch die Automatisierung stets dazu antreibt, intelligenter zu werden, anstatt ihre Arbeit zu wiederholen.

Warum schnell agierende Teams Menschen im Loop brauchen

Wenn die Entwicklung schnell voranschreitet, erfolgt der „Environment Drift“ blitzschnell. Ein manueller Penetrationstest bietet drei Dinge, die eine CI/CD-Pipeline nicht leisten kann:

• Kontextbezogene Risikobewertung: Ein Scanner markiert eine „mittlere“ Schwachstelle basierend auf einem CVSS-Score. Ein Pentester wird sagen, dass diese „mittlere“ Schwachstelle tatsächlich „kritisch“ ist, da sie sich direkt neben der PII-Datenbank befindet.
• Kreative Randfälle: Schnell agierende Teams verlassen sich oft auf Boilerplate- oder modularen Code. Pentester suchen nach den „Nahtstellen“ zwischen diesen Modulen, an denen die Geschäftslogik versagt.
• Proof of Concept (PoC): Wie im Thread besprochen, ist die Sprachbarriere die größte Hürde, um Entwickler für das Thema zu sensibilisieren. Ein Pentest-Bericht, der einen PoC enthält, „zeigt etwas, statt nur etwas zu erzählen“. Er verwandelt eine abstrakte Sicherheitsanforderung in eine greifbare Schwachstelle, die behoben werden muss.

Vom „Gatekeeper“ zum „Enabler“

Wenn Unternehmen wollen, dass Pentests für agile Teams funktionieren, müssen sie das Bereitstellungsmodell ändern. Die Methode, den Bericht einfach „über den Zaun zu werfen“, hat ausgedient. Sicherheitsingenieure sollten Penetrationstests ihren Stakeholdern anders präsentieren.

Anstelle eines einzigen umfangreichen jährlichen Pentests sollten sie zu kontinuierlichem Pentesting oder regelmäßigen Mikrotests für bestimmte Funktionen mit hohem Risiko übergehen. Um die Geschwindigkeit aufrechtzuerhalten, sollten Trigger-Kriterien festgelegt werden. Ein menschlicher Pentester sollte hinzugezogen werden, wenn Änderungen an der Authentifizierungs- oder Autorisierungslogik vorgenommen werden oder neue APIs von Drittanbietern oder Dienste zur Verarbeitung personenbezogener Daten integriert werden. Gleiches gilt, wenn strukturelle Änderungen in der Netzwerkarchitektur auftreten.

Der Einfluss von DevSecOps entscheidend. Sicherheitsingenieure sollten nicht nur Schwachstellen finden, sondern mit den Plattform- oder SRE-Teams zusammenarbeiten, um Korrelationsregeln in ihrem SIEM/SOAR zu erstellen, damit ein erneuter Versuch dieses spezifischen Exploits automatisch erkannt wird. Um einen Mehrwert zu bieten, sollten sie diese Erfolgskennzahlen verfolgen:

• MTTR (Mean Time to Remediation): Das Verständnis der Effizienz von Behebungsprozessen ist entscheidend.
• Schwachstellendichte: Die Anzahl der Sicherheitslücken pro tausend Codezeilen (KLOC) bietet ein standardisiertes Maß für die Codequalität.
• Bereitstellungshäufigkeit: Es gilt sicherzustellen, dass Sicherheitsprüfungen nicht zu einem Engpass für die Wertschöpfung werden.

Bei Pentests in einem schnell agierenden Team geht es nicht darum, das Release zu verlangsamen. Es geht darum, sicherzustellen, dass die Geschwindigkeit das Projekt nicht in den Abgrund treibt. Für Sicherheitsingenieure besteht die Aufgabe nicht nur darin, Schwachstellen zu finden, sondern diese Erkenntnisse in umsetzbare technische Aufgaben zu übersetzen, die in einen modernen Sprint passen. Ein menschlicher, kreativer Pentest bleibt der effektivste Weg, um zu überprüfen, ob die automatisierten Sicherheitsnetze tatsächlich das auffangen, was sie sollen.