Automatisierte Sicherheitsüberprüfungen

Security Testing in der Softwareentwicklung bedeutet, Sicherheitsprüfungen nicht erst am Ende per Pentest zu machen, sondern kontinuierlich in die CI/CD-Pipeline zu integrieren. Tools wie OWASP ZAP oder Nuclei scannen automatisch auf Schwachstellen wie fehlerhafte Zugriffskontrollen oder falsch gesetzte HTTP-Header. Das reduziert Pentest-Findings deutlich und spart Entwicklungsaufwand.

Das Wichtigste in Kürze

• Dynamische Security-Scanner wie OWASP ZAP und Nuclei lassen sich in CI/CD-Pipelines integrieren und decken ohne manuelle Konfiguration bereits 60 bis 80 Prozent der gängigen Sicherheitsanforderungen ab.
• Teams, die Security-Checks vor dem Pentest etablieren, reduzieren den Pentest-Report von typischen 60 auf 4 bis 5 Seiten, weil Standardbefunde wie fehlende HTTP-Header vorab automatisch gefunden werden.
• Broken Access Control hat SQL Injection als häufigste kritische Schwachstelle abgelöst, weil moderne Frameworks Injections weitgehend abfangen, Berechtigungslogik aber weiterhin Eigenverantwortung der Entwickler bleibt.
• Das größte Hindernis beim Einführen von Security-Testing ist nicht technische Komplexität, sondern ungeklärte Verantwortung: Kein Team will den Hut fangen, wer das Thema intern betreut.

Sicherheit ist ein Testfall, kein Anhängsel am Projektende

Software-Sicherheit gehört in den gesamten Entwicklungszyklus, nicht in einen einmaligen Pentest kurz vor dem Go-Live. Christian Biehler arbeitet seit zehn Jahren als Pentester und kennt das Muster: Eine Anwendung wird über Monate gebaut, am Ende kommt jemand und zeigt mit dem Finger auf die offenen Lücken. Dann muss das Team zurück an den Anfang und Code umschreiben.

Der DevOps-Gedanke und später DevSecOps haben die Werkzeuge geliefert, um das anders zu lösen. Security-Testing lässt sich automatisieren und früh in die Pipeline einbauen. Vieles, was sonst erst der Pentester findet, kann ein Tool schon während der Entwicklung melden.

Sicherheit unterscheidet sich darin nicht von anderen nichtfunktionalen Themen. Performance, Architektur, Usability: Auch dort hat man lange am Schluss “ein bisschen rumgetestet” und dann festgestellt, dass alles geändert werden muss. Der Gedanke, das nach vorne zu ziehen, ist nicht neu. Trotzdem fehlt das Thema Security auf vielen Teststrecken noch komplett.

Welche Schwachstellen heute wirklich ausgenutzt werden

Die kritischsten Lücken liegen heute nicht mehr bei den klassischen Injections, sondern bei Logik und Access Control. SQL-Injection war lange das große Thema: Ein Angreifer schleust eigenen Code in eine Datenbankabfrage ein, liest die ganze Datenbank aus oder überschreibt Passwörter. Standard-Frameworks fangen das inzwischen weitgehend ab, deshalb ist diese Kategorie seltener geworden.

Stärker geworden sind Fehler bei Berechtigungen. Das Standardbeispiel: Du loggst dich bei deiner Bank ein und rufst deinen Kontoauszug mit ID = 1 ab. Was macht ein Angreifer? Er probiert ID = 2, ID = 3, ID = 4 und bekommt die Kontoauszüge anderer Leute.

Betroffen ist jede Anwendung mit einem Rollen- und Berechtigungsmodell. Das Durchnummerieren von PDF-Dokumenten gehört dazu, ebenso versteckte administrative Funktionen.

Ein häufiger Fehler steckt in modernen, JavaScript-lastigen Web-Anwendungen, die nur noch mit einer API sprechen. Manche Entwickler legen Security-Prüfungen ins Frontend. Das funktioniert nicht, weil ein Angreifer die API-Anfragen abfängt, manipuliert und so direkt an die Daten kommt.

Wie automatisierte Security-Tools in die Pipeline kommen

Frei verfügbare Werkzeuge decken einen Großteil der offensichtlichen Schwachstellen ab, ohne dass jemand händisch hacken muss. Kein realer Angreifer sitzt mehr im Keller im schwarzen Kapuzenpulli und arbeitet sich manuell durch. Angreifer automatisieren, soweit es geht, und genau diese Tools lassen sich in die CI/CD-Pipeline einbauen.

Bei Security-Tools für den Web-Bereich ist die OWASP eine gute Anlaufstelle. Der OWASP ZAP ist das frei verfügbare Tool der Wahl für dynamisches Application Security Testing. Er lässt sich in eine Pipeline integrieren, gibt XML- und HTML-Reports aus und ist über API und CLI steuerbar. Er crawlt jede Seite und jeden Parameter und schickt dann die klassischen Injections durch.

Die Angriffsmuster haben sich dabei kaum verändert. Ein Cross-Site-Scripting beginnt im einfachsten Fall mit einem Script-Tag plus Alert, eine SQL-Injection oft mit einem Hochkomma. Der ZAP geht diese Patterns für jedes Feld durch, was bei großen Anwendungen schnell ein paar zehntausend Requests bedeutet.

Daneben gibt es leichtere Werkzeuge. Nuclei arbeitet template-basiert, ruft jede Seite einmal auf und prüft Basics wie Verschlüsselung und HTTP-Header. Ein Dependency-Checker deckt veraltete Libraries und ihre Schwachstellen ab.

Lange Scans sprengen die schnelle Deployment-Pipeline

Ein vollständiger ZAP-Scan passt nicht in einen Zyklus, der mehrmals täglich deployt. Während Nuclei in Minuten durchläuft, weil er nur die Seiten einmal aufruft und Basics prüft, muss der ZAP jedes Formular crawlen und jede Anfrage mit jeder Payload abschicken. Je nach Größe der Anwendung dauert das zwischen einer und vier Stunden.

Wer nightly deployt, kann den ZAP unter Umständen noch unterbringen. Bei mehreren Deployments pro Tag gehört er aus der Standard-Pipeline herausgezogen und separat eingeplant.

Wie viel Abdeckung Tools von der Stange liefern

Tools von der Stange decken einen guten Teil der Anforderungen ab, aber nicht alles. Als Referenz dient der OWASP ASVS-Katalog mit rund 290 Controls, nach dem in der Branche geprüft wird. Die Top 10 sind nett, taugen aber nicht als Prüfgrundlage.

Mit vier Werkzeugkategorien kommt man weit: einem dynamischen Scanner wie dem ZAP, statischer Code-Analyse, einem Dependency-Checker für Updates und Libraries und einem Blick aufs Betriebssystem. Out of the Box lassen sich mit dem ZAP grob zwischen 60 und 80 der Anforderungen dynamisch prüfen, die statische Code-Analyse liegt etwas besser.

Ein Gap bleibt, und den füllst du mit eigenen Testfällen. Wer ohnehin Unit-Tests schreibt, kann Security gleich mitdenken. Ob eine E-Mail-Adresse dem zugehörigen RFC entspricht, lässt sich testen. Was passiert, wenn das E-Mail-Feld plötzlich eine 400 MB große Eingabe bekommt? Dann brauchst du sauberes Fehlerhandling, und das gehört als Testfall hinterlegt.

Für diese letzten Prozentpunkte reicht “Clicky-Bunty starten” nicht. Du musst prüfen, was die Tools wirklich abdecken und was du selbst schreiben musst.

Warum Teams beim Pentest am Ende landen statt Security früh einzubauen

Das Problem ist selten technisch, sondern organisatorisch. Die technische Implementierung einer dynamischen Testing-Suite ist in etwa anderthalb Tagen aufgesetzt. Die eigentliche Frage lautet: Wer macht es, wer betreut es, wer kennt sich mit Security aus?

In vielen Unternehmen steht jemand mit einem Hut in der Hand im Meetingraum und will ihn jemandem aufsetzen, der ab dann Security macht. Niemand in Entwicklung oder Betrieb hat Langeweile, also versuchen sich alle wegzuducken. Soll jedes Team es selbst machen, oder bündelt man die Security-Tools zentral über mehrere Dev-Teams? Schnell ist man bei Rollen, Zuständigkeiten und Machtkämpfen.

Hinzu kommt, dass die Gefahr abstrakt wirkt. Niemand garantiert, dass der Angriff wirklich passiert, und oft bekommt man einen Hack am eigenen Produkt gar nicht mit. Manchmal fehlt schlicht die Vorstellung davon, was ein Angreifer kann.

Wir haben gerade im Web-Bereich Entwickler in Schulungen, die sagen: Wir haben doch ein Dropdown definiert, was anderes kann der Angreifer da doch gar nicht eingeben. Der Angreifer hat ein Proxy, der kann eingeben, was er will.

Christian Biehler

Ein Gegenmittel ist Mob-Hacking: sich als Team hinsetzen, ein Angreifer-Werkzeug über die eigene Anwendung schicken und sehen, wie ein Angreifer sie wahrnimmt. Das sorgt für Erleuchtung.

Frameworks helfen bei Injections, nicht bei Berechtigungen

Moderne Web-Frameworks fangen klassische Injection-Schwachstellen gut ab, lassen dich bei der Autorisierung aber allein. React, Angular und Co. encodieren Ausgaben und haben SQL-Injection sowie Cross-Site-Scripting weitgehend im Griff.

Der Haken: Ein Framework gibt dir die Freiheit, dir selbst ins Knie zu schießen. Es gibt Fälle, in denen ein Framework eigentlich encodiert, dann aber etwas auf der Webseite komisch aussah, das Encoding deshalb wieder ausgestellt wurde und der Salat zurück ist.

Beim Thema Autorisierung und Rollenmodelle helfen Frameworks kaum. Wer welche Berechtigung hat und ob sie geprüft wird, definiert derjenige, der die Anwendung baut. Deshalb gehören Access-Control-Fehler zu den kritischsten Funden.

Wo überall Security zählt: Desktop, Mobile und API

Security wird dort relevant, wo Daten verarbeitet oder übertragen werden, nicht bei einer isolierten lokalen Funktion. Eine unsichere Desktop-Anwendung ist so lange unkritisch, bis sie Daten speichert oder kommuniziert. Wenn der Taschenrechner auf dem Windows-Client eine Schwachstelle hat, geht die Welt nicht unter.

Praktisch kommuniziert heute fast jede Anwendung irgendwo per HTTP mit einem Backend. Mobile Apps haben in der Regel ein Frontend für beide großen Plattformen, während die Datenverarbeitung auf dem Server stattfindet. Statt klassischer POST-Aufrufe gibt es dann API-Calls, mit ein paar zusätzlichen Prüfpunkten, aber im Kern wieder Webwelt.

Mobile Apps haben eigene Maßnahmen: Daten, die auf dem Gerät liegen, oder das Ausblurren des Bildschirms, wenn eine Banking-App in den Hintergrund wandert. Der eigentliche Schaden entsteht trotzdem in der Kommunikation zum Server. Den lokalen Kontostand in der App ändern bringt nichts, den echten Kontostand ändert nur eine Anfrage ans Backend.

Wie aktuell die Prüfkataloge gegenüber neuen Angriffen sind

Die etablierten Schwachstellenkategorien sind über Jahre stabil, neue Technologie kommt mit Verzögerung dazu. Die OWASP-Prüflisten sind weitgehend unabhängig von Sprache, Betriebssystem und Datenbank. Spezifika existieren im Detail, etwa Angriffe, die nur unter Linux oder nur unter Windows funktionieren, aber in den Listen steht die Kategorie wie Local File Inclusion oder Remote Code Execution.

Diese Vektoren ändern sich kaum, wenn du von Debian auf Red Hat oder von Windows 10 auf Server 2022 wechselst. Es gibt nur leicht andere Wege, sie auszunutzen. Neben OWASP hilft die CWE-Liste, die auch nicht-webspezifische Themen abdeckt. Eine Neuauflage der Top-Listen kommt etwa alle vier bis fünf Jahre, dann werden Punkte verschoben.

Bei KI sieht es anders aus. Wenn Einschränkungen eines KI-Generators umgangen werden und sich darüber im Firmenkontext Aktionen ausführen lassen, fehlt das in einer klassischen Top 10 noch. Hier ist die Community oft vor der OWASP dran.

Auch Quantencomputing schwebt als Damoklesschwert über der Transportverschlüsselung. Ein Angriffsszenario: heute verschlüsselte Daten abgreifen und später mit ausreichender Rechenleistung entschlüsseln. Praktisch lässt sich dagegen wenig tun, außer aktuelle TLS-Versionen, aktuelle Ciphers und Wegwerfschlüssel (Ephemeral Cipher Suites) einzusetzen, damit nicht immer derselbe Sitzungsschlüssel verwendet wird.

Wo du anfängst, wenn Security bisher nur am Ende stattfand

Die meisten Teams machen bereits Security, ohne es so zu nennen. Ein Scanner mit Quality Gates ist oft schon da, produziert aber tausende Befunde, die niemand anschaut. Auch ein Dependency-Check für veraltete JavaScript- oder Java-Libraries läuft in vielen Pipelines mit.

Der nächste Schritt ist, sich zu trauen. Wenn die Anwendung deployt ist und du ohnehin Selenium-Tests fährst, lass ein Security-Tool wie Nuclei oder den ZAP mitlaufen oder separat laufen. Schau dir die Ergebnisse an und spiel sie ins Team zurück.

Wichtig ist der Einstieg ohne Hürde. Mach den Scan nicht sofort zum Fail-Kriterium zwei Wochen vor Go-Live, das untergräbt die Akzeptanz. Nähere dich dem Thema an. Fang mit Nuclei und ein paar Templates an, prüf erst Header und TLS-Konfiguration. Es muss nicht das perfekte Mittel sein.

Der Maßstab ist nicht eine Eins plus mit Sternchen, sondern kein blaues Auge zu haben. Das ist schon ein guter Start.

Frühe Tests verkürzen den Pentest-Report drastisch

Wer Security in die Entwicklung integriert, reduziert den Pentest-Report von 60 Seiten auf wenige Seiten echter Funde. In einem typischen Report für eine Anwendung, die nie vorher geprüft wurde, sind von 60 Seiten rund 45 Seiten Standardkram: HTTP-Header, Fehlkonfigurationen, Härtungsthemen. Dafür brauchst du keinen ZAP, das zieht dir schon Nuclei.

Aus dokumentierten Funden über sechs Monate zeigt sich die Verteilung: Auf 100 Tests gerechnet etwa einmal SQL-Injection, 30 bis 40 Mal Cross-Site-Scripting, aber in nahezu 100 Prozent der Fälle falsche Cipher Suites, fehlende Header, gesetzte Debugging-Flags oder herumliegende statische Entwickler-Files.

Ziehst du diesen Standardkram automatisiert ab, bleiben im Report die vier bis fünf Seiten, die wirklich nur ein Pentester findet: versteckte Logikfehler, Angriffe über mehrere Formularfelder hinweg. Der Pentest kostet weniger, der Entwickler liest weniger, und im Ticketsystem landen zwei echte Issues statt dreißig Header-Findings.