Softwareentwicklung: Ein kritischer Blick auf statische Codeanalyse-Verfahren

Inhaltsverzeichnis

Die Marketingprospekte sind auf hochwertiges Papier gedruckt, die Liste von Anbietern füllt bei Wikipedia mehrere Bildschirmseiten: Wer den Anbietern von Werkzeugen zur statischen Codeanalyse (SCA) glaubt, der erfährt bei deren Einsatz geradezu sensationelle Ergebnisse. Doch leider deckt sich die Realität nicht immer mit den Erwartungen, und allzu oft halten die Resultate einer genaueren Untersuchung nicht stand. Manchmal scheint es gar, als hätte eine Wahrsagerin schlicht ihre Kristallkugel bemüht.

Weil aber Anwendungssicherheit ein wichtiger Bestandteil jeder ausgereiften Sicherheitsstrategie ist, sind Unternehmen bereit, erhebliche Mittel in SCA-Werkzeuge zu investieren, um Sicherheitsmängel in (ihrem) Quellcode zu erkennen. Deren Marketing verspricht ja auch breite, präzise und effiziente Testabdeckung. Und das wiegt vor allem das IT-Management bisweilen in trügerischer Sicherheit.

SCA-Produkte liefern sehr gute Ergebnisse, wenn es um menschliche Fehler vor allem von unerfahrenen Programmierern, unsauberen Code oder Compliance-Verstöße geht, ein Allheilmittel sind sie jedoch nicht. Wer glaubt, die SCA-Tools brächten eine signifikante Verbesserung der Sicherheit gegen Hacker, Malware oder gar böswillige Mitarbeiter, der täuscht sich. Dennoch findet man bei Gesprächen mit IT-Managern häufig die Einstellung "Unser Code ist sicher, wir haben doch teure SCA-Software im Einsatz", selbst bei Diskussionen über die neuesten APT-Angriffsvarianten. Klar, auch dynamische Tools und Profiler lassen sich austricksen, doch sprechen nicht immer alle Anbieter offen über die Grenzen der statischen Codeanalyse.

Das war die Leseprobe unseres heise-Plus-Artikels "Softwareentwicklung: Ein kritischer Blick auf statische Codeanalyse-Verfahren". Mit einem heise-Plus-Abo können Sie den ganzen Artikel lesen.