Elektroniknet Logo

Software

Sicherer Einsatz von Third-Party-Code

Standards wie ISO 26262 und IEC 62304 geben Handreichungen für die akzeptable Nutzung von Third-Party-Software und helfen Softwareentwicklern mit Best Practices Risiken abzumildern
© style67 / Stock.adobe.com

Moderne embedded Software ist ein komplexes Konglomerat von Code-Komponenten, die von zahlreichen Zulieferern stammen. Standards wie ISO 26262 und IEC 62304 geben Handreichungen für die akzeptable Nutzung von Third-Party-Software und helfen Softwareentwicklern mit Best Practices Risiken abzumildern.

Lang, lang ist es her, da bestand die Entwicklung von Embedded-Software darin, dass Programmierer in C oder Assembler eine auf das Wesentliche beschränkte Applikation schrieben. Ein kleines Team, das nicht selten in einem einzigen Büro saß, entwickelte ein eigenständiges Projekt für eine bestimmte Aufgabe. Heute dagegen gibt es solche Bare-Metal-Applikationen in der Regel nur als Bestandteil eines deutlich umfangreicheren Systems.

Die Zeiten haben sich eindeutig geändert. Inzwischen ist die Entwicklung und Pflege der Software zum teuersten und zeitraubendsten Bestandteil vieler moderner Embedded-Systeme geworden. Diese Systeme gründen auf unzähligen Schichten verschiedener Techniken und benötigen Softwareteams, die aus Hunderten oder gar Tausenden von Entwicklern bestehen, die Millionen von Codezeilen zu einem Release-Image beisteuern. Nur ganz selten liegt der komplette Software-Stack in den Händen einer einzigen Organisation. Wie aber kann man mit den Risiken umgehen, die sich durch das Einbinden von Code von anderen Instanzen und Organisationen ergeben, damit zum Schluss etwas Gutes herauskommt?

Quellen über Quellen

Eine moderne, übergeordnete Softwarearchitektur für ein Embedded-System besteht mit großer Wahrscheinlichkeit aus zahlreichen Komponenten wie etwa Betriebssystemen, Gerätetreibern, Kommunikations-Stacks, Bootloadern, Hypervisoren usw., noch bevor auch nur eine einzige Zeile Applikationscode geschrieben wurde.

In den meisten Fällen ist die Codebasis des Systems eine Mixtur aus handgeschriebenem Code, automatisch generiertem Code, COTS-Software (Commercial Off The Shelf) und Open-Source-Software (OSS). Werden außerdem noch bestehender (Legacy-)Code, compilerbezogene Software, Template-Bibliotheken und Third-Party-Tools hinzugenommen, so ergibt sich ein Mix, der nicht ganz ungefährlich aussieht.

In der Lieferkette beispielsweise sind viele Instanzen an der Entwicklung von Fahrzeugsoftware beteiligt. Fahrzeughersteller arbeiten mit Hunderten von Tier-1- und Tier-2-Zulieferern zusammen, um die in das Fahrzeug integrierten Subsysteme und elektronischen Steuergeräte (Electronic Control Unit, ECU) zu entwickeln. Diese Zulieferer wiederum kooperieren mit Anbietern von Halbleiter-IP und Hardware-Lieferanten, um Mikrocontroller sowie die notwendigen Softwareentwicklungs-Toolchains, Laufzeit-Bibliotheken und Hardwareschnittstellen zu beziehen.

Der daraus resultierende, aus Code von zahllosen Quellen bestehende Software-Stack ist von einer solchen Komplexität, dass es nicht ohne ein sorgfältiges Risikomanagement geht.

Woraus resultieren die Risiken?

Ein Unternehmen muss die absolute Gewissheit haben, dass die von Dritten zugekaufte Software ihren Zweck erfüllt und hinreichend viel Entwicklungsarbeit einspart. Abgesehen davon sind jedoch noch weitere Überlegungen anzustellen.

Lizenzierung

Open-Source-Software wird in der Regel kostenlos angeboten, unterliegt aber häufig bestimmten Einschränkungen und Verpflichtungen. Es ist also genau zu überlegen, ob diese Restriktionen eine Einschränkung für die kommerzielle Nutzung der Software bedeuten, ob etwaige Modifikationen zulässig sind und ob solche Änderungen an die Open-Source-Community oder Ihre Anwender zurückgeführt werden müssen.

Wurden diese Einschränkungen und Verpflichtungen nicht ausreichend verstanden, kann dies den Ruf eines Unternehmens schädigen und empfindliche Geldbußen oder möglicherweise gar Haftstrafen nach sich ziehen.

Die meist zu COTS-Software gehörenden Lizenzabkommen enthalten klare
Aussagen darüber, wie die Software verwendet werden darf und welche Gebühren an den Softwarezulieferer zu entrichten sind. Wird von einem der Beteiligten gegen den Lizenzvertrag verstoßen, kann die jeweils andere Seite rechtliche Schritte einleiten und Schadenersatzforderungen erheben. Unter Umständen sind die Lizenzierungs-modelle von COTS-Software schwieriger zu verstehen als die von Open-Source-Software. Oft enthalten sie komplexe Lizenzierungs-Maßzahlen und bedingte Klauseln, und überdies können die Lizenzmodelle stark variieren.

Es ist auch wichtig sicherzustellen, dass das mit der Software zusammenhängende geistige Eigentum tatsächlich im Besitz des COTS-Anbieters ist. Verstößt der Anbieter gegen Rechte am geistigen Eigentum anderer, kann auf seine eigentlich schuldlosen Kunden die Forderung zukommen, zusätzliche Zahlungen zu leisten oder die Nutzung der Software einzustellen.

Keine Software ist perfekt, aber zweifellos bergen Fehler in zugekaufter Software größere Herausforderungen als solche in selbst entwickeltem Code. Diese Fehler können die funktionale Sicherheit beeinträchtigen oder zu teuren Produktrückrufen führen, was wiederum nachteilige Folgen für die Reputation des jeweiligen Herstellers haben kann.

Funktionssicherheit

Normen wie ISO 26262 Road Vehicles – Functional safety (ISO 2018) enthalten Leitlinien für die Entwicklung eines funk­tional sicheren Produkts. Die Norm schreibt vor, dass bei einem sicherheitskritischen Produkt jegliche externe Software vom Integrator mit größter Sorgfalt geprüft werden muss – vorzugsweise mit Unterstützung seitens des Zulieferers.

Anbieter zum Thema

zu Matchmaker+

  1. Sicherer Einsatz von Third-Party-Code
  2. Schutz der Daten und vor Angriffen

Verwandte Artikel

LDRA Inc.