Holen Sie sich die neuesten wichtigen Update-Informationen für die Log4j-Sicherheitslücke. Sehen Sie sich an, wie Sie das Problem mithilfe der Parasoft-Anleitung beheben können. Erfahren Sie mehr >>

X
BLOG

Erste Schritte mit statischer Analyse, ohne das Team zu überfordern

Erste Schritte mit statischer Analyse, ohne das Team zu überfordern Lesezeit: 8 Minuten

Dieser Beitrag ist der erste von einigen, die ich schreiben werde, um neuen Benutzern dabei zu helfen, statische Analysetools in ihren Entwicklungsprozess aufzunehmen. Der Einstieg kann schwierig sein, wenn Sie sich zunächst nicht die Zeit genommen haben, um sicherzustellen, dass Sie die richtigen Strategien für Ihr Projekt gefunden haben.

Als Solution Architect hier bei ParasoftWir haben viele Leute, die in diesem Bereich Hilfe suchen. Wissen Sie also, dass Sie nicht allein sind! Und wenn Sie weitere Informationen wünschen, können Sie diese herunterladen und lesen diese vollständige Anleitung dass ich mitgeholfen habe.

Ich gehe davon aus, dass Ihre statischen Analysetools installiert sind und eine Erstkonfiguration eingerichtet wurde. Danach kann der Einstieg schwierig sein, wenn Sie sich zunächst nicht die Zeit genommen haben, um sicherzustellen, dass Sie die richtigen Strategien für Ihr Projekt gefunden haben. Mit „Erste Schritte“ meine ich hier, den allgemeinen Ansatz der Integration der statischen Analyse in ein bestehendes Projekt besser zu verstehen und den Return on Investment der statischen Analyse im Laufe der Zeit zu steigern.

Was ist statische Analyse?

In einfachen Worten bedeutet statische Analyse, dass Quell- und Binärcode ohne Ausführung untersucht werden, normalerweise um Fehler zu finden oder die Qualität zu bewerten. Im Gegensatz zur dynamischen Analyse (z Parasoft Insure ++), für dessen Funktion ein laufendes Programm erforderlich ist, kann die statische Analyse für den Quellcode ausgeführt werden, ohne dass eine ausführbare Datei erforderlich ist.

Dies bedeutet, dass die statische Analyse für teilweise vollständigen Code, Bibliotheken und Quellcode von Drittanbietern verwendet werden kann. Die statische Analyse ist für den Entwickler zugänglich, um beim Schreiben oder Ändern von Code verwendet oder auf eine beliebige Codebasis angewendet zu werden.

Statische Analyse zur Unterstützung der Sicherheit

In der Anwendungssicherheitsdomäne statische Code-Analyse wird als statischer Anwendungssicherheitstest (SAST) bezeichnet. Die statische Analyse kann neben der Erkennung von Fehlern, Qualitätsmetriken und der Konformität mit Codierungsstandards auch die Erkennung von Sicherheitslücken unterstützen.

Statische Analyse zur Unterstützung der Funktionssicherheit und der Kodierungsstandards

Statische Analysewerkzeuge sind auch durch funktionale Sicherheitsstandards wie ISO 26262 oder EN 50128 vorgeschrieben (oder in einigen Fällen „sehr zu empfehlen“), da sie schwer zu findende Fehler erkennen und die Sicherheit von Software verbessern können. Dies kommt natürlich auch auf die Sicherheit zurück, da statische Analysetools auch Softwareteams dabei unterstützen, Codierungsstandards einzuhalten, die hauptsächlich zur Validierung sicherer Codierungen wie CERT oder sogar MISRA verwendet werden.

Einführung der statischen Analyse in Ihr Projekt

Eine großartige Sache bei statischen Analysewerkzeugen ist, dass sie in jeder Phase eines Projekts eingeführt und verwendet werden können, auch wenn ein Projekt unvollständig und teilweise codiert ist. Die größte Herausforderung bei der Einführung der statischen Analyse besteht darin, dass eine große Menge an Code eine große Anzahl von Warnungen erzeugen kann. Daher sollte der Schwerpunkt bei der Integration der statischen Analyse in ein Projekt darauf liegen, das Team so schnell wie möglich produktiv zu machen und die Möglichkeit für das Team zu minimieren, von allen Warnungen zur statischen Analyse überfordert zu werden. Dies soll die Bedeutung dieser Warnungen nicht mindern, aber die meisten Entwickler haben nicht den Luxus, vorhandenen oder älteren Code zu reparieren, zumindest nicht sofort.

Der Fokus sollte darauf liegen, die Tools in alltägliche Prozesse zu integrieren, damit Zugriff und Benutzerfreundlichkeit maximiert werden, und dann die kritischsten Fehler und Sicherheitslücken zu beheben. Sobald das Team kompetenter wird, können Sie sich auf die Optimierung der Tools und Prozesse konzentrieren, um die Kapitalrendite zu steigern.

Beginnen Sie mit dem Ende in Sicht

Um die statische Analyse optimal nutzen zu können, ist es wichtig, das Endziel zu verstehen. Wenn das Ziel beispielsweise eine bessere Sicherheit ist, die den Schwerpunkt der Analyse und Korrektur bildet, oder wenn das Ziel darin besteht, einen Kodierungsstandard wie MISRA C einzuhalten, wird der Schwerpunkt darin bestehen, den Kodierungsstandard zu erfüllen und ihn den Zertifizierungsstellen nach Bedarf nachzuweisen .

Wenn Sie zum ersten Mal eine statische Analyse durchführen, können Sie leicht in die Falle tappen, dass mehr besser ist (dh mehr Analyse und mehr Warnungen bedeuten, dass Sie den größtmöglichen Nutzen aus dem Tool ziehen). Dies ist eine häufige Falle. Konzentrieren Sie sich stattdessen auf das Endziel.

Wenn Sicherheit im Mittelpunkt steht, konzentrieren Sie sich weiterhin auf die Verbesserung der Sicherheit und verringern Sie die Ablenkung anderer Arten von Warnungen. Natürlich sind kritische Fehler immer wichtig, um sie aufzuspüren, aber sie sollten nicht vom Hauptziel ablenken. Mit der Zeit, wenn das Team kompetenter wird, können Sie andere sekundäre Ziele einbeziehen, z. B. die Verbesserung der Gesamtqualität oder die Durchsetzung von Codierungsstandards. Da die statische Analyse Teil des Tagesablaufs eines jeden Entwicklers wird, können sie die Ergebnisse schneller analysieren und Fehler effizienter beheben. Zu diesem Zeitpunkt werden die sekundären Ziele effektiver erreicht, anstatt einfach überwältigend zu sein.

Strategien zur Einführung der statischen Analyse in jeder Phase der Produktreife

Sobald Sie Ihr Hauptziel verstanden haben, auf das Sie sich konzentrieren müssen, müssen Sie die Reife des in der Entwicklung befindlichen Produkts ermitteln, da dies Auswirkungen auf die Art und Weise hat, wie statische Analysen angewendet werden können. Betrachten Sie die wichtigsten Entwicklungsstadien unten und ermitteln Sie, wo Ihr Projekt hineinpasst, damit Sie verstehen, welcher Adoptionsansatz für Sie am besten geeignet ist.

Bestehendes Projekt - in aktueller Entwicklung

Das häufigste Szenario ist eine Softwareorganisation, die sich für die Verwendung statischer Analysen entscheidet und diese auf ihre aktuellen Projekte überträgt.

Jedes Projekt kann wählen, ob die Tools zu Beginn eines Sprints oder zu Beginn eines wichtigen Updates für neue Funktionen übernommen werden sollen. Realistisch gesehen arbeiten Softwareteams immer - selbst wenn ein Produkt „fertig“ ist, ist eine andere Version oder Variante im Gange. Der Hauptaspekt dieses Adoptionsszenarios besteht darin, dass täglich ein erheblicher Teil des vorhandenen Codes und des neuen Codes entwickelt wird. Der empfohlene Integrationsansatz heißt „eine Linie im Sand”Ansatz, der bedeutet, neuen Code während seiner Entwicklung zu verbessern und weniger kritische Warnungen als zu verschieben Technische Schulden. Wir werden gleich mehr darüber sprechen.

Bestehendes Projekt - Produkt auf dem Markt für Wartung

Die Einführung einer statischen Analyse für ein ausgereiftes Produkt kann andere Ziele haben als ein Projekt, das sich noch in der Entwicklung befindet. Dies ist ein Produkt, das sich in den älteren Jahren des Lebenszyklus der Softwareentwicklung befindet und in dem nur wenig neuer Code geschrieben wird, um verbleibende Fehler und Sicherheitslücken zu beheben. Der primäre Ansatz zur Einführung einer statischen Analyse für diese Projekte lautet „bestätigen und verschieben.„Bei diesem Ansatz werden alle entdeckten Fehler und Sicherheitslücken zu den bestehenden technischen Schulden hinzugefügt, da nur wenig neuer Code entwickelt wird.

Greenfield-Projekt

Obwohl es nicht oft vorkommt, dass Softwareteams einen Neuanfang haben, ist ein neues Produkt und Projekt der ideale Punkt, um neue Tools und Techniken in den Entwicklungsprozess zu integrieren.

In diesen Projekten ist nur wenig projektspezifischer Code vorhanden, der jedoch möglicherweise auf Open-Source-Software von Drittanbietern basiert. Entwickler können statische Analysen von Anfang an in ihre Entwicklungsumgebungen integrieren und so einen hohen Qualitätsstandard beim Schreiben von Code sicherstellen. Dies ermöglicht die Übernahme von Codierungsstandards und die Sicherstellung, dass kritische statische Analysewarnungen sofort behandelt werden, wodurch weniger Fehler und Schwachstellen zum technischen Schuldenstapel hinzugefügt werden. Der Ansatz zur Adoption in diesem Fall trägt den treffenden Namen „der grünen Wiese"

Ansätze zur Einführung statischer Analysen: Verwalten früher statischer Analyseberichte

Sobald ein statisches Analysetool im Projekt installiert wurde, wird normalerweise ein ziemlich langer Bericht über Verstöße und Warnungen gemeldet, die vom Tool gemeldet wurden. Dies kann insbesondere in großen Codebasen überwältigend sein. Die Art und Weise, wie diese ersten Berichte verwaltet werden, wirkt sich direkt auf den Erfolg der Integration des Tools in das Projekt aus.

Nicht alle Warnungen sind kritisch, daher muss nicht sofort alles behoben werden. Zu lernen, was sofort angegangen und was aufgeschoben werden muss, ist der Schlüssel zum Erfolg. Wie oben erwähnt, hat die Reife und Größe des Produkts einen direkten Einfluss auf den Ansatz, der nachstehend ausführlicher beschrieben wird.

Linie im Sandansatz

Wie der Name schon sagt, entscheiden Entwickler bei diesem Ansatz, dass nach der ersten Analyse keine kritischeren Warnungen und Verstöße mehr in die Codebasis gelangen. Mit anderen Worten, sie verpflichten sich, jede kritische Warnung zu analysieren, um ihre Richtigkeit zu bestimmen, und eine zeitnahe Korrektur zu implementieren, falls es sich tatsächlich um einen Fehler handelt.

Das Team kann auch entscheiden, kritische Warnungen hinzuzufügen, die bereits in vorhandenem Code entdeckt wurden, um sie der Liste der Fehler in seinem Berichterstellungstool hinzuzufügen. Beispiele für diese Arten von Warnungen können kritische Sicherheitslücken wie SQL-Injektionen oder schwerwiegende Speicherfehler wie Pufferüberläufe sein. In den meisten Fällen können die weniger schwerwiegenden Warnungen für eine spätere Analyse zurückgestellt werden. Sie denken vielleicht: "Trägt dies nicht nur zu unserer technischen Verschuldung bei?" Und wenn Sie es sind, haben Sie Recht! Aber zu diesem Zeitpunkt sind wir damit einverstanden. Mögliche Fehler in diesen Warnungen befanden sich bereits im technischen Schuldenstapel. Zumindest jetzt sind sie identifiziert und zu einem späteren Zeitpunkt viel einfacher zu reparieren.

Ansatz bestätigen und verschieben

In dem Fall, in dem ein Produkt bereits auf dem Markt ist und gewartet wird, ist es weiterhin von Vorteil, verbleibende Fehler und Sicherheitslücken im Code zu identifizieren. Für Entwickler ist es jedoch nicht möglich, alle diese Warnungen zu analysieren (geschweige denn zu beheben).

In einem solchen Fall ist es sinnvoll, sich die wichtigsten Berichte anzusehen und eine Vorgehensweise festzulegen. Der Rest der Warnungen wird bestätigt, da das Softwareteam erkennt, dass sie vorhanden sind, sie werden jedoch meistens für einen späteren Zeitpunkt zurückgestellt. (Dies erhöht wiederum die technische Verschuldung der Organisation, aber wie oben erwähnt, existieren diese Fehler technisch bereits als technische Verschuldung.) Dieser Ansatz unterscheidet sich vom Line-in-the-Sand-Ansatz darin, dass Sie nach dem Erkennen der wichtigsten Warnungen einfach aufschieben der Rest ohne notwendige Analyse.

Greenfield-Ansatz

Ein Projekt mit wenig vorhandenem Code ist ein idealer Ausgangspunkt für die statische Analyse. In diesem Fall können die Softwareteams alle auftretenden Warnungen untersuchen und gefundene Fehler beheben. Im Gegensatz zu den anderen Ansätzen müssen nur wenige Warnungen verwaltet werden, sodass Entwickler die zusätzliche Arbeitslast bewältigen können. Dies ist auch ein idealer Zeitpunkt, um einen Codierungsstandard über die Tools zu implementieren und durchzusetzen, da Verstöße direkt in der IDE und vor der Übermittlung von Code an die Versionskontrolle identifiziert und behoben werden können (was Sie auch in den anderen hier beschriebenen Szenarien tun können). .

Die Einführung der statischen Analyse in den drei Hauptreifephasen unterscheidet sich dadurch, wie sie mit dem Rückstand an Warnungen umgehen, wie nachstehend dargestellt:

Die Einführung der statischen Analyse in den drei Hauptstadien der Reife: In einem Greenfield-ProjektDie meisten gemeldeten Warnungen werden untersucht und behoben, ohne dass der technische Schuldenstapel in Mitleidenschaft gezogen wird. Projekte in Entwicklung neigen dazu, einen Rückstand an Warnungen zu haben, die meistens zurückgestellt werden, wenn nur kritische Warnungen behandelt werden, und Produkte unter Wartung neigen dazu, die meisten Warnungen aufgeschoben zu haben.

Konfiguration versus Filterung

Einer der Hauptunterschiede zwischen Open Source- oder leichten statischen Analysetools und kommerziellen erweiterten statischen Analysetools besteht in der Möglichkeit, zu konfigurieren, welche Prüfer für die Analyse aktiviert sind, und gemeldete Ergebnisse basierend auf Warnkategorie, Dateiname, Schweregrad und anderen herauszufiltern Attribute. Dies hilft mit dem Ziel, nicht überfordert zu werden. Entwickler können sich nur auf die Arten von Warnungen konzentrieren, an denen sie interessiert sind, und die Menge der zu einem bestimmten Zeitpunkt bereitgestellten Informationen reduzieren.

Es gibt auch einen bemerkenswerten Unterschied zwischen Prüfer konfigurieren und Filterergebnisse. Obwohl es anfangs vielleicht besser erscheint, die Anzahl der Regeln in der globalen Konfiguration zu begrenzen, sollte stattdessen häufig eine Filterung verwendet werden, um den Umfang der Berichterstellung einzuschränken, anstatt den Prüfer vollständig zu eliminieren. Wenn eine Regel, die sich später als wichtig herausstellt, in der Konfiguration deaktiviert ist, wird im Warnrepository kein Verlauf angezeigt, sodass Sie nicht herausfinden können, ob der Fehler durch die letzten Änderungen oder bereits im Code verursacht wurde bevor die statische Analyse übernommen wurde.

Ich würde empfehlen, die Konfiguration zu verwenden, um den Regelsatz einfach auf diejenigen zu beschränken, die für das Softwareteam als nützlich ersichtlich sind. Beginnen Sie erneut mit dem Endziel: Wenn die Verbesserung der Sicherheit das Hauptziel ist, ist es sinnvoll, alle sicherheitsrelevanten Regeln zu aktivieren, weniger wichtige Regeln zu deaktivieren und einen der integrierten sicheren Codierungsstandards wie CERT C zu aktivieren. Wenn Sie dann eine fortschrittliche statische Analyselösung wie den Parasoft C / C ++ - Test verwenden, können Sie die integrierten Verwaltungstools nutzen, um mit den aus den statischen Analyseberichten erzeugten Daten umzugehen und den zukünftigen Entwicklungsfokus voranzutreiben.

Zusammenfassung

Statische Analysetools bieten Softwareunternehmen die Möglichkeit, Sicherheitslücken in Bezug auf Fehler zu erkennen und zu verfolgen, ohne Code ausführen zu müssen. Diese Tools können auf vorhandenen Code, Legacy-Code und Code von Drittanbietern angewendet werden und bieten Qualität.

Die Übernahme der statischen Analyse hängt in gewissem Maße von der Laufzeit des Projekts ab. Ein großer Code führt zu zahlreichen Warnungen. Dies ist vollständig beherrschbar und der Erfolg der Einführung hängt davon ab, wie sich die Teams entscheiden, die Ergebnisse in Angriff zu nehmen. Für jeden Hauptreifegrad eines Projekts werden verschiedene Techniken vorgestellt und wie diese Tools in den täglichen Workflow für Entwickler, Teamleiter und Manager integriert werden können.

In meinem nächsten Beitrag werde ich über die Integration statischer Analysen in Ihre täglichen Arbeitsabläufe sprechen. Oder abonnieren Sie den Blog, indem Sie Ihren Namen in das Feld direkt unter diesem Beitrag eintragen, um benachrichtigt zu werden, wenn er herauskommt.

Erste Schritte mit der statischen Analyse
„MISRA“, „MISRA C“ und das Dreieckslogo sind eingetragene Marken von The MISRA Consortium Limited. ©The MISRA Consortium Limited, 2021. Alle Rechte vorbehalten.

Geschrieben von

Billy McMullin

Als Solution Architect bei Parasoft unterstützt Billy Teams bei der Strategieplanung und Priorisierung, wenn sie moderne Softwareentwicklungs- und Testpraktiken in ihre Organisation übernehmen.

Erhalten Sie die neuesten Nachrichten und Ressourcen zum Testen von Software sofort.