Injection-Schwachstellen
Benutzereingaben, die ungefiltert in SQL-Abfragen, Betriebssystembefehle, LDAP- oder Template-Ausdrücke gelangen, ermöglichen Datendiebstahl bis hin zur Übernahme des Servers.
Security Services
Security Code Review & Reverse Engineering
Sicherheit, die im Code beginnt.
Viele Schwachstellen lassen sich von außen nur erahnen – im Quellcode werden sie oft eindeutig sichtbar. Mit einem Security Code Review analysieren wir die sicherheitskritischen Teile Ihrer Software, prüfen Abhängigkeiten und Secrets und untersuchen per Reverse Engineering auch Anwendungen, Firmware und Protokolle, für die kein Quellcode vorliegt.
- Festpreis nach Scoping
- Kostenloser Retest
- Angebot in 24 h
Definition
Was ist ein Security Code Review?
Ein Security Code Review – auch Source-Code-Analyse oder Quellcodeprüfung genannt – ist die gezielte Untersuchung von Quellcode auf Sicherheitsschwachstellen. Anders als der funktionale Review im Entwicklungsteam fragt er, wie ein Angreifer die Software missbrauchen könnte: Wo werden Eingaben ungeprüft verarbeitet, wo fehlen Berechtigungsprüfungen, wo wird Kryptografie falsch eingesetzt? Wir kombinieren manuelle Analyse mit statischer Codeanalyse (SAST) und orientieren uns am OWASP Code Review Guide und am OWASP Application Security Verification Standard (ASVS).
Reverse Engineering setzt dort an, wo kein Quellcode vorliegt: bei zugekaufter Software, kompilierten Anwendungen, mobilen Apps, Firmware von IoT- und Industriegeräten oder proprietären Protokollen. Durch Disassemblierung, Dekompilierung und dynamische Analyse rekonstruieren wir Funktionsweise und Schutzmechanismen – und finden Schwachstellen, versteckte Zugänge oder fest eingebaute Zugangsdaten.
Ein Penetrationstest zeigt, was von außen ausnutzbar ist. Ein Code Review findet zusätzlich Fehler, die im Test kaum erreichbar sind – etwa in selten genutzten Funktionen, in der Fehlerbehandlung oder in Logik, die nur unter bestimmten Bedingungen greift. Und je früher eine Schwachstelle im Entwicklungsprozess auffällt, desto günstiger ist ihre Behebung.
Auch regulatorisch gewinnt Codesicherheit an Gewicht: Der Cyber Resilience Act verpflichtet Hersteller von Produkten mit digitalen Elementen – mit gestaffelten Übergangsfristen – zu Security by Design, Schwachstellenmanagement und einer Software-Stückliste (SBOM). PCI DSS 4.0.1 verlangt in Anforderung 6.2.3, individuell entwickelte Software vor der Freigabe auf Schwachstellen zu prüfen. Mit Bericht und Prüfbescheinigung belegen Sie gegenüber Kunden, Partnern und Auditoren, dass Ihre Software unabhängig geprüft wurde.
Unser Vorgehen
So prüfen wir Ihren Code
Am Anfang steht das Verständnis der Anwendung: Architektur, Datenflüsse, Vertrauensgrenzen und die Funktionen mit dem höchsten Schutzbedarf – etwa Anmeldung, Zahlungsabwicklung oder Mandantentrennung. Daraus leiten wir ab, wo ein Angreifer ansetzen würde, und konzentrieren die manuelle Analyse auf diese Bereiche.
Werkzeuge für statische Analyse, Abhängigkeitsprüfung und Secret-Scanning liefern eine breite Grundlage. Jeden Treffer bewerten wir manuell: Ist die Stelle erreichbar, lässt sich die Eingabe kontrollieren, wie groß ist die Auswirkung? Logikfehler, fehlerhafte Berechtigungsprüfungen und kontextabhängige Kryptografieprobleme lassen sich ohnehin nur durch menschliche Analyse zuverlässig erkennen.
Beim Reverse Engineering arbeiten wir mit Disassemblern und Decompilern, mit dynamischer Instrumentierung und – bei Hardware – mit dem Auslesen von Flash-Speichern und Debug-Schnittstellen wie UART oder JTAG. Wo sinnvoll, kombinieren wir den Review mit einem Penetrationstest der laufenden Anwendung, um Verdachtsstellen aus dem Code praktisch zu verifizieren.
Typische Schwachstellen
Schwachstellen, die wir in Code und Binärdateien finden
Fehlerhafte Zugriffskontrolle
Fehlende Berechtigungsprüfungen auf Objektebene (IDOR), unvollständige Mandantentrennung oder Prüfungen nur im Frontend öffnen den Zugriff auf fremde Daten und Funktionen.
Hartcodierte Secrets
Passwörter, API-Schlüssel, private Schlüssel und Tokens im Quellcode, in Konfigurationsdateien oder in der Git-Historie sind für alle mit Repository-Zugriff nutzbar – und nach einem Leak für beliebige Dritte.
Unsichere Kryptografie
Mit MD5 oder SHA-1 statt mit Verfahren wie Argon2 oder bcrypt gespeicherte Passwörter, statische Initialisierungsvektoren, selbst entwickelte Verschlüsselung oder vorhersehbare Zufallszahlen untergraben den Schutz sensibler Daten.
Deserialisierung und Dateiverarbeitung
Das Deserialisieren nicht vertrauenswürdiger Daten, Path Traversal und ungeprüfte Datei-Uploads können bis zur Ausführung von Schadcode auf dem Server führen.
Verwundbare Abhängigkeiten
Veraltete Bibliotheken mit bekannten Schwachstellen, verwaiste Pakete und manipulierte Komponenten in der Lieferkette. Log4Shell hat gezeigt, wie schnell eine einzelne Bibliothek zum Risiko für ganze Unternehmen wird.
Logik- und Sitzungsfehler
Umgehbare Workflows, Race Conditions bei Zahlungen oder Gutscheinen, unsichere Passwort-Reset-Abläufe und fehlerhafte Token-Validierung, etwa bei JWT, bleiben für Scanner unsichtbar.
Speicherfehler in nativem Code
Pufferüberläufe, Use-after-free und Integer-Überläufe in C- und C++-Komponenten, Firmware oder Treibern lassen sich häufig bis zur Codeausführung ausnutzen.
Varianten nach Bedarf
Drei Wege zu sicherer Software
Die Varianten sind keine festen Pakete – im Scoping stellen wir den passenden Umfang zusammen und kombinieren sie bei Bedarf.
Quellcode verfügbar
Security Code Review
Risikoorientierte Analyse Ihres Quellcodes – vor Releases, nach größeren Umbauten oder als Ergänzung zum Penetrationstest.
- Manuelle Analyse plus SAST und SCA
- Orientierung an OWASP ASVS und Code Review Guide
- Befunde mit Fundstelle und Korrekturvorschlag
Kein Quellcode
Reverse Engineering
Analyse von Binärdateien, Apps, Firmware und Protokollen – wenn Sie zugekaufte oder kompilierte Software bewerten müssen.
- Statische und dynamische Analyse
- Suche nach Hintertüren und hartcodierten Zugangsdaten
- Bewertung von Schutz- und Update-Mechanismen
Begleitend
Sicherheit im Entwicklungsprozess
Wir unterstützen Sie dabei, Sicherheitsprüfungen im Sinne von DevSecOps dauerhaft in Ihre Entwicklung zu integrieren – statt nur punktuell zu testen.
- Einbindung von SAST, SCA und Secret-Scanning in CI/CD
- Gemeinsame Auswertung der Befunde mit Ihrem Entwicklungsteam
- SBOM und Schwachstellenmanagement für den Cyber Resilience Act
Ablauf
Ablauf eines Code Reviews
Strukturiert wie alle unsere Security Services, vertraulich und eng abgestimmt mit Ihrem Entwicklungsteam.
-
01
Scoping & Vertraulichkeit
Wir klären Umfang, Technologien und Schutzziele sowie den sicheren Austausch des Codes. Auf Wunsch schließen wir vorab eine Vertraulichkeitsvereinbarung ab.
-
02
Festpreisangebot
Werktags innerhalb von 24 Stunden nach dem Scoping erhalten Sie ein Festpreisangebot für den vereinbarten Umfang – ohne versteckte Kosten.
-
03
Architektur- und Bedrohungsanalyse
Wir verschaffen uns einen Überblick über Aufbau, Datenflüsse und Vertrauensgrenzen und legen die Prüfschwerpunkte fest.
-
04
Analyse
Toolgestützte und manuelle Prüfung der kritischen Komponenten; beim Reverse Engineering statische und dynamische Analyse in einer isolierten Umgebung.
-
05
Bericht & Entwickler-Briefing
Sie erhalten einen Bericht mit Management Summary und technischen Details. Auf Wunsch gehen wir die Befunde gemeinsam mit Ihrem Entwicklungsteam durch.
-
06
Retest & Prüfbescheinigung
Nach der Behebung prüfen wir die Korrekturen kostenlos nach und stellen Ihnen eine Prüfbescheinigung aus.
Ergebnisbericht
Ergebnisse, mit denen Ihr Entwicklungsteam sofort arbeiten kann
Unser Bericht verbindet die Sicht von Management und Entwicklung. Die Management Summary bewertet das Sicherheitsniveau Ihrer Software und benennt die wichtigsten Risiken. Der technische Teil beschreibt jede Schwachstelle mit Fundstelle, Nachweis, CVSS-Bewertung und konkretem Korrekturvorschlag.
- Management Summary mit Risikoeinschätzung
- Befunde mit Datei, Zeile oder Funktion und Nachweis
- Bewertung nach CVSS und Einordnung nach OWASP Top 10 bzw. CWE
- Korrekturvorschläge und Hinweise auf sichere Alternativen
- Kostenloser Retest der behobenen Schwachstellen
- Prüfbescheinigung zur Vorlage bei Kunden, Partnern, Versicherern und Auditoren
Sicherheitslücken finden, bevor Ihre Software ausgeliefert wird
Ob kurz vor dem Release, vor einer Due-Diligence-Prüfung oder bei zugekaufter Software ohne Quellcode: Wir analysieren, was wirklich in Ihrer Software steckt.
FAQ
Häufige Fragen zu Code Review und Reverse Engineering
Ihre Frage ist nicht dabei? Rufen Sie uns an: +49 2932 465265-0 oder schreiben Sie an info@rootsektor.de.
Was ist der Unterschied zwischen Code Review und Penetrationstest?
Ein Penetrationstest prüft die laufende Anwendung von außen, so wie ein Angreifer sie sieht. Ein Code Review analysiert den Quellcode von innen und findet auch Schwachstellen, die im Test schwer erreichbar sind. Am wirksamsten ist die Kombination: Code-Befunde lassen sich im Penetrationstest für Webanwendungen praktisch verifizieren, und Auffälligkeiten aus dem Test führen direkt zur verantwortlichen Codestelle.
Reicht ein automatisiertes SAST-Tool nicht aus?
SAST-Werkzeuge sind ein wertvoller Baustein, liefern aber viele Fehlalarme und übersehen ganze Schwachstellenklassen – etwa Fehler in der Geschäftslogik, fehlende Berechtigungsprüfungen oder kontextabhängige Kryptografieprobleme. Wir nutzen Werkzeuge als Ausgangspunkt und bewerten jeden Treffer manuell. Gern unterstützen wir Sie auch dabei, SAST und Abhängigkeitsprüfungen sinnvoll in Ihre CI/CD-Pipeline zu integrieren.
Wie schützen Sie unseren Quellcode?
Den Austausch stimmen wir individuell mit Ihnen ab – etwa über einen zeitlich begrenzten Lesezugriff auf Ihr Repository oder eine verschlüsselte Übertragung. Auf Wunsch unterzeichnen wir vor Projektbeginn eine Vertraulichkeitsvereinbarung. Nach Projektende wird der Code gemäß Absprache gelöscht oder zurückgegeben.
Müssen wir den gesamten Code prüfen lassen?
Nicht zwingend. Bei großen Codebasen ist ein risikoorientierter Ansatz meist wirtschaftlicher: Wir konzentrieren uns auf sicherheitskritische Komponenten wie Authentifizierung, Zugriffskontrolle, Zahlungsfunktionen, Schnittstellen und die Verarbeitung externer Daten. Den sinnvollen Umfang legen wir gemeinsam im Scoping fest.
Ist Reverse Engineering rechtlich zulässig?
Ja, wenn die Voraussetzungen erfüllt sind – etwa bei eigener Software, mit Zustimmung des Herstellers oder im Rahmen gesetzlicher Ausnahmen. Das Urheberrecht erlaubt in engen Grenzen beispielsweise, die Funktionsweise eines Programms zu beobachten und zu testen (§ 69d Abs. 3 UrhG) oder es zur Herstellung der Interoperabilität zu dekompilieren (§ 69e UrhG). Wir klären die Rahmenbedingungen vor Projektbeginn mit Ihnen; im Zweifel empfehlen wir eine rechtliche Prüfung.
Welche Technologien können Sie analysieren?
Wir prüfen Code in den gängigen Sprachen für Web, Backend und Mobile, z. B. Java, C#/.NET, PHP, Python, JavaScript/TypeScript, Go, Kotlin und Swift, sowie nativen Code in C und C++. Beim Reverse Engineering analysieren wir unter anderem Windows- und Linux-Programme, Android- und iOS-Apps sowie Firmware eingebetteter Systeme. Welche Technologien Sie einsetzen, klären wir im Scoping.
Wann ist ein Code Review besonders sinnvoll?
Typische Anlässe sind größere Releases, neue sicherheitskritische Funktionen, die Übernahme von Software durch Zukauf oder Outsourcing, Due-Diligence-Prüfungen sowie Anforderungen von Kunden oder Regelwerken wie PCI DSS 4.0.1 und dem Cyber Resilience Act. Auch nach einem Sicherheitsvorfall hilft ein Review, die Ursache im Code zu finden und ähnliche Fehler an anderen Stellen aufzuspüren.
Analysieren Sie auch Schadsoftware?
Ja – als eigene Leistung im Bereich Incident Response & Forensik. Beim Code Review & Reverse Engineering bewerten wir legitime Software, Apps, Firmware und Protokolle geplant auf Schwachstellen. Gefundene Schadsoftware untersuchen wir dagegen in einer Malware-Analyse: Wir klären, was das Programm kann, mit welchen Servern es kommuniziert und wie es sich festsetzt, und leiten Indicators of Compromise (IoCs) und Erkennungsregeln für Ihre Abwehr ab.
Weiterführende Seiten
Lassen Sie uns über Ihre Software sprechen
Beschreiben Sie kurz Ihr Projekt – Anwendungstyp, Programmiersprachen und ungefähre Codegröße oder die zu analysierende Binärdatei bzw. Firmware. Wir melden uns mit einem Vorschlag für das passende Vorgehen.