Automatisierte Tools und MISRA C
Software-Security garantieren
Fortsetzung des Artikels von Teil 1
Beseitigung von Schwachstellen
Mit statischer und dynamischer Analyse lassen sich auch Bereiche mit totem Code aufdecken, die eine Gefahrenquelle darstellen können oder einfach nur unnützerweise Platz beanspruchen. Solcher Code muss unbedingt identifiziert und bearbeitet werden – in der Regel, indem er schlichtweg eliminiert wird. Das ist aus mehreren Gründen wichtig. Obwohl es eigentlich ideal wäre, Security von Grund auf zu implementieren, enthalten die meisten Projekte bereits existierenden Code, bei dessen Entwicklung nicht dieselben Tests angewandt wurden wie bei dem aktuellen Projekt. In dem bestehenden Code können zudem Segmente enthalten sein, die von der entwickelten Applikation gar nicht benötigt werden. Schlimmer noch ist es, wenn Bereiche mit totem Code nur darauf warten, von einem Hacker oder einem obskuren Ereignis im System für böswillige Zwecke aktiviert zu werden.
Jobangebote+ passend zum Thema
Selbstverständlich muss zwischen totem Code und selten genutztem Code unterschieden werden. Allein das ist ein guter Grund dafür, dass Anforderungen in beiden Richtungen zurück verfolgbar sein sollten. Einerseits muss nachvollziehbar sein, dass jede Anforderung durch Code in der Applikation umgesetzt wurde. Umgekehrt muss es auch möglich sein, ein bestimmtes Code-Element zur entsprechenden Anforderung zurückzuverfolgen. Wenn in beiden Richtungen keine Verbindung erkennbar ist, gehört der Code definitiv nicht dorthin (Bild 3).
Von besonderer Bedeutung für die Automobilindustrie ist die Tatsache, dass ein großer Teil der Software, die in das fertige Fahrzeug integriert wird, von Fremdunternehmen stammt. Diese liefern Geräte und Subsysteme zu, die zum Bestandteil des gesamten Designs werden. Hier ist es notwendig, diesen Third-Party-Code nach denselben hohen Standards zu testen und zu zertifizieren, damit sich die Security gewährleisten lässt. Diese Überlegung ist ein Teil der Begründung für Modultests und Integration.
Modultest und Integration
In der Automobilindustrie erfordert die Integration von Subsystemen von Fremdunternehmen häufig ein Modifizieren des bestehenden Codes der Zulieferer, damit dieser beispielsweise hinsichtlich gemeinsamer Variablen und Adressen kompatibel ist. Ist dieser Code erst einmal geprüft und zertifiziert, kann er wie ein integrales Subsystem des Fahrzeug-Softwaresystems behandelt werden.
Wegen der bereits erwähnten Eigenschaften in Bezug auf Code-Umfang, Prozessorleistung und Vernetzung erfolgt ein großer Teil der anfänglichen Software-Entwicklung auf Host Workstations, wobei verschiedene Projektmitglieder an unterschiedlichen Teilen der gesamten Applikation arbeiten. Vieles davon wird gestartet, bevor die Ziel-Hardware verfügbar ist. Mit der Entwicklung kann in der Umgebung des Host-Betriebssystems begonnen werden oder auf einem Zielsystem, das auf dem Host simuliert wird, bevor schließlich auf die tatsächliche Ziel-Hardware übergegangen wird.
Die LDRA Tool Suite bietet die Möglichkeit zur Durchführung von Funktionstests sowie von statischen Analysen auf der Modul- und Integrations-Ebene, was auf dem Host ebenso möglich ist wie auf der Ziel-Hardware – sobald diese verfügbar ist. Entwickler können Tests generieren (Test Harnesses, Testvektoren und Code Stubs) und die Erfassung der Ergebnisse für eine breite Palette von Hosts und Zielplattformen unterstützen. Die Instrumentierungs-Technologie von LDRA ist in der Lage, Testinformationen aus stark eingeschränkten 8- und 16-bit-Mikrocontrollern bis hin zu hochleistungsfähigen 16- und 32-bit-Mikrocontrollern zu ziehen. Der Übergang vom Host zum Zielsystem und das Integrieren von Komponenten, die von anderen Teammitgliedern entwickelt wurden, kann deshalb in der größeren Systemkonfiguration zusammengeführt werden, wenn ein großer Teil der Arbeit an den Anforderungen, der Testgenerierung, der Überdeckungs-Analyse sowie am Daten- und Kontrollfluss bereits begonnen hat.
Wenn ein System funktionale Sicherheit bieten soll, muss es auch abgesichert sein. Es muss also so codiert sein, dass es nicht nur die Sprachregeln einhält, sondern auch jene Standards erfüllt, die zur Gewährleistung von Safety und Security dienen. All das muss außerdem verifizierbar sein, d.h. der Daten- und Kontrollfluss von den Anforderungen zum Code und wieder zurück muss sich zurückverfolgen lassen. Die Konformität zu MISRA und CERT C und anderen Kodierstandards kann mit einem Rules Checker erreicht werden, der die Konformität erzwingt und solche Software-Fehler klar sichtbar macht, die in der Regel unentdeckt durch den Build- und Testprozess gelangen und zu latenten Problemen werden (Bild 4).
Die LDRA Tool Suite enthält Reportfunktionen der nächsten Generation, um die Code-Qualität, die Fehlererkennung und Vermeidungsmaßnahmen zu zeigen. Unterstützt wird all das durch deutliche visuelle Darstellungen, die die Komplexität transparent machen und die Gewähr für einen kompletten und sicheren Entwicklungszyklus bieten.
Die Autoren
| Jay Thomas |
|---|
| studierte Luftfahrttechnik an der University of Illinois in Urbana-Champaign. Er arbeitet als Director of Field Engineering bei LDRA Technology in San Bruno (Kalifornien/USA). Thomas befasste sich bisher mit der Simulation eingebetteter Steuerungen und Prozessoren, missions- und sicherheitskritischer Flug-Software sowie Kommunikations-Anwendungen in der Luft- und Raumfahrtindustrie. Seine Fokussierung auf den Bereich Embedded Verification Implementation bürgt dafür, dass die aus dem Aerospace-, Medizin- und Industriesektor kommenden Kunden von LDRA bei allen sicherheits- und missionskritischen Prozessen einen kompetenten Partner finden. |
| Chris Tapp |
|---|
| ist als Field Applications Engineer bei LDRA tätig und besitzt mehr als 20 Jahre Erfahrung in der Entwicklung von Embedded-Software. Nach dem Abschluss seines Studiums an der University of Durham im Jahr 1987 arbeitete er größtenteils als selbstständiger Berater für Industrieunternehmen der Automobil-, Steuerungs- und IT-Branche. Er hat seit 2001 mit MISRA zu tun und ist zur Zeit Vorsitzender der MISRA C++ Working Group sowie aktives Mitglied der MISRA C Working Group. Seit 2007 arbeitet Tapp bei LDRA und hat sich dort auf Programmierstandards spezialisiert. |
- Software-Security garantieren
- Beseitigung von Schwachstellen
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Das große Ganze im Blick
AUTOSAR-Systemsicht konsequent umsetzen
Fokus auf Digitalisierung
Volkswagen baut Kompetenzen in Künstlicher Intelligenz aus
Risiko-orientierte Methodik
Praxis-Erfahrungen zur Anwendung von Cyber Security
Messung, Simulation, Virtualisierung
Methoden und Tools für die Entwicklung von Fahrzeugsystemen
Durchgängig absichern
Testumgebung für sicherheitskritische Fahrerassistenzsysteme
Ausbau des Bereichs Fahrzeugvernetzung
ZF beteiligt sich an Software-Unternehmen doubleSlash
Automatisiertes Fahren
Volvo und Autoliv gründen Joint Venture
IT-Sicherheit in Fahrzeugnetzwerken
Offene Netze schützen
Integration in Automobilsparte
Panasonic kauft OpenSynergy
Berufsbegleitende Studiengänge
Spezialwissen in Safety und Security erwerben
Safety-/Security-Software-Architekturen
Alles sicher?
