Wann braucht Software einen Penetrationstest?

Ein Kundenportal geht live, eine mobile App erhält Zugriff auf sensible Daten oder eine bestehende Anwendung wird an SAP, Zahlungsdienstleister und weitere APIs angebunden. Spätestens dann stellt sich die Frage: Wann braucht Software einen Penetrationstest? Die kurze Antwort lautet: bevor ein Sicherheitsfehler geschäftskritisch wird. Der richtige Zeitpunkt hängt jedoch nicht allein vom Go-live ab, sondern von Risiko, Architektur, Datenverarbeitung und Veränderungstempo.

Ein Penetrationstest ist keine formale Abnahme mit Häkchenliste. Er simuliert gezielt Angriffe auf eine Anwendung, ihre Schnittstellen und oft auch ihre Infrastruktur. Ziel ist, Schwachstellen zu finden, die unter realistischen Bedingungen ausnutzbar sind - und ihre Folgen für Betrieb, Daten und Geschäftsprozesse verständlich zu bewerten.

Wann braucht Software einen Penetrationstest?

Ein Pentest ist besonders sinnvoll, wenn eine Anwendung eine sicherheitsrelevante Grenze überschreitet. Das kann der Wechsel von einer internen Lösung zu einem extern erreichbaren Portal sein, aber auch eine neue Integration oder ein geänderter Berechtigungsprozess. Entscheidend ist nicht, ob die Software groß oder klein ist. Entscheidend ist, welchen Schaden ein erfolgreicher Angriff verursachen könnte.

Bei individuell entwickelter Software sollte ein Penetrationstest vor dem produktiven Einsatz eingeplant werden, wenn Nutzerkonten, personenbezogene Daten, vertrauliche Dokumente, Zahlungsinformationen oder geschäftskritische Funktionen verarbeitet werden. Beispiele sind Self-Service-Portale, SaaS-Produkte, B2B-Plattformen, Apps mit Login sowie Systeme zur Steuerung interner Prozesse.

Auch nach dem Go-live bleibt der Test relevant. Software verändert sich: Neue Features kommen hinzu, Abhängigkeiten werden aktualisiert, APIs werden geöffnet und Cloud-Konfigurationen angepasst. Jede dieser Änderungen kann Annahmen aus dem ursprünglichen Sicherheitskonzept ungültig machen.

Typische Auslöser für einen Penetrationstest sind:

• der Launch einer öffentlich erreichbaren Web-Anwendung oder mobilen App,
• wesentliche neue Funktionen wie Bezahlprozesse, Datei-Uploads oder Rollen- und Rechteverwaltung,
• neue Schnittstellen zu SAP, CRM, Identity-Providern, Partnern oder KI-Diensten,
• Migrationen in die Cloud, Wechsel von Hosting-Modellen oder Änderungen an Netzwerken und Zugriffsregeln,
• Sicherheitsvorfälle, auffällige Logdaten oder konkrete Hinweise auf eine Schwachstelle.

Bei Anwendungen mit hoher Änderungsfrequenz ist ein Pentest nicht nach jedem einzelnen Release wirtschaftlich. Sinnvoller ist eine risikobasierte Planung: Automatisierte Prüfungen begleiten die Entwicklung kontinuierlich, während ein manueller Penetrationstest vor größeren Releases, Architekturwechseln und besonders kritischen Produktphasen erfolgt.

Vor dem Go-live testen, nicht erst nach dem Vorfall

Der häufigste und meist sinnvollste Zeitpunkt ist kurz vor dem Produktivstart. Zu diesem Zeitpunkt stehen die wesentlichen Funktionen, Schnittstellen und Berechtigungsmodelle fest. Gleichzeitig bleibt noch ausreichend Zeit, kritische Findings vor dem ersten echten Nutzerzugriff zu beheben.

Zu früh angesetzte Tests haben einen Nachteil: Werden zentrale Funktionen danach stark verändert, verliert ein Teil der Ergebnisse an Aussagekraft. Zu spät angesetzte Tests sind ebenfalls problematisch. Wenn Vertrieb, Fachbereiche oder externe Kunden bereits auf den Launch warten, geraten notwendige Korrekturen schnell unter Zeitdruck.

In der Praxis bewährt sich ein zweistufiges Vorgehen. Bereits während der Konzeption und Entwicklung werden Architektur, Bedrohungen und Sicherheitsanforderungen geprüft. Der eigentliche Pentest folgt auf einer release-nahen Umgebung, die Produktivsystem und Konfiguration möglichst realistisch abbildet. Kritische Befunde werden behoben und anschließend gezielt nachgetestet.

Das gilt auch für mobile Anwendungen. Eine iOS- oder Android-App ist nur so sicher wie ihr Zusammenspiel mit Backend, API, Authentifizierung und Datenhaltung. Wer ausschließlich den Client testet, übersieht oft die relevanteren Angriffspunkte im Backend.

Besonders kritisch: Identitäten, APIs und Berechtigungen

Viele Sicherheitsvorfälle entstehen nicht durch spektakuläre technische Lücken, sondern durch fehlerhafte Autorisierung. Ein Nutzer kann beispielsweise über eine API auf Datensätze anderer Mandanten zugreifen, weil das Backend zwar prüft, ob ein Login vorliegt, nicht aber, ob genau dieser Nutzer auf diese Ressource zugreifen darf.

Ein Penetrationstest untersucht deshalb nicht nur bekannte Schwachstellen in Frameworks oder Bibliotheken. Er prüft auch die Geschäftslogik: Lassen sich Rabatte manipulieren? Können Genehmigungsprozesse umgangen werden? Ist eine Rolle nur in der Oberfläche verborgen, während die API weiterhin Zugriff erlaubt? Werden Tokens, Sessions und Passwörter korrekt behandelt?

Das ist besonders relevant für Multi-Tenant-SaaS-Lösungen, Portale mit Kunden- oder Lieferantenzugriff, interne Anwendungen mit differenzierten Rollen und Systeme mit Schnittstellen zu führenden Unternehmensdaten. Je stärker Prozesse integriert sind, desto größer kann die Auswirkung eines Berechtigungsfehlers sein.

Auch KI-Funktionen erweitern die Angriffsfläche. Sobald ein Chatbot oder KI-Agent auf Dokumente, Wissensdatenbanken oder Unternehmenssysteme zugreift, müssen Zugriffskonzept, Datenabgrenzung und mögliche Manipulationen von Eingaben geprüft werden. Ein Pentest ersetzt dabei keine fachliche KI-Risikobewertung, ergänzt sie aber um die technische Perspektive auf APIs, Berechtigungen und Datenflüsse.

Compliance ist ein Anlass, aber nicht der einzige Grund

Datenschutzrechtliche, vertragliche oder branchenspezifische Anforderungen können einen Penetrationstest erforderlich machen. Kunden fordern ihn häufig im Rahmen von Lieferantenaudits, Ausschreibungen oder Sicherheitsfragebögen. Auch bei KRITIS-nahen Organisationen, Finanzdienstleistungen, Gesundheitsdaten oder öffentlichen Einrichtungen gelten meist erhöhte Erwartungen an den Sicherheitsnachweis.

Die DSGVO schreibt nicht pauschal für jede Software einen Pentest vor. Sie verlangt jedoch angemessene technische und organisatorische Maßnahmen, orientiert am Risiko der Verarbeitung. Bei einer Anwendung mit sensiblen personenbezogenen Daten kann ein dokumentierter Sicherheitsprozess einschließlich Pentest daher ein wichtiger Baustein sein. Er zeigt, dass Risiken nicht nur theoretisch beschrieben, sondern praktisch geprüft wurden.

Wichtig ist die Einordnung: Ein einzelner Test schafft keine dauerhafte Compliance und keine vollständige Sicherheit. Er liefert eine Momentaufnahme unter klar definierten Rahmenbedingungen. Für belastbare Sicherheit gehören sichere Entwicklung, Code Reviews, Dependency-Management, Monitoring, Patch-Prozesse, Backup- und Berechtigungskonzepte ebenso dazu.

Was ein guter Pentest leisten muss

Ein aussagekräftiger Test beginnt mit einem klaren Scope. Welche Anwendungen, Domains, APIs, mobilen Clients, Cloud-Komponenten und Nutzerrollen werden geprüft? Ist der Test unauthentifiziert, mit normalen Nutzerrechten oder mit privilegierten Rollen geplant? Ohne diese Festlegungen lässt sich ein Ergebnis kaum einordnen.

Ebenso wichtig ist die Testtiefe. Ein automatisierter Schwachstellenscan kann bekannte Sicherheitslücken schnell erkennen und gehört in viele Entwicklungs- und Betriebsprozesse. Er ersetzt jedoch keinen manuellen Pentest. Automatisierung versteht nur begrenzt, ob eine Rechteprüfung fachlich korrekt ist, ob mehrere kleine Fehler zusammenspielen oder ob sich ein Prozess missbrauchen lässt.

Der Bericht sollte daher nicht bei einer technischen Liste enden. Entscheider benötigen eine nachvollziehbare Risikoeinschätzung: Was kann ein Angreifer konkret erreichen? Welche Daten oder Prozesse sind betroffen? Wie hoch ist die Priorität? Welche Maßnahme behebt die Ursache? Gute Berichte unterscheiden sauber zwischen kritischen, hohen, mittleren und niedrigen Risiken und dokumentieren auch positive Grenzen des Tests.

Für Entwicklungsteams sind reproduzierbare Schritte, betroffene Endpunkte und konkrete Hinweise zur Behebung entscheidend. Nach der Umsetzung folgt ein Retest der kritischen Befunde. Erst damit ist nachweisbar, dass eine Schwachstelle nicht nur verstanden, sondern wirksam geschlossen wurde.

Pentests als Teil des Produktlebenszyklus planen

Die Frage ist weniger, ob ein Penetrationstest einmal durchgeführt werden sollte, sondern wie er zum Entwicklungs- und Betriebsmodell passt. Für ein Kundenportal mit wenigen, stabilen Releases kann ein Test vor dem Launch und nach wesentlichen Änderungen ausreichen. Für ein SaaS-Produkt mit vielen Releases, externen Integrationen und wachsender Nutzerzahl braucht es einen wiederkehrenden Rhythmus, ergänzt durch kontinuierliche technische Prüfungen.

Dabei lohnt es sich, Sicherheit früh in Architektur und Backlog zu verankern. Werden Rollenmodelle, Mandantentrennung, Protokollierung, Secrets-Management und Update-Strategien erst kurz vor dem Go-live diskutiert, steigen Aufwand und Projektrisiko. Werden sie von Anfang an mitgeplant, bleibt der Pentest das, was er sein soll: eine wirksame Qualitätskontrolle unter Angriffsbedingungen, nicht eine teure Notfallmaßnahme.

Für Unternehmen ist ein Penetrationstest damit vor allem eine fundierte Entscheidungsgrundlage. Er macht sichtbar, wo technischer Handlungsbedarf besteht, bevor Vertrauen, Daten oder Geschäftsprozesse betroffen sind. Wer ihn an reale Veränderungen und Risiken koppelt, schafft eine Sicherheitsroutine, die mit dem digitalen Produkt mitwächst.