4 Gründe, warum dynamische Sicherheitstests für alle Ihre Assets unverzichtbar sind

Ich kann nicht mehr zählen, wie oft dieses Gespräch schon geführt wurde – meist in einem Konferenzraum, manchmal in einem Zoom-Call und fast immer mit guten Absichten. Einen Satz höre ich in fast jeder Diskussion über Sicherheitsstrategien:

„Wir konzentrieren DAST auf unsere Tier-1-Apps. Dort liegt das eigentliche Risiko.“

Meist gibt es dazu eine Tabelle, ein übersichtliches Klassifizierungsmodell und ein Gefühl der Erleichterung, denn den Umfang einzugrenzen wirkt wie Kontrolle. Aus Sicht eines Angreifers ist diese Entscheidung jedoch ein Geschenk.

Dynamic Application Security Testing (DAST) auf „kritische“ Anwendungen zu beschränken, ist kein ausgereifter risikobasierter Ansatz. Es ist ein Relikt aus der Zeit, als wir Software noch anders entwickelt haben, und er versagt vollständig angesichts moderner Architekturen, moderner Angreifer und moderner DevSecOps-Tools.

Sehen wir uns an, warum.

1. Angreifer zielen nicht auf Werte – sie suchen Schwachstellen

Sicherheitsteams ordnen Anwendungen nach ihrer geschäftlichen Auswirkung. Angreifer bewerten sie nach ihrem Widerstand. Dieser Unterschied ist entscheidend.

Ihre Tier-1-Anwendungen sind in der Regel:

• Durch WAFs geschützt

• Engmaschig überwacht

• Regelmäßig getestet

• Im Besitz erfahrener Teams

Ihre Tier-3-Apps:

• Schnell entwickelt, oft nur einmal

• Selten erneut überprüft

• Laufen mit veralteten Frameworks

• „Intern“, bis sie es nicht mehr sind

Angreifer wissen das. Sie versuchen nicht, direkt in Ihr Zahlungs-Gateway einzudringen, sondern wollen Zugang zu Ihrer Umgebung erhalten. Seien wir ehrlich: Automatisierte dynamische Angriffe sind längst nicht mehr ausschließlich das Werkzeug hochkarätiger Angreifer. Werbetreibende, Growth-Teams und Produktentwickler setzen sie bereits täglich ein, um das Nutzerverhalten kontinuierlich zu untersuchen, Abläufe zu optimieren und Sonderfälle in großem Maßstab auszunutzen. Wenn ganze Branchen bedenkenlos unermüdliche automatisierte Experimente gegen ihre eigenen Systeme durchführen, gibt es für CISOs und Sicherheitsteams keinen vertretbaren Grund, das für die Sicherheit nicht ebenfalls zu tun.

Dieser blinde Fleck ist typisch für eine KI-gestützte, API-orientierte Welt. Viele moderne Anwendungen stellen nur einen einzigen /chat- oder Agent-Endpunkt bereit und behandeln ihn wie „eine weitere API“. Tatsächlich fungiert dieser Endpunkt oft als privilegierte Kontrollebene, die bestimmt, welche Tools aufgerufen, auf welche Daten zugegriffen und welche Aktionen ausgeführt werden. Sind Autorisierungen nur vage definiert oder wird ihnen implizit vertraut, werden diese Agents zum idealen Mittel für Rechteausweitung, eine schleichende Ausweitung des Umfangs und das unbemerkte Umgehen von Richtlinien.

Wenn Sie Ihre KI- und Agent-Endpunkte nicht aktiv mit derselben Automatisierung, Kreativität und Beharrlichkeit angreifen, die die Geschäftswelt bereits bei Growth-Experimenten anwendet, „managen“ Sie kein Risiko – Sie überlassen die Entdeckung dem Angreifer.

DAST zeigt immer wieder: Bei weniger sichtbaren Apps versagen Annahmen zur Authentifizierung, fehlt die Eingabevalidierung, sind Admin-Pfade offengelegt und vertrauen APIs eher dem Netzwerkstandort als der Identität.

Nach einer Kompromittierung werden diese Apps zu Sprungbrettern in Identitätssysteme, gemeinsam genutzte Datenbanken, interne APIs oder die CI/CD-Infrastruktur. Das ist keine Theorie. So laufen moderne Angriffe ab. Kann eine Anwendung mit irgendetwas Bedeutendem kommunizieren, ist sie nicht „unkritisch“. Sie gehört zu Ihrer Angriffsfläche.

2. „Wir kennen unsere Apps“ ist meist übertrieben

Die meisten Unternehmen überschätzen bei Weitem, wie gut sie ihre aktive Anwendungslandschaft kennen.

In der Praxis finden sich in Umgebungen:

• Alte Staging-Systeme, die nie abgeschaltet wurden

• Legacy-APIs, die nur einen einzelnen Kunden unterstützen

• Marketing-Microsites, die von Drittanbietern bereitgestellt werden

• Temporäre Tools, die unbemerkt dauerhaft wurden

Diese Apps tauchen nicht in Architekturdiagrammen auf. Sie werden sichtbar, wenn Angreifer sie finden.

Einer der praktischsten Vorteile eines breit angelegten DAST-Einsatzes ist die systematische Asset-Erkennung. Sie diskutieren nicht länger darüber, was vorhanden sein sollte, sondern prüfen, was tatsächlich vorhanden ist. Aus Sicht des Security Engineering ist das grundlegend:

• Was Sie nicht erfasst haben, können Sie nicht priorisieren

• Was Sie nicht als erreichbar kennen, können Sie nicht überwachen

• Eine Angriffsfläche, die Sie nicht erfasst haben, können Sie nicht verteidigen

Eine breite DAST-Abdeckung macht aus unbekannter Exposition ein bekanntes Risiko – der erste Schritt, um es zu reduzieren.

3. DAST einzuschränken, schwächt die Sicherheitskultur aktiv

Dieser Punkt ist unangenehm, aber wichtig. Wenn Sie nur einen Teil Ihrer Anwendungen scannen, signalisieren Sie – bewusst oder unbewusst –, dass Sicherheit je nach vermeintlicher Bedeutung optional ist.

Was dann passiert:

• Teams interner Tools erhalten nie echte Schwachstellenbefunde

• Entwickler entwickeln kein Gespür für ausnutzbare Fehler

• Sicherheitsfeedback wird zentralisiert und elitär

Dann wird eine „unkritische“ App unweigerlich geschäftskritisch:

• Eine kundenseitige Erweiterung

• Eine Partnerintegration

• Ein Feature mit Bezug zum Umsatz

Nun veröffentlichen Sie etwas für externe Nutzer, das jahrelang keiner Laufzeit-Sicherheitsprüfung unterzogen wurde. DAST ist nicht nur eine Kontrollmaßnahme, sondern auch ein Lerninstrument. Es zeigt Entwicklern, wie sich ihr Code unter Angriffen verhält – nicht, wie er in einem Pull Request aussieht. Wenn Sie sichere Entwicklung als Standard etablieren wollen, muss Sicherheitsfeedback überall ankommen, nicht nur selektiv.

4. Die alten Ausreden gegen DAST ziehen nicht mehr

Sprechen wir den Elefanten im Raum an. Legacy-DAST-Tools waren mühsam: langsame Scans, fragile Konfigurationen, endlose False Positives und keinerlei CI/CD-Tauglichkeit. Daher kommt die Angst, „alles zu scannen“.

Modernes DAST hat sich jedoch grundlegend verändert:

• Wenige False Positives reduzieren Störsignale drastisch

• API-orientierte Tests entsprechen der tatsächlichen Entwicklung von Apps

• Die Authentifizierung wird nicht länger erst nachträglich berücksichtigt

• Interne Scans lassen sich sicher und ohne Exposition durchführen

• Schnellere, inkrementelle und CI/CD-Pipeline-freundliche Scans

Der Zielkonflikt zwischen Geschwindigkeit und Abdeckung besteht nicht mehr. Er ist ein Überbleibsel aus der Zeit von Tools, die nicht für moderne Bereitstellungspipelines entwickelt wurden. Heute ist ein eingeschränkter DAST-Umfang keine technische Notwendigkeit, sondern eine strategische Entscheidung. Und meistens keine gute.

Risiken treten nicht mehr nur dort auf, wo der geschäftliche Wert am höchsten ist. Sie entstehen dort, wo Annahmen nicht zutreffen – und das passiert am häufigsten an den Stellen, die niemand im Blick hat.

Ist eine Anwendung erreichbar, authentifiziert oder wird ihr von etwas Wichtigem vertraut, verdient sie DAST.

Anstatt zu fragen:

„Ist diese App geschäftskritisch?“

Fragen Sie stattdessen:

„Worauf könnte ein Angreifer von hier aus zugreifen?“

Moderne Angreifer dringen nicht direkt zu den Kronjuwelen vor. Sie gelangen durch Seiteneingänge, vergessene Türen und Türen, von denen Sie nicht einmal wussten, dass es sie gibt, ins System. Ihre Sicherheitsstrategie sollte dieser Realität Rechnung tragen. Genau hier kommt es auf moderne Application-Security-Plattformen an – nicht als Einzellösungen, sondern als Wegbereiter für Skalierung.

Plattformen wie Snyk basieren auf der Annahme, dass Risiken nicht mehr nur an einem Ort auftreten. Mit Snyk API & Web (DAST) können Teams Web-Apps und APIs kontinuierlich testen, tatsächlich exponierte Assets entdecken und echte, ausnutzbare Probleme mit Belegen aufdecken – ohne die Bereitstellung zu verlangsamen. In Kombination mit den umfassenderen AppSec-Funktionen von Snyk für SAST, SCA, Container und Infrastructure as Code wird DAST nicht mehr zu einem gelegentlichen Audit, sondern zu einem Bestandteil der Entwicklung und des Betriebs von Software. Es geht nicht darum, um des Scannens willen mehr zu scannen. Es geht darum, blinde Flecken zu beseitigen – besonders jene in Apps, die niemand für wichtig hielt.

Möchten Sie mehr darüber erfahren, warum KI-gestütztes SAST und DAST kombiniert werden sollten? Laden Sie noch heute The Gorilla Guide® To Unified SAST and DAST in the AI Era herunter.