Software Supply Chain: SBOM, Sigstore und Dependency Scanning erklärt
SBOM-Pflicht durch NIS-2 und CRA, Sigstore für sichere Container-Signaturen und Dependency-Track für CVE-Monitoring – so schützen KMUs ihre Software-Lieferkette.
Software Supply Chain: SBOM, Sigstore und Dependency Scanning erklärt
Key Takeaways
- Eine Software Bill of Materials (SBOM) listet alle Komponenten einer Anwendung auf und wird durch NIS-2 und den EU Cyber Resilience Act zunehmend zur Pflicht.
- Sigstore ermöglicht kryptografisch überprüfbare Signaturen für Container-Images und Artefakte – ohne eigene PKI-Infrastruktur.
- Dependency-Track von OWASP automatisiert die Schwachstellenanalyse auf Basis von SBOMs und liefert CVE-Informationen in Echtzeit.
- Das Zusammenspiel dieser drei Werkzeuge bildet die technische Grundlage einer belastbaren DevSecOps-Praxis.
Software Supply Chain: Das unterschätzte Risiko
Der Begriff „Software Supply Chain
Häufige Fragen
Ist eine SBOM für deutsche Unternehmen gesetzlich vorgeschrieben?
Eine explizite SBOM-Pflicht existiert in Deutschland noch nicht als nationales Gesetz, aber der EU Cyber Resilience Act (CRA) verpflichtet ab 2027 alle Hersteller von Produkten mit digitalen Elementen, eine SBOM als Teil der technischen Dokumentation bereitzuhalten. NIS-2 fordert indirekt über die Lieferkettensicherheit eine nachvollziehbare Übersicht über eingesetzte Drittkomponenten. Wer heute beginnt, ist 2027 compliant.
Was kostet der Betrieb von Dependency-Track?
OWASP Dependency-Track ist vollständig Open Source und kostenlos. Für einen Einstieg reicht eine einzelne VM mit 4 vCPUs und 8 GB RAM – als Docker-Container oder Kubernetes-Deployment. Der Aufwand für Setup und initiale Konfiguration liegt bei ein bis zwei Tagen. Die laufenden Betriebskosten bestehen primär aus der Infrastruktur und dem Zeitaufwand für das Triagieren von Findings.
Kann Sigstore auch mit einer eigenen privaten Container-Registry genutzt werden?
Ja. Cosign funktioniert mit jeder OCI-kompatiblen Registry, also auch mit selbst gehosteten Registries wie Harbor, Nexus oder GitLab Container Registry. Bei privaten Umgebungen empfiehlt sich entweder der Einsatz eines eigenen Rekor-Transparency-Log-Servers oder die Verwendung von Cosign mit einem selbstverwalteten Schlüsselpaar (nicht keyless). Die keyless-Variante über Fulcio setzt eine OIDC-Identität voraus, was bei GitHub Actions und GitLab CI/CD out-of-the-box funktioniert.