Statische Analyse in kleinen Schritten übernehmen

Anbieter zum Thema

Parasoft® Deutschland GmbH

MicroConsult Academy GmbH

emlix GmbH

Die statische Analyse ist ein wichtiger Fixpunkt für Software-Entwickler und Fachleute für (funktionale) Sicherheit. Oft wird diese Methode zur Fehlersuche als aufwändig und mühselig wahrgenommen. Aber es gibt Tipps, um die Einrichtung einfacher zu gestalten.

Im Zuge der Digitalisierung wird es noch wichtiger, dass der Code, den wir erstellen, so gut wie möglich ist. Die statische Analyse ist ein wichtiger Fixpunkt für Software-Entwickler und Fachleute für (funktionale) Sicherheit. Wir wissen, dass wir uns mit der statischen Code-Analyse beschäftigen sollten. Einige sind sich im Klaren, dass sie uns hilft, andere mögen das Gefühl haben, dass sie ihnen aufgezwungen wird und eine Zeitverschwendung ist, mühsam oder nur mit geringem Nutzen. Auch wenn ich sagen möchte, dass dies nicht stimmt, haben die Leute mit ‚mühsam‘ leider Recht – aber es gibt Tipps, um die Einrichtung einfacher zu gestalten.

Zu große Brocken …

Wenn die statische Analyse langsam, 'noisy' (mit vielen falsch positiven Ergebnissen), schwer anzuwenden, arbeitsaufwendig oder nicht wertschöpfend ist, dann liegt das meist daran, dass man einen zu großen Brocken verarbeiten möchte. Genau darum geht es in diesem Beitrag. Darum konzentriere ich mich auf einen Fehler, den viele Erstanwender der statischen Analyse machen - sie versuchen, zu viel zu früh zu tun. Insgesamt ist es für den Erfolg entscheidend, den Arbeitsablauf und die Konfiguration der statischen Analyse von Anfang an richtig zu gestalten - weniger Aufwand, mehr Nutzen. Der erste Schritt besteht darin, sicherzustellen, dass Sie das passende Tool für Ihr Unternehmen haben.

Klein anfangen

Sobald Sie das statische Code-Analyse-Tool ausgewählt haben, müssen Sie es konfigurieren. Welche Checker möchten Sie ausführen? Ich würde eine einfache Richtlinie befolgen: Es ist besser, mit einem kleinen Satz von Checkern zu beginnen, wenn nötig sogar nur mit einem einzigen, und sicherzustellen, dass Sie und Ihr Team Ihre statischen Analysefähigkeiten und Ihren Arbeitsablauf verfeinern und dabei nachweislich Nutzen aus dem Aufwand ziehen. Die gängige Alternative ist das Einschalten von hundert oder mehr Checkern, die umfangreiche Berichte erstellen, die nur sporadisch nachbereitet werden.

Statische Analysewerkzeuge können viel ‚Noise‘ erzeugen, bis sie richtig angepasst sind. Wenn ich von einem zu großen Brocken spreche, übertönt das Rauschen (auch als 'falsch positiv' bezeichnet) die wichtigen Warnungen. Eine frühe Einführung beginnt manchmal als akademische Beschäftigung mit der Absicht einer frühzeitigen Untersuchung, um ein Gefühl dafür zu bekommen, wie viele Fehler sich in der Codebasis befinden. Diese Methode berücksichtigt nicht den Arbeitsablauf der Entwickler und ihre alltägliche Verwendung von Tools. Sie entspricht auch nicht dem pragmatischen Bedürfnis, Software zu schreiben, zu testen und schneller fertig zu werden.

Der beste Ansatz ist, klein anzufangen mit dem Ziel, die Qualität des Codes ständig und schrittweise zu verbessern. Beseitigen Sie Ihre schlimmsten kritischen Code-Probleme und suchen Sie dann nach anderen Problemen, die zwar immer noch wichtig, aber vielleicht nicht ganz so gefährlich sind. Werfen wir einen Blick auf die Praxis…

Die großen Probleme zuerst

Manchmal versuchen Unternehmen, im Konsens eine Konfigurationsliste von Checkern zusammenzustellen, die auf einer langen Liste aller möglichen Checker basiert, die ein statisches Analysetool bietet. Obwohl plausibel, aber bedenkt man, dass beispielsweise Parasoft-Tools über mehr als tausend Checker verfügen, so ist der Ansatz doch fehlerhaft. Denn er konzentriert sich darauf, was das Tool leisten kann, und nicht darauf, die wirklichen Probleme anzugehen, mit denen Ihre Anwendung aufgrund des Kundensupports, der erwarteten Umgebung usw. konfrontiert ist.

Teams können viel Zeit damit verbringen, Verstöße von Prüferinnen und Prüfern aufzuspüren, die nicht viel Nutzen bringen, auch wenn der Fehlertyp - abstrakt gesehen - wichtig erscheint. Ausschlaggebend ist, die statische Analyse mit den wirklichen Problemen zu verbinden, die das Team lösen muss oder mit denen es zu rechnen hat. Die Liste der Checker einzugrenzen ist wichtig, kann aber für ein Team oder eben erst begonnenes Projekt immer noch zu viele Verstöße produzieren. Also müssen Sie den Umfang, für den Sie sich entscheiden, prüfen.

Umfang der statischen Analyse begrenzen

Eine gute Möglichkeit, den gewählten Umfang zu minimieren (es geht nicht nur um die Anzahl der Checker), besteht darin, zu evaluieren, gegen welchen Code Sie ihn ausführen. Die meisten Projekte beinhalten heutzutage bestehende, veraltete oder vererbte Codebasen. Sind diese groß genug, ist es nicht praktikabel, diesen Code statisch zu analysieren und Ressourcen für das Beheben von Problemen aufzuwenden. Stattdessen sollten Sie den Umfang in Bezug auf die Menge des analysierten Codes begrenzen.

Ein gängiger Ansatz besteht darin, die Maßnahmen bei gemeldeten Warnungen auf neu entwickelten oder kürzlich geänderten Code zu beschränken. Zum Beispiel entscheidet der Teamleiter, dass beim nächsten Sprint der gesamte neue Code mit einer Startmenge priorisierter Prüfer analysiert werden soll. Anhand des ersten Satzes von Analyseberichten wird der erforderliche Arbeitsaufwand abgeschätzt. Ist dies für einen Sprint zu viel, kann die Analyse weiter eingeschränkt werden. Wenn dieser Ansatz andererseits nicht genügend Warnungen liefert oder Qualitätsziele verfehlt werden, erhöhen Sie den Umfang.

Dahinter steht wieder: Nehmen Sie eine kleine aber wertvolle Menge. Reparieren Sie sie, führen Sie aus, bauen Sie sie in Ihren täglichen Prozess und in Ihre Arbeitskultur ein. Ergänzen sie die Menge langsam. Setzen Sie immer ein paar Checker mehr, bis Sie schließlich Ihr angestrebtes Ziel erreicht haben, nämlich alle zu Beginn ausgewählten Checker.

Den Wert der statischen Analyse steigern

Klein anzufangen ist mehr als die Kontrolle eines überschaubaren Arbeitsablaufs. Es hilft auch den Entwicklern, die neu in der Technik und im Tool sind, den Wert schnell zu erkennen. Indem man ihnen zuerst kritische Erkenntnisse liefert, sehen sie zu behebende Fehler und verstehen, wie diese bei Tests oder Code-Reviews möglicherweise übersehen wurden. Wenn Sie die Analyse steigern, erhalten die Entwickler immer die verwertbarsten Ergebnisse. Das Ziel lautet, niemals geringwertige Warnungen an Entwickler zu geben. Denn das wäre eine Verschwendung ihrer Zeit und Tools, zudem sollten diese über die Prozesse herausgefiltert werden.

Triage vermeiden

Es ist nicht ungewöhnlich, dass bei der Diskussion von Ergebnissen der statischen Code-Analyse eine Bewertung (Triage) zur Sprache kommt. Zur Triage kommt es im wirklichen Leben nur dann, wenn ein Prozess überfordert ist. Software-Teams, die zu viel riskieren, führen statische Analysetools auf einer großen Code-Basis mit aktivierten Standard-Checkern aus und erhalten unweigerlich viele Warnungen. Sie versuchen dann, diese durchzugehen und sagen: Welche muss ich korrigieren? Welche sind die wichtigsten? Das ist mühsam, übermäßig subjektiv, fehleranfällig und meistens unnötig.

Die Bewertung sollten stattdessen die Tools übernehmen. Tuns sie das nicht, haben Sie wahrscheinlich das falsche Werkzeug, die falsche Konfiguration oder den falschen Ansatz. Ein modernes statisches Analysewerkzeug muss in der Lage sein, Warnungen nach Schweregrad, Priorität und inhärentem Risiko zu filtern. Lassen Sie sich nicht vom Tool selbst dazu zwingen, einen zu großen Umfang auszuwählen.

Hoffentlich finden Sie diese Ratschläge nützlich. Die erfolgreiche Einführung der statischen Analyse erfordert kleine Schritte, um Fortschritte bei der Verbesserung von Qualität, Sicherheit und Schutz zu erzielen. Begrenzen Sie, wie viel Ihr Team bearbeitet, indem Sie den Umfang der Analyse sowohl in Bezug auf die Checker als auch auf die Menge des Codes einschränken - jeder kann den Wert erkennen. Vermeidet man einen zu großen Umfang, verhindert das viele der üblichen Beschwerden über statische Analysewerkzeuge. Kontinuierliche und inkrementelle Verbesserungen helfen allen, den Umgang mit statischen Analysen zu erlernen und den Return-on-Investment zu erhöhen.

Static Application Security Testing (SAST) – Statische Analyse nicht erst am Ende beginnen

Statische Code-Analyse in Continuous-Integration und -Deployment-Prozessen

Statische und dynamische Codeanalyse in einem kontinuierlichen Testprozess

(ID:46920724)