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 erwähnte das einmal gegenüber Scott, und obwohl er es nicht so gesehen hatte, brachte es ihn doch ziemlich zum 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, die statische Analyse würde ____ erkennen“ (benennen Sie Ihren bevorzugten nicht auffindbaren Fehler). Viel häufiger hört man: „Wow, ich habe viel zu viele Ergebnisse!“ oder „Statische Analyse ist verrauscht!“ oder „False Positives bei statischen Analysen sind überwältigend!“ Als Softwaretestorganisation ist es unsere Aufgabe, dieses Problem für unsere Kunden weiterhin zu lösen – weiterhin Tools und Funktionen bereitzustellen, die Ihnen helfen, die erhaltenen Ergebnisse zu sortieren und zu verstehen, welche Probleme das größte Risiko darstellen.

Statische Code-Analyse: Vorteile und Einschränkungen

Statische Analysetools kommen Entwicklern zugute indem Sie Fehler, Sicherheitslücken und Codierungsstandardabweichungen finden, die ansonsten mühsam zu finden oder durchzusetzen wären.

Das bringt das Programm

Statische Analyse- und SAST-Tools (Static Application Security Testing) bieten Entwicklerteams die folgenden Vorteile.

• Bessere Codequalität. Die statische Analyse trägt dazu bei, Fehler frühzeitig in der Entwicklung zu beseitigen, wodurch eine bessere Codequalität bereits zum Zeitpunkt der Erstellung gewährleistet und gleichzeitig die nachgelagerte Qualität in späteren Entwicklungsphasen verbessert wird.
• Sichererer Code. Zusätzlich zur Fehlererkennung verbessern statische Analyse und SAST die Sicherheit, indem sie Schwachstellen erkennen, die zu Sicherheitsrisiken führen. Lösungen wie Parasoft erzwingen sicherere Codierungspraktiken und -standards als andere.
• Einhaltung der Kodierungsstandards der Branche und Organisation. Die manuelle Durchsetzung von Codierungsstandards ist mühsam, wenn nicht sogar unmöglich. Die statische Analyse automatisiert die Überprüfung, Durchsetzung und Einhaltung von Codierungsstandards. Dazu gehören branchenspezifische Sicherheits- und Sicherheitscodierungsstandards wie MISRA und Sicherheitsstandards wie OWASP Top 10, CWE Top 25 und SEI CERT C/C++.
• Produktivität verbessern. Statische Analysetests früh während der Implementierung und innerhalb der IDE des Entwicklers und/oder innerhalb des CI/CD-Workflows des Teams fördern die Codequalität und beschleunigen die Entwicklung, indem sie die Tests weiter nach links verlagern. Darüber hinaus integriert Parasoft KI/ML, um identifizierte statische Analyseprobleme automatisch zu organisieren und die Produktivität weiter zu steigern.
• Reduzieren Sie Risiken und Kosten. Durch die Anwendung statischer Analysen werden die im Feldschutz gemeldeten Probleme erheblich reduziert. Organisationen erkennen auch eine höhere Produktzuverlässigkeit an, was die Wartungskosten senkt und einen guten Ruf in Bezug auf Qualität fördert.

Einschränkungen

Statische Analyse und SAST sind keine Allheilmittel. Tatsächlich empfiehlt Parasoft seinen Kunden, statische Analysen in Verbindung mit anderen Testmethoden wie Unit-Tests, Regressionstests und mehr zu verwenden. Statische Analyselösungen wie Parasoft bieten hervorragende Kapitalrenditen, es ist jedoch sinnvoll, die Einschränkungen zu verstehen.

• Fehlalarm. Jede statische Analyse kann ein unklares Codierungskonstrukt fälschlicherweise interpretieren und einen Fehler melden. Bei diesen Fehlern in der Berichterstattung handelt es sich um falsch positive Ergebnisse, die bei der statischen Analyse unvermeidbar sind, wie weiter unten erläutert wird.
• Falsche Negative. Ähnlich wie bei Fehlalarmen können Tools echte Fehler im Quellcode übersehen. Bei diesen übersehenen Fehlern handelt es sich um falsche Negative, die im Folgenden ausführlicher behandelt werden.
• Begrenzter Umfang und Kontext. Der Umfang der statischen Analyse beschränkt sich auf den Quellcode, der zum Zeitpunkt der Analyse verfügbar ist. Je mehr Code, desto besser der Umfang und die Ergebnisse. Der statischen Analyse mangelt es auch an Kontext hinsichtlich der Aufgabe des Codes. Es analysiert die Quelle auf der Grundlage einer Reihe von Regeln oder Prüfern, die nicht unbedingt die Absicht des Programmierers verstehen.
• Werkzeugleistung. Die statische Analyse kann je nach Analysetiefe einige Zeit in Anspruch nehmen, um große Codebasen zu analysieren. Obwohl dies bei moderner Serverhardware weniger problematisch ist, beschränken Entwickler die groß angelegte Analyse normalerweise auf Software-Builds. Moderne statische Analysetools wie C/C++test haben dieses Problem bis zu einem gewissen Grad entschärft, beispielsweise durch inkrementelle Analysen, die innerhalb von IDEs durchgeführt werden. Codeverstöße werden zur Behebung nur dem Ingenieur gemeldet, der seinen Code entwickelt, da bei jeder Codekompilierung und -erstellung inkrementelle Schritte ausgeführt werden.
• Kosten. Kommerzielle statische Analysetools kosten Geld für die Lizenzierung. Statische Analysetools bieten jedoch eine hervorragende Kapitalrendite für kleine oder große Projekte und Organisationen.

Was ist ein falsch positives Ergebnis in der statischen Analyse?

Im Zusammenhang mit der statischen Analyse tritt ein falsch positives Ergebnis auf, wenn ein statisches Analysetool fälschlicherweise meldet, dass eine statische Analyseregel verletzt wurde. Natürlich kann dies subjektiv sein. Manchmal tappen Entwickler in die Falle und kennzeichnen jede Fehlermeldung, die ihnen nicht gefällt, als falsch positiv, aber das ist nicht wirklich richtig.

In vielen Fällen sind sie mit der Regel einfach nicht einverstanden, verstehen nicht, wie sie in der jeweiligen Situation anzuwenden ist, oder halten sie im Allgemeinen nicht für wichtig. Ich würde das nennen Lärm, und kein falsch positives Ergebnis. Das Witzige dabei ist, dass je cleverer das Tool ist, desto wahrscheinlicher ist es, dass es zu einem Ergebnis führt, das ein Entwickler auf den ersten Blick vielleicht nicht versteht.

False Positives in der musterbasierten Analyse

Die musterbasierte statische Analyse weist eigentlich keine Fehlalarme auf. Wenn das Tool meldet, dass gegen eine statische Analyseregel verstoßen wurde, obwohl dies 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 aufweist, nach dem gesucht werden muss, ist sie eine schlechte Regel.

Ich sage nicht, dass jeder gemeldete Regelverstoß auf das Vorliegen eines Mangels hinweist. Ein Verstoß bedeutet, dass das Muster gefunden wurde, was auf eine Schwachstelle im Code hinweist, also auf die Anfälligkeit für einen Fehler.

Wenn ich mir einen Verstoß ansehe, frage ich mich, ob diese Regel auf meinen Code zutrifft oder nicht. Wenn es zutrifft, korrigiere ich den Code. Ist dies nicht der Fall, unterdrücke ich den Verstoß. Es ist am besten, Verstöße gegen die statische Analyse direkt im Code zu unterdrücken, damit er für Teammitglieder sichtbar ist und Sie ihn nicht ein zweites Mal überprüfen müssen. Andernfalls werden Sie immer wieder denselben Verstoß überprüfen; Es ist, als würde man versuchen, die Rechtschreibung zu überprüfen, aber niemals die „besonderen“ Wörter in das Wörterbuch aufnehmen.

Das Schöne an der Unterdrückung im Code ist, dass sie unabhängig von der statischen Analyse-Engine ist. Jeder kann sich den Code ansehen und sehen, dass der Code überprüft wurde und dass dieses Muster in diesem Code als akzeptabel erachtet wird. Dies ist besonders nützlich, wenn Sie die Einhaltung eines Codierungsstandards nachweisen müssen. Und wenn Sie tatsächlich Konformität benötigen, können Sie ganz einfach eine vorhandene Konfiguration für diese Standards verwenden, z CWE, MISRA, IEC 62304, DO-178Cund 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.

Wenn Sie sich andererseits einfach keine Sorgen über Nullen in diesem Codeteil machen, weil sie woanders verarbeitet werden, dann ist die Nachricht zwar nicht wichtig für Sie, aber kein falsch positives Ergebnis. Es ist wahr und zufällig unwichtig. Die Botschaften 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 häufige Falle. Wie im obigen Null-Beispiel glauben Sie vielleicht, dass ein Nullwert diesen Punkt nicht erreichen kann, aber das Tool hat einen Weg gefunden, dies zu erreichen. Wenn dies für Ihre Anwendung wichtig ist, sollten Sie dies unbedingt überprüfen und ggf. davor schützen.

Es ist wichtig zu verstehen, dass es bei der Flussanalyse sowohl Stärken als auch Schwächen gibt. Die Stärke der Flussanalyse besteht darin, dass sie den Code durchgeht und versucht, Hotspots zu finden und dann Probleme in der Umgebung der Hotspots zu finden. Die Schwäche besteht darin, dass Annahmen getroffen werden müssen, um zu versuchen, den Code zu durchlaufen, und je weiter er durchläuft, desto wahrscheinlicher ist es, dass ein unwahrscheinlicher Pfad entsteht.

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, dotTEST, oder auch Test Dies hat beide Arten der statischen Analyse, wenn Sie sicherheitskritische Software erstellen

Falsch Positive vs. Falsch Negative in der statischen Codeanalyse

Trotz gegenteiliger Behauptungen erzeugt jedes statische Analysetool falsch-positive Ergebnisse und übersieht echte Fehler – falsch-negative Ergebnisse. Zwischen fehlenden Mängeln und dem Erhalt zu vieler Berichte müssen Kompromisse eingegangen werden.

Statische Analysetools müssen stattdessen danach bewertet werden, was sie finden – und wie gut diese dargestellt werden – und wie viele Fehler sie übersehen. Tools, die darauf abgestimmt sind, falsch-positive Ergebnisse zu reduzieren, haben zwangsläufig höhere falsch-negative Ergebnisse. Lohnt es sich, echte Fehler zu übersehen, um weniger Meldungen zu erhalten?

Hier sind einige Dinge, die Sie bei der Abwägung zwischen falsch-positiven und falsch-negativen Ergebnissen beachten sollten.

• Nutzen Sie die Funktionen der Tools, um Erkenntnisse zu priorisieren. Bei statischen Analysetools sind Fehlalarme üblich, die meisten haben jedoch ausgefeilte Tools für den Umgang mit den Ergebnissen entwickelt. Statische Analysetools gruppieren Berichte nach Schweregrad und bieten die Möglichkeit, unerwünschte Ergebnisse schnell und einfach zu ignorieren und/oder zu filtern.

Der erste Schritt besteht also darin, Ihre Codeanalyse entsprechend zu konfigurieren und unnötiges Rauschen zu reduzieren. Stellen Sie sicher, dass die richtigen Prüfer mit dem richtigen Code ausgeführt werden. Wenn Sie beispielsweise ein Problem mit einem bestimmten Prüfprogramm nicht beheben möchten, deaktivieren Sie es. Oder wenn Sie Legacy-Code haben, der schon seit vielen Jahren im Einsatz ist und nur ein gemeldeter Fehler Sie zu Änderungen zwingen kann, warum sollten Sie sich dann die Mühe machen, ihn zu analysieren?

Wenn Sie jedoch eine statische Analyse einer großen Codebasis durchführen und eine riesige Liste von Verstößen erhalten, sollten Sie sich nicht überfordern. Es dauert nicht lange, zu lernen, Ergebnisse basierend auf Risiko und Auswirkungen zu priorisieren und sich zuerst auf die höchste Priorität zu konzentrieren. Viele Beschwerden über statische Analysetools beruhen auf Eindrücken von Tools und Funktionen älterer Generationen.

• Falsch positive Ergebnisse halten nicht ewig an. Alle Ergebnisse, die nicht von Interesse sind, können herausgefiltert werden und werden nie wieder gemeldet. Wenn die Art des Fehlers keine hohe Priorität bei der Behebung hat, kann die gesamte Fehlerklasse aus zukünftigen Berichten entfernt werden. Wenn sich herausstellt, dass es sich bei einzelnen Meldungen um echte Falschmeldungen handelt, können diese als solche gekennzeichnet werden. Das Wichtigste ist, dass das Rauschen mit etwas Aufwand verschwindet, wenn sich die Entwickler an die Verwendung der Tools gewöhnen.
• Falsch-negative Ergebnisse beeinträchtigen die Produktqualität und -sicherheit. Falsch-negative Ergebnisse hingegen sind unbekannt, da sie nicht erkannt werden und ihre Existenz möglicherweise erst dann aufgedeckt wird, wenn ein Kunde das Produkt in der Hand hat. Aus dieser Perspektive müssen Entwickler die Auswirkungen falsch positiver Ergebnisse auf ihre Arbeitsbelastung abwägen: Lohnt es sich, wichtige Fehler zu übersehen?

Organisationen müssen ihr eigenes Risiko und die damit verbundenen Kosten ermitteln. Der ideale Kompromiss besteht darin, so wenige falsch-positive Ergebnisse wie möglich zu haben und gleichzeitig falsch-negative Ergebnisse zu minimieren.

• Vertrauen in die Fähigkeiten der Tools aufbauen. Fehlalarme mögen auf den ersten Blick problematisch erscheinen, aber das Finden und Beheben echter Fehler stärkt mit der Zeit das Vertrauen in die Tools. Im Gegenteil, das Fehlen tatsächlicher Fehler, die später beim Testen entdeckt werden, wirkt sich negativ auf die während der Entwicklung verwendeten Tools aus. Entwickler wollen Tools, denen sie vertrauen können, und es lohnt sich nicht, die Reduzierung falsch positiver Ergebnisse auf Kosten des Übersehens echter Fehler zu betonen.

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.