Begriff
PTaaS (Penetration Testing as a Service)
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Früher: Einmal im Jahr kamen teure Consultants ("Pentester"). Sie hackten 2 Wochen lang deine Firma. Sie schrieben ein PDF (300 Seiten). Du fixt die Bugs. Dann wartest du ein Jahr. In der Zeit machst du 100 Releases -> Du bist wieder unsicher. PTaaS macht Pentesting kontinuierlich. Es ist eine Plattform. Du startest einen Pentest (auf Knopfdruck oder API). Eine Community von Testern (weltweit) hackt dich sofort. Die Ergebnisse landen in Echtzeit in deinem Jira/Ticket-System. Du fixt, sie re-testen sofort.
Merksatz: Ein Bereitstellungsmodell für Penetrationstests, das traditionelle manuelle Tests durch eine SaaS-Plattform mit kontinuierlichen Scans, on-demand menschlichen Testern und Echtzeit-Reporting in den DevOps-Workflow integriert.
Anbieter: Cobalt, Synack, HackerOne. Du integrierst es in CI/CD. "Nach jedem Major Release -> Starte Pentest." Es kombiniert Scanner (automatisch) mit echten Hackern (manuell, kreativ).
1. Das Zeit-Problem
Klassische Pentests sind "Point-in-Time" Momentaufnahmen. PTaaS ist "Continuous". Sicherheitslücken leben oft nur Stunden (bis zum Patch). PTaaS schließt das Fenster der Verwundbarkeit.
2. Integration
Der Report ist kein PDF mehr. Es ist ein Finding in der Web-UI. Mit "Chat-Funktion" zum Hacker ("Wie hast du das gemacht?"). Mit "Re-Verify" Button ("Ich hab's gefixt, prüf nochmal").
1. API Pentesting: OWASP Top 10 API
In der Produktion ist meist nicht die Website das Ziel, sondern die API.
PTaaS spezialisiert sich oft auf die OWASP Top 10 API.
Hacker suchen gezielt nach BOLA (Broken Object Level Authorization): Kann ich durch Ändern der ID in der URL (/api/order/500 -> /api/order/501) die Bestellung eines anderen Kunden sehen?
Diese logischen Fehler findet kein automatischer Scanner der Welt. PTaaS-Services bieten hierfür spezialisierte "Security-Champions", die die Business-Logik der App verstehen und nach kreativen Wegen suchen, diese zu bypassen.
2. Infrastructure as Code (IaC) Scanning
Moderne PTaaS-Plattformen "hacken" nicht nur die laufende App, sondern auch die Git-Repositories. Sie prüfen Terraform- oder CloudFormation-Skripte auf Fehlkonfigurationen (z.B. offene S3-Buckets oder zu weite Sicherheitsgruppen), bevor diese überhaupt deployed werden. Das ist das "Shift-Left" Prinzip: Sicherheit wird Teil der Build-Pipeline. Ein Finding im PTaaS-Portal kann so einen Pull Request automatisch blockieren.
3. RBAC & Multi-Tenancy Testing
Bei großen Enterprise-Anwendungen ist das größte Risiko die Rollen-Eskalation. Ein PTaaS-Team erhält oft zwei Test-Accounts: Einen "User" und einen "Admin". Sie versuchen systematisch, Funktionen des Admins mit dem User-Token zu triggern. In PTaaS-Berichten findet man oft komplexe Angriffspfade (Chain of Vulnerabilities): "Ich nutze Bug A, um ein CSRF-Token zu stehlen, dann Bug B (SQL Injection), um meine Rolle auf Admin zu pushen." Die Visualisierung dieser Ketten in der PTaaS-UI hilft Entwicklern, nicht nur Symptome zu heilen, sondern die Architektur zu härten.
Quick-Check
Sind das automatisierte Scanner?
Nein! Scanner (Nessus) finden nur Dummes. PTaaS nutzt Menschen (Ethical Hackers), die logische Fehler finden ("Ich kann Pizza bestellen und -10 Euro bezahlen"). Die Plattform organisiert nur den Prozess.Teuer?
Ja (Abo-Modell). Aber oft billiger als ein eigener interner Pentester ode ein großer Hack.Bug Bounty?
Ähnlich. Bug Bounty ist "Public" (jeder darf). PTaaS ist "Private" (vetted Tester, oft auf Stundenbasis oder per Finding bezahlt, aber strukturierter).