False Positives in der statischen Code-Analyse

„Zu viele falsch positive Ergebnisse“ ist wahrscheinlich die häufigste Ausrede, um statische Analysen zu vermeiden. Aber die statische Analyse muss nicht so laut sein.

Vor Jahren die größte Herausforderung in Statische Softwareanalyse versuchte, immer interessantere Dinge zum Überprüfen zu finden. In Parasofts ursprünglichem CodeWizard-Produkt in den frühen 90er Jahren hatten wir etwa 30 Regeln, die auf Elementen aus dem Buch von Scott Meyers basierten. Effektives C ++. Es war das, was ich gerne als „Angst gerade für Programmierer. " Ich habe das Scott gegenüber einmal erwähnt, und obwohl er nicht daran gedacht hatte, ob es so wäre ... gab es ihm ein ziemlich gutes Lachen.

Seitdem haben die Forscher der statischen Analyse ständig daran gearbeitet, die Grenzen dessen, was erkannt werden kann, zu erweitern, die Möglichkeiten der statischen Analyse zu erweitern und Fehler statt nur eines schwachen Codes zu identifizieren. Aber es leidet immer noch unter falsch positiven Ergebnissen. Die statische Analyse hat den Fokus des Benutzers verändert, vom Härten des Codes hin zur Suche nach Fehlern, was großartig ist, aber jetzt ist eine der häufigsten Hürden, auf die Menschen bei der statischen Codeanalyse stoßen, zu versuchen, die erhaltenen Ergebnisse zu verstehen.

Obwohl die Leute sagen "Ich wünschte, eine statische Analyse würde ____ fangen" (nennen Sie Ihren bevorzugten nicht auffindbaren Fehler), ist es weitaus häufiger zu hören: "Wow, ich habe viel zu viele Ergebnisse!" oder "Statische Analyse ist verrauscht!" oder "Statische Analyse False Positives sind überwältigend!" Als Software-Test-Organisation ist es unsere Aufgabe, dieses Problem weiterhin für unsere Kunden zu lösen und weiterhin Tools und Funktionen bereitzustellen, mit denen Sie die erzielten Ergebnisse sortieren und verstehen können, welche Probleme das größte Risiko darstellen.

Was ist ein falsch positives Ergebnis in der statischen Analyse?

Im Zusammenhang mit der statischen Analyse tritt ein „falsches Positiv“ auf, wenn ein statisches Analysetool fälschlicherweise meldet, dass eine statische Analyseregel verletzt wurde. Dies kann natürlich subjektiv sein. Manchmal geraten Entwickler in die Falle, Fehlermeldungen, die sie nicht mögen, als „falsch positiv“ zu kennzeichnen, aber das ist nicht wirklich richtig. In vielen Fällen stimmen sie der Regel einfach nicht zu, sie verstehen nicht, wie sie in dieser Situation gilt, oder sie halten sie im Allgemeinen (oder in diesem speziellen Fall) nicht für wichtig. Ich würde das nennen Lärmeher als ein falsches Positiv. Das Lustige, was ich hier gefunden habe, ist, dass je cleverer das Tool ist, desto wahrscheinlicher ist es, dass ein Ergebnis entsteht, das ein Entwickler auf den ersten Blick möglicherweise nicht versteht.

False Positives in der musterbasierten Analyse

Die musterbasierte statische Analyse hat eigentlich keine falsch positiven Ergebnisse. Wenn das Tool meldet, dass eine statische Analyseregel verletzt wurde, als dies tatsächlich nicht der Fall war, weist dies auf einen Fehler in der Regel hin (da die Regel nicht mehrdeutig sein sollte). Wenn die Regel kein klares Muster hat, nach dem gesucht werden muss, ist sie eine schlechte Regel.

Ich sage nicht, dass jeder gemeldete Regelverstoß auf das Vorhandensein eines Fehlers hinweist. Ein Verstoß bedeutet einfach, dass das Muster gefunden wurde, was auf eine Schwäche im Code und eine Anfälligkeit für einen Fehler hinweist.

Wenn ich einen Verstoß betrachte, frage ich mich, ob diese Regel für meinen Code gilt oder nicht. Wenn es zutrifft, korrigiere ich den Code. Wenn nicht, unterdrücke ich die Verletzung. Es ist am besten, Verstöße gegen statische Analysen im Code direkt zu unterdrücken, damit sie für Teammitglieder sichtbar sind und Sie sie nicht ein zweites Mal überprüfen müssen. Andernfalls überprüfen Sie immer wieder denselben Verstoß. Es ist, als würde man versuchen, die Rechtschreibprüfung durchzuführen, aber niemals seine „speziellen“ Wörter in das Wörterbuch aufnehmen. Das Schöne an der In-Code-Unterdrückung ist, dass sie unabhängig von der statischen Analyse-Engine ist. Jeder kann sich den Code ansehen und feststellen, dass der Code überprüft wurde und dass dieses Muster in diesem Code als akzeptabel angesehen wird. Dies ist besonders nützlich, wenn Sie die Einhaltung eines Codierungsstandards nachweisen müssen. Und wenn Sie tatsächlich Compliance benötigen, ist es einfach, eine vorhandene Konfiguration für diese Standards zu verwenden, wie z CWE, MISRA, IEC 62304, DO-178B / C.Und vieles mehr.

False Positives in der flussbasierten Analyse

Bei der flussbasierten Analyse sind falsch positive Ergebnisse nicht nur der Methode inhärent, sondern auch relevant - und müssen angegangen werden. Die Durchflussanalyse kann Fehlalarme nicht vermeiden, aus dem gleichen Grund, aus dem Unit-Tests keine perfekten Unit-Testfälle generieren können. Die Analyse muss Bestimmungen über das erwartete Verhalten des Codes treffen. Manchmal gibt es zu viele Optionen, um zu wissen, was realistisch ist. Manchmal haben Sie einfach nicht genug Informationen darüber, was in anderen Teilen des Systems passiert.

Das Wichtigste dabei ist, dass das wahre Falsch-Positive etwas ist, das einfach völlig falsch ist. Angenommen, das von Ihnen verwendete statische Analysetool gibt an, dass Sie einen Nullzeiger lesen. Wenn Sie sich den Code ansehen und feststellen, dass dies tatsächlich unmöglich ist, haben Sie ein falsches Positiv.

Auf der anderen Seite ist die Nachricht (obwohl sie für Sie nicht wichtig ist) kein falsches Positiv, wenn Sie sich in diesem Code einfach keine Sorgen um Nullen machen, weil sie an anderer Stelle behandelt werden. Es ist wahr und zufällig unwichtig. Die Nachrichten eines Flussanalysetools reichen von „wahr und wichtig“ über „wahr und unwichtig“ und „wahr und unwahrscheinlich“ bis „unwahr“. Hier gibt es viele Variationen, und jede sollte anders gehandhabt werden.

Auch hier gibt es eine gemeinsame Falle. Wie im obigen Null-Beispiel können Sie glauben, dass ein Nullwert es nicht bis zu diesem Punkt schaffen kann, aber das Tool hat einen Weg gefunden, dies zu erreichen. Wenn es für Ihre Anwendung wichtig ist, stellen Sie sicher, dass Sie dies überprüfen und möglicherweise davor schützen.

Es ist wichtig zu verstehen, dass die Durchflussanalyse sowohl Kraft als auch Schwäche aufweist. Die Stärke der Flussanalyse besteht darin, dass sie den Code durchläuft und versucht, Hotspots und Probleme in der Umgebung der Hotspots zu finden. Die Schwäche besteht darin, dass Annahmen getroffen werden müssen, um den Code zu durchlaufen, und je weiter er durchläuft, desto wahrscheinlicher ist es, dass er einen unwahrscheinlichen Pfad erzeugt.

Das eigentliche Problem ist, dass Sie sich etwas vormachen, wenn Sie glauben, Sie hätten den gesamten Code bereinigt, weil Ihre Flussanalyse sauber ist. Wirklich, Sie haben einige Fehler gefunden und sollten dafür dankbar sein. Das Fehlen von Fehlern bei der Flussanalyse bedeutet nur, dass Sie nichts gefunden haben und nicht, dass der Code sauber ist. Stellen Sie am besten sicher, dass Sie ein Tool wie verwenden C / C ++ - Test, dotTESTbezeichnet, oder Test Dies hat beide Arten der statischen Analyse, wenn Sie sicherheitskritische Software erstellen

Laufzeitfehlererkennung

Eine großartige, aber häufig übersehene Möglichkeit, die Flussanalyse zu ergänzen, ist die Erkennung von Laufzeitfehlern. Die Laufzeitfehlererkennung hilft Ihnen dabei, viel kompliziertere Probleme zu finden, als die Flussanalyse erkennen kann, und Sie haben das Vertrauen, dass der Zustand tatsächlich aufgetreten ist. Die Laufzeitfehlererkennung weist keine falsch positiven Ergebnisse auf, wie dies bei der statischen Analyse der Fall ist. Wenn ein Fehler festgestellt wird, liegt dies daran, dass er tatsächlich beobachtet hat, dass er während der Ausführung auftritt. Es gibt keine Annahmen.

Ihr Laufzeitregelsatz sollte eng mit Ihrem statischen Analyseregelsatz übereinstimmen. Die Regeln können die gleichen Arten von Problemen finden, aber die Laufzeitanalyse verfügt über eine große Anzahl von Ausführungspfaden. Dies liegt daran, dass zur Laufzeit Stubs, Setup, Initialisierung usw. kein Problem darstellen, wie dies bei der Flussanalyse der Fall ist. Die einzige Einschränkung besteht darin, dass es nur so gut ist wie Ihre Testsuite, da es die Pfade überprüft, die Ihre Testsuite gerade ausführt. Wenn Sie in C oder C ++ programmieren, insbesondere in eingebetteten Geräten wie IoT, werfen Sie einen Blick darauf ++ versichern - Es kann zur Laufzeit mehr Fehler finden als jedes andere Tool. Anstatt sich durch knifflige Probleme wie Thread-Probleme, Speicherlecks und Race-Bedingungen festzumachen, können Sie diese zur Laufzeit genau finden.

Ist es die Zeit wert?

Mein Ansatz für falsch positive Ergebnisse lautet wie folgt: Wenn es 3 Tage dauert, um einen Fehler zu beheben, ist es besser, 20 Minuten damit zu verbringen, ein falsch positives Ergebnis zu untersuchen… solange ich es markieren kann und es nie wieder ansehen muss. Es geht darum, es im richtigen Kontext zu betrachten. Angenommen, Sie haben ein Problem mit Threads. Probleme mit Threads sind dramatisch schwer zu entdecken. Wenn Sie ein Problem im Zusammenhang mit Threads finden möchten, kann es Wochen dauern, bis Sie es gefunden haben. Ich würde es vorziehen, den Code so zu schreiben, dass überhaupt keine Probleme auftreten können. Mit anderen Worten, ich versuche, meinen Prozess von der Erkennung zur Prävention zu verlagern.

Bei ordnungsgemäßer Bereitstellung muss die statische Analyse keine unangenehme Erfahrung sein. Schauen Sie sich an, wie wir die Dinge anders machen Parasoft, vor allem mit der vollen Kraft von Parasoft DTP Verwalten von Ergebnissen mit intelligenten Analysen, mit denen Sie sich auf das Risiko in Ihrer Software konzentrieren können, anstatt unwichtige Probleme zu verfolgen.

„MISRA“, „MISRA C“ und das Dreieckslogo sind eingetragene Marken von The MISRA Consortium Limited. ©The MISRA Consortium Limited, 2021. Alle Rechte vorbehalten.