Springe zum Hauptinhalt

Bewährte Verfahren zur CRA-Übernahme

CRA-Compliance-Leitlinien für KMU

Ein praxisnaher, verhältnismäßiger Weg für KMU, die FOSS-Komponenten integrieren: wer sich worauf konzentrieren sollte, wie Risiken bewertet werden, welche Stufe der Sorgfaltsprüfung angemessen ist und wie sie langfristig aufrechterhalten wird.

Auf dieser Seite

KMU-Personas: Wer worauf achten sollte

KMU gehen die Umsetzung des CRA aus unterschiedlichen Rollen und mit unterschiedlichem technischem Reifegrad an. Die folgenden Personas veranschaulichen typische Verantwortlichkeiten und zeigen, was jede Rolle bei der Nutzung und Integration von FOSS-Komponenten priorisieren sollte.

Persona A

Nicht technische Führungskraft

CEO / COO / Betriebsleitung

Schwerpunkt: Sicherstellen, dass das Unternehmen einen nachvollziehbaren, wiederholbaren Compliance-Ansatz nachweisen kann, ohne tief in technische Details einsteigen zu müssen.

  • Sicherstellen, dass Rollen zugewiesen sind (wer für Updates verantwortlich ist, wer Schwachstellen überwacht, wer Abhängigkeiten freigibt).
  • Sicherstellen, dass grundlegende Nachweise vorhanden sind (verfügbare SBOM, Sicherheitskontakt, Update-Richtlinie, Kanal zur Meldung von Schwachstellen).
  • Zeit und Budget für Maßnahmen im Sinne einer „Minimum Viable Compliance“ freigeben.
  • Einfache Dokumentation einfordern: was wir nutzen, warum wir es nutzen und wie wir es aktuell halten.

Persona B

Technische Leitung

CTO / Lead-Entwickler / DevOps-Leitung

Schwerpunkt: Praktische Kontrollen umsetzen, die Risiken verringern und sich langfristig aufrechterhalten lassen.

  • Sicherheit in den Lebenszyklus integrieren (Reviews, Tests, sichere Releases, Updates).
  • Überblick über Abhängigkeiten schaffen (SBOM, Scannen von Abhängigkeiten, Nachverfolgung transitiver Abhängigkeiten).
  • Schwachstellenbehandlung umsetzen (Eingang, Triage, Patch-Prozess, Release Notes).
  • Nachvollziehbarkeit sicherstellen (disziplinierte Versionierung, Changelog, geschützte Branches, Zugriffskontrollen).

Persona C

Product Owner / Compliance-Koordination

Produktmanagement / QA / Security Champion

Schwerpunkt: Produktentscheidungen, Kundenerwartungen und Compliance-Nachweise miteinander verbinden.

  • Produktumfang und bestimmungsgemäße Verwendung klären (wo FOSS eingesetzt wird, wo Exposition besteht).
  • Risikobasiert vorgehen: Welche Komponenten sind kritisch, welche risikoarm?
  • Schlanke Nachweispakete pflegen (Risikoentscheidungen, Komponentenregister, Update-Historie).
  • Teams koordinieren, damit Überwachung und Updates nicht zwischen den Rollen untergehen.

Diese Personas schließen sich nicht gegenseitig aus. In vielen KMU deckt eine Person mehrere Rollen ab. Entscheidend ist, dass Verantwortung und Rechenschaft ausdrücklich zugewiesen sind.

Von der Ad-hoc-Nutzung zur strukturierten Governance

Der CRA steht für einen umfassenderen Wandel: Compliance beschränkt sich nicht mehr auf das interne Produktdesign, sondern erstreckt sich über die gesamte Software-Lieferkette. Für KMU bedeutet das einen Wechsel von der Ad-hoc-Nutzung von Open Source hin zu einer strukturierten, risikobasierten Governance des Ökosystems.

Ad-hoc-Nutzung

Fragmentiert & manuell

Strukturierte Governance

Risikobasiert & skalierbar

Open-Source-Stewards werden zu zentralen Akteuren dieser Governance-Architektur, während die Nutzung von Komponenten ohne Steward genau unter die Lupe genommen werden muss, um die damit verbundenen Risiken richtig einzuschätzen. Statt jedes Upstream-Projekt einzeln zu prüfen, können KMU:

  • An Stewards ausgerichtete Prozesse nutzen
  • Sich auf strukturierte Sicherheitsrahmenwerke stützen
  • Ihr Engagement als Teil der Sorgfaltsprüfung dokumentieren
  • Ein verhältnismäßiges, risikobasiertes Management nachweisen

Dieser Ansatz entspricht der Absicht des CRA: die Cybersicherheit zu verbessern, ohne eine unverhältnismäßige Last aufzuerlegen.

Sorgfaltsprüfung für Open-Source-Komponenten

Die Integration von FOSS-Komponenten in Produkte mit digitalen Elementen begründet eine geteilte Verantwortung entlang der Software-Lieferkette. Im risikobasierten Rahmen des CRA wird von Herstellern, einschließlich KMU, erwartet, bei Auswahl, Integration und Wartung von Softwarekomponenten Dritter eine angemessene und verhältnismäßige Sorgfaltsprüfung durchzuführen.

Die Sorgfaltsprüfung soll nicht von der Nutzung von Open-Source-Software abschrecken. Im Gegenteil: FOSS bleibt eine grundlegende Triebkraft für Innovation und Wettbewerbsfähigkeit. Sie muss jedoch verantwortungsvoll integriert werden. Die Sorgfaltsprüfung stellt sicher, dass:

Sie verstehen, was Sie integrieren

Sie wissen, welches Risiko damit verbunden ist

Sie Ihre Integrationsentscheidung begründen können

Sie die Komponente langfristig überwachen und warten können

Die Sorgfaltsprüfung ist keine einmalige Kontrolle vor dem Release. Sie ist eine lebenszyklusorientierte Aufgabe, die sich über die gesamte erwartete Lebensdauer des Produkts erstreckt, im Einklang mit den CRA-Anforderungen an sichere Entwicklung und Schwachstellenmanagement.

Risikobasierte Bewertung von FOSS-Komponenten

Vor der Integration einer FOSS-Komponente sollten KMU drei zentrale Dimensionen bewerten. Die Fragen sind so formuliert, dass sie für technische wie nicht technische Entscheidungsträger verständlich sind.

Funktionale Kritikalität

Fragen Sie:

  • Übernimmt diese Komponente Authentifizierung, Verschlüsselung, Zugriffskontrolle oder Updates?
  • Ist sie zentral für die Kernfunktionen des Produkts?
  • Würde unser Produkt nicht mehr funktionieren, wenn diese Komponente ausfällt?
  • Könnte sie die Vertraulichkeit, Integrität oder Verfügbarkeit von Daten gefährden?

Je kritischer die Funktion, desto sorgfältiger sollte die Bewertung ausfallen. Eine Logging-Bibliothek ist nicht dasselbe wie ein Authentifizierungsmodul.

Expositionsgrad

Fragen Sie:

  • Ist diese Komponente aus dem Internet erreichbar?
  • Verarbeitet sie Eingaben externer Nutzer?
  • Ist sie über APIs zugänglich?
  • Oder ist sie vollständig intern und isoliert?

Eine höhere Exposition vergrößert die Angriffsfläche. Eine interne Hilfskomponente erfordert unter Umständen eine weniger umfangreiche Prüfung als eine öffentlich erreichbare Dienstkomponente.

Schadenspotenzial

Fragen Sie:

  • Könnte eine Ausnutzung zu Verletzungen des Schutzes personenbezogener Daten führen?
  • Würde eine Dienstunterbrechung Kunden beeinträchtigen?
  • Würde dies regulatorische Meldepflichten auslösen?
  • Könnte es unserem Ruf schaden?

Das Schadenspotenzial bestimmt, wie viel Aufwand im Risikomanagement gerechtfertigt ist.

Diese Faktoren wirken zusammen

  • Eine mäßig kritische Komponente, die öffentlich exponiert ist, kann erweiterte Kontrollen erfordern.
  • Eine hochkritische Komponente, die nur intern genutzt wird, kann eine strukturierte, aber verhältnismäßige Prüfung rechtfertigen.

Das Ziel ist Verhältnismäßigkeit, nicht einheitliche Kontrolle.

Verhältnismäßige Stufen der Sorgfaltsprüfung

Entsprechend dem Verhältnismäßigkeitsprinzip des CRA lassen sich die Praktiken der Sorgfaltsprüfung in Stufen mit zunehmendem Reifegrad gliedern.

Stufe 1

Grundlegende Sorgfaltsprüfung

Geeignet für Komponenten mit niedriger Kritikalität und eingeschränkter Exposition.

Zu den Maßnahmen gehören:

  • Prüfung der Projektaktivität und der jüngsten Wartung
  • Durchsicht öffentlich bekannter Schwachstellen
  • Prüfung der Lizenzkompatibilität
  • Aufnahme der Komponente in die Software Bill of Materials (SBOM)

Ziel sind Transparenz und Nachvollziehbarkeit. Für viele KMU ist dies eine realistische und erreichbare Grundlage, die den Erwartungen an eine verhältnismäßige Compliance entspricht.

Stufe 2

Strukturierte Sorgfaltsprüfung

Geeignet für Komponenten mit mittlerer Kritikalität oder Exposition.

Zusätzliche Maßnahmen können sein:

  • Prüfung der Governance-Transparenz und der Maintainer-Struktur
  • Bewertung der Praktiken zur Meldung von und Reaktion auf Schwachstellen
  • Bewertung der Release-Disziplin und der Klarheit der Versionierung
  • Werkzeuge zum automatisierten Scannen von Abhängigkeiten

Eine strukturierte Sorgfaltsprüfung schafft Vorhersehbarkeit. Sie verringert die Abhängigkeit von Ad-hoc-Entscheidungen und unterstützt dokumentierte interne Risikobewertungen.

Stufe 3

Erweiterte Sorgfaltsprüfung

Geeignet für hochkritische oder öffentlich exponierte Komponenten.

Erweiterte Maßnahmen können sein:

  • Kontinuierliche Schwachstellenüberwachung
  • Prüfung der Praktiken zur koordinierten Offenlegung
  • Bewertung der langfristigen Wartungszusage
  • Berücksichtigung freiwilliger Sicherheitsattestierungen nach Artikel 25
  • Austausch mit den Maintainern, wo angebracht

Besonders relevant für Komponenten, die:

  • Sensible Daten verarbeiten
  • Öffentlich exponiert sind
  • Wesentliche Produktfunktionen unterstützen
  • In regulierten oder besonders folgenreichen Umgebungen eingesetzt werden

Eine erweiterte Sorgfaltsprüfung stärkt die Resilienz der gesamten Software-Lieferkette.

Unsicher, welche Stufe gilt? Die Entscheidungsmatrix kombiniert Kritikalität und Exposition und empfiehlt eine Stufe. Vorlagen für die Stufen 1 bis 3 finden Sie unter Checklisten und Vorlagen.

Entscheidungsmatrix nutzen

Laufende Überwachung und Verantwortung über den Lebenszyklus

Die Sorgfaltsprüfung endet nicht mit der Integration. Schwachstellen können Jahre später entdeckt werden. Maintainer können wechseln. Releases können seltener werden. Die Verantwortung über den Lebenszyklus erfordert, neue Schwachstellen und den Wartungsstatus des Projekts fortlaufend im Blick zu behalten.

KMU sollten

  • Offenlegungen von Schwachstellen überwachen, die eingebundene Abhängigkeiten betreffen
  • Neue Releases und Sicherheitsupdates verfolgen
  • SBOM-Einträge aktuell halten
  • Das Risiko neu bewerten, wenn sich Exposition oder Architektur ändern

Neu bewerten, insbesondere wenn

  • Neue Produktfunktionen eingeführt werden
  • Die öffentliche Exposition zunimmt
  • Sich regulatorische Anforderungen ändern
  • Die Wartungsaktivität im Upstream nachlässt

Dieser kontinuierliche Ansatz entspricht unmittelbar den Sicherheitspflichten des CRA über den gesamten Lebenszyklus.

Sicherheitsattestierungen nutzen

Sofern verfügbar, können freiwillige Sicherheitsattestierungen nach Artikel 25 eine strukturierte Sorgfaltsprüfung unterstützen. Attestierungen können:

  • Standardisierte und vergleichbare Informationen zu Governance- und Sicherheitspraktiken liefern
  • Wiederholte Compliance-Anfragen an Maintainer reduzieren
  • Die Einbindung in interne Prozesse der Risikobewertung erleichtern

Die Verantwortung des Integrators bleibt bestehen

Wer sich auf Attestierungen stützt, wird dadurch nicht von seiner Verantwortung als Integrator entbunden. KMU müssen die Relevanz der attestierten Informationen im Hinblick auf ihren eigenen Integrationskontext, ihren Expositionsgrad und ihre Produktarchitektur bewerten. Attestierungen erhöhen die Transparenz, ersetzen aber keine kontextbezogene Risikobewertung.

Häufige Fallstricke und Warnsignale

Häufige Fallstricke bei der FOSS-Integration

KMU stoßen immer wieder auf dieselben Herausforderungen:

  • Annehmen, dass weite Verbreitung automatisch Sicherheit bedeutet
  • Indirekte (transitive) Abhängigkeiten nicht erkennen
  • Einmalig prüfen, ohne fortlaufend zu überwachen
  • Sich auf Upstream-Patches verlassen, ohne zu verfolgen, ob Updates tatsächlich übernommen werden
  • Komponenten integrieren, ohne die Gründe für die Auswahl zu dokumentieren

Wer diese Muster erkennt, kann von reaktiver Integration zu strukturiertem Risikomanagement übergehen.

Warnsignale, auf die Sie achten sollten

Anzeichen, die auf ein erhöhtes Risiko hindeuten können:

  • Kein sichtbarer Kanal zur Meldung von Sicherheitsproblemen
  • Lange Zeiträume ohne Updates oder Wartung
  • Ungelöste kritische Schwachstellen ohne Kommunikation
  • Uneinheitliche Versionierung oder Release-Dokumentation
  • Unklare Verantwortlichkeiten der Maintainer
  • Große Abhängigkeitsbäume mit wenig Transparenz

Ein Warnsignal schließt eine Komponente nicht automatisch aus. Mehrere Anzeichen können jedoch eine erweiterte Sorgfaltsprüfung oder ein Überdenken der Integrationsstrategie rechtfertigen.

Kurz-Checkliste zur Sorgfaltsprüfung

Zwölf einfache Fragen zu grundlegender Sichtbarkeit, Kenntnis von Schwachstellen, Transparenz der Lieferkette und Aspekten des Lebenszyklus. Ein leicht zugänglicher, verhältnismäßiger Einstieg für KMU mit begrenzten Ressourcen.

Checkliste öffnen

Der Weg für KMU zu einer CRA-konformen FOSS-Nutzung

Der CRA ist risikobasiert und lebenszyklusorientiert. KMU können pragmatisch vorgehen, indem sie einem einfachen Weg folgen, der mit der Kritikalität des Produkts und den verfügbaren Ressourcen skaliert.

  1. Starten Verantwortlichkeiten festlegen und einen ersten Überblick schaffen

    • Verantwortung zuweisen für: Auswahl von Abhängigkeiten, Sicherheitsupdates, Schwachstellenüberwachung und Dokumentation.
    • Ein minimales Inventar der wichtigsten FOSS-Komponenten im Produkt anlegen.

  2. Umfang bestimmen Wo FOSS in Ihrem Produkt eine Rolle spielt

    • Ermitteln, welche Teile des Produkts aus dem Internet erreichbar sind, Daten verarbeiten oder sicherheitsrelevant sind.
    • Klären, welche Komponenten für die Produktfunktion entscheidend sind.

  3. Risiko bewerten Verhältnismäßig denken

    • Jede Komponente bewerten nach: Kritikalität, Exposition und Schadenspotenzial.
    • Entscheiden, welche Stufe der Sorgfaltsprüfung angemessen ist (grundlegend / strukturiert / erweitert).

  4. Verhältnismäßige Kontrollen anwenden Tun, was angemessen ist

    • Für risikoarme Komponenten: grundlegende Prüfungen + SBOM + Überwachung.
    • Für Komponenten mit höherem Risiko: strukturierte Governance-Prüfungen, strengere Release-Disziplin, mehr Überwachung.

  5. Überwachen Kontinuierlich statt einmalig

    • Schwachstellen und Upstream-Updates verfolgen.
    • Die SBOM bei jedem Release (oder zumindest bei größeren Releases) aktualisieren.
    • Sicherstellen, dass Updates zeitnah übernommen werden.

  6. Neu bewerten Wenn sich etwas ändert

    • Das Produkt wird stärker exponiert (neue Integrationen, Erreichbarkeit aus dem Internet).
    • Kritische Funktionen ändern sich.
    • Die Wartung im Upstream lässt nach.
    • Es treten neue Schwachstellen auf, die zentrale Abhängigkeiten betreffen.

Dieser Weg soll KMU helfen, auch mit begrenzten Ressourcen einen strukturierten und belastbaren Ansatz nachzuweisen.

Entscheidungsmatrix für die Sorgfaltsprüfung von FOSS-Komponenten

Für konsistente und verhältnismäßige Entscheidungen kombiniert die Matrix zwei Dimensionen, funktionale Kritikalität und Expositionsgrad, und empfiehlt die oben definierte Stufe der Sorgfaltsprüfung (L1 / L2 / L3).

Funktionale Kritikalität Expositionsgrad InternIsolierte NutzungEingeschränktKontrollierter ZugriffÖffentlichAus dem Internet erreichbar
NiedrigL1 GrundlegendL1 GrundlegendL2 Strukturiert
MittelL1 GrundlegendL2 StrukturiertL3 Erweitert
HochL2 StrukturiertL3 ErweitertL3 Erweitert

So nutzen Sie die Matrix

  1. Bestimmen Sie die funktionale Kritikalität der Komponente:
    • Unterstützt sie Kernfunktionen?
    • Übernimmt sie Authentifizierung, Verschlüsselung oder Updates?
    • Würde ein Ausfall das Produkt erheblich beeinträchtigen?
  2. Bestimmen Sie den Expositionsgrad:
    • Wird sie nur intern genutzt?
    • Ist sie über authentifizierte APIs zugänglich?
    • Ist sie öffentlich exponiert?
  3. Suchen Sie den Schnittpunkt in der Matrix, um die empfohlene Stufe der Sorgfaltsprüfung zu ermitteln.

Wichtige Hinweise

  • Diese Matrix bietet Orientierung, keine starre Klassifizierung.
  • Ist das Schadenspotenzial außergewöhnlich hoch (z. B. funktionale Sicherheit, regulierte Umgebung), können KMU eine höhere Stufe der Sorgfaltsprüfung wählen.
  • Die Matrix unterstützt Verhältnismäßigkeit und vermeidet sowohl übertriebenen Aufwand als auch eine zu oberflächliche Bewertung.

Zurück nach oben