Prüfstand für Testwerkzeuge: Codeanalyse im Praxiseinsatz
Die statische Codeanalyse hilft beim Auffinden einiger kritischer Fehler. Einige der Werkzeuge zeigen im Praxistests ihr Können.
- Marc Heuse
Im Jahr 2005 hat Microsoft eine Ergänzung zum Softwareentwicklungsprozess vorgestellt: den Secure Development Lifecycle (SDLC). Er war der neue und zentrale Baustein für die Entwicklung von Windows Vista, das planmäßig sicherste Windows-Betriebssystem bis dahin, nachdem Microsoft viel schlechte Presse, Spott und Hohn für Windows XP und den Umgang mit Sicherheitsproblemen generell geerntet hatte – auch für Windows NT. Nicht zuletzt hatten Behörden gedroht, zu Linux zu wechseln, sollte es in zukünftigen Versionen nicht besser um die Sicherheit bestellt sein.
Microsoft hat 2008 das gesamte Konzept, die Hintergrunddokumentation und unterstützende Software für den Prozess veröffentlicht. Bis heute entwickelt das Unternehmen nach diesem Prozess und aktualisiert ihn regelmäßig unter anderem für die Anwendung in agilen Entwicklungsprozessen.
Nach nunmehr fast 15 Jahren führen große Teile der Softwareindustrie langsam sichere Entwicklungsprozesse ein. Grund dafür sind weniger die erhöhte Sicherheit und die verringerten Folgekosten als vielmehr die Vorschriften in den Ausschreibungsbedingungen zahlreicher großer Hersteller der Automobil-, Aeronautik-, Medizin- und Finanzbranche.
In den 17 vorgeschriebenen und einigen optionalen Prozessschritten enthalten ist der Punkt statische Quellcodeanalyse (Static Code Analysis, SCA). Sie ist eine der wenigen Aufgaben, die sich zum Großteil softwaretechnisch lösen lassen. Den Tools haftet jedoch das Vorurteil an, teuer zu sein, viel Konfigurationsarbeit mit sich zu bringen und dabei wenig verwertbare Ergebnisse zu liefern. Einige Teams haben dagegen die Erwartung, durch den Einsatz von SCA nahezu keine Sicherheitsprobleme in der Software mehr zu haben. Zeit für einen Realitätscheck.
Schwierige Testvoraussetzung
Es gibt über 25 Softwareprodukte für die statische Quellcodeanalyse, die sich deutlich voneinander unterscheiden: von der Art und Weise, wie sie vorgehen, nach welchen Fehlertypen sie suchen können und welche Programmiersprachen sie unterstützen. Und viele Hersteller scheuen den Vergleich.
Dieser Artikel möchte beispielhaft einige Produkte in vergleichbarer Form untersuchen. Die zu analysierende Programmiersprache ist C beziehungsweise C++. Der Autor hat 20 Firmen angeschrieben, ob sie an einem Vergleichstest auf heise Developer teilnehmen möchten. Manche bestanden darauf, die Tests selbst vorzunehmen, andere wollten den Test nur für Java-Code. Weitere Firmen haben für den deutschen Markt schlichtweg keinen Ansprechpartner. Schließlich blieben nur vier Anbieter übrig, die bereit waren, sich unabhängig unter die Haube schauen zu lassen. Daraus ergibt sich der Testreigen aus MathWorks Polyspace Bug Finder/Code Prover, Parasoft C/C++test, Perforce Klocwork und Viva64 PVS Studio. Den Kreis der kommerziellen Tools ergänzen die quelloffenen Programme cppcheck und clang-analyzer.
Der ursprünglich Plan sah vor, den Werkzeugen komplexe Programme mit eingebauten Fehlern zum Prüfen zu geben, um die Erkennungsquote zu bewerten. Die Realität brachte jedoch schnell zwei Erkenntnisse: Fast alle Werkzeuge benötigen umfangreiche Anpassungen der Regeln, damit Tester nicht in Meldungen ertrinken, und jedes Tool findet unterschiedliche Sicherheitsprobleme, die die jeweils anderen übersehen. Mit dem Aufbau lässt sich ein Vergleich kaum fair gestalten.
Daher entschloss sich der Autor, stattdessen einfachen, fehlerbehafteten Code zu erstellen und aufzuzeigen, was die jeweiligen Programme finden. Außerdem hielt er Rücksprache mit den Herstellern, um sicherzugehen, dass das Übersehen von Fehlern nicht in einer Fehlkonfiguration begründet ist.
Die im Artikel vorgestellten Programmtexte sind aus Gründen der besseren Lesbarkeit teilweise vereinfacht und verzichten auf Includes.
Über die Schulter geschaut
Im ersten Schritt arbeiten alle Programme ähnlich: Sie klinken sich in den Build-Prozess ein und lernen dadurch die gesetzten Optionen für die Compiler, Includes und deren Speicherort sowie die beim Link-Vorgang genutzten Bibliotheken. Danach gehen die Werkzeuge allerdings recht unterschiedlich vor, um Probleme zu identifizieren.
