Tests bieten den größten Mehrwert während der Entwicklung und vor der Bereitstellung des Produkts in der Produktionsumgebung. Wir empfehlen sie auch nach größeren Aktualisierungen, Architekturänderungen, neuen API-Integrationen oder vor einem Audit beziehungsweise dem Eintritt in einen neuen Markt.

Nicht immer. Wir können das Produkt ohne Kenntnis des Quellcodes oder mit Zugriff auf Code, Dokumentation und Architektur testen. Den passenden Ansatz wählen wir anhand der Ziele, des Umfangs und der Entwicklungsphase.

Ja, sofern die Art des Produkts und die vereinbarten Bedingungen dies zulassen. Vor Beginn definieren wir Umfang, Sicherheitsgrenzen, Zeitplan und das Vorgehen bei kritischen Schwachstellen.

Ja. Die Tests können Web- und mobile Anwendungen, APIs, Cloud-Umgebungen, Quellcode, CI/CD-Umgebungen, Identitäten, Softwareabhängigkeiten und externe Integrationen umfassen. Dadurch können wir auch Angriffswege erkennen, die durch kombinierte Schwachstellen in mehreren Komponenten entstehen.

Ja. Wir überprüfen Prozesse, Benutzerrollen und Anwendungsregeln manuell. Dabei suchen wir nach Möglichkeiten, Kontrollen zu umgehen, Transaktionen zu manipulieren, Funktionen zu missbrauchen oder auf fremde Daten zuzugreifen.

Ja. Tests können technische Nachweise zur Identifizierung von Produktschwachstellen und zur Überprüfung der Wirksamkeit bestehender Maßnahmen über den gesamten Lebenszyklus liefern. Sie ersetzen jedoch weder eine rechtliche Bewertung noch eine umfassende Konformitätsbewertung.

Ja. Wir identifizieren veraltete oder anfällige Komponenten, riskante Pakete und Abhängigkeiten von Drittanbietern. Zudem bewerten wir die möglichen Auswirkungen einer Ausnutzung auf das Produkt und seine Kunden.

Das Entwicklungsteam erhält einen technischen Bericht mit einer Beschreibung der Schwachstellen, Nachweisen, Schritten zur Überprüfung und konkreten Empfehlungen zur Behebung. Auf Wunsch besprechen wir die Ergebnisse direkt mit den Entwicklern und erläutern die Prioritäten.

Ja, ein Retest kann Teil des vereinbarten Projektumfangs sein. Nach der Behebung überprüfen wir, ob die Schwachstellen korrekt geschlossen wurden und ob die Änderungen neue Sicherheitsrisiken verursacht haben.

Die Häufigkeit hängt vom Risikoprofil des Produkts und der Entwicklungsgeschwindigkeit ab. Wir empfehlen Tests nach wesentlichen Änderungen am Code, an der Architektur oder an Integrationen sowie regelmäßige Prüfungen entsprechend den Anforderungen von Kunden oder Regulierungsbehörden.