Schwerpunkte

Funktionale Sicherheit von Software

Statische Code-Analyse für dynamische Teams

04. August 2021, 06:00 Uhr   |  Von Mirosław Zielinski

Statische Code-Analyse für dynamische Teams
© Blue Planet Studio | Shutterstock

Der Einsatz der statischen Code-Analyse stellt Entwicklerteams vor Herausforderungen: schnelle Rückkopplung, das Herausfiltern unwichtiger Probleme, der Umgang mit dynamischen Git-basierten Ansätzen. Mit der richtigen Strategie lässt sich der Aufwand verringern – wie eine Studie von Parasoft zeigt.

Die produktivste Behandlung von Ergebnissen der statischen Analyse ist deren Meldung kurz nach der Erstellung des Quellcodes, wenn die Entwickler den Code noch frisch im Gedächtnis haben und die Kosten niedrig sind. Teams versuchen, den Wert der statischen Analyse zu maximieren, indem sie die Dauer der Analysesitzungen reduzieren. Allerdings ist diese Erwartung unrealistisch, da einige der statischen Analyseprogramme ein zeitaufwendiges Tracing der Graphen des Datenflusses und der Steuerung erfordern.

Die nachfolgend vorgestellten Strategien verkürzen die Zeitdauer der statischen Analyse und maximieren deren Wert, indem sie die Produktivität der Entwickler verbessern. Als Grundvoraussetzung für diese Strategien wird die statische Analyse in zwei Phasen des Entwicklungsprozesses ausgeführt:

  • Pre-Commit (vor der Übergabe), also während der Code-Entwicklung lokal am Desktop-PC der Entwickler. Hier wird Geschwindigkeit der Genauigkeit und Vollständigkeit vorgezogen, damit die Entwickler nicht auf das Tool warten müssen.
  • Bei Post-Commit als Teil der CI/CD-Pipelines werden Genauigkeit und Vollständigkeit gegenüber der Geschwindigkeit der Analyse bevorzugt, um die Einhaltung der Unternehmensstandards zu gewährleisten.

Lokale Scans mit Fokus auf Single-Translation-Einheiten

Checker für statische Analysen arbeiten entweder auf der Ebene der Übersetzungseinheiten oder auf der Systemebene, wo einige der Probleme naturgemäß ein »Verständnis« des Datenverkehrs und des Steuerungsprozesses zwischen den Dateien erfordern. Der Programmierstandard MISRA C 2012 [1] unterscheidet zwischen »Single Translation Unit« und »System Level«-Analyseumfang. Der Standard enthält 39 Richtlinien, die eine »Sicht auf Systemebene« erfordern, und 104 Richtlinien, die eine »Sicht auf eine einzelne Übersetzungseinheit« verlangen.

Prüfprogramme für die statische Analyse, die Verletzungen der Single-Translation-Unit-Richtlinien erkennen, sind in der Regel einfacher und weniger zeitaufwendig als System-Level-Richtlinien. Checker für einzelne Übersetzungseinheiten finden für gewöhnlich mehr Probleme einfacher Art, wogegen Checker auf Systemebene weniger Fehler finden, die in der Regel schwerwiegender sind.

Die Strategie geht davon aus, dass für die einzelne Übersetzungseinheit aktivierte Checker von den auf der System­ebene laufenden getrennt sind, und als zwei Konfigurationen dargestellt werden. Die Checker-Konfiguration für einzelne Übersetzungseinheiten wird bei schnellen lokalen Scans auf dem Rechner des Entwicklers angewendet. Für die System­ebene konfiguriert werden Checker auf leistungsfähigeren Rechnern eingesetzt, um Programmierstandards in den
CI/CD-Pipelines durchzusetzen.

Konzept der Anwendung von zwei Checker-Konfigurationen für die statische Code-Analyse.
© Parasoft

Bild 1. Konzept der Anwendung von zwei Checker-Konfigurationen für die statische Code-Analyse.

Für das Experiment, das mit der internen Code-Basis von Parasoft durchgeführt wurde, dienten die Richtlinien von MISRA C 2012. Checker fanden 87 % der gemeldeten Verstöße bei einzelnen Übersetzungseinheiten, die restlichen 13 % wurden von Checkern auf Systemebene identifiziert (Bild 1).

Fokussierung der statischen Analyse nur auf die geänderten Dateien

Bei lokalen Scans, die mit den Single-Translation-Unit-Checkern für die statische Code-Analyse durchgeführt werden, lässt sich die Analysezeit weiter reduzieren, indem der Scan nur auf die geänderten Dateien fokussiert wird. Dieser Ansatz geht davon aus, dass Entwickler, die an einer kleinen schrittweisen Code-Änderung arbeiten, an den Ergebnissen der statischen Analyse interessiert sind, die für ihre Code-Änderungen relevant sind. Diese begrenzten Scans nehmen viel weniger Zeit in Anspruch und liefern eine schnellere Rückmeldung, sodass Entwickler die Ergebnisse der statischen Code-Analyse sofort bearbeiten können, ohne den Kontext zu wechseln. Kompliziertere Probleme, die aufgrund von sich dateiübergreifend auswirkenden Code-Änderungen auftreten, werden in den CI/CD-Scans erkannt.

In der Parasoft-Studie wurde die Integration der statischen Code-Analyse von Parasoft mit dem Versionskontrollsystem Git erweitert, um den Analyseumfang automatisch so einzuschränken, dass nur geänderte Dateien berücksichtigt werden.

Bei dieser Methode gibt es verschiedene Strategien, um festzustellen, welche Dateien sich geändert haben. Für die vollständige Automatisierung ist die Integration mit dem Verwaltungssystem zur Quellcode-Versionskontrolle notwendig.

Analyse der lokal geänderten Dateien

Das statische Analysewerkzeug vergleicht die lokal auf dem Laufwerk gespeicherten Dateien mit dem referenzierten Zustand im aktuellen Zweig in der Versionsverwaltung. Nur die lokal geänderten Dateien werden als Eingabe für die statische Analyse ausgewählt.

Analyse von Dateien, die sich zwischen Zweigen unterscheiden

Das statische Analysewerkzeug erhält Informationen über den »Referenz«-Zweig im Versionskontrollsystem und führt einen automatisierten Vergleich zwischen dem aktuellen Entwicklungszweig und dem Referenzzweig durch. Nur die Dateien, die sich zwischen dem aktuellen Zweig und dem Referenzzweig unterscheiden, werden als Eingabe für die statische Analyse ausgewählt.

Bei beiden Strategien können Header-Dateien potenziell problematisch sein. Um die Analysedauer zu verkürzen, soll das Werkzeug den Analyseumfang automatisch auf nur modifizierte Dateien beschränken. Zum Problem kommt es, wenn ein Satz modifizierter Dateien Header-Dateien beinhaltet, die von keiner der Quelldateien in diesem Satz enthalten sind. Statische Code-Analysewerkzeuge arbeiten mit Übersetzungseinheiten als Eingaben. Header-Dateien allein werden nicht als gültige Eingabe für die Analyse betrachtet, sondern immer im Zusammenhang mit der Quelldatei analysiert, in der sie enthalten sind.

Oftmals enthält der automatisch eingeschränkte Analysebereich Header-Dateien, die von keiner der Quelldateien im Analysebereich eingeschlossen sind. Um zu verhindern, dass der geänderte Header nicht analysiert wird, wird eine Methode implementiert, die den Analysebereich automatisch auf Quelldateien mit einer geänderten Header-Datei erweitert.

Getestet wurden zwei Ansätze zur automatischen Erweiterung des Analysebereichs: Zunächst wurde der Analyseumfang um alle Quelldateien erweitert, die eine modifizierte Header-Datei enthalten. Dann wurde der Analyseumfang um eine zufällig ausgewählte Quelldatei mit einer modifizierten Header-Datei ergänzt.

Beim ersten Ansatz ist die Wahrscheinlichkeit geringer, dass Tool-Anwender Verletzungen übersehen. Dennoch kann diese Vorgehensweise die Dauer der Analysesitzungen erheblich verlängern. Der zweite Ansatz birgt ein gewisses Risiko für das Übersehen eines Problems oder einer Problemgruppe. Allerdings sind die Auswirkungen auf die Dauer der statischen Analysesitzung minimal, und die vollständigen CI/CD-Scans eliminieren das Risiko, eine wichtige Verletzung zu überspringen.

Aus den mit der internen Code-Basis von Parasoft ausgeführten Experimenten folgt: Die Strategie, bei der für jede geänderte Header-Datei automatisch nur eine zufällig ausgewählte Quelldatei zum Analyseumfang hinzugefügt wird, ist aus Geschwindigkeitsgründen vorzuziehen. Die niedrige Anzahl von beim lokalen Scan übersehenen Verstößen wurde bei den vollständigen CI/CD-Scans erfolgreich erkannt.

Seite 1 von 2

1. Statische Code-Analyse für dynamische Teams
2. Konzentration auf neue Ergebnisse der statischen Code-Analyse

Auf Facebook teilen Auf Twitter teilen Auf Linkedin teilen Via Mail teilen

Verwandte Artikel

Parasoft Corp.