Secure Code Review: Risiken frühzeitig erkennen

Secure Code Review vs. Testen der Anwendungssicherheit

Es ist wichtig, Secure Code Review nicht mit dem Testen der Anwendungssicherheit zu verwechseln. Es gibt viele Möglichkeiten, die Sicherheit einer Anwendung zu testen: Penetrationstests, Fuzzing, dynamische Tests und so weiter. Eine Überprüfung des Codes ist jedoch die einzige Möglichkeit, die gesamte Angriffsfläche unter die Lupe zu nehmen. Durch die Bewertung der Angriffsfläche lassen sich potenzielle Schwachstellen in Randfällen und schwer zugänglichen Anwendungszuständen leichter erkennen.

Secure Code Reviews können zu jedem Zeitpunkt des Softwareentwicklungsprozesses durchgeführt werden, finden aber am häufigsten in der Entwicklungsphase statt, wenn Fehler durch eine Kombination aus Automatisierung und manueller Überprüfung relativ leicht zu beheben sind. Dynamische Anwendungssicherheitstests und Penetrationstests hingegen erfordern ein laufendes System und Beispieldaten, um eine Überprüfung durchzuführen.

Wie ein Secure Code Review durchgeführt wird

Bei jeder Überprüfung von sicherem Code sollte auf die folgenden wichtigen Punkte geachtet werden:

• Fehler bei der Identität, Authentifizierung und Zugangskontrolle;
• mögliche Offenlegung sensibler Daten;
• unzulängliche Fehlerbehandlung und
• alle Arten von Injektionsfehlern.

Automatisierte Code-Scanning-Tools, die als statische Anwendungstests (SAST, Static Application Security Testing) bekannt sind, können mehrere häufige Kodierungsfehler identifizieren, die zu Schwachstellen führen. Solche Analysetools zeigen anfällige und veraltete Komponenten an und stellen sicher, dass der Code den Codierungsstandards des Unternehmens entspricht, indem sie Benennungskonventionen, Formatierung und Kommentare durchsetzen. Ein gut kommentierter und konsistenter Kodierungsstil erleichtert die manuelle Überprüfung des Codes erheblich.

Viele kommerzielle und Open-Source-SAST-Tools können direkt aus der integrierten Entwicklungsumgebung (Integrated Development Environment, IDE) des Entwicklers ausgeführt werden, während dieser programmiert. Dies bedeutet, dass Baseline-Tests überall dort ausgeführt werden können, wo der Entwickler den Code überprüfen möchte, was dazu beiträgt, viele grundlegende und häufige Fehler zu beseitigen, wie beispielsweise diejenigen, die in den OWASP Top Ten und den Top 25 Most Dangerous Software Weakness Enumeration's aufgeführt sind.

SAST-Tools verstehen jedoch keine dynamischen Datenflüsse und sind daher kaum in der Lage, Schwachstellen in komplexer Geschäftslogik und maßgeschneiderten Anwendungen zu erkennen. Manuelle Code-Inspektionen helfen den Entwicklern daher, sich auf sicherheitskritische Komponenten und die Umsetzung der projektspezifischen Sicherheitsanforderungen zu konzentrieren.

Die Anforderungen an den manuellen Code ergeben sich aus dem Bericht zur Bedrohungsmodellierung, der während der Softwareentwurfsphase erstellt wird. In diesen Berichten werden potenzielle Sicherheitsbedrohungen und Schwachstellen sowie die notwendigen Kontrollen zu deren Abschwächung identifiziert, um sicherzustellen, dass die Sicherheitsrichtlinien sowie die Datenschutz- und Regulierungsanforderungen erfüllt werden.

Der gesamte Code sollte einer Sicherheitsüberprüfung unterzogen werden, bevor Entwickler neuen Code in den Hauptzweig eines Projekts einbringen. Denken Sie daran, dass kleine Pull Requests leichter zu bewerten und zu überprüfen sind. Die Entwickler sollten das SAST-Tool und die Unit-Tests ausführen und alle von diesen Tests erzeugten Fehler und Warnungen korrigieren, bevor sie die Pull-Anfrage stellen. Im Idealfall generiert das SAST-Tool Metriken zur Codekomplexität. Zu komplexer Code ist für andere schwer zu verstehen und erschwert die Suche nach potenziellen Fehlern.

Eine manuelle Codeüberprüfung sollte von Personen durchgeführt werden, die in sicherem Code geschult sind und komplexen Kontroll- und Logikflüssen folgen können. Es sollte bestätigt werden, dass die Geschäftslogik und die Sicherheitsanforderungen korrekt implementiert sind. Mit einem Bericht zur Bedrohungsmodellierung und einem guten Verständnis der Funktionsweise der Anwendung ausgestattet, müssen die Prüfer nicht jede einzelne Codezeile überprüfen. Stattdessen sollten sie sich auf kritische Einstiegspunkte in die Anwendung konzentrieren, wie etwa Authentifizierung und Autorisierung, Datenvalidierung und -verschlüsselung, Benutzerkontoverwaltung und risikoreiche Geschäftslogik und Datenflüsse.

Dann gilt es, die Funktionalität des Codes zu überprüfen, um Schwachstellen in den Kontroll- oder Logikpfaden zu finden, die der ursprüngliche Programmierer nicht beachtet oder übersehen hat.

Sicherheitslücken treten am ehesten dann auf, wenn der Code die folgenden Punkte nicht korrekt behandelt:

• Authentifizierung
• Autorisierung
• Zugriffskontrolle
• Cookies und Token
• Eingabe- und Datenüberprüfung
• Verschlüsselung
• Fehler

Die Prüfer sollten auch sicherstellen, dass Injektions- und Cross-Site-Scripting-Angriffe nicht möglich sind und dass keine sensiblen Informationen, wie beispielsweise Passwörter, in den Code eingebettet sind.

Der Code kann mit dem Hauptprojekt zusammengeführt werden, sobald er die Prüfung bestanden hat. Wenn es jedoch Probleme gibt, sollte der Pull Request abgelehnt werden. Jede Überprüfung ist eine Gelegenheit für die Entwickler, ihr Sicherheitswissen zu verbessern und die Qualität ihrer nächsten Pull-Anfrage zu erhöhen.

Wenn dieselben Probleme häufig auftreten, sollten Sie die Schulung und das Bewusstsein für die Richtlinien erhöhen, um die Sicherheit und die Effizienz des Teams zu verbessern. Die durch diese Überprüfungen generierten Metriken - wie die Anzahl der abgelehnten Pull Requests, die Schwere der gefundenen Fehler und die Länge der Antwortzeiten - verbessern die Codequalität und die Produktivität in der Zukunft.

Software wird nie fehlerfrei sein, aber die Auswirkungen einer Sicherheitslücke können weitreichend und potenziell existenzbedrohend sein. Es müssen regelmäßig Sicherheitscodeüberprüfungen durchgeführt werden. Diese verbessern die Gesamtsicherheit einer Anwendung und sorgen für Kostenvorteile und Kennzahlen darüber, wie gut die Entwickler sicheren Code schreiben und häufige Fehler beseitigen.

Es ist besser, vor der Veröffentlichung sicherzustellen, dass der Code sicher ist, als zeitnah ein kritisches Update veröffentlichen zu müssen, dass die Benutzer vielleicht nie installieren.