Ein praktischer Leitfaden, um Ihre Legacy-Codebase MISRA C 2012-kompatibel zu machen

Die Wiederverwendung von Legacy-Code ist eine Realität, aber die Wiederverwendung von Legacy-Code in einem sicherheitskritischen Softwareprojekt und das Erreichen der vollen MISRA Die Einhaltung von C 2012 ist eine gewaltige Aufgabe.

Die ursprünglichen MISRA-Prinzipien wurden geschaffen, um bei der Entwicklung von Code angewendet zu werden. Sogar das Dokument selbst enthält eine Warnung:

"… Ein Projekt, das spät in seinem Zyklus die Einhaltung von MISRA C überprüft, wird wahrscheinlich viel Zeit damit verbringen, neu zu codieren, zu überprüfen und erneut zu testen. Es wird daher erwartet, dass der Softwareentwicklungsprozess die frühzeitige Anwendung der MISRA C-Prinzipien erfordert."

Da viele Unternehmen ihre Legacy-Codebasen aus geschäftlichen Gründen wiederverwenden müssen, wurde der Leitfaden MISRA Compliance: 2016 als Antwort auf diese Herausforderungen erstellt. Darin wird klar unterschieden zwischen dem neuen, nativen Code, der im Rahmen eines laufenden Projekts entwickelt wird, und dem „übernommenen“ Code, der außerhalb des Projekts entwickelt wurde. In diesem Beitrag erkläre ich einen praktischen Ansatz zum Umgang mit Legacy-Code und MISRA C-Konformität.

Die Graustufen der Befolgung der MISRA-Richtlinien

Obwohl es einfach zu verstehen scheint, mit welcher Art von Code Sie es zu tun haben, ist die Situation in vielen Fällen nicht schwarzweiß. Beispielsweise wird ein erster Prototyp erstellt, der ohne Befolgung der MISRA-Richtlinien entwickelt wurde, und das Management erkennt, dass die Einhaltung von Vorschriften eine Voraussetzung für den beabsichtigten Markt ist. In der Regel wurde die Legacy-Codebasis nie unter Berücksichtigung von Codierungsrichtlinien entwickelt. Daher kann eine Codebasis nicht automatisch als "übernommener Code" klassifiziert werden, wenn im Kontext eines neuen Projekts Aktualisierungen erforderlich sind. Dies kann komplex werden.

Allzu oft führen erste Scans einer großen Codebasis über ein statisches Analysetool mit allen aktivierten MISRA C 2012-Regeln, einschließlich Änderung 1, zu Zehntausenden von Verstößen. Nach dem ersten Schock beginnen die Teams, „kreative“ Wege zu finden, um die Verstöße zu beheben. Es ist wichtig, dass sich Entwicklungsteams nicht abschrecken lassen - am Ende des Tunnels ist Licht.

Im Laufe der Zeit habe ich Best Practices und Ansätze gesammelt und identifiziert, mit denen Entwicklungsteams den Code konform gemacht haben, ohne die laufende Entwicklungsgeschwindigkeit zu beeinträchtigen. In diesem Beitrag teile ich einige praktische, ausgewogene Ansätze, um vorhandene Codebasen MISRA-konform zu machen.

Verwenden Sie das MISRA Compliance: 2016 Framework

MISRA C 2012 ist eine Reihe von Codierungsrichtlinien für die Programmiersprache C. Der Schwerpunkt des Standards liegt auf der Erhöhung der Sicherheit von Software, indem Programmierer präventiv daran gehindert werden, Codierungsfehler zu machen, die zu Laufzeitfehlern (und möglichen Sicherheitsbedenken) führen können, indem bekannte Problemkonstrukte in der Sprache C vermieden werden. Im Laufe der Jahre haben (und werden) viele Entwickler eingebetteter Systeme beanstandet, dass MISRA C einem zu strengen Standard entspricht und dass die Kosten für das Schreiben von vollständig kompatiblem Code schwer zu rechtfertigen sind. Angesichts der Tatsache, dass MISRA C in sicherheitskritischer Software angewendet wird, hängt der Wert der Anwendung des Standards auf ein Projekt realistisch von folgenden Faktoren ab:

• Risiko einer Systemstörung aufgrund eines Softwarefehlers
• Kosten eines Systemausfalls für das Unternehmen
• Entwicklungswerkzeuge und Zielplattform
• Kenntnisstand des Entwicklers

Daher müssen Programmierer einen praktischen Mittelweg finden, der dem Geist des Standards entspricht, und dennoch die Einhaltung von MISRA fordern, ohne Anstrengungen für Aktivitäten ohne Mehrwert zu verschwenden.

Im Dokument MISRA-Konformität: 2016 Das MISRA-Konsortium bietet die Antwort, die von der Community benötigt wurde, mit einem einigermaßen genau definierten Rahmen für die Erklärung "MISRA-konform" wirklich bedeutet. Das Dokument unterstützt die Organisation bei der Verwendung einer gemeinsamen Sprache, in der die Compliance-Anforderungen formuliert werden, indem die folgenden Artefakte definiert werden:

• Durchsetzungsplan für Richtlinien - zeigt, wie jede MISRA-Richtlinie überprüft wird.
• Richtlinien-Neukategorisierungsplan - teilt die vereinbarte Schwere der einzelnen Regeln in den Richtlinien als Teil der Lieferanten- / Kundenbeziehung mit.
• Abweichungsbericht - dokumentiert die Verstöße gegen Richtlinien mit angemessener Begründung.
• Zusammenfassung der Richtlinienkonformität - ist die Hauptaufzeichnung der Gesamtkonformität des Projekts.

Um sich darauf zu konzentrieren, was mit einer Legacy-Codebasis zu tun ist, ist das Schlüsseldokument das Neukategorisierung der Richtlinie planen. Dieses Dokument erfasst alle Anweisungen und Regeln und gibt an, welche Kategorien neu kategorisiert wurden. Das folgende Diagramm zeigt beispielsweise einen Teil eines Neukategorisierungsplans:

Erstens, für den "angenommenen" Legacy-Code, der MISRA 2016: Konformität Dokument schlägt gegen Neukategorisierungen von einer weniger strengen zu einer strengeren Klassifizierung vor. Darüber hinaus ist es möglich abmelden Beratungsregeln insgesamt nach Überprüfung der Arten von Verstößen mit dem Team.

Die Anforderung, Abweichungen zu dokumentieren, ist nur für alle erforderlichen Regeln erforderlich. Verstöße gegen den verabschiedeten Kodex sollten überprüft werden, und Abweichungen müssen eindeutig angeben, dass Verstöße die Sicherheit nicht beeinträchtigen. Unabhängig von der Neukategorisierung muss das Problem behoben werden, wenn ein Ergebnis vorliegt, das die Sicherheit des Systems gefährdet. Änderungen am Legacy-Code können auch zu anderen Problemen führen, die vom Entwickler nicht klar erkannt werden.

Fang an und sei dir dem Ende bewusst

Ein Hauptproblem, auf das Entwickler sicherheitskritischer Software stoßen, besteht darin, die Einhaltung am Ende des Projekts nachzuweisen und nachzuweisen. Dies kann ein umstrittenes Thema sein, das zu Zeit- und Arbeitsverschwendung führt, wenn die Bewertungskriterien auf subjektiven Meinungen der verschiedenen Interessengruppen beruhen. Dies ist eine Situation, die die MISRA-Konformität: 2016 Dokument half zu klären.

Ein empfohlener Ansatz zur Verbesserung der Bewertung der Compliance-Bereitschaft besteht darin, vorhandene Vorlagen sowohl für den endgültigen Compliance- als auch für den Tool-Qualifizierungsbericht zu verwenden. Es besteht auch die Tendenz, mehr Informationen in die Berichte aufzunehmen, als erforderlich sind. Wenn die Informationen vom Standard nicht verlangt werden, vermeiden Sie Verzierungen. Das Hinzufügen zusätzlicher Informationen ist nicht nur Zeitverschwendung, sondern birgt auch das Risiko, einen Prüfungsprozess zu verzögern.

Die erforderlichen Informationen, die in den Abschlussbericht aufgenommen werden sollen, werden von bereitgestellt MISRA-Compliance 2016:

• Durchsetzungsplan für Richtlinien
• Zusammenfassung der Richtlinienkonformität
• Details aller genehmigten Abweichungsgenehmigungen
• Abweichungsaufzeichnungen, die alle Verstöße gegen Richtlinien abdecken, die als Erforderlich neu kategorisiert wurden.

Das folgende Beispiel aus dem Parasoft-Tool zeigt ein HTML-Format mit Links zu entsprechenden Abschnitten:

Legen Sie das Endziel frühzeitig fest

Zusätzlich zu den oben genannten Empfehlungen sind noch einige weitere wichtige Punkte zu beachten:

1. Wurde zu Beginn des Projekts der GFK (Guideline Re-Categorization Plan) erstellt? Nach dem MISRA-Standard werden Verhandlungen mit dem Erwerber ist möglich, ebenso wie die Erstellung mehrerer GFKs für die angenommen Code, der ohne Änderungen verwendet wird und nativen Code, bei dem es sich um die Dateien handelt, die während des Projekts aktiv geändert wurden.

2. Für jeden inkrementelle ÄnderungGibt es einen Einblick in die Anzahl der verbleibenden Arbeiten, um die vollständige Einhaltung zu erreichen? Dies hilft, die Arbeit entsprechend zu planen und die richtigen Erwartungen mit dem Management zu setzen.

3. Wurden die GPS-Berichtsvorlagen (Guidelines Compliance Summary) mit dem überprüft? Erwerber zu Beginn des Projekts und wurden sie als akzeptabel und vollständig befunden?

Es gibt Vorlagen für diese Dokumente, die kommerzielle Anbieter von statischen Analysetools, einschließlich Parasoft, bereitstellen, um Unternehmen bei der Einhaltung des MISRA 2016-Compliance-Frameworks zu unterstützen.

Ein schrittweiser Ansatz: Teilen und Erobern

Obwohl der erste Scan des vorhandenen Codes durch ein statisches Analysetool dazu neigt, Tausende von Verstößen zu verursachen (insbesondere bei Verwendung eines Standardregelsatzes), ist es unpraktisch, neue Entwicklungsbemühungen zu stoppen, um sich auf die Behebung all dieser Verstöße zu konzentrieren. Tatsächlich habe ich Fälle gesehen, in denen Regressionen eingeführt wurden, als signifikante Änderungen an der Codebasis vorgenommen wurden, um die Verstöße gegen die statische Analyse zu beheben. Daher ist es wichtig, einen Workflow einzurichten, um die Verstöße im Laufe der Zeit zu beheben, ohne den Entwicklungsprozess zu stören und die Qualität der Software zu beeinträchtigen.

Einige wichtige Empfehlungen für die erstmalige Verwendung statischer Analysewerkzeuge in einem Projekt sind nachstehend aufgeführt:

• Baselining. Markieren Sie nach dem ersten Scannen des Codes alle anfänglichen Verstöße als "später zu beheben" und setzen Sie sie als Baseline. Halten Sie ab diesem Zeitpunkt beim Aktualisieren des vorhandenen Codes und / oder beim Entwickeln des neuen Codes die Richtlinie "Keine neuen Verstöße zulässig" ein. Diese Richtlinie kann durch den Codeüberprüfungsprozess oder ein CI-Tool (Continuous Integration) wie erzwungen werden Jenkins or Bambus. Wenn Entwickler ein paar Stunden oder Tage Zeit haben, können sie verbleibende Verstöße beheben, die von der Baseline markiert sind. Unternehmen können diesen Ansatz basierend auf dem in der Entwicklung befindlichen aktuellen Code, den Ergebnissen der Codeüberprüfung oder anhand von Metriken (z. B. Komplexität) priorisieren, um den nächsten zu behebenden Verstoß vorzuschlagen.
• Linie im Sand. Die Entwicklung legt ein Datum fest, "die Linie im Sand". Nach diesem Datum müssen für jede geänderte Übersetzungseinheit (einzelne Quelldatei) alle Verstöße behoben sein. Alle unveränderten Übersetzungseinheiten fallen automatisch unter die wahre „übernommene“ Code-Definition aus dem MISRA-Compliance-Dokument.
• Schweregradbasierte Priorisierung. Der Entwickler korrigiert alle obligatorischen Ergebnisse für das ihm zugewiesene Modul. Im Laufe der Zeit werden alle erforderlichen Verstöße behandelt, sofern es die Zeit erlaubt, basierend auf einer vom Teamleiter ausgewählten Priorität.

Für jeden der oben beschriebenen Ansätze ist es wichtig, dass die technischen Leiter und das Management den Fortschritt und den Status der Projektkonformität über ein zentrales Dashboard ständig überwachen. Der Berichts-Hub von Parasoft bietet beispielsweise das folgende vorkonfigurierte Dashboard für den Konformitätsstatus:

Werkzeugqualifikation

Ein weniger offensichtlicher Bestandteil der MISRA-Konformität, der häufig bis zum Ende des Projekts verbleibt, ist die Erkenntnis, dass die im Produkt verwendeten Entwicklungswerkzeuge für den beabsichtigten Gebrauch qualifiziert (nachweislich zweckmäßig) sein müssen. Wenn ein Tool qualifiziert werden muss, welche Validierungsstufe muss durchgeführt werden?

Während in vielen Fällen eine Werkzeugqualifizierung erforderlich ist, ist die Methode Die zur Durchführung der Werkzeugqualifizierung verwendete Methode hängt vom Risiko ab, das mit der Fehlfunktion des Werkzeugs und der Kritikalität der Software verbunden ist. Parasoft bietet ein Qualifizierungskit und Zertifizierungen für bestimmte Sicherheitsstandards und deren Anforderungen. In Ermangelung dieses effizienten Kits müssen Softwareteams die Kosten für die Toolqualifizierung bei der Bewertung von kommerziellen, kostenlosen und Open Source-Tools berücksichtigen.

Einige Standards mögen ISO 26262 funktioniert DO-178B / C. Geben Sie angemessene Hinweise zu den Anforderungen an die Werkzeugqualifizierung. Unabhängig von der Methode besteht das Ziel des Werkzeugqualifizierungsprozesses darin, anzugeben, dass „Werkzeug für den beabsichtigten Gebrauch gültig ist“, und einen Beweis und eine Begründung dafür zu liefern, wie das Team zu diesem Schluss gekommen ist.

Im Folgenden sind einige empfohlene Schritte für einen Werkzeugqualifizierungsprozess aufgeführt:

• Geben Sie die Werkzeuganforderungen für Ihren Verwendungszweck an
• Identifizieren Sie eine Teilmenge der verwendeten Funktionen im Produkt. Reduzieren Sie den Qualifizierungsprozess nur auf die verwendeten Funktionen
• Skizzieren Sie einen Qualifikationsplan
• Beschreiben Sie die Qualifizierungsschritte (einschließlich der vom Team durchgeführten Tests), mit denen überprüft wird, ob das Tool die Anforderungen erfüllt
• Führen Sie automatisch Testfälle aus, die automatisiert werden können
• Bereitstellung eines Frameworks zur Eingabe der Ergebnisse manueller Testschritte
• Berichtsvorlagen zur Reduzierung der Textmenge, die von Entwicklern eingegeben werden muss.
• Überprüfen Sie den Bericht mit den Stakeholdern und melden Sie sich ab.

Das Übersehen der Werkzeugqualifikation von Anfang an kann zu Projektverzögerungen spät im Zyklus führen.

Kompetenz und Schulung des Personals

Das Fachwissen und die Schulung des Entwicklungspersonals sind ein weiterer Schlüsselfaktor, der von Softwareorganisationen übersehen wird und von Auditoren häufig als Hauptproblem bei der Bewertung der Bereitschaft eines Produkts identifiziert wird.

Gemäß den MISRA-Richtlinien Personalkompetenz ist ein wichtiger Bestandteil der MISRA-Konformität. Es ist am besten, zu Beginn des Projekts eine Schulung durchzuführen und einen Schulungstermin mit allen Entwicklern aufzuzeichnen, die unterschrieben haben, dass sie die Schulung erhalten haben. Am Ende des Projekts sollte das Entwicklungsteam nachweisen können, dass:

• Mitarbeiter, die Abweichungen genehmigt haben, verstehen und wurden geschult, um die mit dem Verstoß verbundenen Risiken zu erkennen
• Das Personal wurde geschult, um die statischen Analyse- und Entwicklungstools vor der Verwendung ordnungsgemäß zu konfigurieren und zu verwenden.

In der Praxis ist die Schulung für ein erfahrenes Team relativ kurz, aber ein paar Tage, die zu Beginn des Projekts investiert werden, sparen Wochen der Nacharbeit, nachdem ein Projekttermin versäumt wurde.

Zusammenfassung

Es gibt keine Silberkugel, die das Erreichen ermöglicht MISRA Die Einhaltung von Legacy-Code ist in sicherheitskritischen Projekten einfach. Zusammen mit der Einführung der MISRA-Compliance 2016 Unter Verwendung des praktischen schrittweisen Ansatzes unter Berücksichtigung eines klar definierten Endpunkts, wie in diesem Beitrag beschrieben, können Softwareentwicklungsteams Compliance erreichen, ohne ihren Entwicklungsprozess wesentlich zu stören. Das Fazit ist, dass noch viel Arbeit erforderlich ist, um die Einhaltung der Vorschriften zu erreichen. Mit intelligenter Planung und dem richtigen Ansatz kann jedoch ein minimaler und ausgewogener Satz von Aufgaben festgelegt werden, um sowohl alten als auch neu entwickelten Code sicher zu machen.

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