Mit der stetigen Zunahme von Cyberangriffen wird eine effektive Sicherheitsanalyse immer wichtiger, um Software und Daten zu schützen. Gleichzeitig werden Compliance-Anforderungen strenger und verlangen regelmäßige, spezialisierte Sicherheitstests, um den wachsenden Risiken zu begegnen.
Angesichts der Vielzahl an verfügbaren Methoden kann es schwierig sein, die passende Herangehensweise zu wählen. Pentests beispielsweise bieten eine effektive Möglichkeit, reale Bedrohungen zu simulieren, um Schwachstellen in laufenden Anwendungen aufzudecken. Security Code Reviews hingegen sind eine präventive Maßnahme: Sie ermöglichen eine Untersuchung des Quellcodes auf Sicherheitslücken, die potenziell bei künftigen Angriffen ausgenutzt werden könnten. Doch es muss kein Entweder-Oder sein. Ein Whitebox-Pentest kombiniert die Gründlichkeit eines Code Reviews mit der realitätsnahen Angriffssimulation eines Pentests – für eine noch umfassendere Sicherheitsbewertung.
In diesem Blogbeitrag stellen wir die drei Methoden Code Review, Greybox-Pentest und Whitebox-Pentest vor, beleuchten ihre Unterschiede und Gemeinsamkeiten, heben ihre Vorteile hervor und zeigen auf, welche Methode am besten zu Ihren Sicherheitszielen passt.
Security Code Reviews
Bei einem Code Review wird in der Regel eine statische Codeanalyse durchgeführt. Im Gegensatz zu anderen Sicherheitsanalysen, bei denen eine laufende Anwendung getestet wird, erfolgt die Prüfung hier ohne Ausführung des Codes. Es handelt sich daher um die verbreitetste Form des Static Application Security Testing (SAST). Um eine umfassende Testabdeckung zu erreichen, kombinieren Analyst*innen automatisierte Tools zur statischen Codeanalyse mit Abhängigkeitsanalysen sowie einer sorgfältigen manuellen Untersuchung des Quellcodes auf potenzielle Schwachstellen.
Ein wesentlicher Vorteil des Code Reviews ist, dass er bereits früh im Softwareentwicklungsprozess eingesetzt werden kann. So lassen sich Anwendungen testen, noch bevor sie vollständig entwickelt oder bereitgestellt wurden. Dieser proaktive Ansatz ermöglicht es, Schwachstellen zu erkennen und zu beheben, bevor sie in die Produktion gelangen. Zudem lassen sich so auch Sicherheitslücken identifizieren, die in einer laufenden Anwendung schwerer zu entdecken sind – etwa Fehler in der Anwendungslogik, hartkodierte Zugangsdaten oder Probleme in der Kryptografie. Außerdem ermöglicht ein Code Review eine präzise Dokumentation der Ergebnisse, indem der verwundbare Codeabschnitt benannt und hoch spezifische Empfehlungen gegeben werden. Sicherheitsanalyst*innen können zum Beispiel bestimmte Zeilen als verwundbar hervorheben oder sicherere Alternativen für risikobehaftete Funktionen vorschlagen.
Allerdings bringen Code Reviews auch Herausforderungen mit sich: Der Prozess kann ressourcenintensiv und kostspielig sein, da eine gründliche Prüfung viel Zeit und Fachwissen erfordert – besonders bei großen oder komplexen Codebasen. Da es sich bei Code Reviews um einen statischen Prozess handelt, sind sie außerdem nicht geeignet, Probleme mit dem Laufzeitverhalten oder Schwachstellen in der Konfiguration zu erkennen, die nur in einer Live-Umgebung auftreten können. So können beispielsweise Probleme im Zusammenhang mit Serverkonfigurationen, Netzwerksicherheit oder Laufzeitinteraktionen nicht allein durch ein Code Review aufgedeckt werden.
Greybox Pentests
Pentests simulieren reale Bedrohungen, um Sicherheitslücken zu identifizieren, bevor sie von tatsächlichen Angreifern ausgenutzt werden. Im Gegensatz zum Code Review erfolgt beim Pentest eine dynamische Analyse der Anwendung im laufenden Betrieb – entsprechend dem Ansatz des Dynamic Application Security Testing (DAST). Pentests sind besonders gut geeignet, um Schwachstellen zu finden, die sich im Laufzeitverhalten zeigen, wie etwa Probleme beim Session Management oder bei der Interaktion verschiedener Anwendungskomponenten.
Beim Greybox-Ansatz verfügen die Analyst*innen über teilweise Kenntnisse der Anwendung. Dazu gehören unter anderem Dokumentationen, Informationen zur Architektur der Anwendung sowie Zugriff auf bestimmte Komponenten oder Logdateien. Häufig werden Ausnahmen in vorgelagerten Schutzmechanismen wie einer WAF oder einem IPS konfiguriert, und den Pentester*innen werden Benutzerkonten für authentifizierte Tests bereitgestellt. Der Quellcode liegt ihnen allerdings nicht vor und Informationen über die Architektur und andere Komponenten sind möglicherweise unvollständig. Dieses Vorgehen simuliert effektiv einen Angreifer mit Insider-Wissen – etwa eine ehemalige Mitarbeiterin oder ein durch Phishing kompromittiertes Benutzerkonto.
Ein großer Vorteil des Greybox-Pentests ist seine Zeiteffizienz. Dank der vorhandenen Informationen können Analyst*innen in vergleichsweise kurzer Zeit eine hohe Testabdeckung erreichen. Die Methode eignet sich zudem dann, wenn Drittanbieter-Anwendungen verwendet werden und dementsprechend der Quellcode nicht zugänglich ist.
Trotz der realitätsnahen und dynamischen Analyse hat der Greybox-Ansatz Grenzen: Da Analysten nur über partiellen Zugang und Informationen verfügen, sind sie möglicherweise nicht in der Lage, alle Sicherheitslücken aufzudecken. Insbesondere tief im Quellcode verankerte Schwachstellen können so unmöglich oder nur schwierig entdeckt werden. Diese sind zwar auch für Angreifer schwer zu finden, können aber mit genügend Zeit und Aufwand dennoch entdeckt und ausgenutzt werden. Der Greybox-Pentest lässt sich jedoch durch zusätzliche Informationen, die den Analyst*innen zur Verfügung gestellt werden, erweitern – bis hin zum Whitebox-Szenario.
Whitebox Pentests
Der Whitebox-Ansatz kombiniert Pentest und Code Review zu einer umfassenden Sicherheitsanalyse. Dabei reicht das Spektrum von einem Greybox-Pentest mit Quellcodezugriff bis hin zur vollständigen Kombination aus Pentest und vollständigem Code Review.
Der größte Vorteil des Whitebox-Ansatzes liegt in der gesteigerten Testtiefe und Effizienz. In der Regel kann ein Whitebox-Pentest im gleichen Zeitraum wie ein Greybox-Pentest durchgeführt werden – bei gleichzeitig deutlich größerer Testtiefe. Wenn beispielsweise ein Endpunkt einer Webanwendung anfällig für SQL-Injection zu sein scheint, hilft ein kurzer Blick in die entsprechende Implementierung, um die Schwachstelle zu überprüfen. Außerdem ist die Erstellung eines Payloads, der die Auswirkungen demonstriert, wesentlich zeitsparender, wenn die Routinen, die die Eingaben im Backend verarbeiten, bekannt sind.
Im Gegensatz zum reinen Code Review berücksichtigen die Analyst*innen bei einem Whitebox-Pentest auch die Umgebung, in der eine Anwendung eingesetzt wird. Bei reinen Code Reviews erhalten wir oft das Feedback, dass eine Schwachstelle in der Produktivumgebung aufgrund der Architektur der tatsächlichen Umgebung, in der das Asset bereitgestellt wird, nicht ausgenutzt werden kann. Daher empfehlen wir, für den Whitebox-Pentest eine produktionsähnliche Umgebung bereitzustellen. So lassen sich erkannte Schwachstellen im Quellcode gezielt in der laufenden Anwendung prüfen, um die tatsächliche Ausnutzbarkeit und deren Auswirkungen besser einschätzen zu können.
Das Endergebnis eines jeden Pests ist der Bericht. Er dokumentiert die Ergebnisse der Analyst*innen so, dass die Entwickler*innen mögliche Probleme nachvollziehen können, und gibt Hinweise zu deren Behebung. Auch der Abschlussbericht kann davon profitieren, dass die Analyst*innen während der Analyse Zugriff auf den Quellcode haben: So können sie ihre Ergebnisse um Demonstrationen von Exploits zusammen mit dem verwundbaren Codeausschnitt ergänzen und so das zugrunde liegende Problem im Code deutlicher machen.
Falls beispielsweise ein Code Review erforderlich ist, kann der Whitebox-Ansatz als erweiterter Code Review gestaltet werden – mit zusätzlichem Zugriff auf die laufende Anwendung.. Gleichzeitig wird die Dokumentation durch Erkenntnisse aus der realen Umgebung bereichert – etwa durch Screenshots der Exploits. Der zeitliche Aufwand entspricht dabei in der Regel dem eines reinen Code Reviews.
Wenn ein Code Review erforderlich ist, beispielsweise aufgrund von Compliance-Vorgaben, kann der Whitebox-Ansatz als erweitertes Code Review gestaltet werden, bei dem die Analyst*innen zusätzlich Zugriff auf die laufende Anwendung erhalten. So lassen sich Annahmen über potenzielle Schwachstellen im Code anhand von Laufzeitinformationen schneller verifizieren oder widerlegen. Außerdem werden die Ergebnisse durch die in der Live-Umgebung festgestellten Schwachstellen ergänzt, und ihre Dokumentation wird deutlicher, z. B. durch Screenshots der Exploits. Der zeitliche Aufwand entspricht dabei in der Regel dem eines reinen Code Reviews.
Fazit
Der Whitebox-Ansatz bietet die umfassendste Sicherheitsabdeckung. Er ist flexibel konzipierbar und ermöglicht es, den Fokus entweder auf die laufende Anwendung oder den Quellcode zu legen. Selbst wenn nur begrenzte Testzeit zur Verfügung steht, lässt sich ein Greybox-Pentest erheblich verbessern, indem den Analyst*innen Zugang zum Quellcode ermöglicht wird.
Im Folgenden eine tabellarische Übersicht der drei Ansätze zur schnellen Einordnung:
| Zeiteffizienz | Testtiefe | Absolute Zeit (Kosten) | Idealer Anwendungsfall | |
| Code Review | Gering Die Überprüfung der gesamten Codebasis kann viel Zeit in Anspruch nehmen. | Hoch Gründliche Prüfung aller Codepfade, Logik, Eingabevalidierungen usw. | Hoch Kann sehr zeitaufwändig sein, insbesondere bei großen oder komplexen Codebasen. | In der frühen Entwicklungsphase oder wenn gezielt Probleme auf Code-Ebene behoben werden sollen. |
| Greybox Pentest | Medium Reines dynamisches Testen ist schneller als zusätzlich ein Code-Review. Zugriff auf den Code könnte den Prozess jedoch effizienter machen. | Medium Dynamisches Testen mit partiellen internen Informationen. Kann Probleme übersehen, die tiefes Codeverständnis erfordern (z. B. Fehler in der Anwendungslogik oder im Code versteckte Fehlkonfigurationen). | Niedrig In der Regel am schnellsten, da kein Code Review erfolgt und sich das Testen auf Laufzeit-Schwachstellen mit vorhandenen internen Informationen konzentriert. | Schnelles und kosteneffizientes Testen von Anwendungen mit normalen Schutzanforderungen oder wenn kein Quellcode verfügbar ist. |
| Whitebox Pentest | Hoch Code Review und Pentest machen sich gegenseitig effizienter. | Sehr hoch Kombination aus statischer und dynamischer Analyse, deckt Schwachstellen sowohl im Code als auch im Laufzeitverhalten ab. Je nach Ziel kann der Fokus auf dynamischem Testen der Anwendung oder statischer Codeanalyse liegen. | Hängt vom Design ab Der Zeitaufwand (und die Kosten) können fließend sein und reichen von einem Greybox-Pentest, bei dem Zeit für eine gezielte Validierung anhand von Code zur Überprüfung von Schwachstellen aufgewendet wird, bis hin zu fast der Summe eines eigenständigen Code Reviews und Pentests. | Anwendungen mit hohen Schutzanforderungen. Je nach Design geeignet für Assessments, die entweder vom Pentest oder vom Code Review getrieben sind. |
Sie möchten eine der oben dargestellten Sicherheitsanalysen in Ihrem Unternehmen durchführen oder haben Fragen? Kontaktieren Sie uns, wir unterstützen gern.
