ISO/IEC 5230 · ISO/IEC 18974 · OpenChain · OpenSSF
Open Source war lange eine Frage für die Rechtsabteilung – einmal gestellt, kurz bevor ein Produkt ausgeliefert wurde. Der Cyber Resilience Act hat daraus eine fortlaufende regulatorische Pflicht mit Fristen gemacht.
Die meisten Embedded-Produkte bestehen heute überwiegend aus fremdem Code. Das war schon ein Lizenz- und ein Due-Diligence-Thema. Es ist jetzt zusätzlich ein Safety- und ein Melde-Thema – und alle vier sind dasselbe Thema, weil sie davon abhängen, dass Sie genau sagen können, was in einem bestimmten Build steckt.
Zwei Spezifikationen
Dürfen Sie es ausliefern – und können Sie es verteidigen
Das OpenChain Project pflegt zwei internationale Standards, die unterschiedliche Fragen an denselben Code stellen. Die meisten Organisationen haben für die erste etwas aufgebaut und für die zweite fast nichts – was ungünstig ist, denn dort landet gerade der regulatorische Druck.
ISO/IEC 5230
Lizenz-Compliance
Ein Programm, das verlässlich erkennt, was Sie einsetzen und wozu die jeweilige Lizenz Sie verpflichtet. Bewusst prozessorientiert statt rechtsgutachterlich: Die Norm fragt, ob Ihre Organisation das wiederholt richtig hinbekommt – nicht, ob ein Produkt zufällig sauber war.
ISO/IEC 18974
Security Assurance
Dieselbe Idee für Security: Erfahren Sie überhaupt, dass eine Komponente, von der Sie abhängen, verwundbar ist – und können Sie beurteilen und handeln? Als Routine, nicht als Feuerwehreinsatz. Auf diese Spezifikation lassen sich die Vulnerability-Handling-Pflichten des CRA am natürlichsten abbilden.
Was wir tun
Programmaufbau · Gap-Analyse
Feststellen, wo Sie gegenüber beiden Spezifikationen stehen, die fehlenden Teile aufbauen und das Programm auf Ihre Organisation zuschneiden statt auf die Norm. Konformität ist das Nebenprodukt eines funktionierenden Programms, kein Ziel, das man direkt ansteuert.
Die CRA-Checkliste von OpenChain
Das OpenChain Project hat ein CRA-Compliance-Framework veröffentlicht, das zugleich als Selbstbewertungs-Checkliste dient: Programm-Governance, SBOM-Qualität, Schwachstellenbehandlung, Meldepflichten, Open-Source-Stewardship und technische Dokumentation. Es steht unter CC0 und kann ohne Rückfrage übernommen und angepasst werden.
Es ist eine gute Ausgangsstruktur – und kein Compliance-Programm. Wer sie durcharbeitet, sieht schnell, für welche Pflichten es noch keine Antwort gibt; genau das soll eine Gap-Analyse liefern. Wir nutzen sie als gemeinsame Referenz, damit ein Workshop mit einer abgestimmten Liste beginnt statt mit einer Diskussion über den Umfang.
SBOM
Eine Fähigkeit, kein Dokument
Eine einmal von Hand erstellte SBOM, die einen Kundenfragebogen zufriedenstellt, ist fast nichts wert. Die Frage, die sie beantworten muss, wird Jahre später unter Zeitdruck gestellt: Was genau steckte im Build, der jetzt im Feld ist?
Der CRA erwartet von Herstellern, die Komponenten ihrer Produkte zu identifizieren und zu dokumentieren und Schwachstellen über den Supportzeitraum hinweg zu behandeln. Wenn ein Advisory eintrifft, läuft die Uhr – und alles danach hängt davon ab, ob die Stückliste vom Build erzeugt oder von einem Menschen zusammengestellt wurde. Das eine stimmt im sechsten Jahr noch. Das andere war schon bei der Übergabe falsch.
Wir arbeiten am Erzeugungsweg statt am Artefakt: SPDX oder CycloneDX, in der CI erzeugt, an einen konkreten Build gebunden und mit ihm archiviert, tief genug im Abhängigkeitsbaum, um nützlich zu sein – und verbunden mit einem Triage-Prozess, der aus einem CVE eine Entscheidung macht. Bei sicherheitsrelevanten Produkten ist genau das die Voraussetzung dafür, dass eine Safety-Impact-Analyse nach SOP überhaupt möglich ist.
Upstream
Nicht Ihr Code – trotzdem Ihr Problem
Regulierer unterscheiden nicht zwischen dem Code, den Sie geschrieben, und dem, den Sie übernommen haben. Wenn eine Komponente, von der Sie abhängen, ungepflegt ist, keinen Disclosure-Prozess hat und von niemandem signiert wird, ist das Ihr Risiko – und zunehmend Ihre Pflicht, es bemerkt zu haben.
Die Open Source Security Foundation hat hier die meiste nützliche Arbeit geleistet, und es lohnt sich selten, eine eigene Variante davon zu erfinden. Scorecard liefert eine wiederholbare Einschätzung, wie ein Projekt gepflegt wird. SLSA gibt ein Vokabular für Build-Integrität und Provenance, an dem sich Lieferanten messen lassen. Der Best Practices Badge gibt Upstream-Projekten etwas Konkretes an die Hand. Wir helfen zu entscheiden, welche dieser Instrumente in Ihrem Kontext tatsächlich eine Entscheidung verändern, verankern sie in Auswahl und Monitoring und vermeiden den typischen Fehlschlag: ein Dashboard, auf das niemand reagiert.
Auswahl und Monitoring
Kriterien für die Übernahme einer Abhängigkeit, die über „lässt sich übersetzen“ hinausgehen – und eine Beobachtung, die merkt, wenn ein gesundes Projekt aufhört, eines zu sein.
Lieferantenanforderungen
Klauseln, die Ihr Tier-2 auch erfüllen kann – die nach SBOM und Disclosure-Kontakt fragen statt nach einer Unterschrift unter einem Absatz, den niemand liest.
Zurückgeben
Contribution- und Stewardship-Policy – einschließlich der Frage, wo die CRA-Regelungen für Open-Source-Steward Ihre eigene Upstream-Aktivität neu bewerten.
Was wir nicht tun: Rechtsberatung
Wir arbeiten am Prozess, an den Werkzeugen und an den Nachweisen. Auszulegen, wozu eine bestimmte Lizenz im Einzelfall verpflichtet, ist Sache einer Anwältin oder eines Anwalts – und das sagen wir lieber, als zu raten. In der Praxis trennt sich das sauber: Ein gutes Compliance-Programm führt dazu, dass Ihre Rechtsberatung wenige, gut vorbereitete Fragen bekommt statt vieler vager.
Woher die Pflichten kommen: Cyber Resilience Act →