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

> Automatisierter Penetrationstest heißt Tools: Scanner, DAST, Fuzzer und "autonome Pentest"-Plattformen, die ein Ziel auf bekannte Schwächemuster abklopfen. Manueller Penetrationstest heißt ein Mensch, der die Anwendung versteht, Hypothesen bildet und sie ausprobiert. Tools gewinnen bei Tempo, Wiederholbarkeit und Abdeckung des Bekannten; Menschen bei Logikfehlern, Autorisierung, Angriffsketten und allem ohne Signatur. Ein guter Pentest nutzt beides, und ein "Pentest", der in einer Stunde durchläuft, ist ein Scan. Zyberum baut selbst ein Automatisierungsprodukt, AutoST für Steuergeräte, und setzt trotzdem bei jedem Test Menschen ein.

Tools finden bekannte Schwächen schnell und wiederholbar. Menschen finden Logikfehler, Ketten und alles Neue. Wo die Grenze liegt und wie du beides kombinierst.

Source: https://zyberum.com/de/vergleich/manueller-vs-automatisierter-pentest · Updated: 2026-10-07

## 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.

## FAQ

**Sind "autonome Pentest"-Plattformen ein echter Penetrationstest?**

Es sind gute automatisierte Tests, meist eine Stufe über einem reinen Scanner: Solche Plattformen verketten bekannte Schwächen, probieren Standardpasswörter und bestätigen manche Findings durch Ausnutzung. Trotzdem verstehen sie nicht, wofür deine Anwendung da ist, können nicht beurteilen, ob Nutzer A die Bestellung B sehen darf, und enden bei allem ohne bekanntes Muster. Nenn sie kontinuierliche automatisierte Tests und nutz sie als solche; für einen Bericht, den ein Auditor oder OEM als Penetrationstest akzeptiert, muss ein Mensch getestet haben.

**Welcher Anteil der Pentest-Findings kommt von Tools?**

In unseren Web- und API-Tests liefern Tools meist die veralteten Komponenten, fehlenden Header und offensichtlichen Injection-Punkte, also ein Drittel oder weniger der Findings und fast keines der kritischen. Die kritischen sind Autorisierungsfehler, Logikmissbrauch und Ketten, gefunden durch Lesen und Denken. Bei Firmware- und Steuergerätetests verschiebt sich das Verhältnis zu den Tools, weil Fuzzing über Stunden Parser-Abstürze findet, die kein Mensch von Hand erreichen würde.

**Macht Automatisierung einen Pentest günstiger?**

Eher besser fürs gleiche Geld als günstiger. Der Tester steckt die gesparten Stunden in die schwierigen Teile. Ein Pentest einer Webanwendung kostet weiterhin 6.000 bis 15.000 Euro, typische Spannen für Deutschland und die EU, weil der Preis die Menschentage sind. Günstiger wird die Zeit zwischen den Pentests, die automatisierte Tests zu festen Jahreskosten abdecken können.

## Sources

- [NIST SP 800-115: Technical Guide to Information Security Testing and Assessment, Abschnitte 4 und 5 (Zielidentifikation und -analyse, Validierung von Schwachstellen)](https://csrc.nist.gov/pubs/sp/800/115/final)
- [OWASP Web Security Testing Guide, Einführung (Rolle automatisierter Tools)](https://owasp.org/www-project-web-security-testing-guide/)
- [BSI: Durchführungskonzept für Penetrationstests](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Studien/Penetrationstest/penetrationstest.html)
- [Verordnung (EU) 2024/2847 (Cyber Resilience Act), Anhang I Teil II (wirksame und regelmäßige Tests und Überprüfungen)](https://eur-lex.europa.eu/eli/reg/2024/2847/oj)

## Related

- [SAST und DAST](https://zyberum.com/de/glossar/sast-dast)
- [Fuzzing](https://zyberum.com/de/glossar/fuzzing)
- [Schwachstellenscan](https://zyberum.com/de/glossar/schwachstellenscan)
- [Penetrationstest vs. Schwachstellenscan: Was beide finden, wann du was brauchst](https://zyberum.com/de/vergleich/pentest-vs-schwachstellenscan)
- [ECU-Fuzzing erklärt: Fehler in UDS, DoIP und SOME/IP finden](https://zyberum.com/de/insights/ecu-fuzzing-erklaert)
- [Automotive Security Testing, automatisiert.](https://zyberum.com/de/autost)
- [Wir brechen ein. Du bekommst den Beweis und den Fix.](https://zyberum.com/de/penetrationstest)

---
Zyberum GmbH. Canonical page: https://zyberum.com/de/vergleich/manueller-vs-automatisierter-pentest