Supply Chain Security | SBOM

SBOM & Supply Chain
Security: Transparenz in der
Software-Lieferkette.

93 % aller Codebasen enthalten Open-Source-Komponenten. Supply-Chain-Angriffe wie SolarWinds und Log4Shell zeigen: Wer seine Abhängigkeiten nicht kennt, kann sie nicht schützen. Der CRA macht die Software Bill of Materials zur gesetzlichen Pflicht.

SBOM-Beratung vereinbaren Cyber Resilience Act (CRA)

Zuletzt aktualisiert: März 2026 · Von zertifizierten Experten geprüft

CRA-Pflicht

Art. 13

SBOM-Erstellung und -Aktualisierung

Formate

2 Standards

SPDX 2.3+ und CycloneDX 1.4+

Betroffene

7.000+

Hersteller digitaler Produkte in DE

Update-Pflicht

5 Jahre

Sicherheitsupdates nach Inverkehrbringen

der Codebasen enthalten Open Source
betraf 35% aller Java-Anwendungen: Log4Shell
CRA-Übergangsfrist für Meldepflichten
max. Patch-SLA bei CRITICAL-Schwachstellen

Grundlagen

Was ist eine Software Bill of Materials?

Eine Software Bill of Materials (SBOM) ist eine maschinenlesbare, strukturierte Liste aller Software-Komponenten, die in einem Produkt, einer Anwendung oder einem Dienst enthalten sind — vergleichbar mit dem Zutatenverzeichnis auf einem Lebensmittel oder der Stückliste in der Fertigungsindustrie.

Moderne Software besteht zu großen Teilen aus Open-Source-Komponenten und Bibliotheken von Drittanbietern. Laut Synopsys Open Source Security and Risk Analysis (OSSRA) enthalten 93 % aller kommerziellen Codebasen Open-Source-Komponenten. Ohne SBOM ist unklar, welche Komponenten in welchen Versionen vorhanden sind — und damit auch, welche bekannten Schwachstellen das Produkt enthält.

Der Cyber Resilience Act (Art. 13 Abs. 3) macht die SBOM zur rechtlichen Pflicht für alle Hersteller digitaler Produkte. Gleichzeitig fordern NIS-2 Lieferkettensicherheit und DORA Third-Party-ICT-Vetting — beides setzt SBOM-Transparenz voraus.

SBOM-Ökosystem auf einen Blick

CRA-Pflicht: Art. 13 Abs. 3 Verordnung (EU) 2024/2847
NIS-2-Bezug: §30 Abs. 2 Nr. 5 — Lieferkettensicherheit
BSI-Richtlinie: BSI TR-03183 — Cyber Resilience Requirements
Format SPDX: ISO/IEC 5962:2021 — Linux Foundation
Format CycloneDX: OWASP-Standard — Security-optimiert, VEX-Support
DORA-Bezug: Third-Party ICT Vetting — Art. 28-30 DORA

SPDX vs. CycloneDX — Kurzvergleich

SPDX ISO-Standard (5962:2021), breite Tool-Unterstützung, stark für Lizenz-Compliance

CycloneDX OWASP, natives VEX-Support, besser für Security-Workflows, aktive Weiterentwicklung

CRA · NIS-2 · BSI TR-03183

Die 8 Kernanforderungen für SBOM & Supply Chain Security

Effektives Supply-Chain-Security-Management umfasst weit mehr als die Erstellung einer SBOM. Die folgenden Anforderungen decken den gesamten Lebenszyklus von der SBOM-Erstellung bis zum kontinuierlichen Monitoring und der behördlichen Nachweisführung ab.

SBOM-Erstellung und -Pflege (CRA Art. 13)

Der Cyber Resilience Act (Art. 13 Abs. 3) verpflichtet alle Hersteller digitaler Produkte zur Erstellung und Pflege einer vollständigen Software Bill of Materials. Die SBOM muss alle Software-Komponenten erfassen — direkte und transitive Abhängigkeiten —, versioniert sein und mit jeder Produktversion aktualisiert werden. Sie muss Marktüberwachungsbehörden (in DE: BSI) auf Anfrage vorgelegt werden können.

Cyber Resilience Act

Komponentenidentifikation — direkt und transitiv

Eine rechtskonforme SBOM erfasst nicht nur direkte Abhängigkeiten (Pakete, die im Quellcode referenziert werden), sondern auch alle transitiven Abhängigkeiten (Abhängigkeiten von Abhängigkeiten). In modernen Softwareprojekten können transitive Abhängigkeiten 80-95 % aller Komponenten ausmachen. Identifikation erfolgt über CPE (Common Platform Enumeration), PURL (Package URL) oder interne Kennungen. Standardformate: SPDX (ISO/IEC 5962:2021) und CycloneDX (OWASP).

CVE-Monitoring und Vulnerability Feeds

Eine statische SBOM reicht nicht aus — sie muss kontinuierlich gegen aktuelle Schwachstellen-Datenbanken abgeglichen werden: NVD (National Vulnerability Database), OSV (Open Source Vulnerabilities), GitHub Advisory Database und BSI-eigene Quellen. Automatisierte CVE-Feeds ermöglichen eine sofortige Benachrichtigung, wenn bekannte Schwachstellen in SBOM-Komponenten veröffentlicht werden. Reaktionszeit bei CRITICAL-Schwachstellen (CVSS 9.0+): maximal 6 Monate laut BSI TR-03183.

Vulnerability-Management-Beratung

VEX — Vulnerability Exploitability Exchange

VEX-Dokumente ergänzen die SBOM um Kontextinformationen zur Ausnutzbarkeit bekannter Schwachstellen. Ein VEX-Statement kann für jede CVE erklären: "nicht betroffen" (z. B. der verwundbare Code-Pfad wird nicht aufgerufen), "betroffen und behoben", "unter Analyse" oder "in Bearbeitung". VEX reduziert falsch-positive Alarmmeldungen erheblich und ist ein zentrales Element effizienter Vulnerability-Management-Programme. CISA und ENISA empfehlen VEX als Ergänzung zur SBOM.

Supplier Risk Assessment

NIS-2 §30 Abs. 2 Nr. 5 verpflichtet betroffene Einrichtungen zur Überprüfung und Risikobewertung ihrer Lieferanten und Dienstleister. Im Software-Kontext bedeutet das: Bewertung der Sicherheitsreife aller wesentlichen Komponenten-Lieferanten (Open-Source-Projekte, kommerzielle Bibliotheken, externe Dienstleister), vertragliche Verpflichtung zu Vulnerability-Disclosure und Patch-Management sowie regelmäßige Neubewertung bei Änderungen der Lieferantensituation.

NIS-2 Lieferkettensicherheit

Patch-Management-Prozess

Ein strukturierter Patch-Management-Prozess definiert verbindliche SLAs für das Einspielen von Sicherheitsupdates: CRITICAL (CVSS 9.0-10.0) innerhalb von 24-72 Stunden, HIGH (CVSS 7.0-8.9) innerhalb von 30 Tagen, MEDIUM und LOW risikoorientiert. Der Prozess muss dokumentiert, nachvollziehbar und auditierbar sein. Für CRA-betroffene Hersteller gilt zusätzlich die Pflicht, Patches kostenlos und ohne Verzögerung für die gesamte Support-Laufzeit (min. 5 Jahre) bereitzustellen.

CI/CD-Integration der SBOM-Toolchain

SBOMs müssen automatisiert mit jedem Build-Prozess generiert und versioniert werden. CI/CD-Integration bedeutet: SBOM-Generierung im Build-Schritt (z. B. Syft, CycloneDX-CLI, SPDX-tools), automatischer CVE-Abgleich im Security-Gate (z. B. Grype, Trivy, OSS-Review-Toolkit), Artefakt-Signing (Cosign, Sigstore) für Integritätsnachweise und automatisierte VEX-Aktualisierung bei neuen CVE-Veröffentlichungen. Das Ergebnis: jeder Release enthält eine aktuelle, signierte SBOM.

DevSecOps-Beratung

Behördliche Bereitstellung auf Anfrage

Sowohl nach CRA Art. 13 als auch nach BSI TR-03183 muss die SBOM Marktüberwachungsbehörden auf Anfrage bereitgestellt werden. Die SBOM muss in einem maschinenlesbaren Standardformat (SPDX JSON, CycloneDX JSON/XML) vorliegen, vollständig und aktuell sein sowie die gesamte Komponentenhierarchie abbilden. Eine fehlende oder unvollständige SBOM bei behördlicher Anfrage kann als Verstoß gegen CRA-Pflichten gewertet und mit Bußgeldern sanktioniert werden.

Hinweis: Die SBOM-Pflicht nach CRA gilt für alle Hersteller, unabhängig von Produktkategorie und -klasse. Für NIS-2-betroffene Betreiber ergibt sich die Forderung nach SBOM-Transparenz mittelbar aus der Lieferketten-Pflicht — auch ohne direkte gesetzliche SBOM-Verpflichtung ist die Anforderung an Software-Lieferanten praktisch unvermeidbar.

Praxis

Reale Supply-Chain-Angriffe: Was wäre mit SBOM verhindert worden?

Die schwerwiegendsten Cyberangriffe der letzten Jahre hatten eines gemeinsam: Sie nutzten fehlende Transparenz über Software-Abhängigkeiten und Build-Prozesse aus. Eine SBOM-Pflicht hätte in jedem Fall die Erkennungszeit massiv verkürzt.

SolarWinds Orion — Dezember 2020

18.000 Organisationen betroffen, 8 Monate unentdeckt

Angreifer injizierten in den Build-Prozess von SolarWinds Orion schadhaften Code (SUNBURST-Backdoor), der mit einem legitimen Software-Update an 18.000 Kunden ausgeliefert wurde — darunter US-Bundesbehörden, Rüstungskonzerne und Fortune-500-Unternehmen. Der Angriff blieb 8 Monate unentdeckt. Eine SBOM mit Build-Integrität-Nachweisen und Artefakt-Signing hätte den kompromittierten Build frühzeitig identifizierbar gemacht.
Log4Shell (CVE-2021-44228) — Dezember 2021

CVSS 10.0 · 35% aller Java-Anwendungen betroffen

Die kritischste Schwachstelle des Jahrzehnts in der Java-Logging-Bibliothek Log4j betraf Millionen von Produkten weltweit. Das zentrale Problem: Hersteller wussten häufig nicht, dass Log4j als transitive Abhängigkeit in ihren Produkten vorhanden war. Unternehmen mit vollständigen SBOMs konnten betroffene Produkte in Stunden identifizieren — andere benötigten Wochen oder Monate. Log4Shell war der wichtigste Treiber für die CRA-SBOM-Pflicht.
Codecov CI/CD-Kompromittierung — April 2021

15.000 betroffene Kunden, CI/CD-Zugang kompromittiert

Angreifer kompromittierten das Build-Skript des Code-Coverage-Diensts Codecov und exfiltrierten über mehrere Monate Umgebungsvariablen, CI/CD-Credentials und Source-Code-Repositories von 15.000 Kunden. Der Angriff zeigt das Risiko von Software-in-der-Software: Ein externer Dienst, der in CI/CD-Pipelines integriert ist, wird zum Angriffspunkt. SBOM-Transparenz über alle Entwicklungswerkzeuge und CI/CD-Abhängigkeiten hätte das Risiko sichtbar gemacht.
Kaseya VSA Ransomware — Juli 2021

1.500 MSPs und 50.000 Endkunden · $70 Mio. Lösegeld

REvil nutzte Zero-Day-Schwachstellen in Kaseya VSA für einen Supply-Chain-Ransomware-Angriff, der über einen einzigen kompromittierten Software-Anbieter 1.500 Managed-Service-Provider und deren Endkunden traf. Die VSA-Schwachstellen hätten durch konsequentes Vulnerability Management und zeitnahe Patches behoben werden können. Unter dem CRA wären Hersteller wie Kaseya zur 24h-Meldung aktiv ausgenutzter Schwachstellen und zur zeitnahen Patch-Bereitstellung verpflichtet.
xz-utils Backdoor — März 2024

2 Jahre Trust-Aufbau · Insider-Angriff auf Open Source

Ein staatlich gesponserter Angreifer baute über zwei Jahre unter einer Pseudoidentität Vertrauen in das Open-Source-Projekt xz-utils auf, erlangte Maintainer-Rechte und injizierte eine Backdoor in Version 5.6.0/5.6.1 der weit verbreiteten Kompressionsbibliothek. Die Backdoor ermöglichte Remote Code Execution in SSH-Diensten. Der Angriff demonstriert das Risiko von Open-Source-Abhängigkeiten ohne Supplier-Risk-Assessment und unterstreicht die Notwendigkeit von SBOM-Provenance-Informationen.

Was diese Vorfälle gemeinsam haben

In jedem dieser Fälle war die Software-Lieferkette der Angriffspunkt — nicht die direkten Systeme der Betroffenen. Wer seine Abhängigkeiten nicht kennt, kann sie weder schützen noch schnell reagieren. Eine vollständige SBOM mit kontinuierlichem CVE-Monitoring hätte in jedem Szenario die Mean Time to Detect (MTTD) von Monaten auf Stunden reduziert.

Technologie

SBOM-Toolchain: Von der Generierung bis zum Monitoring

Eine produktionsreife SBOM-Toolchain umfasst vier Stufen: Generierung, Analyse, Management und Monitoring. Die folgenden Werkzeuge sind in der Praxis bewährt und haben sich als Industriestandard etabliert.

Stufe 1 — Generierung

Syft (Anchore)
Container-Images, Dateisysteme, polyglott — SPDX + CycloneDX Output
CycloneDX-CLI
OWASP-Referenz-Tool, ideal für CI/CD-Integration, alle Ökosysteme
Trivy (Aqua)
All-in-one: SBOM-Generierung + CVE-Scanning in einem Tool

Stufe 2 — CVE-Analyse

Grype (Anchore)
Schwachstellen-Scanner für SBOMs und Container, integriert NVD + OSV
OSS-Review-Toolkit
Eclipse/Linux Foundation, umfassend: SBOM, CVE, Lizenz-Compliance
OWASP Dep-Check
Etabliert für JVM/Maven/Gradle-Projekte, NVD-Integration

Stufe 3 — Management

OWASP Dependency-Track
Referenz-Plattform für kontinuierliches SBOM-Management, VEX-Support
SW360 (Eclipse)
Komponent-Katalog, Lizenz-Management, SBOM-Export, Enterprise-Ready
Renovate / Dependabot
Automatisiertes Dependency-Update-Management in CI/CD

Stufe 4 — Signing & Provenance

Sigstore / Cosign
Linux Foundation — Artefakt-Signing, SBOM-Integrität, Software-Provenance
SLSA Framework
Supply-chain Levels for Software Artifacts — Build-Provenance-Standard
in-toto
Supply-Chain-Attestierung — lückenlose Nachverfolgung jedes Build-Schritts

Beratungsleistungen

Wie AWARE7 bei SBOM & Supply Chain Security hilft

Wir begleiten Hersteller und Betreiber beim Aufbau einer vollständigen Supply-Chain-Security-Strategie — von der ersten SBOM bis zum kontinuierlichen Vulnerability-Management-Programm.

SBOM-Toolchain-Einführung

Tool-Auswahl (Syft, CycloneDX, Trivy), CI/CD-Integration, Format-Standardisierung, Artefakt-Signing — von der Pilotinstallation bis zum produktiven Betrieb.

Toolchain-Beratung

Vulnerability Management & CVE-Monitoring

Aufbau von Patch-SLA-Prozessen, OWASP Dependency-Track Einführung, VEX-Programm und kontinuierliches Monitoring gegen NVD, OSV und BSI-Quellen.

Vulnerability Management

Supply-Chain-Penetrationstest

Gezielte Tests auf Supply-Chain-Angriffsvektoren: CI/CD-Pipeline-Security, Build-Prozess-Integrität, Dependency-Confusion-Attacks, Insider-Threat-Simulation.

Pentest anfragen

CRA-konforme SBOM & technische Dokumentation

Erstellung und Prüfung CRA-konformer SBOMs nach Art. 13 — in den Formaten SPDX und CycloneDX, inklusive VEX-Statements und Vorbereitung für BSI-Anfragen.

CRA-Compliance

Lieferkettensicherheit nach NIS-2 §30

NIS-2-konforme Lieferantenbewertung, Supplier-Risk-Assessment-Prozesse, Vertragsklauseln für IT-Lieferanten und Monitoring-Programme für wesentliche Drittanbieter.

NIS-2 Lieferkette

SBOM-Schulung & Awareness

Schulungen für Entwicklungsteams und Führungsebene: SBOM-Konzepte, Tool-Einführung, Supply-Chain-Risikobewusstsein und regulatorische Anforderungen (CRA, NIS-2, DORA).

Schulung anfragen

„Software Bill of Materials ist kein technisches Nischenthema — es ist die Grundlage moderner Produktverantwortung. Wer nicht weiß, was in seiner Software steckt, kann bei Log4Shell in Wochen statt Stunden reagieren. Der CRA macht das zur Rechtspflicht. Wir helfen Ihnen, den Vorsprung jetzt aufzubauen.“

Chris Wojzechowski

Prüfer mit §8a BSIG Prüfverfahrenskompetenz · AWARE7 GmbH

FAQ

Häufige Fragen zu SBOM & Supply Chain Security

Die wichtigsten Fragen zu Software Bill of Materials, Vulnerability Management und Supply Chain Security — fachlich fundiert beantwortet.

Was ist ein SBOM (Software Bill of Materials)?

Eine Software Bill of Materials (SBOM) ist eine maschinenlesbare, strukturierte Liste aller Software-Komponenten, die in einem Produkt oder einer Anwendung enthalten sind — vergleichbar mit einem Zutatenverzeichnis für Software. Sie enthält für jede Komponente: Name, Version, Lizenz, Herkunft (Hersteller oder Open-Source-Projekt), Abhängigkeitsbeziehungen und ggf. bekannte Schwachstellen (CVE-Referenzen). Die SBOM bildet die Grundlage für Vulnerability Management, Lizenz-Compliance und Supply-Chain-Sicherheit.

Welche SBOM-Formate sind nach CRA anerkannt?

Der Cyber Resilience Act schreibt kein spezifisches Format vor, aber in der Praxis haben sich zwei Standards etabliert: SPDX (Software Package Data Exchange), ein ISO/IEC-Standard (ISO/IEC 5962:2021), ursprünglich von der Linux Foundation entwickelt, und CycloneDX, ein OWASP-Projekt, das besonders auf Security-Anwendungsfälle optimiert ist und VEX-Integration unterstützt. Beide Formate sind in JSON, XML und anderen Serialisierungen verfügbar. Die ENISA und das BSI empfehlen beide Formate als akzeptable Umsetzung. CycloneDX wird häufig bevorzugt, da es nativ Schwachstelleninformationen und VEX-Statements unterstützt.

Wer muss eine SBOM erstellen?

Nach dem Cyber Resilience Act (Art. 13) sind alle Hersteller von Produkten mit digitalen Elementen zur SBOM-Erstellung verpflichtet — das umfasst sowohl Hardware-Produkte mit Firmware/Software als auch reine Software-Produkte, die eigenständig am Markt platziert werden. Importeure rücken in die Herstellerposition, wenn der Hersteller außerhalb der EU sitzt. Für NIS-2-betroffene Betreiber ist die SBOM eine wichtige Grundlage für die Lieferkettensicherheit nach §30 Abs. 2 Nr. 5 — ohne eigene gesetzliche SBOM-Pflicht ist die Forderung an Lieferanten praktisch unumgänglich.

Was ist der Unterschied zwischen direkten und transitiven Abhängigkeiten?

Direkte Abhängigkeiten sind Komponenten, die explizit im Quellcode oder in Paketmanifesten referenziert werden (z. B. package.json, pom.xml, requirements.txt). Transitive Abhängigkeiten sind Abhängigkeiten von Abhängigkeiten — also Pakete, die von direkten Abhängigkeiten benötigt werden, ohne selbst im eigenen Code referenziert zu sein. In modernen Anwendungen machen transitive Abhängigkeiten 80-95 % aller enthaltenen Pakete aus. Log4Shell war ein klassisches transitives Abhängigkeitsproblem: Viele Produkte enthielten Log4j nicht direkt, sondern über mehrere Ebenen von Abhängigkeiten.

Was ist VEX und wozu dient es?

VEX (Vulnerability Exploitability Exchange) ist ein Dokumentenformat, das SBOMs um Kontextinformationen zur Ausnutzbarkeit bekannter Schwachstellen ergänzt. Für jede CVE, die in einer SBOM-Komponente bekannt ist, kann ein VEX-Statement angeben: "not_affected" (die vulnerable Code-Stelle wird nicht ausgeführt), "affected" (betroffen und Handlungsbedarf besteht), "fixed" (behoben in Version X) oder "under_investigation". VEX reduziert das Problem massiver Falsch-Positive erheblich: Eine Anwendung kann eine Komponente mit 50 bekannten CVEs enthalten, von denen nur 3 tatsächlich im konkreten Nutzungskontext ausnutzbar sind. VEX macht diese Aussagen formal und maschinenlesbar.

Wie wird eine SBOM in CI/CD-Pipelines integriert?

Die SBOM-Generierung sollte vollständig automatisiert als Teil des Build-Prozesses erfolgen. Typische Tools: Syft (Anchore) für Container-Images und Dateisystem-SBOMs, CycloneDX-CLI für polyglotte Projekte, Trivy für kombinierte SBOM-Generierung und CVE-Scanning. Im CI/CD-Ablauf: (1) Build-Schritt generiert SBOM, (2) Security-Gate vergleicht SBOM gegen CVE-Datenbanken und prüft Policy-Regeln (z. B. keine CRITICAL-CVEs ohne VEX-Freigabe), (3) SBOM wird als Build-Artefakt signiert (Cosign/Sigstore), (4) SBOM und VEX werden mit dem Release versioniert und archiviert. Ergebnis: jeder Release enthält eine nachweisbare, integritätsgesicherte SBOM.

Welche Patch-SLAs gelten für SBOM-identifizierte Schwachstellen?

Die BSI TR-03183 (Cyber Resilience Requirements for Manufacturers and Products) definiert Empfehlungen für Patch-Response-Zeiten: CRITICAL (CVSS 9.0-10.0): innerhalb von 24-72 Stunden, zumindest jedoch innerhalb von 6 Monaten für reguläre Patches. HIGH (CVSS 7.0-8.9): innerhalb von 30 Tagen. MEDIUM und LOW: risikoorientiert, in der Regel 90-180 Tage. Der CRA verpflichtet Hersteller zusätzlich zur kostenlosen und zeitnahen Bereitstellung von Sicherheitsupdates über mindestens 5 Jahre. Aktivierte Schwachstellen müssen innerhalb von 24 Stunden dem BSI gemeldet werden (ab September 2026).

Wie hängen SBOM und NIS-2 Lieferkettensicherheit zusammen?

NIS-2 §30 Abs. 2 Nr. 5 (Art. 21 Abs. 2 lit. d NIS-2-RL) verpflichtet betroffene Einrichtungen zur Absicherung der Lieferkette. Für Software-intensive Organisationen bedeutet das: Bewertung der Sicherheitsreife aller Software-Lieferanten, Anforderung von SBOMs von wesentlichen Lieferanten, Überprüfung auf bekannte Schwachstellen (CVE-Scanning) und Monitoring der SBOM-Lieferanten auf neue Schwachstellen. Organisationen, die selbst Produkte herstellen, müssen zusätzlich CRA-SBOM-Pflichten erfüllen. NIS-2 und CRA schaffen gemeinsam einen vollständigen SBOM-Kreislauf in der Lieferkette.

Was kostet die SBOM-Einführung?

Der Aufwand für die SBOM-Einführung hängt von der Anzahl der Produkte, der Technologie-Vielfalt und dem aktuellen Reifegrad der CI/CD-Prozesse ab. Für ein einzelnes Produkt mit etablierter CI/CD-Pipeline ist eine initiale SBOM-Toolchain-Integration in 2-4 Wochen (15.000-40.000 EUR) realisierbar. Die laufenden Kosten umfassen: CVE-Monitoring-Tools (Grype, Trivy, kommerziell: Dependency-Track), VEX-Pflege und den Prozessaufwand für Schwachstellenbewertung und Patch-Management. Unternehmen, die frühzeitig starten, haben einen erheblichen Vorteil gegenüber denen, die kurz vor der CRA-Frist handeln müssen.

Welche Open-Source-Tools gibt es für SBOM-Management?

Etablierte Open-Source-Tools für das SBOM-Ökosystem: SBOM-Generierung: Syft (Anchore), CycloneDX-CLI, SPDX-tools, Trivy. CVE-Scanning: Grype (Anchore), Trivy, OSS-Review-Toolkit (ORT), OWASP Dependency-Check. SBOM-Management und VEX: OWASP Dependency-Track (die Referenzimplementierung für continuous SBOM-Management), SW360 (Eclipse Foundation). Artefakt-Signing: Sigstore/Cosign (Linux Foundation), Notary v2. Das SBOM-Tooling-Ökosystem wächst schnell — AWARE7 berät zu Tool-Auswahl und Integration auf Basis Ihrer spezifischen Technologie-Stack und Compliance-Anforderungen.

Aus dem Blog

Alle Artikel

Offensive Security

SBOM-Strategie gemeinsam entwickeln

In einem kostenlosen 30-minütigen Gespräch analysieren wir Ihren aktuellen SBOM-Reifegrad, prüfen Ihre Regulierungsanforderungen (CRA, NIS-2, DORA) und entwickeln einen konkreten Fahrplan für eine produktionsreife Supply-Chain-Security-Strategie.

Jetzt SBOM-Beratung vereinbaren Mehr zum Cyber Resilience Act

Kostenlos · 30 Minuten · Unverbindlich