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

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