Tool-Check

Wertmessung: Wie finde ich das richtige statische Analysetools

| Autor / Redakteur: Mark Hermeling / Redaktion IoT

Wertmessung von statischen Analysetools
Wertmessung von statischen Analysetools (Bild: Pixabay)

Moderne statische Analysetools sind beliebt, weil sie schwere Programmierfehler finden können. Im Gegensatz zur traditionellen dynamischen Prüfung wird der Code nie ausgeführt, also sind keine Testfälle notwendig. Das ermöglicht ihren Einsatz schon früh im Entwicklungsprozess.

Mit der bestehenden Technologie und heute verfügbaren Ressourcen ist es unvermeidbar, dass diese Tools nicht perfekt funktionieren - bei den meisten nicht trivialen Programmen kann praktisch kein Tool alle Bugs finden (z.B. gibt es False Negatives), und alle dieser Tools könnten auch Probleme in fehlerfreiem Code melden (z.B. False Positives).

Beim Einsatz bzw. der Kaufentscheidung sollten Anwender einen Kompromiss treffen, um die Vorteile des Tools zu maximieren. Viele Faktoren beeinflussen diese Entscheidung. Dieser Beitrag beschreibt ein Modell, mit dem Anwender den Vorteil eines statischen Analysetools messen und dessen beste Konfiguration einschätzen können. Gleichungen aus dem Modell ermöglichen den Nutzern den Vergleich mit Tools, die Warnungen einfach nur zählen.

Terminologie

Recall – die Fähigkeit echte Fehler (True Positives) aufzufinden. Wird definiert als Wahrscheinlichkeit, dass ein Tool einen Fehler findet. Ein Werkzeug mit 100% Recall findet alle Fehler und gilt als zuverlässig.

Precision  - die Fähigkeit False Positives auszuschließen. Bezeichnet die Wahrscheinlichkeit, dass ein Ergebnis einem echten Fehler entspricht.

Precision ist einfach messbar, sobald Warnungen die Sichtung durchlaufen haben, aber die  genaue Messung des Recalls ist wegen der unbekannten Anzahl an False Negatives schwierig. Diese setzt voraus, dass man genau weiß, wie viele Fehler der Code unter Analyse enthält.

Wichtig ist: Precision und Recall können in Fehlerklassen enorm variieren, sogar für ein einzelnes Tool. Ein Werkzeug, das Buffer Overruns ausgezeichnet entdeckt, muss Resource Leaks nicht gezwungenermaßen sehr gut auffinden.

Faktor Mensch

Statische Analysetools sind so gestaltet, dass sie Ergebnisse erzielen, die in Folge eine Sichtung durch Menschen durchlaufen. Es ist möglich, die menschliche Arbeitslast durch automatisch priorisierte Warnungen je nach Risiko zu reduzieren. Ist dies einmal erfolgt, bestehen die verbleibenden Warnungen immer noch aus einigen True und False Positives,  die sich nur mit menschlicher Einschätzung trennen lassen.

Das Modell

Viele Faktoren tragen zur Wirtschaftlichkeit von statischen Analysetools bei, und die Beziehungen zwischen ihnen sind nicht immer einfach. Als grobe Annäherung versucht das nachfolgend vorgestellte Modell, die wichtigen Aspekte des Prozesses festzuhalten. (Um es nützlich und zugleich einfach zu halten, sind einige Feinheiten nicht berücksichtigt.)

Die Funktion f(P) zeigt die Precision eines Tools (Wahrscheinlichkeit, dass ein True Positive korrekt erkannt wird). Die Effektivität (effectiveness) eines Tools, z.B. die Anzahl der entdeckten und als solche erkannten echten Fehler, ist demnach:

            N × R × f(P)

Diese Definitionen zeigen auf, wie gut einige Beispieltools echte Fehler finden.

Betrachten wir nun drei hypothetische Tools (oder Konfigurationen desselben Tools), die einen Platz im erwähnten Recall-Genauigkeitsspektrum einnehmen:

Tool A findet Fehler einigermaßen gut, mit einem Recall von 60%. Bei der Hälfte der gemeldeten Recalls handelt es sich um False Positives.

Tool B arbeitet mit einer Precision von 80%, ist also sehr gut bei der Vermeidung von False Positives; aber es findet nur 30% der echten Fehler.

Tool C hat einen Recall von 95%, bietet also äußerst gute Fehlerfindung, aber seine Precision beträgt nur 10%.

Nützlich ist auch die Betrachtung von zwei anderen Fällen: Das ‚mythologisch perfekte‘  Tool, das alle Fehler ohne False Positives findet, und der fehlende Einsatz eines statischen Analysetools. Abbildung 2 fasst die Eigenschaften der Tools zusammen:

 Tool ATool BTool CNo ToolPerfect Tool
Recall60%30%95%0%100%
Precision50%80%10%0%100%
Costs20.000$20.000$20.000$0$0$

 

Nun nehmen wir an, dass die Anzahl der Fehler, die von anderen Methoden nicht entdeckt wurden, N=100 ist. Abbildung 3 zeigt die Rohergebnisse der Tools:

Entscheidend ist die Interpretation dieser Rohergebnisse: Wie erwähnt werden einige echte Defekte nicht als solche erkannt. Abb. 4 zeigt zwei Balkendiagramme der Fehler, die in der Anwendung im linearen (links) und kubischen (rechts) Modell zur Erkennung von True Positives verbleiben.

Daraus ergibt sich, dass ein Sweet Spot zwischen Precision und Recall existiert. Tool A hatte eine schlechtere Precision als Tool B und einen schlechteren Recall als Tool C, aber im Einsatz bleiben weniger Fehler in der Anwendung.

Wirtschaftlichkeit

Wichtig im Hinblick auf die wirtschaftlichen Aspekte des Prozesses sind folgende Faktoren:

Wahrscheinlichkeit und Kosten eines durch einen Fehler hervorgerufenen Zwischenfalls Nicht alle Software-Fehler und Sicherheitsschwachstellen führen zu ernsten Problemen, sondern viele bleiben bis zu ihrer Entfernung im Zuge einer Routinewartung unentdeckt. Das lässt sich modellieren durch die Zuordnung einer Wahrscheinlichkeit, dass ein Fehler einen Zwischenfall im Lebenszyklus eines Produkts auslöst: Verursacht ein Fehler einen Zwischenfall, führt der Umgang damit zu Kosten, die enorm variieren können. Die Zahlen in Abb. 5 basieren auf einer Wahrscheinlichkeit von 5% und beispielhaften Ausgaben von 40.000 US-Dollar (USD) für den Zwischenfall.

Die Zeit für die Fehlerkorrektur. Unabhängig davon, ob ein Fehler zu einem Zwischenfall führt, entstehen Entwicklungskosten für seine Reparatur. Früh entdeckte Defekte sind wesentlich günstiger zu beheben als die zu einem späteren Zeitpunkt gefundenen, weil das Produkt u.U. neu getestet werden muss. In den unten angeführten Kalkulationen braucht es 4 Stunden, um einen Fehler früh im Entwicklungszyklus zu reparieren, gegenüber 20 für dessen Korrektur nach dem Einsatz. Die Zahlen basieren auf einem 2002 NIST Report [1].

Die Zeit für die Sichtung von Warnungen. Die Warnmeldung eines statischen Analysetools zu sichten, ist zeitintensiv. Der Großteil geht schnell, aber schwierige Reports können ausführliche Passagen über den Code, mehrere Umleitungen und komplexe Beziehungen zwischen Variablen enthalten. Erfahrungsgemäß dauert eine Triage durchschnittlich 10 Minuten pro Warnung [6].

Entwicklungsaufwand. Schlägt hier mit USD 75/Std. (einschl. Gemeinkosten) zu Buche.

Kosten für die Tool-Entwicklung. Darin eingeschlossen sind die Ausgaben für den Kauf und den Einsatz des Tools auf dem Code. Im Modell werden Tools A, B und C mit USD 20.000 angesetzt; keine weiteren Kosten fallen an.

Mit diesen Variablen als Input setzt sich der Preis für den Einsatz eines Tools zusammen aus dem Kaufpreis und der Bereitstellung, Engineeringaufwand für die Sichtung des Berichts und die Behebung der gefundenen Fehler. Dazu kommen die Ausgaben für den Umgang mit Fehlern, die vom Tool nicht gefunden werden - vom Auffinden bis zur Handhabung aller ausgelösten Zwischenfälle.

Um den Nutzen des Tools zu bewerten, eignet sich der Vergleich zwischen diesen Kosten und jenen aus dem Umgang mit entdeckten Fehlern, wenn kein Tool zum Einsatz gekommen wäre. Unter der Annahme des kubischen Modells zur Erkennung von True Positives zeigt Abb. 5 die Kosten-Aufschlüsselung und Vorteile.

Wieder bietet das Tool, das eine vernünftige Balance zwischen Precision und Recall erzielt, den größten Nutzen für den Einsatz. Tool A ist vorteilhafter, auch wenn es nur rund halb so viele echte Fehler wie Tool C gefunden hat, und berichtet acht Mal mehr False Positives als Tool B. Interessant ist auch, dass Tool C knapp unter dem Break-Even Point steht, auch wenn es den höchsten Recall erzielt.

Die jeweilige Reihenfolge der Tools ist relativ unabhängig von den tatsächlichen Werten bei Kosten und Wahrscheinlichkeit eines Zwischenfalls, vorausgesetzt die Aufwendungen für einen Zwischenfall überschreiten die Ausgaben zur Behebung der vom Tool gefundenen Defekte. In einem solchen Extremfall ist die kosteneffektivste Strategie, kein Tool einzusetzen.

Dieses Modell bestätigt, dass der Vorteil des Einsatzes eines strategischen Analysetools von dessen Fähigkeit abhängt, echte Fehler zu entdecken, die in der Folge als solche erkannt werden. Auch wenn die Sichtung der Warnungen Kosten kreiert, sind diese relativ niedrig verglichen mit denen eines Zwischenfalls. Somit ist die Effektivität eines Tools, z.B. seine Fähigkeit echte Fehler zu entdecken, die als solche erkannt werden, eine gute Annäherung an seinen Gesamtnutzen. Zu beachten ist aber, dass dies Kenntnis über den Wert eines Recalls voraussetzt, der – wie erwähnt – schwer zu fassen ist.

Statische Analysetools sind wirkungsvoll, um ernste Programmierfehler und Sicherheitslücken zu finden. Weil sie aber keine Verifzierungstools sind, könnten sie manche Probleme übersehen und False Positives melden. Precision und Recall scheinen eng aneinander gekoppelt, so dass eine höhere Precision zu weniger Recall führt und umgekehrt. Bei den meisten Tools können Nutzer die Analyse selber nach eigenen Vorstellungen konfigurieren. Wichtig ist, dass die Anzahl der False Positives niedrig ist, weil zu viele ein Tool unbrauchbar machen, unabhängig von der Ausgereiftheit der darunter liegenden Analyse. Dies sollte mit dem Risiko abgewogen werden, dass die Analyse keine echten Fehler findet.

Normalerweise bevorzugen Nutzer Konfigurationen mit niedrigen False Positives, aber das hier gezeigte Modell zeigt, dass der Sweet Spot, der den Vorteil des Tooleinsatzes maximiert, eine weit höhere False Positive Rate toleriert, solange das Tool auch mehr echte Fehler findet. Nutzer können mit diesem Modells rationale Überlegungen über die Einführung der statischen Analyse in ihren Unternehmen anstellen. Das Modell ist problemlos anwendbar, weil es nur einfache Zählungen von True und False Positives benötigt.

Autor: Dr. Paul Anderson, Vice President Engineering, GrammTech, Inc.

 

Bilder:

Abb 2 – Eigenschaften der Beispieltools

Abb 3 – Die groben Ergebnisse aus den Beispieltools

Abb 4 – Anzahl der Fehler, die  in der Anwendung zur Erkennung von True Positives verbleiben, links im linearen und rechts im kubischen Modell. Ganz eindeutig sind weniger Fehler besser.

Abb. 5 – Kostenaufstellung für die Beispieltools (links) und der Vorteil aus dem Einsatz jeden Tools, verglichen mit keinem Gebrauch eines Tools (rechts). Die Zahlen sind aus den vorhergehend diskutierten Werten abgeleitet.

 

 

Referenzen

  1. The Economic Impacts of Inadequate Infrastructure for Software Testing, 2002, Research Triangle Institute, National Institute of Sci­ence and Technology, Washington, DC RTI Project No. 7007.011.
  2. Jetley, R. P., Anderson, P., and Jones, P. L., Static Analysis of Med­ical Device Software using CodeSonar. In Static Analysis Workshop (SAW). 2008. Tucson, AZ: ACM Press.

Kommentare werden geladen....

Kommentar zu diesem Artikel abgeben

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 0 / Technologie)