Varje smart enhet levereras med firmware byggd av open source-paket, SDK:er från chipleverantörer och verktyg som hämtas under bygget. En attack mot leveranskedjan behöver bara en av dem. CRACI kör dina firmwarebyggen, registrerar varje komponent som går in och hindrar bygget från att nå något det inte behöver.
Det mesta av koden i en uppkopplad enhet har skrivits av någon annan: en inbyggd Linux-distribution, board support package från chipleverantören, en nätverksstack, några hundra open source-bibliotek och Rust-crates under dem. Samma komponenter levereras i produkter från många varumärken, och enheterna stannar i hemmen i åratal, ofta långt efter att någon senast tittade på vad de innehåller.
Det gör en enda svag komponent mycket värd för en angripare. En brist i ett delat bibliotek eller SDK öppnar varje produkt som levereras med det, och en förgiftad release når varje bygge som hämtar den. De här incidenterna visar mönstret.
Nitton sårbarheter, upp till CVSS 10.0, i ett litet TCP/IP-bibliotek som enhetstillverkare hade licensierat i åratal, ofta under ett annat namn. Det fanns i produkter från många leverantörer, och många av dem måste först ta reda på om de över huvud taget levererade det.
Du kan inte patcha en komponent som du inte vet att du levererar.
Brister i en chipleverantörs SDK nådde omkring 200 enhetsmodeller från cirka 65 tillverkare: routrar, IP-kameror, gateways för smart belysning och uppkopplade leksaker. Ett Mirai-botnät skannade efter dem två dagar efter att detaljerna blev offentliga.
Chipleverantörens kod är din kod så snart den levereras i din enhet.
En bakdörr planterades i själva uppströmsprojektet xz, i versionerna 5.6.0 och 5.6.1. Inbyggda Linux-avbilder drar in komprimeringsbibliotek som xz som en självklarhet, oftast utan att någon har valt dem.
Betrodd öppen källkod kan bli fientlig i en enda release.
Angripare använde ASUS egna signeringscertifikat för att signera en version av företagets uppdateringsverktyg med en bakdörr och levererade den från de officiella uppdateringsservrarna. Kaspersky uppskattade att den kan ha nått mer än en miljon användare.
En giltig signatur bevisar bara vem som signerade, inte vad som ingick.
Härdning av enheten, som secure boot, inga standardlösenord och en stängd felsökningsport, skyddar enheten du levererar. Stegen nedan skyddar det som går in i den.
CRACI täcker byggsidan av den här listan: SBOM:en för varje bygge, leverantörers SBOM:er, löpande bevakning, byggisolering, kontroll av egress och policykontroller. Signering och härdning av enheten ligger kvar hos dina egna verktyg.
Kör dina Yocto-byggen och andra inbyggda Linux-byggen på CRACI:s GitHub Actions-runners, upp till 32 vCPU:er, på x86-64 eller nativ ARM64. Medan bygget körs registrerar CRACI varje paket och varje fil det hämtar, inklusive värdpaket, Git-källor, GitHub Actions och nedladdningar som inget recept eller ingen lockfile listar. I ett core-image-sato-bygge hade CRACI:s SBOM alla komponenter i Yoctos egen SBOM plus 88 som Yoctos missade, med en paket-URL för var och en av de 653 versionerna av Rust-crates, så att alla kan bevakas mot sårbarheter.
Varje jobb körs i sin egen isolerade virtuella maskin under en egress-policy som valideras innan jobbet startar och blockerar vid fel. Med en policy som nekar som standard når bygget dina paketkällor och inget annat. Ett komprometterat beroende som försöker skicka ditt signeringsmaterial eller dina tokens till en angripares värd blockeras och utlöser en varning, även när attacken är ny och ingen ännu har publicerat något säkerhetsmeddelande om den.
Lägg till SBOM:er från dina chipleverantörer och andra leverantörer, så bevakas de inköpta komponenterna tillsammans med programvaran du bygger. När nästa SDK-sårbarhet dyker upp finns leverantörens kod i samma registrering som din.
CRACI fortsätter att omvärdera bevakade SBOM:er när nya sårbarheter publiceras. Bygghistoriken visar vilka byggen som innehöll det sårbara beroendet, direkt eller transitivt, och inventeringsvyn visar vilka programvaruversioner som är driftsatta i vilka produkter. Säkerhetsteam triagerar varje fynd och skickar det till teamet som äger åtgärden, och en policykontroll kan hålla en specifik CVE borta från alla senare byggen.
CE-märkning enligt Cyber Resilience Act vilar på teknisk dokumentation och en bedömning av överensstämmelse. CRACI tillhandahåller det underlag om leveranskedjan som dokumentationen behöver: SBOM:er från bygget exporterade som CycloneDX eller SPDX, sårbarhetsregistreringar och bygghistorik. CRACI skickar också in CRA-anmälningarna av sårbarheter för din räkning. Bedömningen av överensstämmelse, EU-försäkran om överensstämmelse och CE-märkningen ligger kvar hos dig som tillverkare.
CRACI signerar inte firmware, SBOM:er eller proveniens, och det upptäcker inte nya skadliga paket utifrån beteende eller rykte: det flaggar en skadlig release när ett säkerhetsmeddelande med en CVE finns, och förlitar sig på egress-policyn fram till dess. Det genomför inte din bedömning av överensstämmelse och upprättar inte din försäkran om överensstämmelse. Det kör i dag GitHub Actions-jobb på Linux-runners; GitLab CI, Jenkins samt Windows- och macOS-runners finns på roadmapen.
Vanliga frågor om att säkra uppkopplade enheter och deras leveranskedja för programvara
Det är en attack som når en enhet genom något som tillverkaren förlitar sig på snarare än genom själva enheten: ett sårbart open source-bibliotek, en chipleverantörs SDK, en förgiftad paketrelease, ett komprometterat byggverktyg eller en kapad uppdateringskanal. Eftersom samma komponent levereras i många produkter kan en enda svaghet nå miljontals enheter från många varumärken på en gång.
Börja med det du levererar: ha en SBOM för varje firmwarebygge, spåra leverantörskomponenter och fortsätt att kontrollera levererade versioner när nya sårbarheter dyker upp. Lås ner själva bygget, håll kända dåliga versioner ute med policykontroller, skydda dina signeringsnycklar och ha en process för triage, åtgärder och offentliggörande. Härdning av enheten, som secure boot och att inaktivera standardlösenord, är också viktig, men hjälper inte om firmwaren redan innehåller en sårbar komponent.
Känn till varje komponent som går in i avbilden, inklusive det bygget hämtar utanför dina recept och lockfiler, och behåll den registreringen per release. Bygg i en isolerad miljö som bara når de källor den behöver, så att ett skadligt beroende inte kan skicka dina hemligheter någonstans. Bevaka de registrerade komponenterna och dina leverantörers SBOM:er mot nya sårbarheter så länge enheterna stöds.
Ja. Yocto- och BitBake-byggen körs på CRACI-runners, och CRACI registrerar jobbets SBOM medan bygget körs. Yoctos egen SPDX-utdata innehåller fortfarande receptmetadata som CRACI inte registrerar, till exempel tillämpade patchar och CVE:er som ett recept markerar som åtgärdade, så behåll create-spdx påslaget om du förlitar dig på dem.
Ja, när du har en SBOM för dem. Du kan lägga till leverantörers SBOM:er i CRACI, och de komponenterna bevakas tillsammans med programvaran du bygger. Allt som ditt bygge laddar ner från en leverantör under bygget registreras också i jobbets SBOM.
Inte utifrån beteende eller rykte. En känd skadlig release som har en publicerad CVE, som bakdörren i xz, flaggas som vilken annan sårbarhet som helst, och en policykontroll kan blockera byggen som innehåller den. Mot nya attacker är CRACI:s skydd egress-policyn som nekar som standard och hindrar bygget från att nå värdar det inte behöver.
Nej. CRACI signerar inte firmware, SBOM:er eller proveniens. Fortsätt att använda din egen signeringsprocess och hårdvarubaserad nyckellagring för releaser och uppdateringar.
Cyber Resilience Act omfattar produkter med digitala element som släpps ut på EU-marknaden, vilket inkluderar de flesta uppkopplade konsumentenheter. Rapporteringsskyldigheterna gäller från den 11 september 2026 och förordningen gäller i sin helhet från den 11 december 2027. CRACI automatiserar en betydande del av den insyn i och det underlag om leveranskedjan som CRA-processen behöver; att uppfylla förordningen förblir tillverkarens process.
CRACI kör GitHub Actions-jobb på Linux-runners, x86-64 och ARM64, från 1 till 32 vCPU:er. Andra CI-system, som GitLab CI och Jenkins, finns på roadmapen, liksom Windows- och macOS-runners.
Boka en demo så visar vi varje komponent som dina enhetsbyggen hämtar, och vilka av dem som är sårbara
Boka en demo