Werkzeuge zur Codeanalyse: Sicherheits- oder Hackertools?

Tools für die automatische Prüfung von Software sollten nicht zu komplex sein. Setzt man ein Tool zur statischen Codeanalyse, ein, so kann die Auswertung des Outputs sehr mühselig werden. Der Output basiert häufig auf Heuristiken. Falsche Positivmeldungen sind die Regel. Gestaltet ein Entwickler seinen Code so, dass das Tool möglichst wenig Auffälligkeiten meldet, kann dies wiederum zu Sicherheitsproblemen an anderer Stelle führen.

Hat man ein geeignetes Tool gefunden, so ist es wichtig, dass es vom Entwickler selbst häufig eingesetzt wird. Idealerweise nutzt man es mindestens einmal am Tag. Denn auch bei einem Tool gilt: Werden Sicherheitsprobleme zu spät im Entwicklungsprozess entdeckt, so führt das zu einem erhöhten Aufwand für das Redesign größerer Teile des Codes.

Wenn Black-Box-Tools, beispielsweise Fuzzing-Utilities, Sicherheitsprobleme entdecken, muss bedacht werden, dass diese Tools in der Regel aufzeigen, dass das Kind bereits in den Brunnen gefallen ist. Zwar lassen sich schnell Fixes finden, jedoch deuten positive Fuzzing-Tests darauf hin, dass es weitere Fehler gibt, die durch schlecht durchdachten Code verursacht werden.

Laut Brian Chess ist die statische Quellcodeanalyse auf dem Vormarsch, weil sie besser funktioniere als zufällig genierierter Fuzzing-Input, der nicht nachvollziehbar ist. Eine mit Fuzzing entdeckte Lücke ist nur schwierig auf bestimmte Codezeilen zurückzuführen. So könnte der Nischenmarkt in den nächsten Jahren weiter reifen. Auch andere Anbieter wie Coverity, Klocwork, Ounce oder Fortify haben sich auf ähnliche Dienstleistungen spezialisiert – mit feinen, aber für die Unternehmen durchaus gewichtigen Unterschieden.

Trotzdem sollte man auf Fuzzing nicht verzichten. Schließlich ist es die Standard-Methode, die Cyberkriminelle verwenden, um Sicherheitslücken in Webanwendungen zu finden.

In der letzten Zeit hat sich daneben auch die statische Objektcodeanalyse entwickelt. Anders als bei der Quellcodeanalyse untersucht ein solches Tool fertige Binaries oder Pseudo-Binaries, beispielsweise .NET- oder Java-Code. Während Quellcode meist geheimgehalten wird, sind Executables oft auch für Angreifer zugänglich, die dann ein solches Tool einsetzen und Schwachstellen herausfinden können.

Die ist beispielsweise bei Java-Applets oder Flash-Anwendungen der Fall, die immer auf den Rechner des Benutzers geladen werden. Sicherheitslücken können so mittels statischer Codeanalyse von Hackern automatisiert entdeckt werden.