Pentest für SaaS und Software im Release-Takt: aktuelle Nachweise für Enterprise-Kunden und Audits, Tests kritischer Änderungen vor dem Go-live.
In der digitalen Wirtschaft ist die Angriffsfläche das Produkt selbst. Mandantenfähige Plattformen, öffentliche APIs, Build-Pipelines und Cloud-Konten ändern sich mit jedem Release, oft mehrmals pro Woche. Ein jährlicher Pentest bildet davon eine Momentaufnahme ab, die bei Übergabe des Berichts bereits einen Teil ihrer Aussagekraft verloren hat.
Für einen Angreifer ist ein Plattformanbieter doppelt attraktiv, denn wer die Plattform kompromittiert, erreicht die Daten vieler Kunden auf einmal. Die wichtigsten Prüffragen lauten deshalb: Sieht ein Mandant Daten eines anderen? Reicht ein kompromittiertes Entwicklerkonto bis in die Produktion? Lassen sich Build und Deployment manipulieren? Dazu kommt der Druck von außen: Enterprise-Kunden verlangen aktuelle Testnachweise und für Hersteller gelten seit dem 11. September 2026 die Meldepflichten des Cyber Resilience Act.
Sieht ein Mandant die Daten eines anderen, kann der Vorfall alle Kunden der Plattform betreffen und Ihr Kernversprechen infrage stellen. Wir prüfen Autorisierung und Mandantentrennung manuell mit mehreren Testmandanten und Rollen.
Ein zu weit berechtigter Pipeline-Token kann bis in die Produktion reichen und manipulierten Code an alle Kunden ausliefern. Wir prüfen Repository, CI/CD, Secrets und Cloud-Rollen als zusammenhängenden Angriffspfad.
Fehlen aktuelle Testnachweise, bleiben Sicherheitsfragebögen offen und Abschlüsse verschieben sich. Neben dem technischen Bericht erhalten Sie eine Prüfbescheinigung, die Sie Kunden und Auditoren vorlegen können.
Jede Auslieferung kann Login, Rechte oder Mandantenlogik verändern. Für Hersteller im Geltungsbereich des CRA sind aktiv ausgenutzte Schwachstellen meldepflichtig. Wir testen kritische Änderungen vor dem Go-live und dokumentieren die Behebung.
Integrierte LLM-Assistenten können über Prompt Injection Daten aus dem Kontext preisgeben oder Aktionen auslösen, die niemand freigegeben hat. Wir prüfen sie nach den OWASP Top 10 for LLM Applications.
Seit dem 11. September 2026 gelten die Meldepflichten des Cyber Resilience Act (CRA) für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle. Die Anforderungen an sichere Entwicklung und Schwachstellenbehandlung folgen ab dem 11. Dezember 2027. Reine SaaS-Angebote ohne zugehöriges Produkt fallen in der Regel nicht unter den CRA, können aber unter NIS2 fallen. Das deutsche NIS2-Umsetzungsgesetz ist seit dem 6. Dezember 2025 in Kraft.
Wir testen entlang des Produktlebenszyklus und dokumentieren je Release, was geprüft, gefunden und behoben wurde. So entsteht eine Testhistorie, die Sie für Konformitätsbewertung und Schwachstellenbehandlung nutzen können.
Den Scope richten wir an den Diensten aus, mit denen Sie als Cloud-Anbieter, Managed Service Provider oder digitaler Dienst reguliert sind. Der Test kann zugunsten einer realen Bewertung Teil Ihres Verfahrens zur Bewertung der Wirksamkeit von Risikomanagementmaßnahmen sein.
Umfang, Zeitraum und Methodik halten wir so fest, dass Auditoren sie als Nachweis nachvollziehen können. Die Behebung belegen wir per Nachtest. Für Kundenanfragen gibt es eine Prüfbescheinigung ohne technische Details.
Den genauen Zuschnitt legen wir gemeinsam mit Ihnen fest. Die meisten Vorhaben in Ihrer Branche beginnen an einem dieser drei Punkte.
Anbieter, die für Enterprise-Kunden oder eine Zertifizierung einen aktuellen, unabhängigen Nachweis brauchen.
Pentest von Anwendung und APIs mit Fokus auf Mandantentrennung und Autorisierung, dazu ein Test der öffentlichen Angriffsfläche von außen. Für Kundengespräche erhalten Sie eine Prüfbescheinigung.
Ein technischer Bericht für Ihr Engineering und eine Prüfbescheinigung, die Ihr Vertrieb Enterprise-Kunden vorlegt.
Plattformen mit mehreren Cloud-Konten, eigener Build-Kette oder KI-Funktionen, die Kunden direkt im Produkt nutzen.
Cloud-Pentest mit Rechteausweitung über PIM und RBAC entlang der CI/CD-Pipeline und ein Test Ihrer integrierten LLM-Assistenten. Im Technischen Workshop stellt Ihr Team alle Befunde nach.
Die Angriffspfade vom Entwicklerkonto bis in die Produktion, priorisiert und von Ihrem Team im Workshop nachvollzogen.
Teams, die mehrmals pro Woche ausliefern, und Anbieter, deren Enterprise-Kunden fortlaufende Testnachweise erwarten.
Laufende Tests in einem festen Rahmen, Release-Tests vor dem Go-live und Nachtests als Behebungsnachweis. Für Hersteller im Geltungsbereich des CRA entsteht so eine durchgehende Testhistorie.
Sicherheitstests als fester Teil Ihres Entwicklungsprozesses, mit einer Historie für Kunden und Marktüberwachung.
Wir testen dort, wo sich Ihr Produkt ändert, und so oft, wie es sich ändert.
Mandantentrennung, Rollen und APIs prüfen wir mit mehreren Testmandanten nach OWASP ASVS und API Security Top 10, bis zur Autorisierung auf Objektebene.
Release-Tests binden Web- und Mobile-Pentests an Ihren Release-Kalender. Änderungen an Login, Rechten oder Mandantenlogik testen wir vor dem Go-live.
Ein fortlaufender Testrahmen mit festen Ansprechpartnern, aus dem Sie Release-Tests, Nachtests und Antworten auf Kundenanfragen abrufen.
Wir prüfen Azure, Entra ID und die Anbindung Ihrer Build-Kette und zeigen, wie weit ein Entwicklerkonto bis zu Produktionsressourcen reicht.
Wir testen integrierte Assistenten und Agenten auf Prompt Injection, Datenabfluss über den Kontext und unkontrollierte Aufrufe angebundener Tools.
Prüfbescheinigung und Retest belegen Umfang, Zeitraum, Methodik und Behebungsstand. Kunden und Auditoren brauchen dafür nicht den vollständigen Bericht.
Nach einem Ransomware-Angriff wollte VARIO wissen, welche Angriffswege offen sind und ob die eigenen Maßnahmen einem Härtetest standhalten.
Initialer Pentest, Begleitung im Schwachstellenmanagement mit Retests, Aufbau eines ISMS und Coaching der neuen IT-Leitung.
Jeder Retest zeigte deutliche Fortschritte. Neue Entwicklungen werden von Beginn an unter Sicherheitsaspekten abgesichert.
Mitarbeitende zum Junior Penetration Tester ausgebildet.
Im Scoping klären wir, welche Teile Ihrer Plattform wie oft getestet werden sollten.
Für das Beratungsgespräch müssen Sie sich nicht vorbereiten, wir führen Sie fachlich Schritt für Schritt. Im Gespräch klären wir, welche Systeme und Abläufe in den Test gehören und wie tief wir prüfen.
Wir wählen aus, wer fachlich zu Ihrem Anliegen passt. Diese Person meldet sich bei Ihnen. Ab der Beauftragung übernimmt eine feste Projektleitung aus dem Fachbereich bis zum Retest.
Diese Fragen erreichen uns aus Ihrer Branche am häufigsten. Was fehlt, klären wir gern persönlich im Beratungsgespräch.
Für viele Fragebögen formal ja. Aussagekräftig ist er aber nur für den Stand zum Testzeitpunkt. Wer wöchentlich ausliefert, fährt besser mit einem jährlichen Tiefentest und Release-Tests für Änderungen an Authentifizierung, Autorisierung und Mandantenlogik. Den Rhythmus legen wir im Scoping gemeinsam fest.
Software, die als Produkt mit digitalen Elementen in der EU bereitgestellt wird, fällt grundsätzlich darunter. Reine SaaS-Angebote ohne zugehöriges Produkt fallen in der Regel nicht darunter. Die verbindliche Einordnung ist eine rechtliche Frage. Unser Beitrag ist der technische Teil: Sicherheitstests und dokumentierte Schwachstellenbehandlung, die Sie für die Konformitätsbewertung nutzen können.
Ja, in abgestufter Form. Der vollständige Bericht bleibt intern. Für Kunden gibt es eine Prüfbescheinigung mit Scope, Zeitraum und Methodik. Den Behebungsstand belegt der Retest. Viele Anbieter legen sie direkt ihrem Trust Center oder dem Sicherheitsfragebogen bei.
Ein Scanner findet bekannte Schwachstellen und Fehlkonfigurationen. Ein Pentest prüft zusätzlich Geschäftslogik, Autorisierung und Mandantentrennung. Fehler in der Mandantentrennung erkennt ein Scanner in der Regel nicht, weil er nicht weiß, welche Daten zu welchem Mandanten gehören. Beides ergänzt sich: Scans laufen fortlaufend, Pentests gezielt vor Releases und im jährlichen Tiefentest.
Beides ist möglich. Meist testen wir Anwendung und APIs in einer produktionsnahen Staging-Umgebung und die öffentliche Angriffsfläche in Produktion. Staging muss dafür dieselbe Version, Konfiguration und Mandantenlogik haben wie Produktion. Cloud-Konten und Pipeline prüfen wir in ihrer echten Konfiguration, weil Abweichungen dort den Unterschied machen. Die Aufteilung legen wir im Scoping fest.
Mindestens zwei Testmandanten mit Konten in jeder relevanten Rolle, dazu die API-Dokumentation, soweit vorhanden. Mit Nutzenden aus verschiedenen Mandanten prüfen wir, ob sich Daten, Objekte oder Funktionen über die Grenze hinweg erreichen lassen. Die Testdaten sollten realistisch aufgebaut, aber keine echten Kundendaten sein.
Als reproduzierbare Befunde mit Schritten, Nachweis und konkretem Fix-Hinweis, die Ihr Team direkt als Ticket übernehmen kann. Kritische Befunde melden wir sofort und nicht erst mit dem Bericht. Nach der Behebung prüfen wir im Retest, ob der Fix wirkt.
Vor allem von der Zahl der Rollen, Mandantenmodelle und API-Endpunkte und davon, ob Cloud-Konten und Build-Pipeline mitgeprüft werden. Ein fokussierter Anwendungstest dauert je nach Umfang wenige Tage bis einige Wochen. Gute API-Dokumentation und vorbereitete Testmandanten verkürzen die Einarbeitung. Den Umfang leiten wir im Scoping aus Architektur und Kundenanforderungen ab.
SOC 2 schreibt keinen Penetrationstest verbindlich vor, die Trust Services Criteria nennen ihn aber unter CC4.1 als eine Form der Überprüfung. In der Praxis erwarten Auditoren und Kunden aber häufig einen aktuellen Test mit dokumentierter Behebung als Beleg dafür, dass Kontrollen überwacht und Schwachstellen behandelt werden. Welche Evidenz Ihr Auditor erwartet, klären Sie am besten vorab mit ihm.
