DO-178C-Softwarekonformität für die Luft- und Raumfahrt sowie Verteidigung

Statische Codeanalyse ist die Analyse von Code ohne tatsächliche Codeausführung. Statische Analyse deckt Sicherheitslücken im Code durch die Anwendung umfassender Codeanalysetechniken auf, darunter:

• Musterbasierte Analyse
• Datenflussanalyse
• Kontrollflussanalyse
• Abstrakte Interpretation
• Codemetriken und mehr

Diese Methoden identifizieren Speicherpufferüberläufe, Division durch Null, die Verwendung unsicherer Bibliotheken, Organisationscodierungsregeln, Richtlinienverletzungen und so weiter.

In D0-178C fallen die Ziele der statischen Analyse unter Abschnitt 6, der sich auf Softwareverifizierungsprozesse bezieht. Die Ziele der statischen Analyse konzentrieren sich darauf, sicherzustellen, dass der Softwarecode frei von bestimmten Arten von Mängeln ist und guten Codierungspraktiken folgt.

Beispielsweise bietet Abschnitt 6.3.4 „Überprüfung und Analyse des Quellcodes“ einen Überblick über die erforderlichen Softwareüberprüfungsaktivitäten, um Code hinsichtlich Konformität, Überprüfbarkeit und Rückverfolgbarkeit zu überprüfen. Dieser Abschnitt gibt jedoch auch die Notwendigkeit an, den Code auf Konformität mit Standards, Genauigkeit und Konsistenz zu prüfen, was alles gute Anwendungen für die statische Analyse sind.

Obwohl D0-178C keine spezifischen Anforderungen an die statische Analyse stellt, sind die Richtlinien und Ziele in Bezug auf die statische Analyse auf mehrere Abschnitte in Kapitel 6 verteilt. Es ist von entscheidender Bedeutung, diese Richtlinien im Kontext des Projekts richtig zu interpretieren und anzuwenden, um die Einhaltung von D0-178C für die Zertifizierung von Bordsoftware sicherzustellen.

Anforderungen in DO-178C

Einige typische Anforderungen für die statische Analyse in D0-178C können Folgendes umfassen.

Die meisten dieser Verifizierungsaktivitäten werden durch die Automatisierung der statischen Analyse mithilfe moderner fortschrittlicher Tools wie Parasoft C/C++test unterstützt. Darüber hinaus bietet Parasoft Codemetriken zu Wartbarkeit, Klarheit, Testbarkeit, Portabilität, Robustheit, Wiederverwendbarkeit, Komplexität und Unterstützung für Team-Code-Peer-Reviews. Dynamische Analyse, Unit-Tests und andere Laufzeitfehlererkennung werden ebenfalls bereitgestellt.

Frühzeitige Fehlererkennung

Eine frühzeitige Fehlererkennung mit statischen Analysetools kann die Einhaltung von D0-178C erheblich verbessern, indem potenzielle Codierungsprobleme und Schwachstellen im Softwareentwicklungsprozess behoben werden. Bei der statischen Analyse wird der Quellcode analysiert, ohne ihn auszuführen, und anhand vordefinierter Regeln werden Fehler und potenzielle Probleme identifiziert.

Statische Analysetools können Codierungsfehler und Bugs im Quellcode bereits früh im Entwicklungsprozess erkennen. Indem das Entwicklungsteam diese Fehler frühzeitig erkennt und behebt, kann es verhindern, dass sich solche Mängel in spätere Entwicklungsphasen ausbreiten, wo ihre Behebung möglicherweise schwieriger und kostspieliger ist.

Sicherheitskritische Software, die in Bordsystemen verwendet wird, muss vor potenziellen Sicherheitslücken geschützt werden. Statische Analysetools können potenzielle Sicherheitslücken im Code identifizieren, wie Pufferüberläufe, Probleme bei der Eingabevalidierung und andere sicherheitsrelevante Mängel. Die frühzeitige Behebung dieser Schwachstellen im Entwicklungsprozess verbessert die Sicherheit der Software.

D0-178C erfordert umfassende Verifizierungsaktivitäten während des gesamten Softwareentwicklungszyklus (Kapitel 6). Die statische Analyse ist eine Form der statischen Verifizierung und ermöglicht eine frühzeitige Verifizierung des Quellcodes. Durch frühzeitiges Auffinden und Beheben von Mängeln kann die Software die nachfolgenden Verifizierungsphasen mit größerer Sicherheit durchlaufen, was auf lange Sicht Zeit und Aufwand spart.

Durch die frühzeitige Einführung statischer Analysen in Verbindung mit anderen Verifizierungs- und Validierungsmethoden im Softwareentwicklungsprozess können Teams Mängel und Sicherheitslücken proaktiv beheben. Dies führt zu einem rationalisierteren Zertifizierungsprozess und einer höheren Wahrscheinlichkeit, zuverlässige und sichere Software für den Einsatz in Bordsystemen zu entwickeln.

Zu den häufigsten Fehlertypen, die durch die statische Analyse des Parasoft C++-Tests erkannt werden können, gehören:

Dies sind nur einige Beispiele für die Arten von Fehlern, die die statische Analyse von Parasoft C++test erkennen kann. Darüber hinaus können statische Analysetools wie Parasoft C++test so angepasst werden, dass sie je nach den spezifischen Anforderungen und Codierungsstandards des Projekts bestimmte Arten von Prüfungen einschließen oder ausschließen.

Coding Standards

In Bezug auf Codierungsstandards schreibt D0-178C keinen bestimmten Satz von Codierungsstandards vor, die befolgt werden müssen. Stattdessen bietet es Richtlinien und Ziele für die Festlegung und Einhaltung von Codierungsstandards, die für die Entwicklung sicherheitskritischer Bordsoftware geeignet sind.

Die relevanten Abschnitte in D0-178C, die sich auf Kodierungsstandards beziehen, finden sich hauptsächlich in Kapitel 6 „Softwareverifizierungsprozess“ und Kapitel 11 „Softwarelebenszyklusdaten“. Hier ist, was D0-178C normalerweise in Bezug auf Kodierungsstandards verlangt.

D0-178C erkennt an, dass unterschiedliche Projekte je nach Faktoren wie der Komplexität der Software, der Kritikalität des Systems und der Entwicklungsumgebung unterschiedliche Codierungsstandards haben können (z. B. MISRA C/C++, CERT C/C++, CWE, OWASP, DISA ASD STIG usw.).

Daher werden die spezifischen Codierungsstandards und -regeln vom Entwicklungsteam festgelegt, wobei die oben beschriebenen Richtlinien weiterhin eingehalten werden müssen.

Ein wesentlicher Teil der Zertifizierungsnachweise, die für die Einhaltung von D0-178C erforderlich sind, ist die Dokumentation, die während dieser Überprüfungen und des Verifizierungsprozesses gesammelt wird. Es ist wichtig, dass der Codierungsstandard die erforderlichen Inspektions- und Dokumentationsprozesse unterstützt.

MISRA C: 2023

MISRA C. ist eine Reihe von Codierungsrichtlinien für die Programmiersprache C, Versionen C89/C90, C99, C11 und C18. Der Schwerpunkt des Standards liegt auf der Erhöhung der Softwaresicherheit, 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.

MISRA C kann dabei helfen, die Anforderungen von D0-178C zu erfüllen, dem Softwarestandard für die Zertifizierung von Bordsystemen. So kann MISRA C die Anforderungen erfüllen.

1. Erfüllt alle im vorherigen Abschnitt aufgeführten Anforderungen des Codierungsstandards.
2. Bietet einen klar definierten und weithin anerkannten Codierungsstandard, der vom Entwicklungsteam übernommen werden kann, um konsistenten und zuverlässigen Code zu erstellen.
3. Umfasst regelmäßige Codeüberprüfungen, um die Einhaltung des Standards sicherzustellen.

Die Einführung von MISRA C trägt dazu bei, das Potenzial für Codierfehler und Mehrdeutigkeiten zu minimieren, was zu einer verbesserten Sicherheit und Zuverlässigkeit der Software führt. Der Fokus des Codierstandards auf Robustheit und Codekorrektheit passt gut zu den Zielen von D0-178C, die Entwicklung von Software mit hoher Integrität für Bordsysteme sicherzustellen.

Es ist wichtig zu beachten, dass MISRA C an sich keine Garantie für die Einhaltung der Zertifizierung darstellt. Es ist eines der Tools und Prozesse, die zu den allgemeinen Softwareentwicklungs- und Verifizierungsaktivitäten beitragen, die für die D0-178C-Zertifizierung erforderlich sind. Darüber hinaus kann jedes Projekt spezifische Anforderungen und Einschränkungen haben, sodass der MISRA C-Standard möglicherweise angepasst oder durch projektspezifische Codierungsregeln und -praktiken ergänzt werden muss.

Im Laufe der Jahre beschwerten sich viele Entwickler eingebetteter Systeme darüber, dass MISRA C ein zu strenger Standard sei und dass die Kosten für das Schreiben vollständig konformen Codes schwer zu rechtfertigen seien. Angesichts der Tatsache, dass MISRA C in sicherheitskritischer Software eingesetzt wird, hängt der Nutzen der Anwendung des Standards auf ein Projekt realistischerweise von Faktoren wie den folgenden ab:

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

Programmierer müssen einen praktischen Mittelweg finden, der dem Sinn des Standards entspricht und dennoch MISRA-Konformität gewährleistet, ohne Aufwand für Aktivitäten ohne Mehrwert zu verschwenden.

Nachweis der MISRA-Konformität

Ein Hauptproblem, mit dem Entwickler sicherheitskritischer Software konfrontiert sind, ist der Nachweis und die Kontrolle der Einhaltung der Vorschriften am Ende des Projekts. Es besteht die Tendenz, den Berichten mehr Informationen hinzuzufügen als erforderlich. Wenn die Bewertungskriterien auf subjektiven Meinungen der verschiedenen Interessengruppen basieren, kann dies zu einem Streitthema werden, das Zeit und Mühe verschwendet.

Ein empfohlener Ansatz zur Verbesserung der Bewertung der Compliance-Bereitschaft besteht darin, vorhandene Vorlagen sowohl für den endgültigen Compliance-Bericht als auch für den Tool-Qualifizierungsbericht zu verwenden. Wenn die Informationen vom Standard nicht verlangt werden, vermeiden Sie es, sie hinzuzufügen. Das Kombinieren zusätzlicher Informationen ist nicht nur Zeitverschwendung, sondern birgt auch das Risiko einer Verzögerung eines Prüfprozesses. Die Dokumentation automatisch generieren zu lassen, wie es Parasoft tut, ist die ultimative Lösung.

Das Dokument „MISRA Compliance: 2020“ unterstützt Unternehmen außerdem dabei, eine gemeinsame Sprache zur Formulierung der Compliance-Anforderungen zu verwenden, indem es die folgenden Artefakte definiert:

• Zusammenfassung der Richtlinienkonformität
• Richtlinien-Durchsetzungsplan
• Abweichungsbericht
• Richtlinien-Neukategorisierungsplan

Die folgenden Screenshots von Parasoft zeigen automatisch generierte Berichte mit Links zu anderen Datensätzen und/oder erweiterten Informationen auf der Seite.

SEI/CERT

Das Computer Emergency Response Team (CERT) des Software Engineering Institute (SEI) verfügt über eine Reihe von Richtlinien, die Entwicklern dabei helfen sollen, sicherere und zuverlässigere Software zu erstellen. Gestartet wurde das Team 2006 bei einem Treffen des C Standard Committee, dem ersten CERT C-Standard wurde 2008 veröffentlicht und wird ständig weiterentwickelt.

Es gibt eine Buchversion, die 2016 veröffentlicht wurde, aber sie enthält nicht die neuesten Updates. Dieser Standard hat keine spezifischen eingefrorenen Veröffentlichungen wie CWE Top 25 und OWASP Top 10. Der Standard entstand aus einer großen Community von über 3,000 Personen mit einem Schwerpunkt auf Engineering und Prävention. Die CERT-Standards für sicheres Coding konzentrieren sich daher auf die Prävention der Grundursachen von Sicherheitslücken, anstatt die Symptome durch die Suche nach Schwachstellen zu behandeln oder zu bewältigen.

Die CERT-Codierungsrichtlinien sind für C, C++, Java, Perl und Android verfügbar. Sie fallen in zwei Hauptkategorien.

Regeln sind Richtlinien, die durch statische Analysetools erkennbar sind und eine strikte Durchsetzung erfordern, während Empfehlungen Richtlinien sind, die eine geringere Auswirkung haben und manchmal schwierig automatisch zu analysieren sind.

CERT beinhaltet ein Risikobewertungssystem, das die Wahrscheinlichkeit des Auftretens, den Schweregrad und den relativen Schwierigkeitsgrad der Schadensbegrenzung kombiniert. Dies hilft Entwicklern dabei, Prioritäten zu setzen, welche Richtlinienverstöße am wichtigsten untersucht werden müssen. Die Einbeziehung von Schadensbegrenzungsmaßnahmen in die Richtlinienpriorität ist eine wichtige Ergänzung der CERT-Standards für sicheres Codieren, die vielen anderen Standards fehlt.

Der Kostenfaktor ermöglicht die Erstellung des CERT-Bullseye-Diagramms, in dem das mittlere Bullseye die Richtlinien mit dem höchsten Schweregrad darstellt, die am schwierigsten zu beheben sind. Der Vorteil dieser Priorisierung besteht darin, dass der Fokus auf die kritischsten Verstöße gelegt wird, die den größten Nutzen bei der Sicherheitsverbesserung bringen, während das Entwicklungsteam weniger wichtige Warnungen herausfiltern kann.

SEI CERT C/C++-Konformität

Laut der SEI CERT C-Dokumentation erfordert die Konformität „dass der Code keine Verstöße gegen die in diesem Standard festgelegten Regeln enthält. Wenn eine Ausnahmebedingung geltend gemacht wird, muss die Ausnahme einer vordefinierten Ausnahmebedingung entsprechen und die Anwendung dieser Ausnahme muss im Quellcode dokumentiert sein.“

Obwohl die Konformität weniger spezifisch ist als Standards wie MISRA, bleiben die Prinzipien ähnlich. Regeln sollten befolgt werden, Abweichungen sollten nur selten vorkommen und gut dokumentiert sein. Empfehlungen sollten nach Möglichkeit verwendet werden, und diejenigen, die nicht benötigt werden, sollten dokumentiert werden.

Verstöße, die im Quellcode bestehen bleiben, müssen dokumentiert werden. Aus Leistungs- oder Nutzungsgründen sind jedoch keine Abweichungen akzeptabel, und es liegt in der Verantwortung des Entwicklers, nachzuweisen, dass die Abweichung nicht zu einer Sicherheitslücke führt.

Der Parasoft C/C++test bietet ein umfassendes CERT-Compliance-Dashboard und Berichte. Individuelle Compliance-Berichte sind auf Anfrage verfügbar, basierend auf dem neuesten Build der Software oder einem beliebigen vorherigen Build.

Diese Berichte können sortiert und durchsucht werden, um Verstöße genauer zu untersuchen. Es steht ein Konformitätstestplan zur Verfügung, um die CERT-Richtlinie mit dem entsprechenden statischen Analyseprüfer von Parasoft zu korrelieren. Dies ist ein wichtiges Tool, wenn Konformitätsdokumentation für Prüfzwecke benötigt wird. Darüber hinaus stehen alle interessanten Berichte, wie vom Team angegeben, in einem einzigen PDF zum Download für Prüfer zur Verfügung.

Unterstützung für CERT C/C++ im Parasoft C/C++test

Parasoft bietet umfassende Unterstützung für die sicheren Codierungsstandards CERT C und CERT C++ mit vollständiger Abdeckung aller CERT C/C++-Richtlinien, einschließlich Regeln und Empfehlungen, die durch statische Analyse erkennbar sind. Prüfernamen, Dashboards und Berichte verwenden die CERT-Namenskonvention, um Konformität und Auditierung zu vereinfachen. Ein CERT-Konformitäts-Dashboard, das den CERT-Risikowert enthält, hilft Entwicklern, sich auf die kritischsten Verstöße zu konzentrieren.

CWE

CWE (Common Weakness Enumeration) ist eine Liste entdeckter Software-Schwachstellen, die auf der Analyse gemeldeter Schwachstellen (CVEs) basieren. Die Sammlung von CVEs und CWEs ist eine von der US-Regierung finanzierte Initiative, die von der Software-Community entwickelt und von der MITRE-Organisation verwaltet wird. Insgesamt enthält die CWE-Liste über 900 verschiedene Qualitäts- und Sicherheitsprobleme von Software und Hardware.

Diese über 900 Einträge sind in benutzerfreundlicheren Listen wie den bekannten CWE Top 25 organisiert. Die Top 25 listet die häufigsten und gefährlichsten Sicherheitslücken auf, bei denen es sich um Exploits handelt, die eine hohe Wahrscheinlichkeit haben, aufzutreten, und die Auswirkungen der Ausnutzung der Schwachstelle sind groß. Die von einem CWE dokumentierten Softwareschwachstellen sind die Software, die in einer Reihe entdeckter Schwachstellen (dokumentiert als CVEs) involviert ist, als eine Analyse durchgeführt wurde, um die Grundursache zu ermitteln. CVEs sind bestimmte beobachtete Schwachstellen in Softwareprodukten, für die es eine genaue Definition gibt, wie sie ausgenutzt werden können.

Die aktuelle Version der CWE Top 25 ist von 2023 und wird in der folgenden Tabelle angezeigt. Eine aktualisierte Top 25 mit verbesserter Verknüpfung zu CVEs und NVD ist derzeit in Bearbeitung. Das Ranking berücksichtigt Informationen aus der Praxis, sodass es die 25 wichtigsten Anwendungssicherheitsprobleme von heute wirklich widerspiegelt. Sobald es veröffentlicht wird, wird Parasoft aktualisierten Support für die neueste Version haben.

Für Softwareteams, die die Top 25 gut im Griff haben, gibt es eine weitere Gruppierung der nächsthäufigsten und schwerwiegendsten Schwachstellen, die CWE CUSP genannt wird. Eine andere Möglichkeit, sich diese vorzustellen, sind die 25 wichtigsten ehrenvollen Erwähnungen.

Das CWE verwendet eine Risikobewertungsmethode, um die Top 25 und den CUSP zu bewerten. Diese Bewertung berücksichtigt die technischen Auswirkungen einer Softwareschwäche (wie gefährlich die Ausnutzung dieser Schwäche in der realen Welt ist), gemessen mit dem CWSS (Common Weakness Scoring System).

Beispiele für technische Auswirkungen von Sicherheitslücken können sein:

• Dienstverweigerung (DoS)
• Verteilter Denial-of-Service (DDoS)
• Lese- oder Schreibzugriff auf geschützte Informationen
• Unbefugter Zugriff und mehr

Die Einzelheiten dieser Methoden sind nicht allzu wichtig, aber die sortierte Liste ist hilfreich, um zu verstehen, welche Schwachstellen am meisten Anlass zur Sorge geben. Beispielsweise ist es möglich, dass Ihre Anwendung rein intern ist und DoS-Probleme für Sie nicht kritisch sind. Wenn Sie die wichtigsten Schwachstellen Ihrer eigenen Anwendung priorisieren können, können Sie die Überlastung durch Verstöße gegen die statische Analyse überwinden.

CWE Top 25 und On the Cusp Compliance

Die Einführung des Codierstandard-Compliance-Prozesses in den Entwicklungsworkflow des Teams ist keine leichte Aufgabe. Daher ist es wichtig, ein Tool auszuwählen, das bei der Einhaltung der Compliance hilft, ohne zu viel Aufwand zu verursachen und ohne dass zusätzliche manuelle Verfahren erforderlich sind. Die folgenden Punkte sind wichtige Entscheidungsfaktoren bei der Auswahl der Lösung für die statische Analyse.

Die CWE Top 25 und ihr weniger bekanntes Geschwisterchen On the Cusp sind keine Kodierungsstandards per se, sondern eine Liste von Schwachstellen, die vermieden werden sollten, um die Sicherheit zu verbessern. Um CWE-konform zu sein, sollte ein Projekt nachweisen können, dass es angemessene Anstrengungen unternommen hat, um diese häufigen Schwachstellen zu erkennen und zu vermeiden.

Parasofts erweiterte statische Analysetools für C, C++, Java und .NET sind offiziell mit CWE kompatibel und ermöglichen die automatische Erkennung der Top 25- und On-the-Cusp-Schwachstellen und vielem mehr. CWE-zentrierte Dashboards bieten Benutzern schnellen Zugriff auf Standardverletzungen und den aktuellen Projektstatus. Eine integrierte CWE Top 25-Konfiguration ist für C, C++, .NET und Java verfügbar und deckt alle 25 gängigen Schwachstellen vollständig ab.

Die Parasoft-Tools enthalten Informationen aus dem Common Weakness Risk Analysis Framework (CWRAF), z. B. zu technischen Auswirkungen. So können Sie von der gleichen Art der Priorisierung basierend auf Risiken und technischen Auswirkungen sowie den in Ihrem eigenen Code gefundenen Schwachstellen profitieren.

Parasoft unterstützt außerdem detaillierte Compliance-Berichte, um Auditprozesse zu optimieren. Die Web-Dashboards bieten Links zu Compliance-Berichten, um ein vollständiges Bild vom aktuellen Stand eines Projekts zu erhalten. Darüber hinaus ordnet der CWE-Schwachstellenerkennungsplan den CWE-Eintrag den Prüfern zu, die zur Erkennung der Schwachstelle verwendet werden. Dies hilft einem Prüfer zu veranschaulichen, wie die Compliance erreicht wurde, und die Prüfberichte können zur einfachen Berichterstattung als PDFs heruntergeladen werden.