Każde inteligentne urządzenie zawiera firmware zbudowany z pakietów open source, SDK dostawców układów i narzędzi pobieranych podczas buildu. Atakowi na łańcuch dostaw wystarczy jeden z nich. CRACI uruchamia Państwa buildy firmware'u, rejestruje każdy trafiający do nich komponent i nie pozwala buildowi łączyć się z niczym, czego nie potrzebuje.
Większość kodu w połączonym urządzeniu napisał ktoś inny: dystrybucja embedded Linux, pakiet wsparcia płyty od dostawcy układów, stos sieciowy, kilkaset bibliotek open source i crate'y Rust pod nimi. Te same komponenty trafiają do produktów wielu marek, a urządzenia zostają w domach na lata, często długo po tym, jak ktoś ostatnio sprawdzał, co zawierają.
To sprawia, że jeden słaby komponent jest dla napastnika wiele wart. Błąd we wspólnej bibliotece lub SDK otwiera drogę do każdego produktu, który je zawiera, a zatrute wydanie dociera do każdego buildu, który je pobiera. Te incydenty pokazują ten schemat.
Dziewiętnaście podatności, do CVSS 10.0, w małej bibliotece TCP/IP, którą producenci urządzeń licencjonowali od lat, często pod inną nazwą. Znajdowała się w produktach wielu dostawców, a wielu z nich musiało najpierw ustalić, czy w ogóle ją dostarcza.
Nie można załatać komponentu, o którego dostarczaniu się nie wie.
Błędy w SDK dostawcy układów dotarły do około 200 modeli urządzeń od mniej więcej 65 producentów: routerów, kamer IP, bramek inteligentnego oświetlenia i połączonych zabawek. Dwa dni po upublicznieniu szczegółów botnet Mirai już ich szukał.
Kod dostawcy układów staje się Państwa kodem, gdy trafia do Państwa urządzenia.
Tylną furtkę umieszczono w samym projekcie upstream xz, w wersjach 5.6.0 i 5.6.1. Obrazy embedded Linux standardowo zawierają biblioteki kompresji takie jak xz, zwykle bez niczyjego świadomego wyboru.
Zaufane open source może stać się wrogie w jednym wydaniu.
Napastnicy użyli certyfikatów podpisujących należących do samej firmy ASUS, aby podpisać wersję jej narzędzia aktualizacyjnego z tylną furtką, i dostarczyli ją z oficjalnych serwerów aktualizacji. Kaspersky oszacował, że mogła dotrzeć do ponad miliona użytkowników.
Ważny podpis dowodzi tylko tego, kto podpisał, a nie tego, co trafiło do środka.
Utwardzanie urządzeń, takie jak secure boot, brak domyślnych haseł i zamknięty port debugowania, chroni dostarczane urządzenie. Poniższe kroki chronią to, co do niego trafia.
CRACI obejmuje część tej listy dotyczącą buildu: SBOM każdego buildu, SBOM-y dostawców, ciągłe monitorowanie, izolację buildów, kontrolę ruchu wychodzącego i bramki polityk. Podpisywanie i utwardzanie urządzeń pozostają przy Państwa własnych narzędziach.
Buildy Yocto i innych systemów embedded Linux można uruchamiać na runnerach GitHub Actions CRACI, do 32 vCPU, na x86-64 lub natywnym ARM64. Podczas działania buildu CRACI rejestruje każdy pobrany pakiet i plik, łącznie z pakietami hosta, źródłami Git, GitHub Actions i pobraniami, których nie wymienia żadna receptura ani lockfile. W buildzie core-image-sato SBOM CRACI zawierał każdy komponent z własnego SBOM Yocto oraz 88, które on pominął, z package URL dla każdej z 653 wersji crate'ów Rust, więc wszystkie można monitorować pod kątem podatności.
Każde zadanie działa we własnej izolowanej maszynie wirtualnej w ramach polityki ruchu wychodzącego, która jest walidowana przed startem zadania i blokuje w razie błędu. Przy polityce domyślnego blokowania build dociera do Państwa źródeł pakietów i nigdzie indziej. Przejęta zależność, która próbuje wysłać materiały do podpisywania lub tokeny na host napastnika, zostaje zablokowana i wywołuje alert, nawet gdy atak jest nowy i nikt nie opublikował jeszcze biuletynu na jego temat.
Po dodaniu SBOM-ów od dostawców układów i innych dostawców kupowane komponenty są monitorowane razem z budowanym przez Państwa oprogramowaniem. Gdy pojawi się kolejna podatność w SDK, kod dostawcy będzie w tym samym zapisie co Państwa.
CRACI stale ponownie ocenia monitorowane SBOM-y, w miarę publikowania nowych podatności. Historia buildów pokazuje, które buildy zawierały podatną zależność, bezpośrednią lub przechodnią, a widok inwentarza pokazuje, które wersje oprogramowania są wdrożone w których produktach. Zespoły bezpieczeństwa przeprowadzają triaż każdego znaleziska i kierują je do zespołu odpowiedzialnego za poprawkę, a bramka polityk może nie dopuścić konkretnego CVE do żadnego późniejszego buildu.
Oznakowanie CE na podstawie Cyber Resilience Act opiera się na dokumentacji technicznej i ocenie zgodności. CRACI dostarcza dowody dotyczące łańcucha dostaw potrzebne w tej dokumentacji: SBOM-y z buildu eksportowane jako CycloneDX lub SPDX, rejestry podatności i historię buildów. CRACI składa też w Państwa imieniu zgłoszenia podatności CRA. Ocena zgodności, deklaracja zgodności UE i oznakowanie CE pozostają po Państwa stronie jako producenta.
CRACI nie podpisuje firmware'u, SBOM-ów ani danych o pochodzeniu i nie wykrywa nowych złośliwych pakietów na podstawie zachowania ani reputacji: oznacza złośliwe wydanie, gdy istnieje już biuletyn z CVE, a do tego czasu polega na polityce ruchu wychodzącego. Nie przeprowadza oceny zgodności ani nie sporządza deklaracji zgodności. Dziś uruchamia zadania GitHub Actions na runnerach Linux; GitLab CI, Jenkins oraz runnery Windows i macOS są w planach rozwoju.
Częste pytania o zabezpieczanie połączonych urządzeń i ich łańcucha dostaw oprogramowania
To atak, który dociera do urządzenia przez coś, na czym polega jego producent, a nie przez samo urządzenie: podatną bibliotekę open source, SDK dostawcy układów, zatrute wydanie pakietu, przejęte narzędzie buildu lub przejęty kanał aktualizacji. Ponieważ ten sam komponent trafia do wielu produktów, jedna słabość może naraz dotknąć milionów urządzeń wielu marek.
Należy zacząć od tego, co jest dostarczane: prowadzić SBOM dla każdego buildu firmware'u, śledzić komponenty dostawców i stale sprawdzać dostarczone wersje, gdy pojawiają się nowe podatności. Trzeba też zabezpieczyć sam build, blokować znane złe wersje bramkami polityk, chronić klucze podpisujące i mieć proces triażu, naprawy i ujawniania. Utwardzanie urządzeń, takie jak secure boot i wyłączenie domyślnych haseł, też ma znaczenie, ale nie pomoże, jeśli firmware już zawiera podatny komponent.
Trzeba znać każdy komponent trafiający do obrazu, łącznie z tym, co build pobiera poza recepturami i lockfile'ami, i prowadzić ten zapis dla każdego wydania. Build powinien działać w izolowanym środowisku, które dociera tylko do potrzebnych źródeł, aby złośliwa zależność nie mogła nigdzie wysłać sekretów. Zarejestrowane komponenty i SBOM-y dostawców należy monitorować pod kątem nowych podatności tak długo, jak urządzenia są wspierane.
Tak. Buildy Yocto i BitBake działają na runnerach CRACI, a CRACI rejestruje SBOM zadania podczas działania buildu. Własny wynik SPDX Yocto nadal zawiera metadane receptur, których CRACI nie rejestruje, takie jak zastosowane łatki i CVE oznaczone w recepturze jako naprawione, więc jeśli Państwo na nich polegają, warto pozostawić włączone create-spdx.
Tak, jeśli mają Państwo ich SBOM. Do CRACI można dodawać SBOM-y dostawców, a te komponenty są monitorowane razem z budowanym przez Państwa oprogramowaniem. Wszystko, co build pobiera od dostawcy w trakcie działania, także trafia do SBOM zadania.
Nie na podstawie zachowania ani reputacji. Znane złośliwe wydanie z opublikowanym CVE, takie jak tylna furtka w xz, jest oznaczane jak każda inna podatność, a bramka polityk może blokować zawierające je buildy. Przed nowymi atakami CRACI chroni polityka domyślnego blokowania ruchu wychodzącego, która nie pozwala buildowi łączyć się z niepotrzebnymi hostami.
Nie. CRACI nie podpisuje firmware'u, SBOM-ów ani danych o pochodzeniu. Do wydań i aktualizacji należy nadal używać własnego procesu podpisywania i sprzętowego przechowywania kluczy.
Cyber Resilience Act obejmuje produkty z elementami cyfrowymi wprowadzane na rynek UE, co dotyczy większości połączonych urządzeń konsumenckich. Obowiązki zgłaszania obowiązują od 11 września 2026, a rozporządzenie będzie stosowane w pełni od 11 grudnia 2027. CRACI automatyzuje znaczną część widoczności łańcucha dostaw i dowodów potrzebnych w procesie CRA; spełnianie wymogów rozporządzenia pozostaje procesem producenta.
CRACI uruchamia zadania GitHub Actions na runnerach Linux, x86-64 i ARM64, od 1 do 32 vCPU. Inne systemy CI, takie jak GitLab CI i Jenkins, są w planach rozwoju, podobnie jak runnery Windows i macOS.
Proszę umówić demo, a pokażemy każdy komponent pobierany przez buildy Państwa urządzeń i które z nich są podatne
Umów demo