Jedes smarte Gerät enthält Firmware aus Open-Source-Paketen, SDKs von Chipherstellern und Tools, die während des Builds geladen werden. Einem Lieferkettenangriff reicht eines davon. CRACI führt Ihre Firmware-Builds aus, zeichnet jede Komponente auf, die hineinfließt, und verhindert, dass der Build etwas erreicht, das er nicht braucht.
Der meiste Code in einem vernetzten Gerät stammt von anderen: eine Embedded-Linux-Distribution, das Board Support Package des Chipherstellers, ein Netzwerk-Stack, einige hundert Open-Source-Bibliotheken und die Rust-Crates darunter. Dieselben Komponenten stecken in Produkten vieler Marken, und die Geräte bleiben jahrelang in Haushalten, oft noch lange, nachdem zuletzt jemand geprüft hat, was sie enthalten.
Damit ist eine schwache Komponente für Angreifer viel wert. Ein Fehler in einer gemeinsam genutzten Bibliothek oder einem SDK öffnet jedes Produkt, das sie enthält, und ein vergiftetes Release erreicht jeden Build, der es lädt. Diese Vorfälle zeigen das Muster.
Neunzehn Schwachstellen, bis CVSS 10,0, in einer kleinen TCP/IP-Bibliothek, die Gerätehersteller seit Jahren lizenziert hatten, oft unter anderem Namen. Sie steckte in Produkten vieler Anbieter, und viele von ihnen mussten erst herausfinden, ob sie sie überhaupt auslieferten.
Eine Komponente, von der Sie nicht wissen, dass Sie sie ausliefern, können Sie nicht patchen.
Fehler im SDK eines Chipherstellers erreichten etwa 200 Gerätemodelle von rund 65 Herstellern: Router, IP-Kameras, Gateways für smarte Beleuchtung, vernetztes Spielzeug. Zwei Tage nach Veröffentlichung der Details suchte ein Mirai-Botnet bereits danach.
Der Code des Chipherstellers ist Ihr Code, sobald er in Ihrem Gerät ausgeliefert wird.
Eine Hintertür wurde im Upstream-Projekt xz selbst platziert, in den Versionen 5.6.0 und 5.6.1. Embedded-Linux-Images ziehen Kompressionsbibliotheken wie xz ganz selbstverständlich mit ein, meist ohne dass jemand sie ausgewählt hätte.
Vertrauenswürdiges Open Source kann mit einem einzigen Release feindlich werden.
Angreifer nutzten die eigenen Signaturzertifikate von ASUS, um eine Version des Update-Tools mit Hintertür zu signieren, und verteilten sie über die offiziellen Update-Server. Kaspersky schätzte, dass sie mehr als eine Million Nutzer erreicht haben könnte.
Eine gültige Signatur beweist nur, wer signiert hat, nicht, was hineingeflossen ist.
Gerätehärtung wie Secure Boot, keine Standardpasswörter und ein geschlossener Debug-Port schützt das Gerät, das Sie ausliefern. Die folgenden Schritte schützen, was hineinfließt.
CRACI deckt die Build-Seite dieser Liste ab: die SBOM jedes Builds, Lieferanten-SBOMs, kontinuierliche Überwachung, Build-Isolation, Egress-Kontrolle und Policy-Gates. Signierung und Gerätehärtung bleiben bei Ihren eigenen Tools.
Führen Sie Ihre Yocto- und anderen Embedded-Linux-Builds auf den GitHub-Actions-Runnern von CRACI aus, mit bis zu 32 vCPUs, auf x86-64 oder nativem ARM64. Während der Build läuft, zeichnet CRACI jedes Paket und jede Datei auf, die er lädt, einschließlich Host-Paketen, Git-Quellen, GitHub Actions und Downloads, die in keinem Recipe und keinem Lockfile stehen. In einem core-image-sato-Build enthielt die SBOM von CRACI jede Komponente aus Yoctos eigener SBOM plus 88, die dort fehlten, mit einer Package-URL für jede der 653 Rust-Crate-Versionen, sodass alle auf Schwachstellen überwacht werden können.
Jeder Job läuft in seiner eigenen isolierten virtuellen Maschine unter einer Egress-Richtlinie, die vor dem Start des Jobs validiert wird und im Zweifel blockiert (fail closed). Mit einer Default-Deny-Richtlinie erreicht der Build Ihre Paketquellen und sonst nichts. Eine kompromittierte Abhängigkeit, die versucht, Ihr Signaturmaterial oder Ihre Tokens an den Host eines Angreifers zu senden, wird blockiert und löst eine Warnung aus, selbst wenn der Angriff neu ist und noch niemand ein Advisory dazu veröffentlicht hat.
Fügen Sie SBOMs Ihrer Chiphersteller und anderer Lieferanten hinzu, und die zugekauften Komponenten werden zusammen mit der Software überwacht, die Sie bauen. Wenn die nächste SDK-Schwachstelle auftaucht, steht der Code des Herstellers in derselben Aufzeichnung wie Ihrer.
CRACI bewertet überwachte SBOMs laufend neu, sobald neue Schwachstellen veröffentlicht werden. Die Build-Historie zeigt, welche Builds die verwundbare Abhängigkeit enthielten, direkt oder transitiv, und die Inventaransicht zeigt, welche Softwareversionen in welchen Produkten im Einsatz sind. Sicherheitsteams sichten jeden Befund und leiten ihn an das zuständige Team weiter, und ein Policy-Gate kann eine bestimmte CVE aus jedem späteren Build heraushalten.
Die CE-Kennzeichnung nach dem Cyber Resilience Act beruht auf technischer Dokumentation und einer Konformitätsbewertung. CRACI liefert die Lieferkettennachweise, die diese Dokumentation braucht: Build-SBOMs, exportiert als CycloneDX oder SPDX, Schwachstellenaufzeichnungen und die Build-Historie. Außerdem reicht CRACI die CRA-Schwachstellenmeldungen in Ihrem Namen ein. Die Konformitätsbewertung, die EU-Konformitätserklärung und die CE-Kennzeichnung bleiben bei Ihnen, dem Hersteller.
CRACI signiert weder Firmware noch SBOMs noch Provenienz, und es erkennt neue bösartige Pakete nicht anhand von Verhalten oder Reputation: Es kennzeichnet ein bösartiges Release, sobald ein Advisory mit CVE existiert, und verlässt sich bis dahin auf die Egress-Richtlinie. Es führt weder Ihre Konformitätsbewertung durch noch erstellt es Ihre Konformitätserklärung. Es führt heute GitHub-Actions-Jobs auf Linux-Runnern aus; GitLab CI, Jenkins sowie Windows- und macOS-Runner sind auf der Roadmap.
Häufige Fragen zur Sicherung vernetzter Geräte und ihrer Software-Lieferkette
Ein Angriff, der ein Gerät über etwas erreicht, worauf sich sein Hersteller verlässt, nicht über das Gerät selbst: eine verwundbare Open-Source-Bibliothek, das SDK eines Chipherstellers, ein vergiftetes Paket-Release, ein kompromittiertes Build-Tool oder einen gekaperten Update-Kanal. Weil dieselbe Komponente in vielen Produkten ausgeliefert wird, kann eine einzige Schwachstelle Millionen Geräte vieler Marken auf einmal erreichen.
Beginnen Sie mit dem, was Sie ausliefern: Führen Sie für jeden Firmware-Build eine SBOM, verfolgen Sie Lieferantenkomponenten und prüfen Sie ausgelieferte Versionen weiter, sobald neue Schwachstellen auftauchen. Schotten Sie den Build selbst ab, halten Sie bekannt schlechte Versionen mit Policy-Gates fern, schützen Sie Ihre Signaturschlüssel und etablieren Sie einen Prozess für Triage, Fixes und Offenlegung. Gerätehärtung wie Secure Boot und das Deaktivieren von Standardpasswörtern ist ebenfalls wichtig, hilft aber nicht, wenn die Firmware bereits eine verwundbare Komponente enthält.
Kennen Sie jede Komponente, die in das Image fließt, auch das, was der Build außerhalb Ihrer Recipes und Lockfiles lädt, und bewahren Sie diese Aufzeichnung pro Release auf. Bauen Sie in einer isolierten Umgebung, die nur die benötigten Quellen erreicht, damit eine bösartige Abhängigkeit Ihre Secrets nirgendwohin senden kann. Überwachen Sie die aufgezeichneten Komponenten und die SBOMs Ihrer Lieferanten auf neue Schwachstellen, solange die Geräte unterstützt werden.
Ja. Yocto- und BitBake-Builds laufen auf CRACI-Runnern, und CRACI zeichnet die SBOM des Jobs auf, während der Build läuft. Yoctos eigene SPDX-Ausgabe enthält weiterhin Recipe-Metadaten, die CRACI nicht aufzeichnet, etwa die angewendeten Patches und die CVEs, die ein Recipe als behoben markiert. Lassen Sie create-spdx also aktiviert, wenn Sie darauf angewiesen sind.
Ja, wenn Sie eine SBOM dafür haben. Sie können Hersteller-SBOMs zu CRACI hinzufügen, und diese Komponenten werden zusammen mit der Software überwacht, die Sie bauen. Alles, was Ihr Build während des Builds von einem Hersteller herunterlädt, wird ebenfalls in der SBOM des Jobs aufgezeichnet.
Nicht anhand von Verhalten oder Reputation. Ein bekanntes bösartiges Release mit veröffentlichter CVE, etwa die xz-Hintertür, wird wie jede andere Schwachstelle gekennzeichnet, und ein Policy-Gate kann Builds blockieren, die es enthalten. Gegen neue Angriffe schützt CRACI mit der Default-Deny-Egress-Richtlinie, die verhindert, dass der Build Hosts erreicht, die er nicht braucht.
Nein. CRACI signiert weder Firmware noch SBOMs noch Provenienz. Nutzen Sie für Releases und Updates weiterhin Ihren eigenen Signaturprozess und hardwaregestützte Schlüsselspeicher.
Der Cyber Resilience Act erfasst Produkte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden, und das schließt die meisten vernetzten Consumer-Geräte ein. Die Meldepflichten gelten ab dem 11. September 2026, die Verordnung gilt vollständig ab dem 11. Dezember 2027. CRACI automatisiert einen erheblichen Teil der Transparenz über die Lieferkette und der Nachweise, die der CRA-Prozess braucht; die Verordnung zu erfüllen bleibt Sache des Herstellers.
CRACI führt GitHub-Actions-Jobs auf Linux-Runnern aus, x86-64 und ARM64, von 1 bis 32 vCPUs. Weitere CI-Systeme wie GitLab CI und Jenkins sind auf der Roadmap, ebenso Windows- und macOS-Runner.
Buchen Sie eine Demo, und wir zeigen Ihnen jede Komponente, die Ihre Geräte-Builds laden, und welche davon verwundbar sind
Demo buchen