Prüft Ihr Pentest die Version, die gerade live geht, oder die vom letzten Jahr?
Release-Pentests prüfen gezielt, was sich in einer Version geändert hat: neue Rollen, API-Endpunkte und Workflows. Im Greybox-Test suchen wir nach IDOR (Zugriff auf fremde Datensätze über manipulierte IDs), Broken Access Control und Logikfehlern. Methodisch nach OWASP WSTG, OWASP Top 10, API Security Top 10 und MASTG, ergänzt um einzelne ASVS-Anforderungen, als Nachweis nach ISO/IEC 27001, Anhang A 8.29.
Web- und Mobile-Anwendungen ändern sich mit jedem Sprint. Ein jährlicher Pentest prüft eine Version, die zum Zeitpunkt des Berichts oft schon ersetzt ist. Kritische Schwachstellen entstehen dabei oft nicht in der Technik, sondern in neuer Geschäftslogik: eine neue Rolle, ein neuer API-Endpunkt, ein geänderter Freigabeprozess.
Release-Tests binden den Pentest an Ihren Entwicklungszyklus. Über Pentest as a Service mit einer Mindestlaufzeit von zwölf Monaten sind Rahmen, Zugänge und Team vorbereitet. Wir testen gezielt, was sich geändert hat, und prüfen die Auswirkung auf bestehende Berechtigungen und Datenflüsse. ISO/IEC 27001 fordert mit Anhang A 8.29 ausdrücklich Sicherheitstests in Entwicklung und Abnahme, Release-Pentests liefern dafür einen Nachweis. Hersteller von Produkten mit digitalen Elementen müssen nach dem Cyber Resilience Act seit 11. September 2026 aktiv ausgenutzte Schwachstellen melden und ab 11. Dezember 2027 Schwachstellen behandeln und die Sicherheit regelmäßig testen.
Auf Basis von Release Notes, Tickets oder Änderungsübersichten konzentrieren wir den Test auf neue und geänderte Funktionen, Schnittstellen und Rollen.
Greybox mit Testkonten: IDOR, Broken Access Control, Manipulation von Preisen oder Workflows und Rechteausweitung zwischen Rollen.
Injection, Fehlkonfigurationen und die Schwachstellenklassen der OWASP Top 10 in neuem Code und neuen Komponenten.
Web- und Mobile-Backends entlang der OWASP API Security Top 10, einschließlich Autorisierung auf Objektebene.
iOS und Android auf dedizierten Testgeräten: lokale Datenhaltung, Transportsicherheit und API-Kommunikation, bei sensiblen Apps auch Reverse Engineering.
Ein Release-Pentest prüft vor dem Go-live, wie sich die Änderungen einer Version auf Rollen, Berechtigungen und Datenflüsse auswirken. Gedacht ist er für Produktteams mit kurzen Sprints, Web- oder Mobile-Apps und Kunden, die Tests verlangen. Er setzt auf einer vollständigen Prüfung von Webanwendungen und APIs oder Mobile Apps auf und ersetzt sie nicht. Wiederkehrende Schwachstellenklassen gehen als Anforderungen nach OWASP ASVS oder als Testfälle an Ihr Entwicklungsteam zurück.
Release-Kalender, Testumgebung, Testkonten und Vorlaufzeiten werden einmalig vereinbart. Umfang legen wir im Scoping gemeinsam fest.
Ihr Team meldet das Release mit einer Beschreibung der Änderungen an.
Manuelle Tests durch unsere Pentester auf einer produktionsnahen Umgebung. Kritische Befunde melden wir sofort. Für besonders sensible Umgebungen arbeiten wir bei Bedarf auch vor Ort.
Befunde mit Einschätzung, welche vor dem Go-live geschlossen sein sollten. Die Freigabeentscheidung bleibt bei Ihnen.
Korrekturen prüfen wir gezielt nach, damit das Release mit belegtem Stand live geht. Über alle Releases validieren wir Ihre Maßnahmen kontinuierlich.
Zuerst die technischen Erkenntnisse für Ihr IT-Team, dann der Plan für die Behebung, dann die Zusammenfassung für Ihre Geschäftsführung und die Prüfbescheinigung für Kunden, Auditoren oder Versicherer. Alles beruht auf denselben Befunden.
Jeder Befund mit Nachweis, Einordnung nach CVSS, Auswirkung und Relevanz für Ihre Umgebung, dazu die Liste der betroffenen Systeme und Geräte. Nachvollziehbar und im vereinbarten Retest überprüfbar.
Ein priorisierter Actionplan mit klaren Verantwortlichkeiten, optional geschärft im Technischen Workshop mit Ihrem Team. Er ist die Grundlage für die Behebung und auf Wunsch begleiten wir die Umsetzung bis zum Retest.
Die Freigabelage je Release auf einen Blick, dazu der Validierungsbericht: welche Schwachstellen aus früheren Releases geschlossen sind und ob Korrekturen in der Pipeline greifen.
Die Bestätigung der durchgeführten Prüfung, ohne technische Details preiszugeben. Für Kunden, Auditoren, Aufsicht und Ihre Cyberversicherung.
Melden Sie sich bei uns. Im Termin zeigen wir Ihnen an einem anonymisierten Beispiel, wie IT-Sicherheitsreport, Actionplan, technische Ergebnispräsentation und Prüfbescheinigung für Ihre Prüfung aussehen.
„Gestartet sind wir mit einem umfangreichen Penetrationstest […]. Mittlerweile sind wir in einer regelmäßigen Betreuung, um das erreichte Sicherheitsniveau weiter auszubauen.“
Marcel Widmaier, Geschäftsführer, Glatthaar Keller GmbH & Co. KG
Release-Pentests prüfen, was sich geändert hat, und setzen eine vollständig geprüfte Ausgangslage voraus. So greifen Tiefenprüfung und Release-Takt ineinander.
Wenn die Anwendung noch nie vollständig geprüft wurde oder die letzte Tiefenprüfung länger zurückliegt, schafft ein Test der Webanwendungen & APIs die Ausgangslage.
Zur LeistungWenn Ihre App sensible Daten lokal speichert oder auf manipulierten Geräten bestehen muss, geht ein Test der Mobile Apps bis zum Reverse Engineering in die Tiefe.
Zur LeistungWenn noch kein Rahmen besteht, stellt Pentest as a Service Team, Zugänge und Testfenster bereit, damit Release-Tests ohne eigene Beauftragung pro Version laufen.
Zur LeistungSchildern Sie kurz, worum es geht. Den Zuschnitt erarbeiten wir mit Ihnen im Scoping. Für das Beratungsgespräch müssen
Sie sich nicht vorbereiten, wir führen Sie fachlich Schritt für Schritt. Ausgehend von Ihren Unternehmensabläufen und IT-Systemen ermitteln wir gemeinsam das passende Testkonzept.
Diese Fragen erreichen uns zu dieser Leistung am häufigsten. Was fehlt, klären wir gern persönlich im Beratungsgespräch.
Das legen wir im Rahmen fest. Entscheidend sind ein stabiler Stand in einer Testumgebung und eine Beschreibung der Änderungen. Mit festen Testfenstern im Release-Kalender entfällt die Abstimmung pro Release weitgehend.
In der Regel testen wir auf einer produktionsnahen Staging-Umgebung. Tests in der Produktion sind möglich, werden mit Vorlauf angekündigt und eng mit Ihrem Betrieb abgestimmt.
Nein, er ergänzt sie. Werkzeuge finden bekannte Muster schnell und zuverlässig. Fehler in Berechtigungen und Geschäftslogik findet in der Regel nur ein Mensch, der die Anwendung versteht.
Ein vollständiger Pentest prüft die gesamte Anwendung, ein Release-Pentest konzentriert sich auf die Änderungen einer Version und ihre Auswirkung auf den Bestand. Dadurch passt er in den Entwicklungstakt, setzt aber eine geprüfte Ausgangslage voraus. Beide Formen ergänzen sich.
Release Notes, Tickets oder eine Änderungsübersicht, dazu Testkonten für alle betroffenen Rollen. Bei APIs hilft eine aktuelle Spezifikation, etwa im OpenAPI-Format, bei Mobile Apps benötigen wir die Builds für iOS und Android. Je genauer die Änderung beschrieben ist, desto gezielter wird der Test.
Wir melden ihn sofort, damit Ihr Team über Verschiebung, Behebung oder eine abgesicherte Freigabe entscheiden kann. Nach der Korrektur prüfen wir den Befund gezielt nach. Die Entscheidung über den Go-live bleibt bei Ihnen.
ISO/IEC 27001:2022 fordert in Anhang A 8.29, Sicherheitstests im Entwicklungslebenszyklus festzulegen und durchzuführen. Eine bestimmte Methode schreibt die Norm nicht vor, erwartet wird ein dokumentierter, wiederholbarer Ablauf. Release-Pentests mit Ergebnis je Version liefern dafür einen Nachweis.
Der Aufwand richtet sich nach dem Umfang der Änderung, nicht nach der Größe der Anwendung. Treiber sind neue Rollen, API-Endpunkte und Workflows sowie die Zahl der Plattformen, etwa Web, iOS und Android. Feste Testfenster im Release-Kalender machen den Aufwand planbar.
