# 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. --- ## MVC-Checkliste – Minimum Viable Compliance (A1.1) 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. ### A. Rollen und Verantwortlichkeiten — Wer macht was? Eine verantwortliche Person benennen für: - [ ] Auswahl und Freigabe von Abhängigkeiten - [ ] Schwachstellenüberwachung - [ ] Sicherheitsupdates / Patches - [ ] Release-Dokumentation (was sich geändert hat, was aktualisiert wurde) > Klare Verantwortlichkeiten verhindern, dass Sicherheitsaufgaben stillschweigend vorausgesetzt werden oder niemandem zugeordnet sind. ### B. Überblick über Komponenten — Wissen, was Sie nutzen - [ ] Ein einfaches FOSS-Komponentenregister führen mit: - Name + Version der Komponente - Einsatzort (Modul / Produktbereich) - Kritikalität (niedrig / mittel / hoch) - Exposition (intern / eingeschränkt / öffentlich) - Update-Verantwortung - [ ] Eine SBOM erstellen (mindestens für größere Releases) oder eine gleichwertige Abhängigkeitsliste pflegen > 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: - [ ] Sie wird aktiv gepflegt (jüngste Aktivität / Release-Signale) - [ ] Bekannte Schwachstellen wurden geprüft - [ ] Die Lizenzkompatibilität wurde geprüft - [ ] Ein Sicherheitskontakt oder Offenlegungsweg ist vorhanden (falls zutreffend) ### D. Schwachstellenbehandlung — Was Sie tun, wenn ein Problem auftritt Einen einfachen internen Prozess haben, der folgende Fragen beantwortet: - [ ] Wie erhalten wir Warnmeldungen zu Schwachstellen? - [ ] Wer übernimmt die Triage? - [ ] Wie entscheiden wir über die Dringlichkeit? - [ ] Wie patchen und veröffentlichen wir? - [ ] Wie kommunizieren wir Änderungen (Release Notes)? ### E. Updates und Lebenszyklus — Langfristig sicher bleiben Eine einfache Update-Richtlinie festlegen: - [ ] Wie oft prüfen wir Updates? (z. B. monatlich + dringende Patches so schnell wie möglich) - [ ] Wie gehen wir mit Komponenten am End-of-Life um? - [ ] Wer genehmigt Upgrades von Abhängigkeiten? Mindestens festhalten: - [ ] Datum der letzten Überprüfung der Abhängigkeiten - [ ] Datum des letzten Sicherheitsupdates / Patch-Releases ### F. Nachweise — Belegen können, dass Sie es getan haben Schlanke Nachweise aufbewahren, die bei Bedarf vorgelegt werden können: - [ ] Komponentenregister + SBOM - [ ] Update-Richtlinie (1 Seite genügt) - [ ] Notizen zur Schwachstellenbehandlung (Prozess + mindestens ein Beispiel-Logeintrag) - [ ] Release Notes mit Verweis auf Abhängigkeits- / Sicherheitsupdates > **MVC-Prinzip** — Klein anfangen, konsequent bleiben und Kontrollen risikobasiert ausbauen. --- ## Kurz-Checkliste zur Sorgfaltsprüfung (§5.4.5) 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. ### Grundlegende Sichtbarkeit - [ ] Wird das Projekt aktiv gepflegt? - [ ] Ist die Versionshistorie transparent? - [ ] Ist ein Sicherheitskontakt öffentlich verfügbar? ### Kenntnis von Schwachstellen - [ ] Sind Schwachstellen dokumentiert? - [ ] Werden Korrekturen strukturiert veröffentlicht? - [ ] Gibt es Belege für Reaktionsfähigkeit? ### Transparenz der Lieferkette - [ ] Ist die Komponente in der SBOM enthalten? - [ ] Sind Abhängigkeiten sichtbar? - [ ] Ist die Versionierung konsistent? ### Aspekte des Lebenszyklus - [ ] Gibt es Belege für laufende Wartung? - [ ] Werden Updates klar kommuniziert? - [ ] Ist der End-of-Life-Status festgelegt? --- ## FOSS-Komponentenregister (A1.2) 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. | Komponentenname | Version | Eingesetzt in | Kritikalität | Exposition | Lizenz | Maintainer-Aktivität | Letzte Schwachstellenprüfung | Update-Verantwortung | Anmerkungen | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | ExampleAuthLib | 2.4.1 | Authentifizierungsmodul | Hoch | Öffentlich | MIT | Aktiv (monatliche Releases) | 12. Feb. 2026 | CTO | Sicherheitskritisch. CVE-2025-XXXX in v2.4.1 behoben. Kontinuierliche Überwachung aktiviert. | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - **Kritikalität:** Niedrig / Mittel / Hoch - **Exposition:** Intern / Eingeschränkt / Öffentlich --- ## Steckbrief für Open-Source-Komponenten (A1.3) 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. ### 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 - [ ] Maintainer-Aktivität geprüft - [ ] Schwachstellenhistorie geprüft - [ ] Sicherheitskontakt / Offenlegungsweg vorhanden (falls zutreffend) - [ ] Lizenzkompatibilität bestätigt - [ ] In der SBOM enthalten ### 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**: --- ## Mini-Playbook zur Schwachstellenbehandlung (A1.4) Ein strukturierter, aber schlanker Ablauf zur Schwachstellenbehandlung im KMU-Format, von der ersten Warnmeldung bis zum Abschluss. ### 1. Eingang — Wie wir Warnmeldungen erhalten Überwachte Quellen: - [ ] Sicherheitshinweise der Projekte - [ ] CVE-Datenbanken - [ ] Werkzeug zum Scannen von Abhängigkeiten - [ ] Meldungen von Kunden - [ ] Interne Tests - **Verantwortlich für Warnmeldungen**: - **Vertretung**: ### 2. 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 ### 3. Behebung — Beheben und verifizieren Ergriffene Maßnahme: - [ ] Upgrade auf die korrigierte Version - [ ] Patch anwenden - [ ] Gegenmaßnahme / Konfigurationsänderung - [ ] Vorübergehender Workaround - **Verantwortlich**: - **Zieldatum**: - **Durchgeführte Validierung** (z. B. Tests / Regressionstests / Prüfung des Deployments): ### 4. 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**: ### 5. Abschluss und Erkenntnisse - **Abschlussdatum**: - **Was gut lief / was wir beim nächsten Mal verbessern** (1–2 Stichpunkte): --- ## Richtlinie für Abhängigkeits-Updates (A1.5) Eine Kurzrichtlinie, die festlegt, wie Abhängigkeiten von Dritten geprüft, aktualisiert und ausgemustert werden. Eine Seite genügt. ### 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 --- ## SBOM-Checkliste für KMU (A1.6) 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. ### Was erfasst werden sollte — Mindestumfang - [ ] Produktname + Version (Release-Kennung) - [ ] Komponentenname + Version - [ ] Direkte und transitive Abhängigkeiten (soweit verfügbar) - [ ] Lizenzinformationen (soweit machbar) - [ ] Eindeutige Kennungen (sofern verfügbar, z. B. Package URL / Hashes) ### Wann die SBOM erstellt oder aktualisiert werden sollte Mindestens: - [ ] Bei größeren Releases (z. B. Version 1.0, 1.1, 2.0) Empfohlen: - [ ] Bei jedem Release, das Abhängigkeiten ändert Immer aktualisieren, wenn: - [ ] Ein Sicherheitspatch das Upgrade einer Abhängigkeit erfordert - [ ] Eine kritische / stark exponierte Komponente die Version wechselt - [ ] Eine Schwachstellenbehebung umgesetzt wird ### 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 --- _Basierend auf dem OCCTET-Projektergebnis D2.3 – CRA Adoption Best Practice Document (v1.0, März 2026), lizenziert unter CC BY 4.0._