Penetrationstest oder Schwachstellenscan: der Unterschied
Ein Schwachstellenscan sucht automatisch nach bekannten Lücken, ein Penetrationstest prüft zusätzlich von Hand, ob sich Rechte und Abläufe der Anwendung überlisten lassen. Der Scan gehört laufend in den Betrieb, der Pentest vor den Start und nach größeren Änderungen.
Am deutlichsten zeigt sich der Unterschied an einer Frage, die kein Scanner beantwortet: Sieht Kunde A die Rechnung von Kunde B, wenn er in der Adresszeile die Rechnungsnummer ändert? Für den Scanner ist das eine fehlerfreie Seite, die mit Status 200 antwortet. Erst ein Mensch, der weiß, wem die Rechnung gehört, erkennt darin eine Lücke, in der Fachsprache eine IDOR.
Das BSI behandelt beide Verfahren als Prüftiefen: In seinem Praxis-Leitfaden für IS-Penetrationstests ist der Schwachstellenscan eine Stufe innerhalb eines Pentests. Der Leitfaden stammt in der aktuellen Fassung 1.2 vom November 2016; Werkzeuge und Angriffstechniken haben sich seitdem verändert, die Empfehlungen zu Auftrag, Ablauf und Bericht sind weiter brauchbar. Wie wir solche Prüfungen durchführen, beschreibt unsere Seite zu Analysen und Audits.
Begriffe
Scan, Pentest und Audit sauber getrennt
Schwachstellenscan: Ein Werkzeug fragt Versionen, Konfigurationen und bekannte Muster ab und vergleicht sie mit Listen bekannter Lücken. Das BSI unterscheidet den nicht invasiven Scan, der Lücken nur meldet, vom invasiven Scan, der sie mit Exploits ausprobiert.
Penetrationstest: Ein Pentest ist ein beauftragter, simulierter Angriff. Prüfer nutzen Scanner als Hilfsmittel und prüfen danach von Hand, ob sich Rechte umgehen, Abläufe austricksen oder Daten abziehen lassen.
Audit: Ein IT-Audit prüft gegen Vorgaben, etwa IT-Grundschutz oder ISO 27001: Gibt es ein Rechtekonzept, werden Updates eingespielt, ist das Vorgehen dokumentiert? Ein Audit muss die Anwendung nicht angreifen.
Scan und Pentest im direkten Vergleich:
| Schwachstellenscan | Penetrationstest | |
|---|---|---|
| Wer prüft | ein automatisiertes Werkzeug | Prüfer mit Werkzeugen und Handarbeit |
| Was gefunden wird | bekannte Lücken, veraltete Versionen, Fehlkonfigurationen | zusätzlich Fehler in Rechten, Rollen und Abläufen |
| Kenntnis der Anwendung | nur, was von außen oder mit einem Konto sichtbar ist | Testkonten je Rolle, Unterlagen, auf Wunsch Quellcode |
| Fehlalarme | häufig, weil viele Scanner nur Versionsangaben auswerten | selten, Befunde werden nachgewiesen |
| Dauer | Minuten bis Stunden | mehrere Tage, je nach Umfang |
| Wiederholung | laufend, zum Beispiel wöchentlich und nach jeder Auslieferung | vor dem Start und nach größeren Änderungen |
| Ergebnis | Trefferliste | Bericht mit Nachweis, Bewertung und Empfehlung |
Grenzen
Was ein automatischer Scan findet und was nicht
Ein Scanner ist stark bei allem, was sich an einer einzelnen Antwort des Servers erkennen lässt, und blind für alles, was Wissen über Ihr Geschäft voraussetzt.
Zuverlässig findet ein Scan zum Beispiel:
veraltete Server- und Bibliotheksversionen mit bekannten Lücken,
schwache TLS-Einstellungen und fehlende Sicherheits-Header,
offen erreichbare Dateien wie Konfigurations- oder Versionsverwaltungsordner,
Standardpasswörter und offene Verwaltungsoberflächen,
typische Muster für eingeschleusten Code in Formularfeldern.
Nicht finden kann er, was erst im Zusammenhang zur Lücke wird. Die OWASP schreibt im Web Security Testing Guide, Fehler in der Geschäftslogik ließen sich von einem Schwachstellenscanner nicht erkennen, ihre Prüfung bleibe Handarbeit. Dazu gehören:
Rechte zwischen Nutzern und Mandanten: wie im Beispiel mit der Rechnung. Ein Scan mit einem Konto sieht nur, was dieses Konto sehen darf, und kann nicht beurteilen, ob es das sehen darf.
Rollen: Darf ein Sachbearbeiter über eine direkte Adresse eine Freigabe auslösen, die nur Abteilungsleiter sehen?
Abläufe: Lässt sich ein Bestellprozess mit dem Zahlungsschritt überspringen, ein Gutschein zweimal einlösen, eine Frist durch Zurückspringen verlängern?
Dazu kommt das umgekehrte Problem. Laut BSI entscheiden die meisten Scanner anhand gemeldeter Versionen, ob eine Lücke vorliegt. Wer aus Kompatibilitätsgründen bewusst eine ältere, aber gepatchte Version einsetzt, erscheint dann als verwundbar, obwohl die Lücke geschlossen ist. Jeder Treffer braucht deshalb eine Bewertung durch jemanden, der das System kennt.
Prüfauftrag
Ablauf eines Pentests für eine Webanwendung
Ein Pentest beginnt mit dem schriftlichen Auftrag. Das BSI empfiehlt, nie ohne schriftlichen Auftrag zu testen und darin Prüfzeitraum, Prüfobjekt und Prüftiefe festzulegen. Liegt die Anwendung bei einem Hoster, gehört er laut BSI in den Vertrag. Der Grund ist auch strafrechtlich: § 202a StGB stellt den unbefugten Zugang zu geschützten Daten unter Strafe, § 202c StGB schon das Vorbereiten mit dafür bestimmten Programmen. Mit der schriftlichen Erlaubnis des Berechtigten handeln die Prüfer nicht unbefugt. Ein Referentenentwurf des damaligen Bundesministeriums der Justiz vom November 2024, das seit 2025 Bundesministerium der Justiz und für Verbraucherschutz heißt, sieht eine Ausnahme für IT-Sicherheitsforschung vor; § 202a StGB galt am 14.05.2026 unverändert.
Vorgespräch und Prüfumfang
Im Vorgespräch klären Sie, welche Teile der Anwendung geprüft werden, mit welchen Rollen und auf welchem System. Das BSI empfiehlt Whitebox-Tests, bei denen die Prüfer Unterlagen und Zugänge bekommen, weil Blackbox-Tests mehr Aufwand kosten und Angriffe informierter Innentäter übersehen.
Wie wichtig die Liste der Oberflächen ist, zeigt unsere Case Study zu einer REST-API mit HR-Frontend: zwei Frontends, eines für interne Disponenten und eines für externe Mitarbeiter, beide über dieselbe Auth-Schicht und dieselben Rollen-Checks. Ein Prüfauftrag für eine solche Anwendung sollte beide Frontends und die API getrennt nennen, mit Testkonten für jede Rolle. Sonst prüft der Pentest womöglich das Backoffice gründlich und das Portal für Externe nur am Rand.
Test, Abschlussgespräch, Bericht
Die Prüfer arbeiten im vereinbarten Zeitraum, melden kritische Funde sofort und stellen die Ergebnisse in einem Abschlussgespräch vor. Verbindlich ist laut BSI erst der Bericht. Nach der Behebung folgt ein Nachtest der kritischen Befunde.
Diese Vorlage können Sie für die Beauftragung kopieren und ausfüllen. Sie orientiert sich an den Punkten des BSI-Leitfadens und am Web Security Testing Guide der OWASP:
PENTEST-AUFTRAG WEBANWENDUNG (Vorlage)
1. Beteiligte
Auftraggeber: ...
Prüfer / Prüfstelle: ...
Ansprechpartner im Prüfzeitraum: Name, Telefon
Notfallkontakt bei Ausfall oder kritischem Fund: Name, Telefon
2. Prüfobjekt
Anwendung: ...
Adressen (URLs): https://...
API (Basis-URL, Dokumentation): ...
System: Testsystem / Produktivsystem
Hoster: ... (schriftliche Zustimmung liegt vor: ja / nein)
Nicht im Umfang: Mailserver, Drittdienste (z. B. Zahlungsanbieter),
Last- und Ausfalltests
3. Prüftiefe
Vorgehen: Whitebox / Graybox / Blackbox
Bereitgestellt: Testkonten je Rolle (Rolle: Anzahl), Architekturskizze,
Quellcode: ja / nein
Exploits: nicht erlaubt / nur nach Rücksprache
Leitfaden: OWASP Web Security Testing Guide v4.2
Schwerpunkte: Anmeldung und Sitzungen, Rechte zwischen Rollen und
Mandanten, Geschäftsabläufe (Bestellung, Freigabe,
Zahlung), Datei-Uploads, API
4. Zeitraum und Bedingungen
Prüfzeitraum: TT.MM.JJJJ bis TT.MM.JJJJ, ... bis ... Uhr
IP-Adressen der Prüfer: ...
Lastgrenze: höchstens ... Anfragen pro Sekunde
Testdaten: ... (keine echten personenbezogenen Daten: ja / nein)
5. Ergebnisse
Kritische Funde: sofort telefonisch an den Notfallkontakt
Bericht: Prüfobjekt und Bedingungen, Management-Zusammenfassung,
Befunde mit Nachweis, Bewertung (CVSS) und Empfehlung
Abschlussgespräch: ja, Teilnehmer: ...
Nachtest behobener Befunde: enthalten / optional
6. Vertraulichkeit und Daten
Verschwiegenheit über Befunde und Systemaufbau: vereinbart
Prüfdaten: Speicherort ..., Löschung bis TT.MM.JJJJ mit Nachweis
Datenschutzbeauftragter informiert: ja / nein
7. Kosten und Haftung
Preis: Festpreis ... / ... Tage x ... Tagessatz
Haftung bei Störungen: ...
Hinweis: Ergebnisse gelten für den Prüfzeitpunkt,
Vollständigkeit wird nicht zugesichert.
8. Freigabe
Der Auftraggeber ist berechtigt, die Prüfung des Prüfobjekts zu erlauben,
und erlaubt sie im oben beschriebenen Umfang.
Ort, Datum, Unterschrift Auftraggeber Ort, Datum, Unterschrift Prüfer
Prüfen Sie vor der Unterschrift, wer auf Ihrer Seite die Zeile „berechtigt“ wirklich erfüllt. Gehört der Server einem Dienstleister oder läuft die Anwendung in einer fremden Cloud, braucht es dessen Zustimmung zusätzlich.
Prüfrhythmus
Wie oft prüfen, und nach welchen Änderungen
Der Scan begleitet den Betrieb, der Pentest folgt Anlässen. Ein eingerichteter Scan kostet je Lauf wenig Zeit. Lassen Sie ihn regelmäßig und nach jeder Auslieferung laufen, damit eine neu bekannt gewordene Lücke in einer Bibliothek schnell auffällt.
Einen Pentest planen Sie für bestimmte Anlässe:
vor dem ersten Start einer Anwendung mit Konten, Zahlungen oder personenbezogenen Daten,
nach neuen Rollen, Mandanten oder Freigabe-Abläufen,
nach Änderungen an Anmeldung, Passwortrücksetzung oder Sitzungen,
nach einer neuen öffentlichen Schnittstelle,
nach einem Umzug zu einem anderen Hoster oder einem großen Versionssprung des Frameworks,
wenn ein Kunde, eine Versicherung oder eine Prüfung einen aktuellen Bericht verlangt.
Ohne solche Anlässe ist ein fester Abstand sinnvoll, zum Beispiel jährlich bei Anwendungen mit sensiblen Daten, weil auch an einer unveränderten Anwendung neue Angriffstechniken ausprobiert werden.
Befundbericht
Was Sie mit dem Bericht anfangen
Ein Pentest-Bericht ist vor allem eine Arbeitsliste für die Behebung. Das BSI empfiehlt, ihn mit Prüfobjekt und Prüfbedingungen zu beginnen, dann eine Zusammenfassung für die Geschäftsleitung zu bringen und danach die Befunde für die Technik. Für die Bewertung nennt es verbreitete Standards wie CVSS und ordnet Befunde in vier Stufen:
hoch: sofort beheben, etwa wenn Daten ausgelesen oder verändert werden können,
mittel: kurzfristig beheben,
niedrig: mittelfristig beheben,
zur Information: langfristig als Verbesserung einplanen.
Machen Sie aus jedem Befund ein Ticket mit verantwortlicher Person und Datum, und vereinbaren Sie den Nachtest gleich mit. Halten Sie den Bericht vertraulich, denn er beschreibt den Weg in Ihr System. Und lesen Sie die Einschränkung, die das BSI für jeden Vertrag empfiehlt: Ergebnisse gelten für den Zeitpunkt der Prüfung, und es ist nicht gewährleistet, dass alle Fehler gefunden wurden.
Sind Prüfungen von außen Pflicht, etwa für einen Großkunden, koordinieren wir externe Pen-Tester und begleiten den Prozess von der Beauftragung bis zur Abarbeitung der Befunde, wie auf unserer Seite zu Sicherheit und Compliance beschrieben.
Scan oder Pentest für Ihre Anwendung?
Mit der Vorlage oben ist der Prüfauftrag zur Hälfte geschrieben. Prüfumfang je Rolle, Auswahl der Prüfer und die Abarbeitung der Befunde klären wir gern mit Ihnen.
Vor dem Auftrag
Häufige Fragen
-
Der Preis ergibt sich aus Prüftagen mal Tagessatz plus Tagen für Bericht und Nachtest, und die Prüftage hängen an der Zahl der Rollen, Oberflächen und Schnittstellen. Ein Rechenweg mit Annahmen, keine Marktangabe: vier Prüftage und ein Tag Bericht ergeben fünf Tage, bei einem angenommenen Tagessatz von 1.200 Euro also 6.000 Euro. Lassen Sie sich Tage je Prüfbereich nennen, um Angebote zu vergleichen.
-
Ein Gesetz, das kleinen Unternehmen allgemein einen Pentest vorschreibt, gibt es nicht. Art. 32 DSGVO verlangt aber ein Verfahren zur regelmäßigen Überprüfung der Wirksamkeit Ihrer Schutzmaßnahmen, und ein Pentest ist ein Weg, diese Überprüfung zu belegen. Einen aktuellen Bericht verlangen außerdem manche Großkunden oder Versicherer in ihren Verträgen.
-
Prüfen darf, wer die schriftliche Erlaubnis des Berechtigten hat, eine geschützte Berufsbezeichnung gibt es nicht. Als Qualitätsnachweis zertifiziert das BSI einzelne Penetrationstester und führt eine Liste zertifizierter Dienstleister für IS-Penetrationstests. Fragen Sie außerdem nach einem Musterbericht und danach, wer die Prüfung tatsächlich durchführt.
Nachweise
Quellen und Stand
Stand: 14.05.2026. Die Hinweise zu Strafrecht und Datenschutz beschreiben den Stand zu diesem Datum und sind keine Rechtsberatung. Der Preis in der Antwort zu den Kosten beruht auf Annahmen.
BSI: Ein Praxis-Leitfaden für IS-Penetrationstests, Version 1.2 (November 2016)
BSI: Liste zertifizierter IT-Sicherheitsdienstleister im Geltungsbereich IS-Penetrationstests
OWASP Web Security Testing Guide v4.2: Introduction to Business Logic
§ 202c StGB Vorbereiten des Ausspähens und Abfangens von Daten, gesetze-im-internet.de
BMJ, seit 2025 BMJV: Referentenentwurf zur Modernisierung des Computerstrafrechts (November 2024)
MARCODES Case Study: REST-API und HR-Frontend für ein internes Tools-Portal
Weiterlesen: Patch-Disziplin: Warum kleine Updates großen Schaden verhindern vom 23.05.2026 und OWASP Top 10 2025 vom 12.10.2026.
Artikel teilen