# 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.

---

_Basierend auf dem OCCTET-Projektergebnis D2.3 – CRA Adoption Best Practice Document (v1.0, März 2026), lizenziert unter CC BY 4.0._

<https://occtet.eu/de/best-practices/checklists-and-templates/>