Product Penetration Testing
Penetrationstest der Software und Infrastruktur, die Teil des Produkts sind. Web- und Mobile-Applikationen, APIs, Cloud-native-Backends, Kubernetes, Management-Schnittstellen und Netzwerkdienste.
Wir folgen Angriffspfaden über Applikations-, Identitäts-, Backend- und Infrastruktur-Grenzen, statt jede Komponente als isoliertes Testziel zu behandeln.
Ein Produkt. Mehrere Applikations- und Infrastruktur-Grenzen.
Produkt-Sicherheit endet selten am Frontend. Authentisierungsentscheidungen in einer API können Backend-Dienste betreffen. Ein kompromittierter Applikations-Account kann Verwaltungsfunktionen freilegen. Kubernetes-Identitäten und Secrets können einen Applikationsfehler zu Infrastruktur-Zugang machen.
Was wir testen
Applikationen
Web-Applikationen, Mobile-Applikationen, Management-Schnittstellen, privilegierte Produktfunktionen und Client-Seitige-Trust-Annahmen.
APIs & Autorisierung
Authentisierung, Autorisierung, Objektzugriff, Privilegien-Grenzen, Geschäftslogik und Management-APIs.
Identität & Session-Trust
Sessions, Tokens, Geräte-/Nutzer-Identität, Federation, Service-Identitäten, Rollenmodelle und Privilegien-Übergänge.
Backend-Dienste
Produktdienste, interne APIs, Message-Flows, Service-zu-Service-Vertrauen und Backend-Geschäftslogik.
Kubernetes & Cloud-native Runtime
RBAC, Service-Accounts, Workload-Identity, Namespace-Grenzen, exponierte Dienste und Wege von der Applikation in die Runtime.
Secrets & Netzwerkdienste
Credentials, Tokens, Secret-Exposition, Management-Ports, Netzwerkprotokolle und Infrastrukturdienste, die Teil des Produkts sind.
Die konkrete Prüffläche folgt der Produktarchitektur. Nicht jedes Assessment braucht jede Schicht.
Die spannenden Befunde liegen oft zwischen Komponenten.
Applikation → API → Administration
Ein Applikations-Account mit niedrigen Rechten erreicht eine API-Operation, die eine Verwaltungsfunktion freilegt, die nur Administratoren zugedacht ist.
API → Identität → Backend
Eine Autorisierungsschwäche erlaubt Zugriff auf einen anderen Mandanten oder eine andere Produktinstanz. Backend-Vertrauen macht aus einem API-Fehler eine mandantenübergreifende Auswirkung.
Applikation → Kubernetes → Secrets
Eine Kompromittierung der Applikation erreicht eine Workload-Identity mit überhöhten Rechten. Der ursprüngliche Applikationsfehler wird zum Zugriff auf Produkt-Secrets oder interne Dienste.
Der Umfang folgt der Produktarchitektur.
Architektur
Applikationen, APIs, Backend-Dienste, Identitätssysteme, Kubernetes, Netzwerkdienste und für das Produkt relevante externe Abhängigkeiten.
Angreifer-Annahmen
Unauthentisierter Nutzer, authentifizierter Kunde, Account mit niedrigen Rechten, kompromittierter Client, Netzwerkzugang oder eine andere vereinbarte Startposition.
Technische Tiefe
Wir wählen die Angriffspfade und Testmethoden, die die tatsächliche Produkt-Sicherheitsfrage beantworten, statt das System in unzusammenhängende Testpakete zu zerlegen.
Ein vollständiges Architektur-Paket ist vor dem ersten Gespräch nicht erforderlich.
Was Sie erhalten
Reproduzierbare Befunde
Schritte, Requests, Nachweise und betroffene Komponenten, ausreichend, damit Engineering-Teams das Problem reproduzieren können.
Technische Auswirkung
Was die Schwäche unter den vereinbarten Angreifer-Annahmen ermöglicht.
Attack-Path-Kontext
Wie Applikations-, API-, Identitäts- und Infrastruktur-Schwächen im Produkt zusammenwirken.
Remediation & Retest
Technischer Remediation-Kontext und Verifikation der Fixes gegen den ursprünglichen Angriffspfad, soweit Retesting im Umfang liegt.
- ACCESS
- authentifizierter Produkt-Nutzer
- PATH
- API → Backend-Dienst → Workload-Identity → Secrets
- IMPACT
- Zugriff auf Service-Credentials
- STATUS
- reproduzierbar
Wann dieses Assessment passt
Soll das Assessment eine regulatorische Anforderung stützen?
Wo erforderlich, lassen sich Assessment-Umfang und Befunde auf relevante technische Anforderungen aus CRA, EN 18031 und IEC 62443 mappen.
Vom Fund zum nachweisbaren Angriffspfad.
Ein Pentest-Befund reicht uns dann, wenn er am Gerät hält: reproduzierbar, mit klaren Bedingungen und technischer Auswirkung. Dafür läuft das Gerät bei uns am Prüfstand, seine Schnittstellen werden gezielt angegangen und die Firmware dort analysiert, wo der Schutz sie nicht zurückhält.
Die Lab-Methodik entspricht der unseres Assessments, vertieft auf die Angriffsseite. Was dabei im Einzelnen passiert, steht bei Leistung 01; entscheidend ist hier nur der Anspruch: Ein Befund wird erst berichtet, wenn er am Produkt standhält.
Dr. Ewan Fleischmann
22+ Jahre IT-Security · PhD Kryptografie · OSCP · OSCE · CISSP
Sie bauen ein Produkt, das ernsthaften Security-Testing braucht?
Sagen Sie uns, was Sie bauen, in welcher Phase es steht und was getestet werden soll. Der Umfang folgt aus dem Produkt.