Hver smartenhet leveres med firmware bygget av pakker med åpen kildekode, SDK-er fra brikkeleverandører og verktøy hentet under bygget. Et leverandørkjedeangrep trenger bare én av dem. CRACI kjører firmware-byggene dine, registrerer hver komponent som går inn, og hindrer bygget i å nå noe det ikke trenger.
Det meste av koden i en tilkoblet enhet er skrevet av noen andre: en innebygd Linux-distribusjon, board support package fra brikkeleverandøren, en nettverksstakk, noen hundre biblioteker med åpen kildekode og Rust-cratene under dem. De samme komponentene leveres i produkter fra mange merker, og enhetene blir stående i hjem i årevis, ofte lenge etter at noen sist så på hva de inneholder.
Det gjør én svak komponent svært verdifull for en angriper. En feil i et delt bibliotek eller SDK åpner hvert produkt som leverer det, og en forgiftet utgivelse når hvert bygg som henter den inn. Disse hendelsene viser mønsteret.
Nitten sårbarheter, opptil CVSS 10.0, i et lite TCP/IP-bibliotek som enhetsprodusenter hadde lisensiert i årevis, ofte under et annet navn. Det lå inne i produkter fra mange leverandører, og mange av dem måtte først finne ut om de i det hele tatt leverte det.
Du kan ikke patche en komponent du ikke vet at du leverer.
Feil i en brikkeleverandørs SDK nådde omtrent 200 enhetsmodeller fra rundt 65 produsenter: rutere, IP-kameraer, gatewayer for smart belysning og tilkoblede leker. Et Mirai-botnett skannet etter dem to dager etter at detaljene ble offentlige.
Brikkeleverandørens kode er din kode så snart den leveres i enheten din.
En bakdør ble plantet i selve upstream-prosjektet xz, i versjonene 5.6.0 og 5.6.1. Innebygde Linux-images henter inn komprimeringsbiblioteker som xz som en selvfølge, vanligvis uten at noen har valgt dem.
Betrodd åpen kildekode kan bli fiendtlig i én enkelt utgivelse.
Angripere brukte ASUS' egne signeringssertifikater til å signere en versjon av oppdateringsverktøyet med bakdør og leverte den fra de offisielle oppdateringsserverne. Kaspersky anslo at den kan ha nådd mer enn én million brukere.
En gyldig signatur beviser bare hvem som signerte, ikke hva som gikk inn.
Herding av enheten, som secure boot, ingen standardpassord og en lukket feilsøkingsport, beskytter enheten du leverer. Stegene nedenfor beskytter det som går inn i den.
CRACI dekker byggesiden av denne listen: SBOM-en for hvert bygg, SBOM-er fra leverandører, kontinuerlig overvåking, isolering av bygg, egress-kontroll og policy gates. Signering og herding av enheter forblir hos dine egne verktøy.
Kjør Yocto- og andre innebygde Linux-bygg på CRACIs GitHub Actions-runnere, opptil 32 vCPU-er, på x86-64 eller native ARM64. Mens bygget kjører, registrerer CRACI hver pakke og fil det henter inn, inkludert vertspakker, Git-kilder, GitHub Actions og nedlastinger som ingen oppskrift eller lockfile viser. I et core-image-sato-bygg hadde CRACIs SBOM alle komponentene i Yoctos egen SBOM pluss 88 den manglet, med en package URL for hver av de 653 Rust crate-versjonene, så alle kan overvåkes for sårbarheter.
Hver jobb kjører i sin egen isolerte virtuelle maskin under en egress-policy som valideres før jobben starter og blokkerer ved feil (fail closed). Med en default deny-policy når bygget pakkekildene dine og ingenting annet. En kompromittert avhengighet som prøver å sende signeringsmateriale eller tokens til en angripers vert, blir blokkert og utløser et varsel, selv når angrepet er nytt og ingen har publisert en advisory om det ennå.
Legg til SBOM-er fra brikkeleverandørene og andre leverandører, så overvåkes de innkjøpte komponentene sammen med programvaren du bygger. Når neste SDK-sårbarhet dukker opp, ligger leverandørens kode i samme oversikt som din.
CRACI fortsetter å vurdere overvåkede SBOM-er på nytt etter hvert som nye sårbarheter publiseres. Byggehistorikken viser hvilke bygg som inneholdt den sårbare avhengigheten, direkte eller transitiv, og inventarvisningen viser hvilke programvareversjoner som er rullet ut til hvilke produkter. Sikkerhetsteam prioriterer hvert funn og ruter det til teamet som eier rettingen, og en policy gate kan holde en bestemt CVE ute av alle senere bygg.
CE-merking under Cyber Resilience Act hviler på teknisk dokumentasjon og en samsvarsvurdering. CRACI leverer leverandørkjedebevisene den dokumentasjonen trenger: SBOM-er fra bygget eksportert som CycloneDX eller SPDX, sårbarhetsoppføringer og byggehistorikk. CRACI sender også inn CRA-sårbarhetsvarslene på dine vegne. Samsvarsvurderingen, EU-samsvarserklæringen og CE-merkingen forblir hos deg, produsenten.
CRACI signerer ikke firmware, SBOM-er eller provenance, og oppdager ikke nye ondsinnede pakker ut fra atferd eller omdømme: CRACI flagger en ondsinnet utgivelse først når det finnes en advisory med en CVE, og er avhengig av egress-policyen frem til da. CRACI gjennomfører ikke samsvarsvurderingen din og utarbeider ikke samsvarserklæringen din. CRACI kjører GitHub Actions-jobber på Linux-runnere i dag; GitLab CI, Jenkins og Windows- og macOS-runnere står på veikartet.
Vanlige spørsmål om å sikre tilkoblede enheter og programvareleverandørkjeden deres
Det er et angrep som når en enhet gjennom noe produsenten er avhengig av, ikke gjennom selve enheten: et sårbart bibliotek med åpen kildekode, en brikkeleverandørs SDK, en forgiftet pakkeutgivelse, et kompromittert byggeverktøy eller en kapret oppdateringskanal. Fordi den samme komponenten leveres i mange produkter, kan én svakhet nå millioner av enheter fra mange merker samtidig.
Begynn med det du leverer: Ha en SBOM for hvert firmware-bygg, spor leverandørkomponenter, og fortsett å sjekke leverte versjoner etter hvert som nye sårbarheter dukker opp. Lås ned selve bygget, hold kjente dårlige versjoner ute med policy gates, beskytt signeringsnøklene, og ha en prosess for prioritering, retting og offentliggjøring. Herding av enheten, som secure boot og deaktivering av standardpassord, betyr også noe, men det hjelper ikke hvis firmwaren allerede inneholder en sårbar komponent.
Kjenn hver komponent som går inn i imaget, inkludert det bygget henter utenom oppskriftene og lockfilene dine, og ta vare på den registreringen per utgivelse. Bygg i et isolert miljø som bare når kildene det trenger, så en ondsinnet avhengighet ikke kan sende hemmelighetene dine noe sted. Overvåk de registrerte komponentene og leverandørenes SBOM-er mot nye sårbarheter så lenge enhetene støttes.
Ja. Yocto- og BitBake-bygg kjører på CRACI-runnere, og CRACI registrerer jobbens SBOM mens bygget kjører. Yoctos egen SPDX-utdata inneholder fortsatt oppskriftsmetadata som CRACI ikke registrerer, for eksempel patchene som er brukt og CVE-ene en oppskrift merker som rettet, så la create-spdx være på hvis du er avhengig av dem.
Ja, når du har en SBOM for dem. Du kan legge til SBOM-er fra leverandører i CRACI, og disse komponentene overvåkes sammen med programvaren du bygger. Alt bygget ditt laster ned fra en leverandør underveis, registreres også i jobbens SBOM.
Ikke ut fra atferd eller omdømme. En kjent ondsinnet utgivelse som har en publisert CVE, for eksempel xz-bakdøren, flagges som enhver annen sårbarhet, og en policy gate kan blokkere bygg som inneholder den. Mot nye angrep er CRACIs beskyttelse default deny-egress-policyen, som hindrer bygget i å nå verter det ikke trenger.
Nei. CRACI signerer ikke firmware, SBOM-er eller provenance. Fortsett å bruke din egen signeringsprosess og maskinvarebasert nøkkellagring for utgivelser og oppdateringer.
Cyber Resilience Act omfatter produkter med digitale elementer som bringes i omsetning på EU-markedet, noe som inkluderer de fleste tilkoblede forbrukerenheter. Rapporteringspliktene gjelder fra 11. september 2026, og forordningen gjelder fullt ut fra 11. desember 2027. CRACI automatiserer en betydelig del av synligheten i leverandørkjeden og bevisene CRA-prosessen trenger; å oppfylle forordningen forblir produsentens prosess.
CRACI kjører GitHub Actions-jobber på Linux-runnere, x86-64 og ARM64, fra 1 til 32 vCPU-er. Andre CI-systemer, som GitLab CI og Jenkins, står på veikartet, det samme gjør Windows- og macOS-runnere.
Book en demo, så viser vi hver komponent enhetsbyggene dine henter inn, og hvilke av dem som er sårbare
Book en demo