Statische Code-Analyse

Grundidee und Einordnung

Die statische Code-Analyse, kurz statische Analyse, ist ein statisches Software-Testverfahren zur Übersetzungszeit. Dabei wird Quelltext formalen Prüfungen unterzogen, bevor die Software ausgeführt wird, etwa in einem Modultest. So lassen sich bestimmte Fehler früh erkennen.

Sie gehört zu den falsifizierenden Verfahren: Geprüft wird, ob Fehler vorhanden sind. In Anlehnung an das Programm Lint heißt der Vorgang auch „linten“ beziehungsweise „linting“.

Abgrenzung zu anderen Prüfungen

Statische Code-Analyse ist ein White-Box-Testverfahren, weil dafür der Quellcode benötigt wird. Die Prüfung kann manuell durch Inspektion oder automatisch durch Programme erfolgen. „Statisch“ bedeutet, dass Algorithmen und Daten der Software in ihrer formulierten Form vorliegen und nicht laufen müssen.

Vorläufer sind Prüfverfahren der normierten Programmierung und Style Checker, die Code-Muster erkennen. Die dynamische Code-Analyse benötigt dagegen ein laufendes Programm; ein Beispiel für ein dynamisches Pendant zur Analyse zur Compilezeit ist Profiling zur Laufzeit.

Prüfverfahren und erkennbare Fehler

Entwickler können Quelltext sorgfältig lesen; viele Fehler lassen sich aber auch werkzeuggestützt oder automatisch finden. Die Verfahren reichen von einfachen Coding-Standards, etwa nur einem return-Statement pro Funktion, über Prüfungen von Typumwandlungen und Bereichsgrenzen bis zur Suche nach Speicherlecks und zur technischen Verifikation von Quelltext.

Einfache Prüfungen sind oft bereits im Compiler integriert, zum Beispiel die Kontrolle, ob eine Variable initialisiert wurde. Stilistische Methoden bewerten Programmierstil nach Ästhetik und Pragmatik; häufig geben sie nur ignorierbare Warnungen aus. Profiler erzeugen zusätzlichen Objektcode und liefern Aussagen über Codeabdeckung und Codefrequentierung.

Semantik-basierte statische Analysatoren prüfen große Codebereiche systematisch auf angreifbare Stellen. Dazu zählen Race Conditions (Wettlaufsituationen), Formatstring-Angriffe, Pufferüberläufe, Speicherlecks, ungültige Arrayzugriffe außerhalb der Grenzen („Out of Bound“) und Division durch 0.

Für sicherheitsrelevante Software schreiben Safety-Normen den Einsatz statischer Analyseverfahren vor, darunter ISO 26262, IEC 61508 und DO-178C.

Werkzeuge und Einsatzorte

Zu den genannten klassischen Werkzeugen gehören Lint, Checkstyle, FindBugs und PMD für Java, Cppcheck für C/C++, Splint für C sowie FxCop und StyleCop für C#. Werkzeuge können eigenständig laufen oder in Entwicklungsumgebungen und Build Server integriert sein.

Sie prüfen nicht nur Kodierungsregeln wie MISRA-C-Regeln, sondern erkennen auch funktionale und technische Fehler, potenzielle Bugs und qualitative Schwachstellen im Code. Solche Schwachstellen heißen Code-Smells; ein Beispiel ist duplizierter Code, auch Software-Klone genannt.

Einige Werkzeuge, etwa Rough Auditing Tool for Security (RATS), suchen sicherheitsrelevante Fehler wie Pufferüberläufe oder Wettlaufsituationen. Andere prüfen Architekturmetriken und die Übereinstimmung des Codes mit einer Architekturspezifikation, beispielsweise Axivion Bauhaus Suite, ConQAT, Teamscale, Sonargraph und Sotograph.