SaaS-Security-Audit vs. Penetrationstest: Was beide abdecken und welchen du brauchst
Die meisten Anfragen für ein SaaS-Security-Audit beginnen gleich. Ein Enterprise-Interessent hat einen Fragebogen geschickt, ein Anwalt hat um "Nachweis von Sicherheitstests" gebeten, oder ein Gründer ist nervös geworden, nachdem er von einem Datenleck bei einem Unternehmen mit ähnlichem Stack gelesen hat. Die E-Mail, die dann ankommt, lautet: "Wir brauchen ein Security-Audit, kannst du auch einen Pen-Test machen, oder ist das dasselbe?"
Es ist nicht dasselbe, und der Unterschied ist wichtig dafür, was du bezahlst, was du zurückbekommst, und ob das Ergebnis die Person zufriedenstellt, die danach gefragt hat. Dieser Beitrag trennt die beiden, erklärt, wann welcher Kauf richtig ist, und geht durch, was ein Security-Audit einer SaaS-Anwendung abdeckt, wenn es ordentlich gemacht wird.
Die Kurzfassung
Ein Security-Audit ist eine Überprüfung. Jemand liest deinen Code, deine Konfiguration, deine Zugriffskontrollen und deine Prozesse und sagt dir, wo sie hinter dem zurückbleiben, was ein gut geführtes System haben sollte. Der Auditor muss nicht einbrechen, um dir zu sagen, dass deine Passwort-Reset-Tokens nie ablaufen. Das sieht er im Code.
Ein Penetrationstest ist ein Angriff. Ein Tester bekommt ein Ziel, einen Scope und ein Zeitfenster und versucht, einzudringen. Das Ergebnis ist eine Liste von Dingen, die er geschafft hat, obwohl er es nicht können sollte, mit Nachweis.
Beide sind nützlich. Sie beantworten unterschiedliche Fragen. Ein Audit beantwortet "wie gut ist dieses System gebaut und betrieben, und wo sind die Schwachstellen?" Ein Pen-Test beantwortet "kann ein motivierter Angreifer mit so viel Zeit und diesem Zugriffslevel an dem vorbeikommen, was ihr gebaut habt?"
Was ein SaaS-Security-Audit abdeckt
Ein Audit ist bewusst breit angelegt. Der Punkt ist, jede Schicht zu betrachten, auf der ein SaaS-Produkt typischerweise Daten verliert oder Zugriff gewährt, den es nicht gewähren sollte. Für eine Symfony- oder Next.js-Anwendung sind die folgenden Bereiche die, die in fast jedem Engagement auftauchen.
Authentifizierung und Session-Management
Wie Nutzer beweisen, wer sie sind, und wie das System sich das merkt. Das Audit prüft Passwort-Hashing (bcrypt oder argon2id mit sinnvollen Cost-Parametern), Rate-Limiting bei Login und Passwort-Reset, Token-Ablauf und -Rotation, Schutz vor Session-Fixation und ob "Angemeldet bleiben"-Cookies korrekt begrenzt und signiert sind. Multi-Faktor-Unterstützung und ihr Recovery-Flow werden ebenfalls geprüft, denn Recovery ist der Punkt, an dem die meisten MFA-Implementierungen auseinanderfallen.
Autorisierungslogik
Das ist der Abschnitt, der die schwerwiegendsten Probleme in SaaS-Produkten findet, und der, bei dem automatisierte Scanner am schlechtesten sind. Kann Nutzer A die Rechnung von Nutzer B lesen, indem er eine ID in der URL ändert? Kann ein Mitglied eines Mandanten Daten eines anderen sehen? Passiert die Admin-Rollen-Prüfung auf dem Server, oder nur in der React-Komponente, die den Button versteckt? In einem Code-Audit liest der Reviewer die Voter, die Middleware und die Query-Schicht, um zu sehen, wo Mandantentrennung durchgesetzt wird und wo sie nur angenommen wird. In KI-unterstützten Codebasen rechtfertigt allein dieser Abschnitt oft das ganze Engagement. Wir haben über dieses Muster geschrieben in vibe-codierte API-Zugriffskontrolllücken absichern, die KI-Assistenten übersehen.
API-Sicherheit
Eingabevalidierung an der Grenze, Ausgabe-Encoding, Schutz vor Mass Assignment bei Schreib-Endpunkten, korrekte Nutzung von HTTP-Methoden, CORS-Konfiguration, und ob interne Endpunkte von außen erreichbar sind. Für öffentliche APIs schaut das Audit auch darauf, wie API-Keys ausgestellt, gespeichert, rotiert und widerrufen werden.
Abhängigkeits- und Supply-Chain-Review
Welche Pakete installiert sind, welche bekannte Schwachstellen haben, welche verwaist sind, und ob die Lockfile im Build tatsächlich verwendet wird. Composer Audit und npm Audit sind der Ausgangspunkt. Der nützlichere Teil ist zu prüfen, ob die Build-Pipeline Versionen pinnt, Integrität verifiziert und bemerken würde, wenn sich eine Abhängigkeit unter ihr verändert.
Secrets-Management
Wo Zugangsdaten liegen. Die klassischen Funde sind eine .env-Datei, die vor drei Jahren ins Repository committet wurde und immer noch in der Historie steckt, Datenbankpasswörter in Docker-Compose-Dateien, und API-Keys hartcodiert in einem Client-Bundle, wo jeder sie im Browser auslesen kann. Das Audit prüft auch, wie Secrets in Produktion gelangen: Umgebungsvariablen, ein Vault, oder von Hand auf den Server kopiert.
Datenspeicherung und Verschlüsselung
Was ruhend verschlüsselt ist, was während der Übertragung verschlüsselt ist, und welche personenbezogenen Daten gespeichert werden, die nicht gebraucht werden. Für europäisches SaaS überschneidet sich das stark mit DSGVO-Arbeit: Aufbewahrungsfristen, Löschpfade, und ob Backups Löschanfragen respektieren. Spaltenweise Verschlüsselung für sensible Felder wird geprüft, ebenso das Schlüsselmanagement für diese Verschlüsselung.
Logging und Monitoring
Würdest du ein Datenleck bemerken? Das Audit prüft, ob Authentifizierungsereignisse, Berechtigungsänderungen und Admin-Aktionen protokolliert werden, ob Logs Secrets oder personenbezogene Daten enthalten, die sie nicht sollten, und ob jemand alarmiert würde, wenn ein einzelnes Konto zehntausendmal pro Stunde die API träfe. Fehlendes Logging ist selbst ein Befund.
Infrastruktur und Konfiguration
Offene Ports, TLS-Konfiguration, Security-Header, Cookie-Flags, und ob die Debug-Toolbar oder ein Profiler in Produktion erreichbar ist. In einer Symfony-App gehört dazu APP_ENV, die Firewall-Konfiguration und was die access_control-Regeln erlauben. In Next.js gehört dazu das Verhalten der Middleware und was im Client-Bundle landet.
Prozess
Der letzte Abschnitt handelt nicht vom Code. Wer darf in Produktion deployen? Gibt es einen Review-Schritt? Wie werden Schwachstellen gemeldet und behandelt? Gibt es einen Incident-Plan? Für Teams auf dem Weg zu SOC 2 oder mit NIS2-Pflichten entscheidet dieser Teil, ob die technischen Befunde behoben bleiben.
Was ein Penetrationstest abdeckt
Ein Pen-Test ist enger und tiefer. Der Tester vereinbart mit dir einen Scope (die Web-Anwendung, die öffentliche API, vielleicht die Mobile-App, meist nicht das Büronetzwerk) und ein Zugriffslevel (nicht authentifiziert, ein normales Nutzerkonto, ein Admin-Konto). Dann verbringt er eine feste Anzahl von Tagen damit, konkrete Ziele zu erreichen: Daten eines anderen Mandanten lesen, zu Admin eskalieren, Code auf dem Server ausführen, die Datenbank exfiltrieren.
Die Methodik folgt meist dem OWASP Testing Guide oder einem ähnlichen Rahmenwerk, und ein guter Tester kombiniert automatisiertes Scannen mit manueller Arbeit. Der manuelle Teil ist das, wofür du bezahlst. Scanner finden reflektiertes XSS und veraltetes jQuery. Menschen finden heraus, dass der CSV-Export-Endpunkt einen Mandanten-ID-Parameter akzeptiert, den niemand validiert hat.
Was ein Pen-Test nicht tut, ist dir von Problemen zu erzählen, die der Tester nicht erreicht hat. Wenn er seine drei Tage mit der API verbracht und nie in die Deploy-Pipeline geschaut hat, ist die Pipeline nicht abgedeckt. Ein sauberer Pen-Test bedeutet, dass dein System diesem Tester für diese Zeit in diesem Scope standgehalten hat. Er bedeutet nicht, dass das System gut gebaut ist.
Gegenüberstellung
| Security-Audit | Penetrationstest | |
|---|---|---|
| Ansatz | Review von Code, Konfiguration und Prozess | Simulierter Angriff auf ein laufendes Ziel |
| Breite | Breit, deckt alle Schichten ab | Eng, folgt dem vereinbarten Scope |
| Zugriff | Voller Zugriff auf Quellcode und Infrastruktur | Black Box, Grey Box oder White Box, wie vereinbart |
| Findet | Design-Schwächen, fehlende Kontrollen, schlechte Praktiken | Ausnutzbare Schwachstellen mit Nachweis |
| Übersieht | Ob die Schwäche in der Praxis tatsächlich ausnutzbar ist | Alles außerhalb von Scope oder Zeitfenster |
| Typische Ausgabe | Priorisierte Befunde plus Remediation-Roadmap | Befunde mit Reproduktionsschritten und Schweregrad |
| Bestes Timing | Vor dem Launch, vor der Zertifizierung, nach größeren Änderungen | Vor Enterprise-Onboarding, wenn ein Kunde danach fragt, jährlich |
| Erfüllt | Internes Risikomanagement, SOC-2-Vorbereitung, Due Diligence | Kunden-Sicherheitsfragebögen, Aufsichtsbehörden, vertragliche Anforderungen |
Wann du ein Audit brauchst
Hol dir ein Audit, wenn die Frage lautet "ist dieses System richtig gebaut?" Konkrete Situationen, in denen das die Frage ist:
Du startest bald ein Produkt, das sensible Daten verarbeitet, seien es Gesundheitsdaten, Zahlungsdetails oder Personaldaten, und niemand außerhalb des Teams hat je den Code gesehen. Das Audit ist günstiger als der Vorfall.
Du bereitest dich auf SOC 2, ISO 27001 oder eine ähnliche Zertifizierung vor. Die Zertifizierungsauditoren werden nach Nachweisen fragen, dass Kontrollen existieren. Ein Security-Audit zeigt dir, welche Kontrollen fehlen, bevor du Geld für den Zertifizierungsprozess ausgibst. Wir haben die technische Seite davon in der SOC-2-Type-II-Checkliste behandelt.
Deine Codebasis wurde größtenteils von KI-Coding-Assistenten geschrieben, oder von einem Auftragnehmer, der das Team inzwischen verlassen hat, und du weißt nicht, welche Sicherheitsannahmen getroffen wurden. Der Autorisierungsabschnitt eines Audits ist genau dafür gemacht.
Ein Investor oder Käufer führt eine technische Due Diligence durch. Er will strukturelles Risiko kennen, und ein Pen-Test-Bericht allein beantwortet das nicht. Der Audit-Bericht schon.
Wann du einen Pen-Test brauchst
Hol dir einen Pen-Test, wenn die Frage lautet "kannst du es beweisen?" Situationen:
Der Beschaffungsprozess eines Enterprise-Kunden verlangt einen aktuellen Penetrationstest-Bericht eines Drittanbieters. Das ist der häufigste Auslöser. Meist wollen sie einen, der weniger als zwölf Monate alt ist und die Teile des Produkts abdeckt, die sie nutzen werden. Unser Beitrag zum Enterprise-Sicherheitsfragebogen geht darauf ein, was sie sonst noch fragen werden.
Eine Aufsichtsbehörde oder ein vertragliches Rahmenwerk verlangt adversariales Testen. DORA ist für Fintech-Anbieter explizit bei Threat-led Penetration Testing für bestimmte Unternehmen. PCI DSS verlangt es für Umgebungen mit Karteninhaberdaten.
Du hast eine spezifische Angriffsfläche, die validiert werden soll. Du hast eine neue öffentliche API, eine neue SSO-Integration oder ein neues Datei-Upload-Feature gebaut und willst, dass jemand versucht, es zu brechen, bevor es Kunden tun.
Beides tun, und in welcher Reihenfolge
Erst Audit, dann Pen-Test, ist die Reihenfolge, die am meisten aus dem Budget herausholt. Das Audit findet die strukturellen Lücken: fehlende Mandantentrennung in einer Query-Schicht, Secrets im Repository, kein Rate-Limiting irgendwo. Die behebst du. Dann geht der Pen-Tester gegen ein System vor, das die offensichtlichen Löcher nicht mehr hat, und seine Zeit fließt in das Finden der subtilen Probleme statt in die fünfte Dokumentation desselben fehlenden Rate-Limits.
Einen Pen-Test zuerst gegen ein System auszuführen, das nie überprüft wurde, produziert meist einen langen Bericht über Dinge, die ein Code-Leser in einem Nachmittag gefunden hätte, zu Pen-Test-Tagessätzen.
Manche Anbieter verkaufen ein gebündeltes "Security Assessment", das ein Schwachstellenscan mit Pen-Test-Etikett ist. Das Erkennungsmerkmal ist ein Bericht voller CVE-Nummern und TLS-Cipher-Warnungen ohne Reproduktionsschritte und ohne Nachweis manueller Tests. Wenn der Bericht auch entstanden wäre, indem man ein Tool auf deine Domain gerichtet hätte, ist genau das passiert.
Wie die Audit-Lieferung aussieht
Wenn wir ein Security-Audit als Teil unseres Code-Quality-Consulting durchführen, läuft das Engagement in grob drei Phasen, und der Bericht ist so strukturiert, dass er umgesetzt statt abgeheftet wird.
Discovery dauert ein bis zwei Tage: Zugriff auf Repository und Infrastruktur, ein Architektur-Walkthrough, und ein Gespräch darüber, welche Daten das Produkt verarbeitet und wer die Kunden sind. Ein B2B-Tool, das von drei Enterprise-Kunden genutzt wird, hat ein anderes Risikoprofil als eine Consumer-App mit hunderttausend Konten, und die Review-Prioritäten folgen daraus.
Das Review selbst läuft ein bis zwei Wochen, je nach Codebasisgröße. Tooling läuft zuerst (statische Analyse, Abhängigkeits-Audit, Konfigurations-Scanner), um die mechanischen Befunde zu klären. Der manuelle Durchgang folgt: Authentifizierungs- und Autorisierungscode von Anfang bis Ende lesen, nachverfolgen, wie ein Request eines nicht authentifizierten Nutzers die Datenbank erreicht, jeden Ort prüfen, an dem Mandantenkontext durchgesetzt werden soll, die Deploy-Pipeline und die Produktionskonfiguration überprüfen. Für eine PHP-Anwendung überschneidet sich das mit der allgemeinen Audit-Methodik, die wir nutzen, mit stärker gewichteten Security-Abschnitten.
Der Bericht hat eine Zwei-Seiten-Zusammenfassung, die ein Nicht-Ingenieur lesen kann, dann Befunde gruppiert nach Bereich und nach Schweregrad geordnet. Jeder Befund nennt die Datei und Zeile oder den Konfigurationsschlüssel, erklärt das Risiko in einfachen Worten und gibt eine konkrete Lösung. Kritische und hohe Befunde kommen mit einer Aufwandsschätzung. Der letzte Abschnitt ist eine Remediation-Roadmap: was diese Woche zu beheben ist, was dieses Quartal, und was in den Prozess eingebaut werden sollte, damit dieselbe Problemklasse nicht wiederkommt.
Ein Follow-up-Review der Fixes ist meist Teil des Engagements. Dieses Review ist auch der natürliche Übergabepunkt zu einem Pen-Tester, falls ein Kunde oder eine Aufsichtsbehörde einen braucht.
Häufig gestellte Fragen
Kann ein Security-Audit einen Penetrationstest für einen Kunden-Fragebogen ersetzen?
Meist nicht, wenn der Fragebogen ausdrücklich nach einem Penetrationstest fragt. Manche Kunden akzeptieren einen Audit-Bericht plus Nachweis der Behebung, besonders wenn das Audit einer erkennbaren Methodik gefolgt ist. Frag den Kunden, bevor du das annimmst.
Wie viel kostet ein SaaS-Security-Audit im Vergleich zu einem Pen-Test?
Beide hängen vom Scope ab. Ein Security-Audit einer mittelgroßen SaaS-Anwendung wird typischerweise nach Größe und Komplexität der Codebasis bepreist und läuft ein bis drei Wochen Senior-Engineering-Zeit. Ein Pen-Test wird nach Testtagen und Scope bepreist, meist drei bis zehn Tage. Pen-Test-Tagessätze von Spezialfirmen sind tendenziell höher. Unser Beitrag zu den PHP-Code-Audit-Kosten in Deutschland geht mehr darauf ein, wie Audit-Preise funktionieren.
Unser Code wurde mit Cursor oder Claude Code generiert. Ändert das das Audit?
Es ändert die Gewichtung. KI-generierter Code wirkt an der Oberfläche oft sauber und ist schwach bei Autorisierung, Mandantenisolation und Fehlerbehandlung. Das Audit verbringt mehr Zeit in diesen Bereichen und weniger bei Stilfragen. Siehe das Vibe-Code-Audit für den Aufbau dieses Reviews.
Nächster Schritt
Wenn du nicht sicher bist, welchen du brauchst, beschreib die Situation, die die Frage ausgelöst hat, sei es eine Kundenanfrage, ein Launch, eine Zertifizierung oder ein ungutes Gefühl beim Code, und wir sagen dir, welches Engagement passt und was es abdecken würde. Schreib an hello@wolf-tech.io oder sieh dir den Security-Audit-Scope auf wolf-tech.io an.