Der Cyber Resilience Act verlangt von Herstellern eine Software Bill of Materials (SBOM): ein maschinenlesbares Verzeichnis der Software-Komponenten eures Produkts – mindestens der obersten Abhängigkeitsebene. Pflicht wird sie mit der vollen Geltung des CRA am 11.12.2027, gebraucht wird sie früher: Die Meldepflichten ab dem 11.09.2026 setzen voraus, dass ihr in Stunden wisst, ob eine CVE eure App betrifft. Für Mobile Apps gut machbar – mit Eigenheiten, über die Standard-Anleitungen aus der Web-Welt stolpern: vier Abhängigkeitsebenen statt einer, binäre Vendor-SDKs und zwei native Welten.
Eine SBOM (Software Bill of Materials) ist die Stückliste eurer Software: jede Bibliothek, jedes SDK, jede Version – maschinenlesbar in CycloneDX oder SPDX, vom Cyber Resilience Act als Teil des Schwachstellenmanagements vorgeschrieben. Ihr wirklicher Wert zeigt sich aber erst im Ernstfall:
Morgen früh wird eine kritische CVE in einer verbreiteten Bluetooth-Bibliothek veröffentlicht. Die einzige Frage, die dann zählt: „Betrifft uns das?"
Ohne SBOM
Mit gepflegter SBOM
„Betrifft uns das?"
Tage
Code-Archäologie über vier Abhängigkeitsebenen
Sekunden
Ein Blick in die Stückliste des Releases
Betroffene Versionen
Handarbeit
Lockfiles, native Ebenen, SDK-Lieferant
Sofort identifiziert
SBOM je Release, Abgleich in Dependency-Track
24-h-Meldung
Nicht belastbar
Die Frist verstreicht beim Suchen
Machbar
Impact-Analyse läuft, Nachweis liegt vor
Genau diese Antwortfähigkeit setzen die Meldepflichten ab September 2026 voraus – ohne SBOM keine Impact-Analyse in Stunden, ohne Impact-Analyse keine belastbare Meldung.
Eine Mobile App hat nicht eine Abhängigkeitswelt, sondern bis zu vier gleichzeitig. Eure SBOM muss alle abdecken:
01
Bei Flutter die Pakete aus pubspec.lock inklusive transitiver Abhängigkeiten, bei Kotlin Multiplatform die Gradle-Dependencies der Shared-Module.
02
Gradle-Abhängigkeiten der Android-Shell – auch die, die Flutter-Plugins transitiv hereinziehen, ohne dass sie je in eurer pubspec standen.
03
CocoaPods- bzw. Swift-Package-Manager-Abhängigkeiten – dieselbe Logik wie bei Android, aber eigenes Tooling und eigene Fallstricke.
04
Binäre SDKs eurer Chip- und Komponentenlieferanten (Nordic, Espressif & Co. für BLE/DFU) sowie Payment-, Analytics- und Push-SDKs – sicherheitstechnisch oft die relevantesten Komponenten.
So sieht es richtig aus – ein Vendor-SDK, das kein Paketmanager kennt, manuell als CycloneDX-Komponente erfasst:
{
"type": "library",
"name": "nordic-dfu-sdk",
"version": "2.5.1",
"supplier": { "name": "Nordic Semiconductor" },
"purl": "pkg:generic/nordic-dfu-sdk@2.5.1",
"properties": [
{ "name": "integration", "value": "binary / platform channel" }
]
} Eine SBOM, die jemand „einmal im Jahr macht", ist beim ersten Release danach wertlos. Deshalb bauen wir sie als automatischen Pipeline-Schritt – einmal eingerichtet, läuft sie mit jedem Release mit:
CycloneDX-Generatoren für Dart/Flutter, Gradle und CocoaPods/SPM erfassen alle Paketmanager-Ebenen inklusive transitiver Abhängigkeiten. Vendor-SDKs pflegen wir als kuratierte Komponentenliste, die ins Merge einfließt – so ist auch das binäre BLE-SDK eures Chip-Lieferanten dokumentiert.
Die Teil-SBOMs werden zu einer Gesamt-SBOM pro App-Release zusammengeführt – als versioniertes Build-Artefakt in eurer CI/CD (GitHub Actions, GitLab CI, Bitrise, Codemagic – was ihr habt). Jeder Release kennt seine exakte Stückliste.
Import in Dependency-Track, das eure SBOMs kontinuierlich gegen CVE-Datenbanken abgleicht und euer Team alarmiert. Damit wird aus der Stückliste ein Frühwarnsystem – die Grundlage eurer Meldefähigkeit.
Die SBOM liegt versioniert neben dem Release – als Teil eurer technischen Dokumentation nach CRA, vorlegbar gegenüber der Marktüberwachung und zunehmend auch gefragt in B2B-Ausschreibungen.
Wir richten das einmal sauber ein – danach gehört das System euch und läuft automatisch mit jedem Release:
Alle vier Abhängigkeitsebenen eurer App, inklusive der binären Vendor-SDKs eurer Chip- und Komponentenlieferanten.
Integriert in eure bestehende CI/CD-Pipeline – jede Release-Version kennt ab sofort ihre exakte Stückliste, automatisch.
Selbst gehostet oder in eurer Cloud, mit kontinuierlichem CVE-Abgleich und Alarmierung direkt an euer Team.
Damit euer Team das System versteht und besitzt – keine Abhängigkeit von uns.
Typischer Umfang: 2 Tage für eine App mit einer CI-Pipeline. Den Festpreis nennen wir nach einem kurzen Blick in euer Repository.
Lieber erst der Gesamtüberblick? Die SBOM ist einer von mehreren CRA-Bausteinen. Wenn ihr wissen wollt, wo eure App insgesamt steht – Update-Fähigkeit, Meldeprozesse, Anhang-I-Anforderungen –, ist der Readiness-Check der bessere Einstieg. Die SBOM ist darin als Prüfpunkt enthalten.
Könntet ihr heute in einer Stunde sagen, ob die nächste kritische CVE eure App betrifft?
Sprich direkt mit James & Joanna – ohne Vertrieb, ohne Umwege.
25+
Jahre Erfahrung
40+
Anwendungen
10+
Top-DACH-Firmen vertrauen
MVP
~6 Wochen
Buche eine 15-minütige Erstberatung – kostenlos & unverbindlich.
Schilder uns kurz eure App und euren Stack – zwei, drei Sätze reichen. Du bekommst werktags innerhalb von 24 Stunden eine ehrliche Ersteinschätzung: welche Abhängigkeitsebenen eure SBOM abdecken muss und was das Setup bei euch kostet. Unverbindlich, in klarer Sprache, ohne Verkaufsdruck.
Deine Daten werden ausschließlich zur Kontaktaufnahme verwendet. Keine Weitergabe an Dritte.