SBOMs als Compliance-Nachweis: ISO 27001, SOC 2 und NIS2

Nachweis ist nicht Compliance

Eine Anforderung erfüllt ein Prozess, der funktioniert. Ein Nachweis zeigt, dass er funktioniert. Eine SBOM zeigt eine bestimmte Sache: was ein bestimmtes Release enthielt. Über Zugriffskontrolle, Incident Response oder darüber, ob jemand auf einen Befund reagiert hat, zeigt sie nichts.

Sie kann auch falsch sein, ohne dass es jemand merkt. Ein Generator, der die falschen Dateien gelesen hat, erzeugt eine gültige SBOM, der das halbe Produkt fehlt. Der Schwachstellenscan dieser SBOM ist sauber, die Compliance-Plattform sieht, dass ein Scan gelaufen ist, und jede Prüfung zeigt Grün. Was eine grüne SBOM-Prüfung für SOC 2 verifiziert zeigt diesen Fehler im Detail.

Ein Nachweis aus einer SBOM zählt, wenn sie:

1. an ein Release gebunden ist. Eine SBOM pro ausgelieferter Version, nicht eine für das Repository.
2. vollständig ist oder sagt, was ihr fehlt. Einer SBOM, die ihre Lücken nennt, kann man bei dem trauen, was sie auflistet.
3. für den Zeitraum aufbewahrt wird, den das Audit abdeckt. Ein Auditor, der Stichproben aus dem letzten März zieht, braucht die SBOM vom letzten März.
4. neu geprüft wird, wenn neue Schwachstellen auftauchen. Eine Liste, die niemand mit neuen Advisories abgleicht, beweist wenig über Schwachstellenmanagement.

Was eine SBOM enthält, erklärt Was ist eine SBOM?. Zu den Frameworks für sichere Entwicklung bei Industrieprodukten und US-Bundessoftware siehe IEC 62443-4-1 und NIST SSDF.

ISO/IEC 27001:2022

ISO/IEC 27001 ist die Norm, nach der ein Informationssicherheits-Managementsystem zertifiziert wird (Glossar). Anhang A listet 93 Maßnahmen; eine Organisation wählt die aus, die ihre Risikobeurteilung erfordert, und hält sie in ihrer Erklärung zur Anwendbarkeit fest. ISO/IEC 27002:2022 enthält die Umsetzungshinweise. Keine der beiden nennt eine SBOM. Die Tabelle zitiert nur die Titel der Maßnahmen, in der deutschen Fassung DIN EN ISO/IEC 27001:2024, und sagt kurz, worum es in jeder geht.

Maßnahme	Worum es geht	Wie eine SBOM oder Build-Aufzeichnung als Nachweis dient	Was sie nicht abdeckt
5.9 „Inventar der Informationen und anderen damit verbundenen Werte“	Wissen, welche Werte Sie haben und wem sie gehören	Die Software, die Sie ausliefern und betreiben, ist ein Wert. Eine Komponentenliste pro Release ist das Inventar dessen, was darin steckt.	Hardware, Daten, Personen und Dienste
5.19 „Informationssicherheit in Lieferantenbeziehungen“, 5.20 „Behandlung von Informationssicherheit in Lieferantenvereinbarungen“, 5.21 „Umgang mit der Informationssicherheit in der Lieferkette der Informations- und Kommunikationstechnologie (IKT)“, 5.22 „Überwachung, Überprüfung und Änderungsmanagement von Lieferantendienstleistungen“	Das Risiko steuern, das mit Lieferanten und der IKT-Lieferkette einhergeht	In zwei Richtungen. Als Käufer können Sie SBOMs von Lieferanten verlangen und überwachen. Als Lieferant ist Ihre SBOM das, was der Lieferkettenprozess Ihres zertifizierten Kunden von Ihnen verlangt. Open-Source-Komponenten gehören zur IKT-Lieferkette, kommen aber ohne Lieferantenvereinbarung, und genau deshalb ist ein Inventar davon wichtig.	Verträge, Lieferantenbewertungen und Überprüfungen
8.8 „Handhabung von technischen Schwachstellen“	Informationen über Schwachstellen beschaffen, die eigene Gefährdung bewerten und handeln	Eine aktuelle Komponentenliste, mit Advisories abgeglichen und neu bewertet, wenn neue erscheinen, dazu eine Aufzeichnung, welche Releases eine verwundbare Version enthielten und seit wann	Das Patchen Ihrer Infrastruktur, das Scannen von Hosts und die Entscheidungen selbst
8.25 „Lebenszyklus einer sicheren Entwicklung“	Regeln für die sichere Entwicklung von Software und Systemen	Ein aufgezeichneter, wiederholbarer Release-Prozess: jedes Release in derselben Pipeline gebaut, mit seiner SBOM	Den größten Teil der Maßnahme: Schulung, Umgebungen, Design und Review
8.26 „Anforderungen an die Anwendungssicherheit“, 8.27 „Sichere Systemarchitektur und Entwicklungsgrundsätze“, 8.28 „Sichere Codierung“	Anforderungen, Design und Code	Nicht direkt. Hier geht es um das, was Sie schreiben, nicht um das, was Sie einbinden.	Alles davon: Code-Reviews, SAST und Design-Unterlagen sind hier der Nachweis
8.29 „Sicherheitsprüfung bei Entwicklung und Abnahme“	Sicherheit vor dem Release testen	Ein Policy-Gate, das einen Build bei einem Schwachstellenbefund blockiert, ist ein aufgezeichneter Test mit Ergebnis	Funktionale Sicherheitstests, Penetrationstests
8.30 „Ausgegliederte Entwicklung“	Ausgelagerte Entwicklung steuern und überwachen	Ausgelagerter Code, der in Ihrer Pipeline gebaut wird, erhält dieselbe SBOM und dieselben Prüfungen wie Ihr eigener	Den Vertrag, die eigenen Praktiken des Lieferanten

Bleiben Sie bei 8.25 bis 8.30 ehrlich: Das meiste, was diese Maßnahmen verlangen, liegt außerhalb einer SBOM. Wer mehr behauptet, verspielt am schnellsten das Vertrauen des Auditors in den Rest.

Beispiel aus der Praxis: Ein Auditor fragt nach 8.8

„Woher wissen Sie, wann eine neue Schwachstelle ein Produkt betrifft, das Sie bereits ausgeliefert haben?“ Hier ist die Nachweiskette für ein Advisory, und wer jedes Glied liefert.

Schritt	Nachweis	Stammt aus
1. Der Inhalt des Release	Die SBOM von Version 4.2, aufgezeichnet von dem Build, der sie erzeugt hat	Ihren Build-Tools
2. Der Abgleich mit dem Advisory	Eine neue CVE für eine Bibliothek in dieser SBOM, zugeordnet über ihre Package URL	Ihrer Schwachstellenüberwachung
3. Der Zeitraum der Gefährdung	Jeder Build, der die verwundbare Version enthielt, und das Datum des ersten	Ihrer Build-Historie
4. Die Entscheidung	Wer sie bewertet hat, wann und mit welchem Ergebnis: beheben, abmildern oder nicht betroffen, mit Begründung	Ihrem Prozess und seinen Aufzeichnungen
5. Die Behebung	Version 4.2.1, deren SBOM die verwundbare Version nicht mehr enthält	Ihren Build-Tools

Tools können die Schritte 1, 2, 3 und 5 liefern. Schritt 4 ist Ihr Prozess, und diesen Schritt lesen Auditoren am genauesten.

SOC 2

Ein SOC-2-Bericht stellt fest, ob Kontrollen die Trust Services Criteria des AICPA erfüllen (2017, mit 2022 überarbeiteten Points of Focus). Die Kriterien beschreiben Ergebnisse. Sie nennen keine SBOMs, und bei zweien helfen SBOMs.

• CC7.1 verlangt sinngemäß, dass die Organisation Erkennungs- und Überwachungsverfahren nutzt, um (1) Konfigurationsänderungen zu erkennen, durch die neue Schwachstellen entstehen, und (2) die Anfälligkeit für neu entdeckte Schwachstellen. Nachweis: eine SBOM pro Release, neu bewertet gegen neue Advisories, und eine Aufzeichnung, wie jeder Befund behandelt wurde.
• CC8.1 betrifft das Änderungsmanagement: wie Änderungen an Infrastruktur, Daten, Software und Verfahren genehmigt, entwickelt oder beschafft, getestet, freigegeben und umgesetzt werden. Nachweis: jedes Release in einer aufgezeichneten Pipeline gebaut, die Änderung seiner Abhängigkeiten von einem Build zum nächsten sichtbar, und Policy-Gates als Kontrolle darüber, was ausgeliefert werden darf.

Die Kriterien werden überarbeitet. Im Oktober 2026 hat das AICPA einen Exposure Draft der Trust Services Criteria 2027 veröffentlicht, mit einer gezielten Umstrukturierung der Kriterien, Kommentaren bis zum 15. Januar 2027 und einem vorgeschlagenen Inkrafttreten für Prüfungen, die am oder nach dem 31. Dezember 2027 beginnen. Es ist ein Entwurf, und die Nummern der Kriterien können sich ändern: Prüfen Sie den endgültigen Text, bevor Sie Nachweise den neuen Nummern zuordnen.

Wenn Sie bereits eine SOC-2-Plattform nutzen, behalten Sie sie. Die Frage ist, was die SBOM hinter ihren Prüfungen zeigt: SBOM-Prüfungen für SOC 2 im Vergleich.

NIS2

Die NIS-2-Richtlinie (EU) 2022/2555 gilt für wesentliche und wichtige Einrichtungen in den Sektoren, die sie aufführt. Wenn Sie dies als Software- oder Gerätelieferant lesen, fallen Sie meist nicht selbst darunter. Ihr Kunde schon, und seine Pflichten erreichen Sie als Fragen. Artikel 21 legt die Risikomanagementmaßnahmen im Bereich der Cybersicherheit fest, und drei Stellen erzeugen die meisten dieser Fragen:

• Artikel 21 Absatz 2 Buchstabe d: „Sicherheit der Lieferkette einschließlich sicherheitsbezogener Aspekte der Beziehungen zwischen den einzelnen Einrichtungen und ihren unmittelbaren Anbietern oder Diensteanbietern“.
• Artikel 21 Absatz 2 Buchstabe e: „Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen, einschließlich Management und Offenlegung von Schwachstellen“.
• Artikel 21 Absatz 3: Die Einrichtungen berücksichtigen „die spezifischen Schwachstellen der einzelnen unmittelbaren Anbieter und Diensteanbieter sowie die Gesamtqualität der Produkte und der Cybersicherheitspraxis ihrer Anbieter und Diensteanbieter, einschließlich der Sicherheit ihrer Entwicklungsprozesse“. Aus diesem Satz wird der Fragebogen auf Ihrem Schreibtisch.

Durchführungsverordnung (EU) 2024/2690

Die Durchführungsverordnung (EU) 2024/2690 der Kommission vom 17. Oktober 2024 legt die technischen und methodischen Anforderungen an die Maßnahmen nach Artikel 21 Absatz 2 fest, und zwar für DNS-Diensteanbieter, TLD-Namenregister, Anbieter von Cloud-Computing-Diensten, Anbieter von Rechenzentrumsdiensten, Betreiber von Inhaltszustellnetzen, Anbieter verwalteter Dienste, Anbieter verwalteter Sicherheitsdienste, Online-Marktplätze, Online-Suchmaschinen, Plattformen für Dienste sozialer Netzwerke und Vertrauensdiensteanbieter. Die übrigen NIS2-Sektoren bindet sie nicht, aber sie ist die ausführlichste öffentliche Beschreibung dessen, was „Sicherheit der Lieferkette“ bedeutet, und andere Käufer übernehmen daraus. Die Punkte, die Lieferanten erreichen:

Punkt im Anhang	Was er sagt	Was ein Lieferant gefragt wird
5.1.2(a)	Bei der Auswahl von Lieferanten wird berücksichtigt: „die Cybersicherheitsverfahren der Anbieter und Diensteanbieter, einschließlich der Sicherheit ihrer Entwicklungsprozesse“	Wie entwickeln Sie sicher, und woher wissen Sie, was in Ihr Produkt einfließt?
5.1.4(e) und (f)	Verträge legen gegebenenfalls das Recht auf Prüfung oder auf Erhalt von Prüfberichten fest sowie „eine Verpflichtung der Anbieter und Diensteanbieter zur Behebung von Schwachstellen, die ein Risiko“ für die Einrichtung darstellen	Behandeln Sie Schwachstellen in dem, was Sie liefern, und können wir die Nachweise sehen?
5.2	Ein Verzeichnis der direkten Anbieter, mit „eine[r] Liste der IKT-Produkte, -Dienste und -Prozesse“, die jeder von ihnen bereitstellt	Welche Produkte und Versionen liefern Sie uns?
6.1.2(c)	Für den Erwerb von IKT-Diensten oder IKT-Produkten: „Informationen zur Beschreibung der Hardware- und Softwarekomponenten, die in den IKT-Diensten oder -Produkten verwendet werden“	Welche Hardware- und Softwarekomponenten enthält Ihr Produkt? So nah wie hier kommt kein Text auf dieser Seite einer SBOM, und doch nennt auch er keine.
6.10	Umgang mit Schwachstellen: Informationen über Schwachstellen über Kanäle wie Mitteilungen von CSIRTs oder „von Anbietern oder Diensteanbietern bereitgestellte Informationen“ überwachen (6.10.2(a)), und wenn eine Schwachstelle keine Abhilfe erfordert, „dokumentieren und begründen die betreffenden Einrichtungen, warum die Schwachstelle keine Abhilfemaßnahmen erfordert“ (6.10.3)	Wie informieren Sie uns über Schwachstellen, und warum ist diese hier kein Problem?

Der letzte Punkt beschreibt eine Nicht-betroffen-Aussage mit Begründung. Genau das enthält ein VEX-Dokument, auch wenn die Verordnung kein Format nennt.

Beispiel aus der Praxis: ein Fragebogen von einem NIS2-Kunden

Fünf Fragen der Art, die ein Kunde aus diesen Punkten ableitet, mit dem Nachweis, den ein Lieferant beilegen kann. Manche Antworten stammen aus Aufzeichnungen Ihrer Tools; andere sind Richtlinien, die Sie schreiben.

Frage	Beizulegender Nachweis	Aufzeichnung oder Richtlinie
„Führen Sie die Softwarekomponenten der Produktversion auf, die Sie uns liefern.“ (6.1.2(c))	Die SBOM dieser Version, in CycloneDX oder SPDX, mit Angabe ihrer Vollständigkeit	Aufzeichnung
„Beschreiben Sie Ihren Umgang mit Schwachstellen und die Fristen dafür.“ (5.1.4(f))	Ihr Verfahren für den Umgang mit Schwachstellen, mit Schweregraden und Zielzeiten	Richtlinie
„Welche der Versionen, die wir einsetzen, enthielten die verwundbare Bibliothek, und seit wann?“ (6.10)	Build-Historie, die jeden Build mit der Komponente zeigt, mit Datum	Aufzeichnung
„Warum betrifft uns diese CVE nicht?“ (6.10)	Eine Nicht-betroffen-Aussage mit Begründung, etwa „der verwundbare Code ist nicht vorhanden“	Aufzeichnung, gestützt auf Ihre Bewertung
„Wie können Forschende Schwachstellen in Ihren Produkten melden?“ (5.1.2(a))	Ihre Richtlinie zur koordinierten Offenlegung von Schwachstellen	Richtlinie

Eine Unterscheidung sollten Sie festhalten: Für Produkte mit digitalen Elementen, die in der EU verkauft werden, verlangt der Cyber Resilience Act eine SBOM. NIS2 tut das nicht.

DORA, wenn Sie an Finanzunternehmen verkaufen

Der Digital Operational Resilience Act, Verordnung (EU) 2022/2554, gilt für Finanzunternehmen, nicht direkt für ihre Lieferanten. Finanzunternehmen müssen ihre IKT-Assets und deren Abhängigkeiten ermitteln, dokumentieren und Inventare darüber führen (Artikel 8 Absätze 1, 4 und 6), das IKT-Drittparteienrisiko als Teil ihres IKT-Risikos steuern (Artikel 28 Absatz 1), ein Informationsregister zu allen Verträgen über IKT-Dienstleistungen führen (Artikel 28 Absatz 3) und Mindestbestimmungen in diese Verträge aufnehmen (Artikel 30). DORA nennt keine SBOMs. Für einen Softwarelieferanten einer Bank hilft eine Komponentenliste pro Release dem Kunden, Artikel 8 zu erfüllen.

Eine Nachweis-Übersicht für alle Frameworks

Die Zeilen sind Nachweise; jede Zelle nennt die Maßnahme, das Kriterium oder den Punkt, den der Nachweis stützt, oder „nicht direkt“.

Nachweis	ISO/IEC 27001:2022	SOC 2	NIS2 und 2024/2690	DORA
1. Eine SBOM pro Release, mit Angabe ihrer Vollständigkeit	5.9, 5.21, 8.8	CC7.1	Art. 21(2)(d); 6.1.2(c)	Art. 8 (das Inventar des Kunden)
2. Laufende Neubewertung gegen neue Advisories	8.8	CC7.1	Art. 21(2)(e); 6.10	Nicht direkt
3. Build-Historie: welche Releases eine Komponente enthielten und seit wann	8.8	CC7.1, CC8.1	6.10	Nicht direkt
4. Aufzeichnungen zu Triage und Weiterleitung	8.8	CC7.1	Art. 21(2)(e); 6.10	Nicht direkt
5. Nicht-betroffen-Aussagen mit Begründung	8.8	CC7.1	6.10	Nicht direkt
6. Policy-Gates, die einen Build blockieren	8.25, 8.29	CC8.1	Art. 21(2)(e)	Nicht direkt
7. SBOMs von Lieferanten, zusammen mit den eigenen überwacht	5.19, 5.21, 5.22	CC7.1	Art. 21(2)(d), 21(3); 5.2, 6.10	Art. 28(1)
8. Egress-Policy und Netzwerkaufzeichnungen des Builds	8.25	CC8.1	Art. 21(2)(d)	Nicht direkt

Was eine SBOM nicht beweist

• Ihre Zugriffskontrolle, Incident Response, Business Continuity, Personalsicherheit, Kryptografie oder physische Sicherheit.
• Dass irgendjemand etwas behoben hat. Das ist Ihr Prozess, mit seinen Aufzeichnungen.
• Dass Ihr eigener Code fehlerfrei ist. Dafür sind Code-Reviews, SAST und Tests der Nachweis.
• Was in Binärdateien steckt, die Sie ohne SBOM erhalten haben.
• Dass Sie zertifiziert sind. Eine SBOM ist kein Zertifikat, und ein Zertifikat Ihres Tool-Anbieters zertifiziert dessen eigenes Managementsystem, nicht Sie.

Wo CRACI passt

CRACI ersetzt Ihre GitHub-gehosteten Runner und zeichnet auf, was jeder Build geladen hat. Die SBOM stammt also aus dem Release-Build selbst, mit einem Vollständigkeitsstatus für jeden Job.

• Überwachte SBOMs werden laufend neu bewertet, sobald neue Schwachstellen veröffentlicht werden (Schwachstellenverfolgung).
• Die Build-Historie zeigt, welche Builds eine verwundbare Abhängigkeit enthielten, und damit den Zeitraum, in dem Sie gefährdet waren, innerhalb Ihrer Aufbewahrungsfrist. Deckt Ihr Audit einen längeren Zeitraum ab, exportieren Sie die SBOM jedes Release und bewahren Sie sie beim Release auf.
• Sicherheitsteams triagieren die gefundenen Schwachstellen und leiten sie an die Teams weiter, die für die Behebung zuständig sind, und CRACI unterstützt VEX, um festzuhalten, welche Produkte eine Schwachstelle nicht betrifft.
• Policy-Gates können einen Build bei Befunden blockieren, auch einen Build, der eine bestimmte CVE enthält.
• SBOMs von Drittanbietern lassen sich hinzufügen, sodass zugekaufte Komponenten zusammen mit Ihren eigenen Builds überwacht werden.
• SBOMs lassen sich als CycloneDX oder SPDX exportieren, und die API liefert SBOMs, Netzwerk-Traces und Provenienzdaten. Die Egress-Policy zeichnet auf und begrenzt, wohin sich jeder Build verbinden darf.

CRACI liefert Nachweise für diese Anforderungen. Es macht Sie weder ISO-27001- noch SOC-2-konform oder bereit für NIS2, und es ist keine Plattform zur Compliance-Automatisierung. CRACIs eigenes Zertifikat ist eine separate Tatsache: Das Informationssicherheits-Managementsystem der CRACI Corporation Oy für die Entwicklung und den Betrieb der CRACI-Plattform ist nach ISO/IEC 27001 zertifiziert, ausgestellt von Into Certification. Es deckt ab, wie CRACI seinen Dienst betreibt, nicht Ihre Organisation oder Ihre Produkte. Siehe Sicherheit bei CRACI und So funktioniert CRACI für die gesamte Plattform.

Wann CRACI nicht die Antwort ist

• Ihre Builds laufen nicht auf GitHub Actions. Das ist derzeit das einzige CI, das CRACI unterstützt; weitere CI-Systeme sind auf der Roadmap.
• Sie brauchen eine Plattform zur Compliance-Automatisierung für Richtlinien, Zugriffsüberprüfungen und den Ablauf mit dem Auditor. Behalten oder kaufen Sie eine; siehe SBOM-Prüfungen für SOC 2 im Vergleich.
• Ihre Nachweislücke ist vor allem organisatorisch: Richtlinien, Schulung, Incident Response.
• Ihr größtes Lieferantenrisiko sind Binärdateien, die Sie ohne SBOM erhalten. Das beantwortet eine Binäranalyse.

Sie beantworten die Anfrage eines Kunden? Siehe So beantworten Sie eine SBOM-Anfrage eines Kunden, den Leitfaden für Komponentenlieferanten und die Checkliste, die Ihr Kunde anwenden wird.

SBOMs als Compliance-Nachweis: häufig gestellte Fragen

Verlangt ISO 27001 eine SBOM?

Nein. ISO/IEC 27001:2022 nennt keine SBOMs. Die Maßnahmen 5.9 (Inventar), 5.21 (IKT-Lieferkette) und 8.8 (technische Schwachstellen) aus Anhang A verlangen Ergebnisse, die eine SBOM stützt, und die Organisation und ihr Auditor entscheiden, welcher Nachweis ausreicht.

Verlangt SOC 2 eine SBOM?

Nein. Die Trust Services Criteria beschreiben Ergebnisse und nennen keine SBOMs. Eine SBOM pro Release, neu bewertet gegen neue Advisories, ist ein Nachweis für CC7.1, und eine aufgezeichnete Build-Pipeline stützt CC8.1 zum Änderungsmanagement.

Verlangt NIS2 eine SBOM?

Nein. Artikel 21 Absatz 2 Buchstabe d verlangt Sicherheit der Lieferkette und Buchstabe e den Umgang mit Schwachstellen, ohne SBOMs zu nennen. Die Durchführungsverordnung (EU) 2024/2690, die bestimmte digitale Diensteanbieter betrifft, verlangt in Punkt 6.1.2(c) Informationen zu den Hardware- und Softwarekomponenten von IKT-Produkten, auch dort ohne das Wort SBOM.

Welche Maßnahmen aus Anhang A von ISO 27001 stützt eine SBOM?

Vor allem 5.9 (Inventar der Informationen und anderen damit verbundenen Werte), 5.19 bis 5.22 (Lieferanten und die IKT-Lieferkette) und 8.8 (Handhabung von technischen Schwachstellen). Eine Build-Aufzeichnung berührt 8.25, 8.29 und 8.30 teilweise. 8.26 bis 8.28 betreffen Anforderungen, Design und Code, außerhalb einer SBOM.

Was verlangen NIS2-Kunden von ihren Softwarelieferanten?

Meist eine Beschreibung der sicheren Entwicklung, die Komponenten der gelieferten Version, eine Zusage, Schwachstellen zu behandeln, einen Weg, Schwachstelleninformationen zu erhalten, und Begründungen, wenn eine Schwachstelle nicht zutrifft. Diese Fragen stammen aus Artikel 21 Absatz 3 und, für einige Sektoren, aus den Lieferantenpunkten der Durchführungsverordnung 2024/2690.

Ist eine SBOM ein ausreichender Nachweis für die ISO-27001-Maßnahme 8.8?

Nein. Sie zeigt, was jedes Release enthält. Maßnahme 8.8 braucht außerdem Nachweise, dass Sie Informationen über Schwachstellen beschaffen, Ihre Gefährdung bewerten und handeln. Kombinieren Sie die SBOM mit laufender Neubewertung, einer Aufzeichnung der betroffenen Releases und den Entscheidungen, die Sie getroffen haben.

Was ist der Unterschied zwischen Compliance und einem Nachweis?

Compliance heißt, dass Ihre Prozesse die Anforderungen des Frameworks erfüllen, beurteilt von einem Auditor oder einem Kunden. Ein Nachweis zeigt, dass diese Prozesse funktionieren. Eine SBOM ist ein Nachweis für einige Anforderungen. Sie macht Sie mit keinem Framework konform.