# 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): --- _Basierend auf dem OCCTET-Projektergebnis D2.3 – CRA Adoption Best Practice Document (v1.0, März 2026), lizenziert unter CC BY 4.0._