Manueller vs. automatisierter Pentest: Was Tools finden und was Menschen

Was ist der Unterschied?

Automatisiertes Testen ist Software, die einem Ziel sehr viele Fragen stellt, deren Antwortmuster sie schon kennt: Hat diese Version eine CVE, reflektiert dieser Parameter Eingaben, akzeptiert dieser Port ein Standardpasswort, bringt diese Nachricht den Parser zum Absturz. Manuelles Testen ist ein Mensch, der Fragen stellt, die noch niemand aufgeschrieben hat: Was passiert, wenn ich diese ID ändere, kann eine Lieferantenrolle ihre eigene Rechnung freigeben, was macht dieses Steuergerät, wenn ich eine gültige Session-Anfrage mit unmöglicher Länge schicke. Tools sind schnell, unermüdlich und konsistent. Menschen sind langsam, teuer und die Einzigen, die verstehen, wofür das System da ist.

Die Grenze ist nicht mehr “Scanner gegen Pentest”. Fuzzer, DAST-Tools und sogenannte autonome Pentest-Plattformen liegen dazwischen: Diese Tools erkunden, verketten und nutzen manchmal aus, und sie laufen Stunden oder Tage unbeaufsichtigt. Solche Werkzeuge sind ein echter Teil modernen Testens. Was sie nicht tun: eine Hypothese über deine Geschäftslogik bilden, den Schweregrad in deinem Kontext beurteilen oder merken, dass zwei mittlere Findings zusammen ein kritisches ergeben. Das bleibt die Arbeit des Testers, und das ist der Teil, für den ein Bericht bezahlt wird.

Nebeneinander

	Automatisiertes Testen	Manuelles Testen
Was es findet	Bekannte CVEs, veraltete Komponenten, Fehlkonfigurationen, Standardpasswörter, reflektierte und einfache Injections, Parser-Abstürze unter Fuzzing, fehlende Härtung	Autorisierungsfehler über Rollen und Mandanten hinweg, Missbrauch der Geschäftslogik, Angriffsketten, Design- und Krypto-Fehler, Race Conditions, Schwächen auf Protokollebene, alles Neue
Was es übersieht	Logik, Kontext, Ketten, alles ohne Muster; angemeldete Abläufe, die es nicht navigieren kann; falsch Positive brauchen Triage	Breite im großen Maßstab, Regressionen zwischen den Tests, lange Fuzzing-Läufe; begrenzt durch die gebuchten Tage
Wer macht es	Software, betrieben von deinem Team oder einem Dienst; ein Fuzzer oder eine Testsuite in der CI-Pipeline oder am Prüfplatz	Security Engineers mit Scope, Spielregeln und den Tools der linken Spalte
Dauer	Minuten bis Stunden für einen Scan, Stunden bis Tage für eine Fuzzing-Kampagne	Tage bis Wochen pro Ziel
Typische Kosten	Scanner- oder DAST-Lizenz ab einigen tausend Euro im Jahr; automatisierte Steuergeräte-Testsuiten und Fuzzing-Setups als Lizenz oder Dienst	6.000 bis 15.000 Euro für eine Webanwendung, 20.000 bis 45.000 für ein Steuergerät; typische Spannen für Deutschland und die EU, kein Angebot
Häufigkeit	Laufend, bei jedem Build oder wöchentlich	Ein- bis zweimal im Jahr und nach großen Änderungen
Verlangt von	ISO 27001 und TISAX als Schwachstellenmanagement, PCI DSS vierteljährliche Scans, CRA Anhang I Teil II in der Praxis für Regressionstests	PCI DSS jährliche Tests, OEM- und TISAX-Anforderungen, Nachweisen für die CRA-Konformität, Kundenverträgen, Verifikationsaktivitäten im UN-R155-CSMS in der Praxis
Ergebnis	Finding-Listen mit generischem Text und Scores; Crash-Logs und Reproduzierer aus dem Fuzzing	Bericht mit Reproduktion, Kontext, Schweregrad, Ketten und Fixes; Debrief und Retest

Nimm automatisiertes Testen, wenn

• du laufend wissen musst, ob sich eine bekannte Schwäche eingeschlichen hat: eine neue CVE in einer Bibliothek, eine Konfigurationsregression, ein nach dem Firmware-Update wieder offener Debug-Port.
• du dieselbe Schnittstelle viele Male testest: jede Steuergerätevariante, jedes Firmware-Release, jeden Sprint. Ein Fuzzer oder eine Testsuite, die jedes Mal dieselben tausenden Fälle fährt, fängt Regressionen, die kein jährlicher Pentest sehen würde.
• die Schwächeklasse eine ist, in der Tools gut sind: Parser-Robustheit unter fehlerhaftem CAN- oder UDS-Verkehr, Speicherfehler in einem Protokollstack, Header- und TLS-Hygiene über hunderte Hosts.
• du noch kein Budget für einen Pentest hast. Fix zuerst, was die Tools zeigen; sonst verbringt der Tester bezahlte Tage mit Dingen, die ein Scanner umsonst findet.

Für Regressionstests und Protokollrobustheit ist Automatisierung die bessere Wahl. Ein Mensch, der dieselben Fälle von Hand fährt, wäre langsamer und weniger konsistent.

Nimm manuelles Testen, wenn

• das System Rollen, Mandanten, Geld oder personenbezogene Daten hat. Die ernsten Findings sitzen in Autorisierung und Logik, und kein Tool weiß, was erlaubt sein soll.
• es ein Produkt ist, das du zum ersten Mal auslieferst: ein neues Gerät, eine neue Steuergeräteplattform, eine neue App. Jemand muss es verstehen, bevor irgendwer das Testen automatisieren kann.
• du einen Bericht mit dem Namen eines Testers brauchst, den ein Kunde, OEM, Auditor oder eine Konformitätsbewertung akzeptiert.
• Findings verkettet und beurteilt werden müssen. Ein Tool meldet ein Informationsleck und ein schwaches Session-Token als zwei mittlere Findings; ein Tester zeigt, dass beides zusammen Kontoübernahme bedeutet.

Beides zusammen

Ein gut gemachter Penetrationstest ist bereits beides: Der Tester lässt Scanner, Fuzzer und Skripte im Hintergrund laufen und steckt die eigenen Stunden dorthin, wo Tools blind sind. Das sinnvolle Setup für ein Unternehmen ist deshalb automatisiertes Testen laufend, in der Pipeline oder am Prüfplatz, plus ein manueller Test ein- bis zweimal im Jahr und vor Launches, mit Übergabe der automatisierten Ergebnisse, damit die Tage in die schwierigen Teile gehen.

Zyberum testet manuell und automatisiert dort, wo es sich lohnt: Bei Steuergerätetests fuzzen wir CAN-, UDS-, DoIP- und SOME/IP-Schnittstellen über Stunden, und wir bauen AutoST, eine automatisierte Security-Testsuite für Steuergeräte, die Kunden selbst auf jeder Variante und jedem Release laufen lassen. Wir sind ehrlich darin, was es leistet: AutoST findet das Bekannte, die Regressionen und die Abstürze, und jede neue Plattform testet weiterhin ein Zyberum-Engineer von Hand. Wenn ein Angebot, das du bekommen hast, einen vollständigen Pentest allein aus einem Tool verspricht, frag, wer die Ergebnisse gelesen hat.