Parasoft bietet Lösungen, um die Einhaltung zahlreicher Sicherheits- und Qualitätsstandards sicherzustellen. Wie unterstützen Ihre Tools konkret die Konformität mit Normen wie IEC 61508?

Ricardo Camacho ist Director of Safety & Security Compliance bei Parasoft. © Parasoft

Parasoft erleichtert die Einhaltung funktionaler Sicherheitsstandards wie IEC 61508 sowie branchenspezifischer Normen wie ISO 26262 oder IEC 62304 durch Automatisierung und Unterstützung der Verifikations- und Validierungsaktivitäten. Dazu zählen statische Code-Analyse, Unit-Tests, Code Coverage und Requirements Traceability.

Mit statischer Analyse sorgen wir dafür, dass sichere Programmierpraktiken eingehalten werden und der Code Normen wie MISRA für funktionale Sicherheit oder CERT und CWE für Sicherheit entspricht. Durch automatisierte Unit-Tests überprüfen wir, ob sich der Code wie spezifiziert verhält. Ergänzend dazu stellen wir mit struktureller Codeabdeckung sicher, dass alle relevanten Teile des Codes geprüft sind – von Statement- über Branch- bis hin zu MCDC-Coverage, wie es IEC 61508 abhängig vom SIL-Level fordert.

Darüber hinaus unterstützen wir die Nachverfolgbarkeit von Anforderungen bis hin zu Testfällen. Unsere Tools helfen, eine Traceability-Matrix zu erstellen, Lücken zu erkennen und alle Nachweise sauber zu dokumentieren. Über Dashboards können Entwickler jederzeit den Teststatus und die Erfüllung der Anforderungen überwachen.

Kurz gesagt: Unsere Lösungen automatisieren Softwaretests weitgehend, reduzieren den Aufwand erheblich und liefern nachweisbare Ergebnisse. Unsere C/C++-Testtools sind zudem für sicherheitskritische Entwicklungen zertifiziert. Das schafft Vertrauen und minimiert Entwicklungsrisiken – gerade bei sicherheitsrelevanten Anwendungen. 

Sie haben ISO 26262 und die Nachverfolgbarkeit angesprochen. Gibt es Unterschiede zur IEC 61508?

Im Kern nicht. Beide Normen fordern lückenlose ‚Traceability‘, also die Nachverfolgbarkeit von Anforderungen über alle Entwicklungsphasen hinweg. Anforderungen werden entlang des V-Modells immer weiter verfeinert, von High-Level-Sicherheits- oder Sicherheitsanforderungen bis hin zu detaillierten Spezifikationen. Traceability stellt sicher, dass jede Anforderung getestet, verifiziert und validiert wird. Gleiches gilt auch für andere Normen wie IEC 62304 (Medizintechnik) oder DO-178C (Luftfahrt). Das Prinzip ist identisch: Jede Anforderung muss durch geeignete Tests nachgewiesen werden.

Können Sie den Unterschied zwischen statischer und dynamischer Analyse in wenigen Sätzen erklären?

Statische Analyse prüft den Code rein durch Inspektion, also ohne ihn auszuführen. Dynamische Analyse hingegen bedeutet, dass der Code ausgeführt wird, um sein Laufzeitverhalten zu überprüfen. Dazu zählen Unit-Tests, Integrations- und Systemtests sowie Akzeptanztests. Im Prinzip deckt die dynamische Analyse alle Tests ab, die den Code in realen oder simulierten Szenarien ausführen, um Funktionalität, Robustheit und Performance zu validieren.

Wie wichtig ist statische Code-Analyse für sicherheitskritische oder sicherheitsrelevante Software?

Statische Analyse ist essenziell, um Fehler, Schwachstellen und Abweichungen von Coding-Guidelines frühzeitig zu erkennen, also noch bevor der Code ausgeführt wird. Sie unterstützt damit den ‚Shift-Left‘-Ansatz: Fehler werden so früh wie möglich im Entwicklungszyklus gefunden, was deutlich günstiger ist, als sie später zu beheben.

Neben klassischen Regelverstößen prüft unsere statische Analyse auch Daten- und Kontrollfluss. So werden z. B. fehlerhafte Pointer, Division durch null oder ungenutzter – ‚toter‘ – Code gefunden. Tatsächlich finden wir mit statischer Analyse oft dieselben Fehler wie mit aufwändigen Unit-Tests – nur sehr viel schneller.

Wichtig ist auch die nahtlose Einbindung in moderne Entwicklungsprozesse: Unsere ‚Parasoft C/C++test’-Tools lassen sich in CI/CD-Pipelines wie Jenkins, GitHub, GitLab oder Azure DevOps integrieren. Entwickler können Analysen zudem direkt aus IDEs wie ‚VS Code‘, ‚Eclipse‘ oder ‚Visual Studio‘ starten oder vollständig automatisiert im Build-Prozess. So wird statische Analyse zu einem kontinuierlichen Bestandteil der Qualitätssicherung.

Wo sehen Sie Risiken, wenn man sich zu stark auf automatisierte Tests verlässt?

Automatisierte Tests sind enorm hilfreich, aber sie ersetzen nicht das Ingenieurswissen. Automatisierung kann helfen, schnell große Testabdeckung zu erzielen – doch kritische Randfälle oder ungewöhnliche Fehler werden oft nur durch das Know-how und die Intuition erfahrener Ingenieure gefunden.

Ein Beispiel: Ich habe erlebt, wie zwei Entwickler identischen Code getestet haben. Einer nutzte ausschließlich automatisierte Tests und erzielte 100% Codeabdeckung – übersah aber einen Fehler, den sein Kollege durch gezielte, manuell entworfene Edge-Testfälle aufdeckte. Deshalb: Automatisierung ja, aber immer kombiniert mit menschlicher Expertise.

Wo scheitern Unternehmen Ihrer Erfahrung nach am häufigsten bei der Umsetzung von Normen?

Häufig fehlt es am Verständnis der Anforderungen. Viele wissen nicht genau, welche Prozesse, Nachweise oder Artefakte für Standards wie IEC 61508 nötig sind. Ohne präzises Wissen werden wichtige Schritte übersehen oder unvollständig dokumentiert.

Mein Rat: Eng mit Auditspezialisten und Prüfstellen zusammenarbeiten – und gegebenenfalls interne Experten oder Berater einbinden. Wir überlegen beispielsweise, unseren Kunden standardisierte Checklisten bereitzustellen, damit sie wissen, welche Dokumente, Testnachweise oder Verifikationen sie liefern müssen.

Welche Rolle spielen Coding-Guidelines wie MISRA heute?

MISRA definiert verbindliche Richtlinien für sicheres und robustes Programmieren in C und C++. Sie sorgen für eine konsistente Codequalität (z.B. sicher, geschützt und zuverlässig) innerhalb des Entwicklungsteams, die auch von externen Zulieferern verlangt werden sollte. Das Ziel besteht darin, Fehler im Code zu identifizieren und zu beheben, um sichere und vorhersehbare Software zu liefern, die auch die in branchenspezifischen Sicherheitsnormen wie IEC 61508 oder ISO 26262 definierten Konformitätsanforderungen erfüllt.

Außerdem werden die MISRA-Richtlinien ständig weiterentwickelt, um mit neuen C-Sprachversionen und Konstrukten Schritt zu halten, die in der Version C17, auch bekannt als C18, zu finden sind. Bei Parasoft tragen wir aktiv zur Weiterentwicklung bei – einer unserer Experten ist Mitglied der MISRA-C und-C++-Arbeitsgruppe. Dadurch kann Parasoft nicht nur alle Richtlinien vollständig unterstützen, sondern auch dazu beitragen, die Regeln so zu gestalten, dass sie für verschiedene Branchen - von Automotive über Medizintechnik bis zur Luft- und Raumfahrt - praxisnah und zukunftssicher sind..

Was ist besonders an der aktuellen MISRA-Version?

Die neue Version, MISRA C 2025, baut auf MISRA C 2023 auf. Es gibt vier neue Regeln, zwei wurden entfernt, 13 überarbeitet. Besonders hervorzuheben sind drei Schwerpunkte Vorhersagbarkeit, Portabilität und Sicherheit.

Beispiel Vorhersagbarkeit: Manche Compiler verhalten sich bei Bit-Shift-Operationen unterschiedlich. Neue Regeln stellen sicher, dass der Code auf allen Plattformen konsistent funktioniert. Beim Thema Sicherheit reagiert MISRA auf die wachsende Bedrohungslage und schärft Vorgaben z. B. für dynamische Speicherverwaltung. Außerdem ist neu geregelt, dass KI-generierter Code denselben Prüfungen unterliegen muss wie von Menschen geschriebener Code.

Es wurde erwähnt, dass Regeln entfernt wurden. Hat das Löschen dieser Regeln Auswirkungen auf die Wartbarkeit?

Nein. Wenn eine Regel entfernt oder deaktiviert wird, geschieht das sehr bewusst und gut begründet. Das bedeutet lediglich, dass diese Regel bei der Analyse nicht mehr geprüft wird. Man sucht also nicht länger nach etwas, das als irrelevant betrachtet wird oder bei dem sich die Sichtweise geändert hat. Ein Beispiel: Früher gab es die Regel 15.5, laut der eine Funktion am Ende nur einen einzigen Ausgangspunkt haben sollte. Sie verbot die Verwendung von ‚goto‘-Anweisungen oder Sprüngen aus Funktionen oder switch-Blöcken. Da viele Entwickler dieses Verhalten aber bewusst nutzten, wurde die Regel aufgehoben. Heute wird dieser Fall einfach nicht mehr gemeldet und es muss keine Abweichung mehr vom Standard berichtet werden, wenn dieses Verhalten gewünscht ist. Ältere Versionen der Prüftools erkennen das möglicherweise noch, dann ist eine Abweichungserklärung erforderlich.

Welchen Rat würden Sie Unternehmen geben, die gerade erst mit der neuen MISRA-Version arbeiten?

Für Unternehmen, die MISRA schon lange einsetzen und eine entsprechende Kultur etabliert haben, ändert sich kaum etwas. Für Neueinsteiger gilt: MISRA ist extrem hilfreich, sollte aber schrittweise eingeführt werden. Mein Tipp hierzu lautet: Aktivieren Sie zunächst nur die wichtigsten, hoch priorisierten Regeln, um nicht gleich mit Hunderten oder Tausenden Verstößen überfordert zu werden. So haben Entwickler die Chance, sich an die Regeln zu gewöhnen und fühlen sich nicht gleich von der Fülle an Meldungen entmutigt. Wichtig ist auch, MISRA in einen agilen Entwicklungsprozess zu integrieren, also den Code regelmäßig zu prüfen und Rückmeldungen direkt in die Entwicklung einfließen zu lassen. Das verbessert nicht nur den Code, sondern macht Entwickler langfristig zu besseren Softwareingenieuren. Entscheidend ist, dass das Team die Regeln akzeptiert, anwendet und versteht, warum sie wichtig sind. Davon profitieren Unternehmen, Produkte und die Entwickler selbst.

Welchen Einfluss haben regulatorische Entwicklungen wie der EU Cyber Resilience Act (CRA) auf Richtlinien wie MISRA?

Solche gesetzlichen Vorgaben haben großen Einfluss. Zum Beispiel dürfen Produkte in der EU nur verkauft werden, wenn sie die Sicherheitsanforderungen des CRA erfüllen. Dazu gehört auch, Sicherheitsmaßnahmen über den gesamten Lebenszyklus nachzuweisen. Für Tool-Anbieter wie uns bedeutet das keine grundlegend neue Entwicklung, sondern eher, dass wir unsere Kunden dabei unterstützen, diese regulatorischen Verifizierungs- und Validierungsanforderungen zu erfüllen. Neben der Entwicklung betrifft das auch die Absicherung nach dem Release, etwa bei der Schlüsselverwaltung für Fahrzeuge oder beim Schutz sensibler Daten. Für digitale Komponenten mit Kommunikation wird außerdem gefordert, Sicherheitsfunktionen wie Passwörter oder biometrische Authentifizierung zu implementieren. All diese Anforderungen müssen getestet werden; hier kommen statische Analysen mit Standards wie MISRA, OWASP, CWE oder CERT ins Spiel. Parasoft selbst deckt neben Embedded-Lösungen auch API-Tests oder Service-Virtualisierung ab, um Sicherheitslücken in Kommunikationsschnittstellen zu finden. Kurz gesagt: Die Regulierungen haben einen großen Einfluss auf unsere Kunden. Wer sie nicht umsetzt, darf seine Produkte nicht verkaufen.

Wie könnte sich die Rolle von Codier-Standards wie MISRA künftig entwickeln?

MISRA wird sich weiterentwickeln, genauso wie die Programmiersprachen C und C++. Es wird neue Regeln geben, veraltete Regeln werden entfernt oder angepasst. Ein wichtiger Trend ist der zunehmende Fokus auf Sicherheit. Hier überschneiden sich MISRA und Sicherheitsstandards wie CERT C/C++. In Zukunft wird MISRA sicher noch mehr Sicherheitsaspekte aufnehmen — vielleicht auch neue Sprachen wie Rust berücksichtigen, die derzeit diskutiert werden. Für Tool-Anbieter bedeutet das, dass wir Überschneidungen zwischen Standards wie MISRA und CERT elegant handhaben müssen, damit es keine Konflikte oder Dopplungen gibt. Ziel ist es, die Anwendung mehrerer Standards für Unternehmen so nahtlos wie möglich zu gestalten. Zusammengefasst: MISRA selbst wird vor allem im Bereich Sicherheit weiterwachsen, und wir als Anbieter entwickeln unsere Tools entsprechend weiter, um diese Entwicklung vollständig zu unterstützen.