de
Startseite
Cyber Resilience Act

SBOM für Mobile Apps

SBOM für Mobile Apps erstellen: CRA-konform für Flutter, KMP & nativ

In 30 Minuten verstanden, in 2 Tagen umgesetzt – als automatischer Schritt in eurer CI, nicht als jährliches Ritual.

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.

Die 4 Ebenen, die eure SBOM abdecken muss

Was ist eine SBOM – und wozu dient sie wirklich?

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?"

„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.

Die 4 Abhängigkeitsebenen einer Mobile App – und warum Web-Anleitungen hier scheitern

Eine Mobile App hat nicht eine Abhängigkeitswelt, sondern bis zu vier gleichzeitig. Eure SBOM muss alle abdecken:

01

Framework-Ebene

pubspec.lock / Gradle

Bei Flutter die Pakete aus pubspec.lock inklusive transitiver Abhängigkeiten, bei Kotlin Multiplatform die Gradle-Dependencies der Shared-Module.

02

Native Android-Ebene

build.gradle

Gradle-Abhängigkeiten der Android-Shell – auch die, die Flutter-Plugins transitiv hereinziehen, ohne dass sie je in eurer pubspec standen.

03

Native iOS-Ebene

Podfile.lock / Package.swift

CocoaPods- bzw. Swift-Package-Manager-Abhängigkeiten – dieselbe Logik wie bei Android, aber eigenes Tooling und eigene Fallstricke.

04

Vendor-SDKs

kein Paketmanager

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.

Der häufigste Fehler: Eine SBOM nur aus der pubspec.yaml zu generieren. Damit fehlen transitive Pakete, beide nativen Ebenen und alle Vendor-SDKs – also ausgerechnet die Teile, in denen Schwachstellen am wahrscheinlichsten sitzen. Eine solche SBOM sieht konform aus und ist es nicht.

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" }
  ]
}

SBOM in der CI: unser Standard-Setup in 4 Schritten

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:

  • 1

    Erzeugung je Ökosystem

    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.

  • 2

    Automatisierung im Release

    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.

  • 3

    Auswertung als Frühwarnsystem

    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.

  • 4

    Ablage als technische Dokumentation

    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.

SBOM-Erzeugung als automatischer Schritt in der CI/CD-Pipeline einer Mobile App mit Auswertung in Dependency-Track

Festpreispaket: SBOM-Setup für eure App

Wir richten das einmal sauber ein – danach gehört das System euch und läuft automatisch mit jedem Release:

Inventur

Alle vier Abhängigkeitsebenen eurer App, inklusive der binären Vendor-SDKs eurer Chip- und Komponentenlieferanten.

CycloneDX-Generierung

Integriert in eure bestehende CI/CD-Pipeline – jede Release-Version kennt ab sofort ihre exakte Stückliste, automatisch.

Dependency-Track-Aufsetzung

Selbst gehostet oder in eurer Cloud, mit kontinuierlichem CVE-Abgleich und Alarmierung direkt an euer Team.

Doku & Übergabe-Session

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.

Häufige Fragen zur SBOM für Apps

Kurze Antworten zu Pflicht, Format, Tooling und Kosten – für den Einzelfall gilt wie immer: keine Rechtsberatung.

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.

James, Tech-Gründer und Entwickler bei fab App-Agentur Joanna, Tech-Gründerin und Entwicklerin bei fab App-Agentur

25+

Jahre Erfahrung

40+

Anwendungen

10+

Top-DACH-Firmen vertrauen

MVP

~6 Wochen

Buche eine 15-minütige Erstberatung – kostenlos & unverbindlich.

SBOM-Setup für eure App anfragen – zum Festpreis

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.