🛏️ ✍🏿 😽 Gründe für die Einführung des statischen Code-Analysators PVS-Studio in den Entwicklungsprozess 👩🏾‍✈️ 🎅🏽 🕎

PVS-Studio ist ein Tool zum Auffinden von Fehlern und potenziellen Schwachstellen im Quellcode von Programmen, die in C, C ++, C # oder Java geschrieben wurden. PVS-Studio gehört zur Klasse der Tools zum Testen der Sicherheit statischer Anwendungen (Static Application Security Testing, SAST). Der Analyzer konzentriert sich auf die Praxis der kontinuierlichen Integration (Continuous Integration, CI) und ermöglicht es Ihnen, Fehler frühzeitig zu erkennen, wenn sie behoben werden.

Statische Code-Analyse

Softwareprojekte in ihrem Entwicklungsprozess werden immer mehr. Beispiele:

Linux-Kernel 1.0.0: 176.000 Codezeilen
Linux-Kernel 5.0: 26.000.000 Codezeilen
Photoshop 1.0: 128.000 Codezeilen
Photoshop CS 6: 10.000.000 Codezeilen

Mit zunehmender Größe eines Projekts wächst seine Komplexität schneller als linear. Aus diesem Grund nimmt mit zunehmender Größe der Codebasis auch die Fehlerdichte zu. Eine Möglichkeit, die zunehmende Komplexität zu kompensieren, besteht in der Verwendung statischer Code-Analysetools.

Ein statischer Analysator ist ein Hilfsprogramm für Programmierer, das eine vorläufige Überprüfung des Codes durchführt und Codefragmente anzeigt, die mit größerer Wahrscheinlichkeit einen Fehler enthalten. Dadurch können viele Fehler frühzeitig behoben werden, wenn die Kosten für deren Behebung minimal sind.

Die statische Analyse ersetzt nicht andere Methoden zur Fehlererkennung, sondern ergänzt sie, z. B. Codeüberprüfungen, Komponententests, dynamische Codeanalysen, Regressionstests, manuelle Tests usw.

Wenn es sich beispielsweise um Codeüberprüfungen handelt , ist es viel besser, wenn das Programm einfache Fehler erkennt. Dann können sich die Programmierer, die den Code überprüfen, auf nützlichere Überprüfungen des Algorithmus konzentrieren und sind nicht gezwungen, die Vergleichsfunktionen einzulesen. Darüber hinaus ist es, wie die Praxis zeigt, sehr schwierig, viele Fehler „mit den Augen“ zu suchen, und es ist sehr wahrscheinlich, dass sie die Codeüberprüfungsphase unbemerkt durchlaufen.

Ein weiterer Vorteil der statischen Analysetools ist das Vorhandensein einer umfangreichen Datenbank mit Fehlermustern. Sie können Probleme finden, deren Existenz der Programmierer möglicherweise nicht einmal bemerkt. Einige Beispiele: V698 , V718 , V1023 .

PVS-Studio

Wir empfehlen die Implementierung des statischen Code-Analysators PVS-Studio, den wir im Entwicklungsprozess entwickelt haben. Das Produkt läuft auf 64-Bit-Systemen unter Windows, Linux und macOS und kann Code analysieren, der für 32-Bit-, 64-Bit- und eingebettete ARM-Plattformen entwickelt wurde.

Zum Zeitpunkt der Veröffentlichung dieses Artikels unterstützt das Analyseprogramm die folgenden Sprachen und Compiler:

Windows Visual Studio 2010-2019 C, C ++, C ++ / CLI, C ++ / CX (WinRT), C #
Windows IAR Embedded Workbench, C / C ++ - Compiler für ARM C, C ++
Windows QNX Momentics, QCC C, C ++
Windows / Linux Keil µVision, DS-MDK, ARM Compiler 5/6 C, C ++
Windows / Linux Texas Instruments Code Composer Studio, Tools zur ARM-Codegenerierung C, C ++
Windows / Linux / MacOS. GNU Arm Embedded Toolchain, GCC-Compiler für Arm Embedded, C, C ++
Windows / Linux / MacOS. Clang C, C ++
Linux / macOS. GCC C, C ++
Windows MinGW C, C ++
Windows / Linux / MacOS. Java

Der Analysator verfügt über eine detaillierte Dokumentation in Englisch und Russisch. Beschreibungen der Diagnoseregeln enthalten Beispiele für korrekten und falschen Code sowie Links zu Beispielen für echte Fehler in Open Source-Projekten.

Zur Vereinfachung für Spezialisten, die PVS-Studio als SAST-Tool verwenden , zeigt der Analysator seine Warnungen zu Common Weakness Enumeration, SEI CERT Coding Standards und dem MISRA-Standard an. Konformitätstabellen der PVS-Studio-Diagnose nach verschiedenen Standards:

Der Analysator kann unabhängig voneinander verwendet und in Visual Studio und IntelliJ IDEA integriert werden. Darüber hinaus haben kürzlich einige unserer Kunden PVS-Studio als Teil von SonarQube verwendet. PVS-Studio, das als Plug-in mit SonarQube verbunden ist, ist eine zusätzliche Quelle für Diagnosemeldungen.

Verschiedene Integrationsszenarien in CI wurden ausgearbeitet. Die Berücksichtigung aller Szenarien würde den Rahmen dieses Artikels sprengen, und es ist besser, die Dokumentation zu Rate zu ziehen. Hier nur ein paar Links, damit sich der Leser einen allgemeinen Eindruck machen kann:

Der PVS-Studio-Analysator erkennt eine Vielzahl von Fehlern, von Tippfehlern bis hin zu Speicherlecks . Dies ist dank Datenflussanalyse, symbolischer Ausführung, Musterabgleich und Methodenanmerkung (einschließlich automatisch) möglich. Weitere Informationen zu Funktionsprinzipien finden Sie im Artikel " Im PVS-Studio Code Analyzer verwendete Technologien zum Auffinden von Fehlern und potenziellen Schwachstellen ".

Warum sollten Sie PVS-Studio verwenden?

Durch die Einführung des statischen Code-Analysators PVS-Studio in den Entwicklungsprozess reduzieren Sie die Kosten für die Behebung vieler Fehler. Dies spart Zeit für die Implementierung neuer Funktionen oder für gründlichere Tests auf hoher Ebene.

Bei regelmäßiger Verwendung des Analysegeräts wird der Code allmählich besser, was die Wartung erleichtert. Eine systematische Fehlerkorrektur und das Schreiben von qualitativ hochwertigem Code verringern die Wahrscheinlichkeit, Zero-Day-Schwachstellen im Projekt zu erkennen. Dieses Thema wird im Artikel " Wie kann PVS-Studio bei der Suche nach Sicherheitslücken helfen? " Näher erläutert.

Die Verwendung des PVS-Studio-Tools ist für Teams mit fünf oder mehr Personen von Vorteil. Die Methode zur Berechnung der Nutzungseffizienz des Analysators finden Sie im Artikel " PVS-Studio ROI ".

Bei Projekten, die von einem oder zwei Enthusiasten entwickelt wurden, ist der PVS-Studio-Analysator höchstwahrscheinlich überflüssig. Es kann jedoch auch in solchen kleinen Projekten verwendet werden, zumal wir verschiedene kostenlose Lizenzierungsoptionen für Studenten, Open Source-Projekte usw. anbieten.

Am häufigsten erwerben unsere Kunden zu Beginn eine Lizenz für ein Jahr. Nach einem Jahr, wenn sie überzeugt sind, dass die Fähigkeiten des Analysegeräts und ihre Unterstützung voll und ganz zufrieden sind, verlängern sie die Lizenz um zwei oder drei Jahre auf einmal. Dies ermöglicht es ihnen, einen erheblichen Rabatt zu erhalten. Hier können Sie Preise anfordern und sich zu Lizenzfragen beraten lassen.

Werden Sie unser Kunde. Mit PVS-Studio können Sie den Entwicklungsprozess beschleunigen, im Kampf gegen Fehler Geld sparen und bessere Software erstellen.

Wir werden Sie schnell und kompetent unterstützen. Die Fragen werden direkt von den Programmierern beantwortet, die die Module entwickeln, auf denen die Frage entstand. Dies hilft, auch in schwierigen Situationen Antworten zu erhalten. Ein Beispiel für eine solche Kommunikation ist " False Positives in PVS-Studio: Wie tief ist das Kaninchenloch? ".

Einspruch beantwortet

Manchmal nehmen Programmierer die Idee der Einführung der statischen Code-Analyse in den Entwicklungsprozess negativ wahr und kritisieren die Methodik der statischen Analyse als Ganzes oder speziell das PVS-Studio-Tool. Wenn die Diskussion beginnt, stellt sich heraus, dass die Kritik nicht begründet ist und einfach auf die mangelnde Bereitschaft zurückzuführen ist, im etablierten Entwicklungsprozess etwas zu ändern. Betrachten Sie die typischen Argumente, um nichts zu ändern, und deren Schwäche.

"Statische Analyse wird Teil der Arbeitszeit sein"

Die Aussage "Die statische Analyse nimmt einen Teil der Arbeitszeit in Anspruch" ist unabhängig vom Kontext richtig. Das regelmäßige Überprüfen der Warnungen des statischen Analysators, die für neuen oder geänderten Code ausgegeben wurden, nimmt viel Zeit in Anspruch. Der Gedanke sollte jedoch fortgesetzt werden: Die dafür aufgewendete Zeit ist viel geringer als die Kosten für die Identifizierung von Fehlern mit anderen Methoden.

Woher kommt die Meinung über die Notwendigkeit, Zeit damit zu verbringen, statische Code-Analysatoren zu warnen?

Programmierer, die mit der Code-Analyse-Methodik noch nicht vertraut sind, verwechseln Testläufe und die regelmäßige Verwendung. Bei den ersten Starts geben alle Analysegeräte eine große Liste von Warnungen aus, von denen viele falsch sind. Der Grund ist, dass der Analysator noch nicht konfiguriert ist. Ein abgestimmtes Analysegerät erzeugt beim regulären Start eine kleine Anzahl von Fehlalarmen. Mit anderen Worten, bei regelmäßiger Verwendung erkennen die meisten Warnungen echte Mängel oder einen Geruchscode. Es ist nur wichtig, diese Einstellung vorzunehmen.

Dieses Thema wird im Artikel „ Arbeiten mit Einwänden: Die statische Analyse nimmt einen Teil der Arbeitszeit in Anspruch “ ausführlicher beschrieben.

"Der statische Analysator ist sehr laut (es werden viele falsche Positive erzeugt)"

Wie oben erwähnt, wird diese Schlussfolgerung unter Verwendung eines nicht konfigurierten Codeanalysators gezogen. Nach dem Einrichten von PVS-Studio können Sie damit rechnen, dass der Prozentsatz der Fehlalarme 10-20% beträgt. Das heißt, mit fünf ausgegebenen Warnungen weisen vier auf echte Fehler oder einen Code hin, der in Zukunft wahrscheinlich zu Fehlern führen wird. Ein Beispiel für eine solche Einstellung finden Sie im Artikel " Spezifikationen des PVS-Studio-Analysators anhand des Beispiels für EFL-Kernbibliotheken, 10-15% der falsch-positiven Ergebnisse ".

Ein weiterer Grund, der die Idee des Analysators verfälscht, ist der Wunsch, so viele Warnungen wie möglich einzubeziehen, ohne deren Zweck zu verstehen. Wenn Sie beispielsweise den MISRA-Regelsatz für eingebettete Systeme für eine klassische Windows-Anwendung aktivieren, generiert der Analyzer Hunderttausende von Warnungen. Es wird keine praktische Bedeutung in ihnen geben. Insbesondere unnötige Diagnosen stören bereits beim Kennenlernen des Werkzeugs und bilden ein Missverständnis über dessen Diagnosemöglichkeiten. Der Artikel „ Wie kann man schnell interessante Warnungen sehen, die der PVS-Studio Analyzer für C- und C ++ - Code ausgibt ? “ Hilft, dies zu vermeiden.

„Die Einführung der statischen Analyse in den Entwicklungsprozess ist sehr schwierig, langwierig und teuer.“

Sehr gut, diese Bedenken spiegeln sich in diesem Kommentar wider:

Leider sind die statischen Analysatoren selbst nichts anderes als Spielzeug. Ihre Einführung in den Workflow ist eine verdammt schwierige Aufgabe. Sie müssen Personen auswählen, um die Ergebnisse zu verarbeiten und zu filtern. Versuche, diese Aufgaben auf die Schultern gewöhnlicher Entwickler zu verlagern, führen normalerweise zu nichts.

Es ist nicht so beängstigend. Es gibt mindestens drei Ansätze, mit denen Sie statische Analysen auch in großen alten Projekten mühsam implementieren können.

Erster Ansatz. "Ratchet Method", die Ivan Ponomarev in seinem Bericht " Continuous Static Code Analysis " gut ausdrückt .

Zweiter Ansatz. Um schnell mit der statischen Analyse beginnen zu können, bieten wir PVS-Studio-Kunden die Verwendung der " Markup-Basis " an. Die allgemeine Idee ist wie folgt. Der Benutzer hat den Analysator gestartet und viele Warnungen erhalten. Da ein seit vielen Jahren entwickeltes Projekt lebt, sich entwickelt und Geld einbringt, wird der Bericht höchstwahrscheinlich nicht viele Warnungen enthalten, die auf kritische Mängel hinweisen. Mit anderen Worten, kritische Fehler wurden bereits auf die eine oder andere teurere Weise oder dank des Feedbacks von Kunden behoben. Dementsprechend kann alles, was der Analysator jetzt findet, als technische Verschuldung angesehen werden, deren sofortige Beseitigung nicht praktikabel ist.

Sie können PVS-Studio anweisen, diese Warnungen als irrelevant zu betrachten (technische Schulden für später zu verschieben) und sie nicht erneut anzuzeigen. Der Analysator erstellt eine spezielle Datei, in der Informationen zu bisher uninteressanten Fehlern gespeichert werden. Und jetzt gibt PVS-Studio Warnungen nur für neuen oder geänderten Code aus. Darüber hinaus ist dies alles intelligent umgesetzt. Wenn beispielsweise am Anfang einer bestimmten CPP-Datei eine leere Zeile eingefügt wird, hat der Analysator verstanden, dass sich nichts geändert hat, und bleibt stumm. Diese Markup-Datei kann in das Versionskontrollsystem eingebettet werden. Die Datei ist groß, aber nicht unheimlich, da es oft keinen Sinn macht, sie zu legen.

Jetzt sehen alle Programmierer Warnungen, die sich nur auf neuen oder geänderten Code beziehen. Somit kann der Analysator beginnen, das zu verwenden, was am nächsten Tag aufgerufen wird. Und es wird möglich sein, später zu den technischen Schulden zurückzukehren, Fehler schrittweise zu korrigieren und den Analysator zu konfigurieren.

Der dritte Ansatz. Sie können mit uns einen Vertrag abschließen und die Arbeit zum Aufbau und zur Integration der statischen Analyse an unser Team delegieren. Ein Beispiel für diese Praxis: " Wie das PVS-Studio-Team den Code der Unreal Engine verbessert hat ."

„Wir haben den Analysator gestartet und nichts Interessantes gefunden“

Dies ist durchaus möglich, bedeutet jedoch nicht, dass der Analysator nicht nützlich ist. Die Sache ist, dass die Fehler durch teurere Methoden behoben wurden. So nehmen Sie den Text eines Buches, das bereits von mehreren Korrektoren gelesen wurde, und sehen, was die in Microsoft Word integrierte Rechtschreibprüfung finden kann. Es werden kleine Fehler gefunden, aber daraus folgt nicht, dass die Prüffunktion in Word beim Schreiben neuer Texte nicht hilfreich ist.

Dieses Thema wird im Artikel " Philosophie der statischen Code-Analyse: Wir haben 100 Programmierer, der Analysator hat nur wenige Fehler gefunden, ist es nutzlos? " Ausführlicher besprochen.

"Ein statischer Analysator ist teuer. Es ist besser, einen anderen Programmierer / Tester zu beauftragen."

In der Tat bedeutet dies, dass Sie nichts ändern möchten. In der Tat, bevor das Team wuchs und mit neuen Programmierern und Testern aufgestockt wurde. Dies führte jedoch nicht zu einer signifikanten Erhöhung der Reife des Entwicklungsprozesses. Lassen Sie uns diesen Einwand dennoch genauer untersuchen.

Erstens ist die Suche nach Fehlern durch eine zusätzliche Person viel teurer als die Verwendung eines Code-Analysators. Berechnen Sie die Gehaltskasse einer Person für das Jahr. Fügen Sie Steuern und Organisation des Arbeitsplatzes hinzu. Das Argument, dass eine Lizenz teuer ist, ist kein Argument mehr. Und dennoch fährt der statische Analysator im Gegensatz zu der Person nicht in den Urlaub, ist nicht krank und geht nicht. Wenn es sich um große Teams handelt, zum Beispiel 100 Personen, müssen Sie mehrere Personen einstellen, um eine gewisse Wirkung zu erzielen. Der Abstand zu Gunsten des statischen Analysators vergrößert sich.

Zweitens wird der größte Effekt aufgrund der Synergie der Verwendung verschiedener Fehlersuchtechniken erzielt. Einige Fehler werden durch Komponententests, andere durch manuelle Tests usw. gut erkannt. Stellen Sie sich die Situation vor. Das Projekt hat 10 Programmierer, viele Unit-Tests sind geschrieben, aber es gibt keine Tester. Die Qualität des Projekts passt nicht zu den Nutzern und die Idee ist, einen Job als Tester zu eröffnen. Dies geschieht jedoch nicht unter dem Vorwand „es ist besser, einen anderen Programmierer einzustellen“, sondern es wird noch mehr Unit-Tests geben! Stimmen Sie zu, das ist die falsche Entscheidung. Offensichtlich ist der Qualitätssicherungsprozess einseitig und die Hinzufügung manueller Tests wird viel größere Vorteile bringen. Gleiches gilt für die statische Analyse.

"Dynamische Analyse ist effizienter als statische."

Statische Analysatoren finden einige Fehler gut. Einige sind dynamische Analysatoren. Diese Tools ergänzen sich und es macht keinen Sinn, eine Sache auszuwählen.

Beispielsweise können dynamische Analysegeräte nicht viele Tippfehler finden oder nicht erreichbaren Code erkennen. Im Artikel " Validieren von Valgrind Dynamic Analyzer-Code mithilfe eines statischen Analysators " können einige dieser Fehler auftreten.

"Unit-Tests sind effizienter als statische Code-Analyse"

Wenn Sie zwischen dem Schreiben von Einheitentests und statischen Analysen wählen, sind die Tests möglicherweise wichtiger und nützlicher. Aber es muss keine Wahl getroffen werden. Es ist erforderlich, sowohl Unit-Tests als auch statische Code-Analysen durchzuführen. Diese Fehlersuchmethoden ergänzen sich perfekt.

Die statische Analyse wird Unit-Tests aus folgenden Gründen ergänzen:

Niemand testet die Tests selbst und sie enthalten oft Fehler. In unseren Artikeln haben wir wiederholt Beispiele für Fehler im Unit-Test-Code angeführt. Dementsprechend kann eine statische Analyse Fehler in Tests finden, die wiederum Fehler im Hauptanwendungscode finden können.
Tests sind sehr schwierig, den gesamten Code abzudecken. Besonders wenn es um Code für den Umgang mit Notfallsituationen geht. Statische Analysatoren überprüfen den gesamten Code.
Einige Fehler sind bei Unit-Tests nicht oder nur sehr schwer zu erkennen. Beispiel: V597 (CWE-14) .
Einige Fehler treten nur bei der Verarbeitung großer Datenmengen auf, und Komponententests sind für die Modellierung solcher Situationen unpraktisch. Ein Beispiel ist der Überlauf einer 32-Bit-Variablen in einem 64-Bit-Programm ( V108 , V127 ).
Es ist einfacher und schneller, einen Fehler durch Ausführen einer statischen Analyse zu finden, als den Code zu debuggen, wenn sich herausstellt, dass der Komponententest nicht funktioniert. Natürlich finden Unit-Tests mehr Fehler, aber wenn einige davon billiger gefunden werden können (statische Analyse), warum nicht?
Wir finden eine Vielzahl von Fehlern in verschiedenen Projekten. Viele dieser Projekte sind durch Tests gut abgedeckt, aber wie Sie sehen, hilft dies nicht. Es gibt also keinen Grund, nicht zusätzlich zu Komponententests auch eine statische Code-Analyse durchzuführen, um die Qualität und Sicherheit zu verbessern.

„Moderne kostenlose Compiler können dasselbe wie PVS-Studio“

Ja, in der Tat entwickeln sich Compiler weiter und es werden neue Warnungen implementiert, um Fehler im Code zu finden. Sie sollten jedoch im Vergleich zu professionellen kostenpflichtigen Lösungen wie PVS-Studio nicht zu viel von Compilern erwarten.

Vorteile von PVS-Studio:

Benutzerunterstützung.
Umfangreiche Infrastruktur (Integration mit anderen Produkten).
Entwickelte Diagnosefunktionen.

Die ersten beiden Punkte reichen bereits aus, um die Waage zugunsten von PVS-Studio zu überwiegen. Sprechen wir jedoch über die Diagnose. Wir entwickeln den Analysator ständig weiter, um anderen Tools einen Schritt voraus zu sein. Zum Beispiel können wir hier einen so interessanten Fehler " 31. Februar " finden.

Das reicht nicht aus, um skeptische Leser zu überzeugen. Daher überprüfen wir von Zeit zu Zeit andere Compiler und zeigen, dass PVS-Studio darin Fehler finden kann:

PS

Wenn Sie immer noch nicht sicher sind, ob Sie PVS-Studio verwenden sollen, schauen Sie sich an, welche Fehler und in welchen Projekten wir festgestellt haben .

Nützliche Links

Wenn Sie diesen Artikel mit einem englischsprachigen Publikum teilen möchten, verwenden Sie bitte den Link zur Übersetzung: Andrey Karpov. Warum Sie sich für den PVS-Studio Static Analyzer entscheiden sollten, um ihn in Ihren Entwicklungsprozess zu integrieren .

Gründe für die Einführung des statischen Code-Analysators PVS-Studio in den Entwicklungsprozess