Springe zum Hauptinhalt

Bewährte Verfahren zur CRA-Übernahme

Checklisten & Vorlagen

Das praktische Umsetzungs-Toolkit für KMU: schlanke Checklisten und Vorlagen, die Sie online abhaken, ausdrucken oder in die Werkzeuge herunterladen können, die Sie bereits nutzen.

Auf dieser Seite

Praktisches Umsetzungs-Toolkit für KMU

Wiederverwendbare Vorlagen und praktische Hinweise helfen KMU, FOSS-Komponenten unter dem CRA verhältnismäßig und lebenszyklusorientiert zu integrieren. Die Werkzeuge sind bewusst schlank gehalten und skalieren mit der Kritikalität des Produkts, seiner Exposition und den verfügbaren Ressourcen.

Haken Sie die Checklisten online ab (Ihr Fortschritt bleibt in diesem Browser gespeichert), drucken Sie sie aus oder laden Sie die Vorlagen für das Werkzeug herunter, das Sie bereits nutzen: eine Tabellenkalkulation, ein Wiki oder ein Git-Repository.

Alle Vorlagen herunterladen (.md)

A1.1 Checkliste

MVC-Checkliste – Minimum Viable Compliance

Eine einseitige Grundausstattung an Praktiken, die die meisten KMU umsetzen können, um eine CRA-konforme Integration von Open-Source-Komponenten zu unterstützen. Ausgelegt für begrenzte Zeit und Ressourcen; je nach Risiko verhältnismäßig ausbauen.

Herunterladen .md

A. Rollen und Verantwortlichkeiten Wer macht was?

  • Eine verantwortliche Person benennen für:

Klare Verantwortlichkeiten verhindern, dass Sicherheitsaufgaben stillschweigend vorausgesetzt werden oder niemandem zugeordnet sind.

B. Überblick über Komponenten Wissen, was Sie nutzen

    • Name + Version der Komponente
    • Einsatzort (Modul / Produktbereich)
    • Kritikalität (niedrig / mittel / hoch)
    • Exposition (intern / eingeschränkt / öffentlich)
    • Update-Verantwortung

Transparenz über die eingesetzten Komponenten ist die Grundlage eines risikobasierten Managements.

C. Grundlegende Sorgfaltsprüfung Vor der Integration

  • Für jede wichtige Komponente bestätigen:

D. Schwachstellenbehandlung Was Sie tun, wenn ein Problem auftritt

  • Einen einfachen internen Prozess haben, der folgende Fragen beantwortet:

E. Updates und Lebenszyklus Langfristig sicher bleiben

  • Eine einfache Update-Richtlinie festlegen:
  • Mindestens festhalten:

F. Nachweise Belegen können, dass Sie es getan haben

  • Schlanke Nachweise aufbewahren, die bei Bedarf vorgelegt werden können:

MVC-Prinzip

Klein anfangen, konsequent bleiben und Kontrollen risikobasiert ausbauen.

§5.4.5 Checkliste

Kurz-Checkliste zur Sorgfaltsprüfung

Zwölf Fragen, die Sie vor der Integration einer FOSS-Komponente stellen sollten. Sie ersetzen keine strukturierte Risikobewertung, bieten KMU mit begrenzten Ressourcen aber einen leicht zugänglichen und verhältnismäßigen Einstieg.

Herunterladen .md

Grundlegende Sichtbarkeit

Kenntnis von Schwachstellen

Transparenz der Lieferkette

Aspekte des Lebenszyklus

Die Komponente übernimmt sensible Funktionen oder ist aus dem Internet erreichbar? Ermitteln Sie mit der Entscheidungsmatrix, welche Stufe der Sorgfaltsprüfung sie benötigt.

Entscheidungsmatrix öffnen

A1.2 Vorlage

FOSS-Komponentenregister

Ein einfaches Register der in Ihr Produkt integrierten Open-Source-Komponenten. Es unterstützt Nachvollziehbarkeit, Sorgfaltsprüfung und Überwachung über den Lebenszyklus und lässt sich in einer Tabellenkalkulation, in SharePoint, in Git oder in jedem internen Werkzeug pflegen.

Herunterladen .csv Herunterladen .md

Beispiel (ausgefüllte Zeile)

KomponentennameVersionEingesetzt inKritikalitätExpositionLizenzMaintainer-AktivitätLetzte SchwachstellenprüfungUpdate-VerantwortungAnmerkungen
ExampleAuthLib2.4.1AuthentifizierungsmodulHochÖffentlichMITAktiv (monatliche Releases)12. Feb. 2026CTOSicherheitskritisch. CVE-2025-XXXX in v2.4.1 behoben. Kontinuierliche Überwachung aktiviert.
  • Kritikalität: Niedrig / Mittel / Hoch
  • Exposition: Intern / Eingeschränkt / Öffentlich

A1.3 Vorlage

Steckbrief für Open-Source-Komponenten

Für Komponenten mit mittlerer oder hoher Kritikalität sowie für alle öffentlich exponierten Komponenten. Ergänzt das Komponentenregister um die Begründung, warum die Komponente ausgewählt wurde und welche Überwachung besteht.

Herunterladen .md

Komponente

  • Komponentenname
  • Version / genutzter Versionsbereich
  • Repository / Referenzlink optional
  • Eingesetzt in Modul / Funktion
  • Funktionale Kritikalität Niedrig / Mittel / Hoch
  • Exposition Intern / Eingeschränkt / Öffentlich
  • Lizenz

Begründung der Auswahl Warum diese Komponente?

  • Warum wurde sie gewählt? z. B. passender Funktionsumfang, Stabilität, Performance, Ökosystem
  • Geprüfte Alternativen falls vorhanden

Durchgeführte grundlegende Sorgfaltsprüfung

Bekannte Risiken / Anmerkungen

  • Bekannte Einschränkungen / Bedenken
  • Bedenken zur Abhängigkeitstiefe falls relevant

Überwachung und Verantwortung

  • Update-Verantwortung / verantwortliche Person
  • Quelle(n) für die Schwachstellenüberwachung z. B. Sicherheitshinweise, CVE-Feeds, Repository-Warnungen
  • Prüfintervall z. B. monatlich + bei dringenden Warnungen nach Bedarf
  • Datum der letzten Prüfung
  • Datum der nächsten geplanten Prüfung

A1.4 Playbook

Mini-Playbook zur Schwachstellenbehandlung

Ein strukturierter, aber schlanker Ablauf zur Schwachstellenbehandlung im KMU-Format, von der ersten Warnmeldung bis zum Abschluss.

Herunterladen .md

Eingang Wie wir Warnmeldungen erhalten

  • Überwachte Quellen:
  • Verantwortlich für Warnmeldungen
  • Vertretung

Triage Schweregrad und Dringlichkeit festlegen

  • Für jede Schwachstelle festhalten:
  • Betroffene Komponente und Version(en)
  • Wird sie in unserem Produkt verwendet? Ja / Nein
  • Expositionskontext Intern / Eingeschränkt / Öffentlich
  • Funktionale Kritikalität Niedrig / Mittel / Hoch
  • Hinweise auf Ausnutzbarkeit falls bekannt
  • Vorgeschlagene Priorität der Reaktion Niedrig / Mittel / Hoch
  • Entscheidungsregel (einfach):
  • Hohe Kritikalität + öffentliche Exposition → als dringend behandeln
  • Mittleres Risiko → geplante Behebung
  • Niedriges Risiko → nachverfolgen und im nächsten geplanten Zyklus beheben

Behebung Beheben und verifizieren

  • Ergriffene Maßnahme:
  • Verantwortlich
  • Zieldatum
  • Durchgeführte Validierung z. B. Tests / Regressionstests / Prüfung des Deployments

Release und Kommunikation

  • Release Notes aktualisiert Ja / Nein
  • SBOM aktualisiert Ja / Nein
  • Kommunikation an Kunden / intern erforderlich? Ja / Nein
  • Falls ja: Kanal und Verantwortliche(r) für die Mitteilung

Abschluss und Erkenntnisse

  • Abschlussdatum
  • Was gut lief / was wir beim nächsten Mal verbessern 1–2 Stichpunkte

A1.5 Richtlinie

Richtlinie für Abhängigkeits-Updates

Eine Kurzrichtlinie, die festlegt, wie Abhängigkeiten von Dritten geprüft, aktualisiert und ausgemustert werden. Eine Seite genügt.

Herunterladen .md

Geltungsbereich

  • Gilt für Abhängigkeiten von Dritten, einschließlich FOSS-Komponenten.

Grundsatz

  • Abhängigkeiten werden risikobasiert und lebenszyklusorientiert gepflegt. Update-Maßnahmen richten sich verhältnismäßig nach Kritikalität, Exposition und Schadenspotenzial.

Update-Rhythmus

  • Routinemäßige Prüfung der Abhängigkeiten z. B. monatlich / vierteljährlich
  • Sicherheitsupdates werden je nach Risikoeinstufung eingespielt:
  • Hohes Risiko: so schnell wie möglich
  • Mittleres Risiko: geplante Behebung im nächsten Release-Zyklus
  • Niedriges Risiko: nachverfolgt und im Rahmen der regulären Wartung behoben

Entscheidungsverantwortung

  • Verantwortlich für die Freigabe von Abhängigkeits-Upgrades
  • Verantwortlich für die Freigabe dringender Sicherheitskorrekturen

Abhängigkeiten am End-of-Life

  • Wird eine Abhängigkeit nicht mehr unterstützt oder erreicht sie ihr End-of-Life, gehen wir wie folgt vor:
  • Das Risiko festhalten
  • Alternativen bewerten
  • Migration oder kompensierende Kontrollen planen
  • Entscheidung und Zeitplan dokumentieren

A1.6 Checkliste

SBOM-Checkliste für KMU

Was eine Software Bill of Materials enthalten sollte und wann sie zu erstellen ist. Eine SBOM unterstützt Transparenz und Nachvollziehbarkeit bei Produkten mit FOSS-Komponenten; SBOM-Praktiken lassen sich schrittweise einführen.

Herunterladen .md

Was erfasst werden sollte Mindestumfang

Wann die SBOM erstellt oder aktualisiert werden sollte

  • Mindestens:
  • Empfohlen:
  • Immer aktualisieren, wenn:

SBOM-Reifegrade

Stufe 1

Grundlegend

  • Strukturierte Abhängigkeitsliste
  • Aktualisierung bei größeren Releases
  • Mit der Release-Dokumentation verknüpft
Stufe 2

Strukturiert

  • Automatisierte SBOM-Erstellung (wo möglich)
  • Direkte + transitive Abhängigkeiten
  • Erfassung der Lizenzen
  • SBOM wird mit den Release-Artefakten gespeichert
Stufe 3

Fortgeschritten

  • In CI/CD integrierte SBOM-Erstellung
  • Kontinuierliche Überwachung der Abhängigkeiten
  • Hash-Verifizierung
  • Versionshistorie der SBOMs
  • Schnelle Auswirkungsanalyse bei CVEs

Die OCCTET-Toolchain scannt Ihren Quellcode und erstellt automatisch SBOMs. So gelangen Sie von Stufe 1 zu Stufe 3.

OCCTET-Toolchain entdecken

Zurück nach oben