Mythos-Härtungs-Control · MRIS 2.0 · Wirkt in ISO/IEC 27001 und IT-Grundschutz

MHC-02 SBOM und Build-Provenance

Macht Herkunft und Bestandteile jeder Software nachweisbar – die Grundlage, um KI-beschleunigte Lieferketten-Angriffe und manipulierte Builds zu erkennen, bevor sie in Produktion wirken.

Auf einen Blick

Operativer Nutzen: Macht sofort sichtbar, welche fremden Komponenten in der eigenen Software stecken, sodass bei einer neuen Schwachstelle in Minuten statt Tagen klar ist, ob und wo man betroffen ist. Voraussetzung: SBOM-Erzeugung und Schwachstellen-Korrelation mindestens auf Stufe Defined.
Betroffene Richtlinie: Richtlinie zur sicheren Softwareentwicklung und zum Lieferantenmanagement.
Abhängigkeiten: keine Vorbedingung; setzt eine automatisierte Build-/CI-Pipeline voraus, um den Nutzen voll zu heben.
Aufwandstreiber: hängt von Zahl und Aufbau der Build-Pipelines und der Tiefe der Lieferkette ab. Der konkrete Aufwand richtet sich nach den Ressourcen der Organisation.
Primäre Kennzahl: Anteil der ausgelieferten Artefakte mit aktueller, automatisch erzeugter Stückliste (SBOM-Coverage).
Berührte Standards (ohne Erfüllungsanspruch): ISO/IEC 27002 A.5.21/A.8.30 primär, ergänzend A.5.19, A.5.20, A.5.22 (Lieferanten- und Dienstleistungssteuerung) sowie A.8.4 (Quellcode-Zugang); vollständige Zuordnung in MRIS Anhang A. CRA Annex I; BSI TR-03183-2; C5:2026 DEV-13; SLSA.

Control-Statement

Für jede selbst erstellte und weitergegebene Software wird automatisch eine Stückliste der enthaltenen Komponenten (SBOM) erzeugt und gegen Schwachstellendatenbanken abgeglichen. Weiterführende Härtung (Stufe Managed): Für kritische Artefakte wird zusätzlich nachvollziehbar belegt, wie und woraus sie gebaut wurden (Build-Provenance), und die Herkunftsnachweise werden automatisiert geprüft.

Zweck und Bedrohungsbezug

Moderne Software besteht zum großen Teil aus fremden Bausteinen (Open-Source-Bibliotheken, Frameworks). Wird in einem dieser Bausteine eine Schwachstelle bekannt — oder schleust ein Angreifer gezielt Schadcode in die Lieferkette ein —, ist ohne Übersicht oft tagelang unklar, ob und wo man betroffen ist. AI verkürzt die Zeit zwischen Bekanntwerden einer Schwachstelle und einem funktionierenden Angriff drastisch. Eine aktuelle Stückliste macht die eigene Betroffenheit sofort prüfbar; ein Nachweis über Herkunft und Bauweise erschwert es, manipulierte Bausteine unbemerkt unterzuschieben. Schutzziel ist, Angriffe über die Software-Lieferkette schnell zu erkennen und einzugrenzen.

Wirkung in den Regelwerken

Auf diese Controls und Anforderungen wirkt das MHC. Die Einstufung zeigt, wie stark das jeweilige Control unter KI-gestützten Angriffen an Wirkung verliert.

Wirkung in den Regelwerken
Nummer	Titel	Einstufung / Stufe
ISO/IEC 27001:2022, Annex A 6 Controls
A.5.19	Informationssicherheit in Lieferantenbeziehungen	teilweise degradiert
A.5.20	Adressierung in Lieferantenvereinbarungen	teilweise degradiert
A.5.21	Management der ICT-Lieferkette	teilweise degradiert
A.5.22	Überwachung Lieferantendienstleistungen	teilweise degradiert
A.8.4	Zugang zu Quellcode	teilweise degradiert
A.8.30	Ausgelagerte Entwicklung	teilweise degradiert
IT-Grundschutz, MRIS.bd 1 Anforderungen
MRIS.bd.1.A7	Erzeugung von Software-Stücklisten und Build-Provenance-Nachweisen	Standard

Alle 93 Controls in der Analysematrix · Alle 23 Anforderungen der Bausteinfamilie

Reifegrad-Pfad

Initial: SBOM-Erzeugung in einzelnen Pipelines.
Defined: SBOM für alle eigenen Artefakte; automatisierter Schwachstellen-Abgleich.
Managed: SBOM auch von kritischen Lieferanten; Build-Provenance (SLSA) für kritische Artefakte; automatisierte Prüfung der Herkunftsnachweise.

Messung und Audit-Nachweis

Kennzahl: SBOM-Coverage — Anteil der ausgelieferten Artefakte mit aktueller, automatisch erzeugter Stückliste (Zielwert: vollständige Abdeckung der eigenen Artefakte).
Nachweis: SBOM-Dateien je Version, Konfiguration der Pipeline, Berichte des Schwachstellen-Abgleichs, Provenance-Nachweise kritischer Artefakte.
Nachweislogik (in Anlehnung an ISO/IEC 27001, Clause 9): dokumentiert? — Pipeline-Konfiguration und Stücklisten; verantwortlich? — Entwicklungs-/Produktverantwortliche; Häufigkeit? — bei jedem Build, Abgleich fortlaufend; Toleranz? — kein ausgeliefertes Artefakt ohne aktuelle Stückliste.

Typische Fehler

Stücklisten werden erzeugt, aber nie ausgewertet — im Schwachstellenfall liegt zwar eine SBOM vor, doch niemand gleicht sie ab.
Nur die obersten Abhängigkeiten werden erfasst; gerade die tief verschachtelten Bausteine, in denen Schwachstellen stecken, fehlen.
Die SBOM wird einmalig erstellt und nicht je Version fortgeschrieben, sodass sie nicht zum tatsächlich ausgelieferten Stand passt.
Schwachstellendaten werden in die SBOM gemischt; dadurch wird die statische Stückliste mit dynamischen Informationen vermengt und schnell unbrauchbar.

Abgrenzung und Restrisiko

Abgrenzung: betrifft Transparenz und Herkunft der Software-Bausteine; das eigentliche Schließen der Schwachstellen ist Teil des Schwachstellen- und Patch-Managements, das automatisierte Testen behandelt MHC-09.
Restrisiko: eine Stückliste erkennt bekannte, nicht aber unbekannte Schwachstellen; korrekt deklarierte, aber manipulierte Komponenten werden allein durch die SBOM nicht entlarvt — dafür dient die Provenance.
ISO/IEC 27002:2022: A.5.19 Informationssicherheit in Lieferantenbeziehungen; A.5.20 Behandlung von Informationssicherheit in Lieferantenvereinbarungen; A.5.21 Umgang mit der Informationssicherheit in der IKT-Lieferkette; A.8.4 Zugriff auf den Quellcode; A.8.30 Ausgegliederte Entwicklung.
Framework: C5:2026 DEV-13; CRA Annex I (SBOM-Pflicht für Hersteller von Produkten mit digitalen Elementen; Schwachstellen-Meldepflichten ab 2026, Hauptpflichten für nach dem 11.12.2027 in Verkehr gebrachte Produkte); BSI TR-03183-2; DORA Art. 28; NIS2-DVO Nr. 5; SLSA-Framework; Formate CycloneDX (ECMA-424) und SPDX (ISO/IEC 5962).

Umsetzung im Detail

Organisatorische und technische Umsetzung, Umsetzungsbeispiele und die Priorisierung im Gesamtprogramm beschreibt der Implementation Guide.

Implementation Guide (PDF)Zum MHC-Katalog