Offensive Sicherheit für SaaS und digitale Produkte.
Bei SaaS ist Sicherheit kein Infrastrukturthema mehr, sondern eine Vertragsklausel. Der Unternehmenskunde prüft vor der Unterschrift, der Investor fragt in der Due Diligence. Wir testen das Produkt mit beiden Blickwinkeln.
Die Schwachstelle, die den Vertrag kostet
In einem mandantenfähigen Produkt entscheidet eine Frage alles: Kann ein Kunde die Daten eines anderen sehen? Lautet die Antwort auf irgendeinem Weg ja, zählt der Rest wenig. Der Druck auf Liefergeschwindigkeit, verbunden mit Berechtigungsmodellen, die durch Hinzufügen wachsen und nie ganz überprüft werden, lässt diese Fehlerklasse weit häufiger auftreten als erwartet.
- Mandantentrennung ist die Anforderung, die keine Ausnahme zulässt.
- Das Berechtigungsmodell wächst durch Hinzufügen und wird selten vollständig geprüft.
- Anbindungen, Webhooks und API-Token erweitern die Angriffsfläche mit jedem Release.
- Der Unternehmensverkauf stockt ohne Nachweis unabhängiger Prüfung.
Was wir in einem SaaS-Produkt prüfen
Wir greifen das Produkt als bösartiger Kunde an, der das Abonnement bereits bezahlt hat, denn das ist das wahrscheinlichste Szenario.
Systematischer Versuch, über Kennungen, Parameter, Export, Suche und Cache an Daten eines anderen Mandanten zu gelangen. Das ist der zentrale Test.
Anmeldung, SSO, zweiter Faktor, Sitzungsablauf, Nutzereinladungen und welcher Zugang bleibt, nachdem jemand aus dem Team entfernt wurde.
Rollen, Geltungsbereiche und Vererbung: ob ein eingeschränkter Nutzer über einen direkten API-Aufruf administrative Funktionen erreicht.
Token-Geltungsbereich, Widerruf, Anfragebegrenzung und Datenexposition über das Notwendige hinaus in den Antworten.
Signaturprüfung, Schutz vor Wiedereinspielung und Anfragen, die Ihr Backend an vom Kunden angegebene Ziele richtet.
Von Nutzern gesendete Dateien: Typ, Ablage, Isolation der Verarbeitung und Inhaltszugriff über vorhersagbare URLs.
Nachweise, die Verkauf und Finanzierungsrunde freimachen
Das Material ist für die beiden Adressaten aufbereitet, die es anfordern werden: das Sicherheitsteam Ihres Kunden und die Due-Diligence-Seite des Investors.
- Lieferantenfragebögen
- Das Bestätigungsschreiben beantwortet die Frage nach unabhängigen Penetrationstests, die in nahezu jedem Sicherheitsfragebogen auftaucht.
- ISO 27001 und SOC 2
- Beide Programme verlangen regelmäßige Tests als Kontrolle. Der Bericht dient als Nachweis in diesem Zyklus, ersetzt aber das Audit nicht.
- Auftragsverarbeitung
- Als Auftragsverarbeiter der Daten Ihrer Kunden haften Sie vertraglich. Wir dokumentieren die Exposition je Mandant, den vom Vertrag geforderten Zuschnitt.
- Technische Due Diligence
- In einer Runde oder Übernahme wirkt ein aktueller Test mit umgesetztem Behebungsplan zu Ihren Gunsten und vermeidet Risikoabschläge.
Wie wir neben einem kleinen Team arbeiten
Zuerst die Abnahmeumgebung
Wo eine Replik existiert, beginnen wir dort. Das erlaubt aggressiveres Testen und hält echte Kundendaten aus dem Weg.
Kontrollierte Testmandanten
Wir legen mindestens zwei Testmandanten mit unterschiedlichen Daten an. Die Trennung wird bewiesen, indem wir diese Grenze auf jede mögliche Weise zu überschreiten versuchen.
Kritischer Befund sofort gemeldet
Ein Trennungs- oder Authentifizierungsfehler wartet nicht auf den Bericht: Er geht direkt heraus, sobald er bestätigt ist, damit Sie ihn am selben Tag beheben können.
Behebung im Release-Zyklus
Der Plan ist so geschnitten, dass er in einen Sprint passt, und der Nachtest erfolgt nach dem Deployment, ohne die Roadmap anzuhalten.
Was Sie erhalten
- Managementbericht für Board und Kunden
- Reproduzierbarer technischer Bericht
- Eigener Test der Mandantentrennung
- Prüfung des Berechtigungsmodells
- Begründete CVSS-Bewertung
- Sofortmeldung kritischer Befunde
- Nachtest nach dem Deployment
- Bestätigungsschreiben für die Due Diligence
Häufige Fragen zur Branche
Können Sie testen, ohne echte Kundendaten zu berühren?
+
In den meisten Fällen ja. Wir bevorzugen eine Abnahmeumgebung mit synthetischen Daten, in der wir ohne Risiko aggressiver vorgehen können. Muss in der Produktion getestet werden, legen wir eigene Mandanten an und beschränken die Aktivität darauf, innerhalb vereinbarter Volumengrenzen.
Wie lange dauert ein Projekt für ein SaaS-Produkt?
+
Das hängt von der Größe der Angriffsfläche ab: Zahl der Rollen, Umfang der API und Menge der Anbindungen. Der Umfang wird nach einem kurzen fachlichen Gespräch über diese drei Achsen festgelegt. Unverändert bleibt die Methode: manuelle Ausnutzung, jeder Befund vor dem Bericht verifiziert.
Beantwortet der Bericht den Sicherheitsfragebogen des Kunden?
+
Ja, das ist eine der häufigsten Verwendungen. Das Bestätigungsschreiben belegt, dass eine unabhängige Prüfung stattgefunden hat, mit Umfang und Zeitraum, ohne ausnutzbare Details, also genau das, was der Fragebogen verlangt. Den vollständigen technischen Bericht teilen Sie nur, wenn Sie möchten, und unter Vereinbarung.
Was, wenn Sie mitten im Test einen kritischen Fehler finden?
+
Sie werden sofort über einen direkten Kanal informiert, mit allem, was zur Behebung am selben Tag nötig ist. Kritische Befunde halten wir nicht bis zum Projektende zurück. Nach der Behebung testen wir erneut und halten den geschlossenen Zyklus im Abschlussbericht fest.