Dlaczego skanery SBOM nie widzą, co jest w buildach Yocto

Czym build Yocto różni się od tego, czego oczekują skanery

Build Yocto to nie instalacja za pomocą menedżera pakietów. Większość tego, co trafia na urządzenie, rozstrzyga się w czasie buildu, wewnątrz BitBake, w pięciu warstwach. Skanery patrzą na jedną warstwę po fakcie i resztę muszą zgadywać.

1. Host buildu

BitBake działa z narzędziami z maszyny buildu. Zmienna HOSTTOOLS wymienia narzędzia na hoście buildu, które mogą wywoływać zadania buildu, a system buildu tworzy do nich dowiązania symboliczne w ${TMPDIR}/hosttools. BitBake buduje też własne narzędzia za pomocą receptur -native i -cross. Narzędzia hosta wpływają na obraz, a z założenia nie są jego częścią.

2. Pobieranie

Receptury wskazują swoje źródła w SRC_URI, a fetcher pobiera je do DL_DIR. Szuka najpierw w DL_DIR, potem w PREMIRRORS, następnie upstream, a na końcu w MIRRORS. Crate'y Rust przychodzą przez fetcher crate:// i są wymienione w pliku -crates.inc, który cargo-update-recipe-crates generuje z Cargo.lock. Moduły Go przychodzą przez klasę go-mod albo są vendorowane za pomocą go-vendor. BB_NO_NETWORK i BB_ALLOWED_NETWORKS określają, do czego fetcher może sięgać.

3. Receptury i łatki

Każda receptura przypina wersję upstream w PV i nakłada na nią łatki. Łatka z wierszem CVE: w nagłówku oznacza dane CVE jako załatane. Numer wersji pozostaje numerem upstream, więc receptura może być naprawiona, choć jej wersja mówi coś innego.

4. Skompilowany kod

Biblioteki statyczne (pakiety -staticdev), crate'y Rust i moduły Go trafiają do wnętrza plików binarnych, które z nich korzystają. Jądro i jego moduły są budowane z konfiguracji właściwej dla produktu, więc dwie platformy z tą samą wersją jądra zawierają różny kod.

5. Obraz

Główny system plików. Funkcja obrazu package-management instaluje narzędzia do zarządzania pakietami i zachowuje bazę danych menedżera pakietów. Bez niej pliki danych menedżera pakietów są usuwane z głównego systemu plików, co jest częste w obrazach produkcyjnych.

Cache shared state (sstate), czyli współdzielonego stanu

BitBake może odtworzyć wynik zadania z cache shared state, zamiast je uruchamiać. Overview manual Yocto mówi to wprost: jeśli prekompilowane obiekty są dostępne, kompilator nie jest potrzebny, "a zatem kompilator nie jest nawet pobierany". Zadania odtworzone z sstate pomijają pobieranie, kompilację i instalację, co ma znaczenie dla każdego narzędzia, które opiera się na obserwowaniu tych kroków. Więcej na ten temat w sekcji o cache poniżej.

Dlaczego skanery obrazów i systemów plików nie widzą większości

• Brak bazy danych pakietów. Obraz produkcyjny zbudowany bez package-management nie daje skanerowi żadnej listy do odczytania, więc skaner wraca do heurystyk opartych na plikach albo nie zgłasza prawie nic. Wynik wygląda na kompletny, a jest prawie pusty.
• Kod statyczny i vendorowany. Biblioteka statyczna albo crate wkompilowany w /usr/bin/foo nie zostawia żadnego wpisu pakietu. Przykładem jest librsvg: obecna receptura w oe-core wymienia ponad 350 crate'ów Rust, a na urządzeniu jest to jedna biblioteka współdzielona.
• Host buildu i pobrane narzędzia. Nigdy nie ma ich w obrazie, więc nigdy nie ma ich w skanie obrazu, chociaż skompromitowane narzędzie hosta lub GitHub Action może skompromitować obraz. Backdoor w xz utils (CVE-2024-3094) trafił do biblioteki w trakcie jej budowania, z tarballi wydania, a nie z repozytorium Git. W marcu 2025 roku CISA poinformowała, że wszystkie wersje akcji GitHub tj-actions/changed-files były skompromitowane przez trzy dni.
• Nałożone łatki. Obraz podaje openssl w wersji upstream. Receptura nałożyła poprawkę CVE dotyczącej tej wersji i oznaczyła łatkę tagiem CVE:. Dopasowanie po zakresie wersji i tak ją zgłasza. To odmiana problemu backportów znanego z dystrybucji, występująca w Yocto, i jedno z głównych źródeł szumu opisanego w artykule jak ograniczyć szum podatności.

W sumie powstaje mieszanina brakujących komponentów i błędnych wyników, a nic w wyniku nie mówi, co jest czym. Ten sam argument dotyczy kontenerów w SBOM dla obrazów Docker oraz projektów w różnych językach w generatorach SBOM open source.

Dlaczego binarne skanowanie firmware'u musi zgadywać

Analiza binarna dopasowuje ciągi znaków, symbole i sygnatury kodu w wyodrębnionym firmware do znanych komponentów, a potem wnioskuje o wersjach. Tam, gdzie plik binarny niesie wyraźne dowody, to działa. W obrazie Yocto często musi zgadywać:

• pliki binarne pozbawione symboli i ciągów z wersją;
• kod linkowany statycznie, w którym granice bibliotek zniknęły;
• skompilowany Rust, w którym granice crate'ów znikają w jednym pliku wykonywalnym;
• backportowane łatki, niewidoczne w numerze wersji;
• kod jądra, który konfiguracja włączyła do kompilacji lub z niej wyłączyła.

Analiza binarna to właściwe narzędzie dla firmware'u, którego Państwo nie zbudowali: blobów dostawców, kupionych modułów, urządzenia, które Państwo oceniają. Jeśli nie mają Państwo buildu, analiza pliku binarnego jest jedyną opcją. Reguła decyzyjna jest prosta: jeśli Państwo to budują, należy to rejestrować; jeśli tylko otrzymują, należy to analizować i poprosić dostawcę o SBOM z jego buildu.

Co dobrze robią własne narzędzia SBOM i CVE z Yocto

Prace Yocto Project nad SBOM to dobra inżynieria, a projekt wie rzeczy, których nie wie żadne zewnętrzne narzędzie. Według dokumentacji SBOM to "opis wszystkich użytych komponentów, ich licencji, ich zależności, ich źródeł, zmian, które zostały do nich wprowadzone, oraz znanych podatności, które zostały naprawione".

create-spdx według wydań

• 4.3 (Nanbield): generowanie SPDX jest domyślnie włączone.
• 5.1 (Styhead): domyślnie SPDX 3.0 zamiast 2.2 oraz klasa vex, która przekazuje zewnętrznym narzędziom CVE potrzebne im informacje.
• 5.3 (Whinlatter): SPDX_INCLUDE_COMPILED_SOURCES, która uwzględnia tylko źródła użyte do kompilacji.
• 6.0 (Wrynose, wsparcie długoterminowe): usunięto SPDX 2.2; dodano SPDX_INCLUDE_KERNEL_CONFIG i SPDX_INCLUDE_PACKAGECONFIG; receptury budowane z klasami Cargo, Go, PyPI, npm i CPAN otrzymują package URL swojego ekosystemu.

SBOM obejmuje to, co buduje BitBake, łącznie z natywnymi narzędziami, które buduje dla hosta. Jest dokładny w odniesieniu do wszystkiego, co ma recepturę.

Status CVE jako VEX wewnątrz SBOM

W SPDX 3 system buildu zapisuje status CVE każdej receptury jako relacje VEX: załatane CVE staje się "fixed", z powiązaniem z plikami łatek; niezałatane "affected"; zignorowane "not affected", z uzasadnieniem jako impact statement. SPDX_INCLUDE_VEX określa, ile informacji trafia do SBOM: none, current (domyślnie, podatności, które nie są już naprawione w źródle upstream) albo all.

CVE_STATUS i tag w łatce

CVE_STATUS zapisuje decyzję dla każdego CVE jako uzasadnienie i opcjonalny opis. Uzasadnienia odpowiadają statusom: załatane (backported-patch, cpe-stable-backport, fixed-version i inne), niezałatane (vulnerable-investigating) i zignorowane (cpe-incorrect, disputed, not-applicable-config, not-applicable-platform, upstream-wontfix). CVE_STATUS_GROUPS stosuje jedną decyzję do grupy CVE, a CVE_PRODUCT ustawia nazwę produktu używaną do dopasowywania.

# In a recipe or .bbappend
CVE_STATUS[CVE-2020-15523] = "not-applicable-platform: Issue only applies on Windows"

# In the header of a patch file
CVE: CVE-2022-3341
Upstream-Status: Backport [link to the upstream commit]

Od cve-check do sbom-cve-check

cve-check dopasowywał nazwy receptur (CVE_PRODUCT) i wersje do danych o podatnościach. Informacje o wydaniu 5.2 ostrzegają, że od początku 2024 roku opiekunowie NVD przestali opisywać wiele CVE dotkniętymi CPE, więc "obecne raporty CVE mogą wyglądać dobrze, ale w rzeczywistości niektóre podatności po prostu nie są zgłaszane". Wydanie 5.2 ustawiło też jako domyślny feed FKIE zamiast NVD. Yocto 6.0 usunęło cve-check i zastąpiło go klasą sbom-cve-check, która uruchamia sbom-cve-check od Bootlin na wyjściu SPDX. W wydaniach od 5.0 do 5.3 nadal mają Państwo cve-check; należy traktować go jako rozwiązanie przestarzałe.

Gdzie kończy się SBOM z Yocto

Yocto nie widzi niczego, co leży poza metadanymi BitBake. Zbudowaliśmy core-image-sato dwukrotnie na natywnym runnerze ARM64 z 32 vCPU, raz z generowaniem SBOM przez Yocto, a raz bez niego, i porównaliśmy SBOM Yocto w formacie SPDX 3.0.1, zapisany jako 1632 pliki, z SBOM w formacie CycloneDX zarejestrowanym przez CRACI:

• Komponenty. Zarejestrowany przez CRACI SBOM zawierał wszystkie komponenty z SBOM Yocto oraz 88, których tamten nie uwzględnił: 23 pakiety hosta na maszynie buildu (takie jak cpio z Ubuntu), 10 źródeł z GitHub, w tym akcję GitHub actions/upload-artifact, oraz 55 innych źródeł i narzędzi pobranych w trakcie buildu.
• Crate'y Rust. Oba wymieniały te same 653 wersje crate'ów Rust. W wydaniu, które zbudowaliśmy, SBOM Yocto wymieniał je tylko jako pliki .crate z lokalizacją pobierania, bez package URL pkg:cargo, więc nie dało się ich dopasować do advisories. Od Yocto 6.0 receptury budowane z klasą Cargo mają package URL dla samej receptury, na przykład pkg:cargo/librsvg; w obecnym kodzie poszczególne pobrania crate'ów nadal go nie mają. Warto sprawdzić, co zapisuje Państwa wydanie.
• Koszt. Build z generowaniem SBOM przez Yocto trwał 155 min 40 s i zapisał 1632 pliki SPDX. Bez niego build trwał 88 min 48 s, o 43% krócej. SPDX_INCLUDE_SOURCES, SPDX_INCLUDE_COMPILED_SOURCES, SPDX_INCLUDE_KERNEL_CONFIG i SPDX_INCLUDE_PACKAGECONFIG były włączone, więc konfiguracja domyślna kosztuje mniej. Własna dokumentacja Yocto ostrzega, że po uwzględnieniu skompilowanych źródeł nieskompresowany SBOM core-image-minimal "może urosnąć ze setek megabajtów do kilku gigabajtów".

Natywne receptury, takie jak cmake, llvm, ninja i qemu, są w SBOM Yocto. Metoda, oba SBOM i pełny raport są dostępne na stronie Buildy Yocto w CRACI.

CVE jądra Linux: problem każdej konfiguracji z osobna

Projekt jądra Linux ogłosił 13 lutego 2024 roku, że został CVE Numbering Authority, i hojnie przydziela CVE poprawkom. Jego dokumentacja CVE mówi, że o zastosowaniu danego CVE "ma zdecydować użytkownik Linuksa", ponieważ "nie znamy Państwa przypadku użycia i nie wiemy, z jakich części jądra Państwo korzystają".

Dopasowanie po wersji jądra daje więc setki wyników, w większości dotyczących kodu, którego Państwa konfiguracja nigdy nie kompiluje. Cztery platformy sprzętowe z czterema konfiguracjami jądra dają cztery różne odpowiedzi dla tej samej wersji jądra. Można sobie z tym radzić na cztery sposoby:

1. Tylko dopasowanie wersji. Zgłaszane jest każde CVE dla danej wersji. Maksymalny szum.
2. Wyselekcjonowane listy wykluczeń. Wpisy CVE_STATUS generowane z danych CVE jądra. W maju 2026 roku oe-core usunęło swoją generowaną listę dla linux-yocto, ponieważ sbom-cve-check robi to sam na podstawie listy CVE dostarczanej przez jądro, z niezmienionym raportem CVE i plikiem SPDX mniejszym o prawie 20 MB.
3. Filtrowanie według tego, co skompilowano. Gdy SPDX_INCLUDE_COMPILED_SOURCES jest włączone dla receptury jądra, improve_kernel_cve_report.py sprawdza, czy pliki, których dotyczy CVE, zostały użyte do zbudowania jądra. Według security manual Yocto "ogranicza to fałszywe alarmy CVE o 70%-80%".
4. Rejestrowanie konfiguracji. SPDX_INCLUDE_KERNEL_CONFIG (6.0) zapisuje konfigurację jądra w SBOM, więc odpowiedź można później zweryfikować.

Przykład. Jedno CVE jądra w sterowniku sieciowym. Platforma A buduje ten sterownik; platforma B nie.

Platforma	Sterownik skompilowany?	Dopasowanie wersji	Filtr skompilowanych źródeł
A	Tak	Zgłoszone	Zgłoszone: pliki, których dotyczy, zostały zbudowane
B	Nie	Zgłoszone	Niezgłoszone: pliki, których dotyczy, nie zostały zbudowane

Aby dziś uzyskać raporty CVE jądra dla każdej platformy, należy uruchomić narzędzia Yocto do skompilowanych źródeł raz dla każdej konfiguracji maszyny. To konfiguracja rozstrzyga o odpowiedzi, więc raport musi pochodzić z buildu każdej konfiguracji.

Cache, mirrory i vendoring: gdzie każde narzędzie rejestrujące musi uważać

• Build, który odtwarza wszystko z sstate albo z wypełnionego DL_DIR, pobiera niewiele albo nic. Narzędzie, które widzi pobrania, musi przenosić swoje dowody razem z tymi cache, inaczej zapis się kurczy.
• Receptura wskazująca wcześniej zvendorowany tarball pokazuje jedno pobranie, a nie crate'y czy moduły w jego wnętrzu.
• Niezależnie od narzędzia należy budować obrazy wydań ze znanego stanu cache, utrzymywać własne mirrory i porównywać liczbę komponentów między buildami.

W CRACI pakiety przywrócone z cache CI zostają w SBOM, a stan kompletności każdego zadania wskazuje, czego rejestrowanie nie mogło zobaczyć.

Co uruchomić: tabela decyzyjna

Sytuacja	Czego użyć	Co Państwo otrzymują	Czego nadal brakuje
Budują Państwo obraz w GitHub Actions	Rejestrowanie buildu (CRACI); create-spdx warto zachować, jeśli polegają Państwo na jego statusie łatek i CVE	Pakiety hosta, pobrane źródła i akcje, URL pkg:cargo dla każdego crate'a, ciągły monitoring	Filtrowanie jądra dla każdej konfiguracji: należy użyć narzędzi Yocto
Budują Państwo z Yocto w innym systemie CI lub na serwerze buildów	create-spdx z sbom-cve-check (albo cve-check w starszych wydaniach), filtrowanie jądra ze skompilowanymi źródłami	Receptury, łatki, status CVE jako VEX	Inwentarz pakietów hosta i pobranych narzędzi, prowadzony osobno
Otrzymują Państwo firmware, którego nie budują	Analiza binarna oraz SBOM z buildu od dostawcy	Komponenty wywnioskowane z pliku binarnego	Pewność co do wersji, łatek i wejść buildu
Potrzebują Państwo CVE jądra dla każdej platformy	Narzędzia Yocto do skompilowanych źródeł, dla każdej konfiguracji maszyny	CVE dla kodu, który buduje każda konfiguracja	Komponenty spoza jądra, z Państwa SBOM
Mają Państwo tylko skaner obrazów	Do zainstalowanych pakietów, jeśli baza danych pakietów jest zachowana	Część listy pakietów środowiska uruchomieniowego	Wszystko, co wkompilowano, załatano lub pozostawiono na hoście buildu; czysty wynik nie jest dowodem

Co widzi każda metoda

Klasa komponentów	Skaner obrazów	Analiza binarna	Yocto create-spdx	Rejestrowanie buildu (CRACI)
Zainstalowane pakiety	Tylko jeśli baza danych pakietów jest zachowana	Wywnioskowane z plików	Tak	Tak, ze źródeł pobranych przez build
Biblioteki statyczne	Nie	Wywnioskowane z sygnatur	Tak, jako receptury	Tak, ze źródeł pobranych przez build
Crate'y Rust	Nie	Wywnioskowane; granice crate'ów znikają	Jako pobrania .crate, bez package URL dla każdego crate'a	Tak, każdy z package URL pkg:cargo
Moduły Go	Nie	Wywnioskowane z pliku binarnego	Jako pobrania modułów receptury	Tak, jeśli pobrano je w trakcie buildu
Nałożone łatki i status CVE	Nie	Nie	Tak, jako VEX	Nie
Konfiguracja jądra	Nie	Nie	Tak, z SPDX_INCLUDE_KERNEL_CONFIG (6.0)	Nie
Narzędzia hosta na maszynie buildu	Nie	Nie	Nie (receptury natywne tak)	Tak
Narzędzia buildu pobrane poza recepturami oraz GitHub Actions	Nie	Nie	Nie	Tak

Miejsce CRACI

W przypadku buildów Yocto uruchamianych w GitHub Actions CRACI jest runnerem, z maksymalnie 32 vCPU i 96 GB RAM. Rejestruje, co build pobrał, w tym pakiety hosta, źródła i akcje z GitHub oraz inne pobrane źródła, z package URL dla każdego crate'a Rust: w opublikowanym porównaniu wszystkie komponenty z SBOM Yocto oraz 88, których tamten nie uwzględnił. Dopasowuje komponenty do advisories, stale ponownie ocenia SBOM w miarę publikowania nowych i pokazuje, które buildy zawierały podatną zależność.

BitBake może już ograniczać swój fetcher za pomocą BB_ALLOWED_NETWORKS. Polityka ruchu wychodzącego CRACI dodaje drugą kontrolę na runnerze, sprawdzaną przed startem zadania i blokującą w razie błędu, więc skrypt lub narzędzie, które omija fetcher, nadal nie może połączyć się z hostem, na który Państwo nie zezwolili.

Jeśli chodzi o pokrycie łańcucha dostaw, SBOM z CRACI może zastąpić create-spdx. SPDX z Yocto nadal zawiera nałożone łatki i CVE oznaczone jako naprawione, których CRACI nie rejestruje, więc jeśli polegają Państwo na tych informacjach, należy pozostawić włączone create-spdx. Dokumentacja CRACI zawiera przykład budujący core-image-sato. Dlaczego rejestrowanie jest ogólnie lepsze od skanowania, wyjaśniamy na stronie SBOM z czasu buildu; narzędzia dla Yocto porównujemy na stronach porównanie narzędzi bezpieczeństwa dla systemów wbudowanych i CRACI vs Timesys Vigiles.

Kiedy CRACI nie jest odpowiedzią

• Polegają Państwo na statusie CVE na poziomie łatek, takim jak decyzje CVE_STATUS oraz załatane lub zignorowane CVE jako VEX. Te informacje są w SPDX z Yocto: warto go zachować.
• Potrzebują Państwo już dziś raportów CVE jądra dla każdej konfiguracji. Należy użyć narzędzi Yocto do skompilowanych źródeł.
• Nie budują Państwo firmware'u. Należy użyć analizy binarnej.
• Państwa buildy Yocto działają poza GitHub Actions albo muszą działać na Państwa własnej infrastrukturze. CRACI oferuje dziś zarządzane runnery na europejskiej infrastrukturze; inne systemy CI i runnery hostowane przez klienta są na roadmapie.
• Potrzebują Państwo SBOM zadania Yocto właśnie w formacie SPDX. SBOM z CRACI w opublikowanym porównaniu był w formacie CycloneDX; własny SBOM Yocto jest w SPDX.

Budują Państwo podłączone urządzenia na rynek UE? Warto przeczytać, czego wymaga CRA, jak działa VEX i jak CRACI sprawdza się w branżach telekomunikacji i sprzętu sieciowego, przemysłowego IoT i elektroniki użytkowej.

Yocto CVE check i SBOM: najczęściej zadawane pytania

Dlaczego nasze narzędzie SCA nie potrafi przeskanować naszych produktów opartych na Yocto?

Ponieważ większość narzędzi SCA odczytuje manifesty, lockfile'y albo bazę danych pakietów obrazu, a build Yocto rozstrzyga o swojej zawartości wewnątrz BitBake. Obrazy produkcyjne często nie zawierają bazy danych pakietów, biblioteki statyczne i crate'y Rust są kompilowane do plików binarnych, łatki w recepturach zostawiają numery wersji upstream bez zmian, a narzędzia hosta buildu nigdy nie trafiają do obrazu.

Czy można przeskanować obraz Yocto lub firmware za pomocą Trivy, Grype albo skanera binarnego?

Można, ale odpowiedź będzie częściowa. Skaner obrazów odczytuje zainstalowane pakiety, jeśli baza danych pakietów jest zachowana, i pomija to, co jest wkompilowane. Skaner binarny wnioskuje o komponentach z ciągów znaków i sygnatur i musi zgadywać przy plikach binarnych pozbawionych symboli, kodzie statycznym i skompilowanym Rust. Żaden z nich nie widzi hosta buildu ani łatek nałożonych przez recepturę.

Czy SBOM z Yocto zawiera crate'y Rust i moduły Go?

Wymienia je jako źródła receptury, która z nich korzysta. W wydaniu, które zbudowaliśmy, każdy crate Rust występował jako pobranie .crate z lokalizacją pobierania i bez package URL pkg:cargo. Od Yocto 6.0 receptury budowane z klasami Cargo i Go otrzymują package URL swojego ekosystemu dla samej receptury, a nie dla każdego pobranego crate'a czy modułu.

Dlaczego nasz skaner zgłasza CVE, które nasze receptury Yocto już łatają?

Ponieważ dopasowuje numery wersji. Receptura Yocto zachowuje wersję upstream i nakłada poprawki bezpieczeństwa jako łatki, oznaczone wierszem CVE: albo zapisane w CVE_STATUS. Dopasowanie po zakresie wersji nie widzi łatki. Własny SPDX z Yocto zapisuje te CVE jako naprawione, z powiązaniem z plikami łatek.

Co zastąpiło cve-check w Yocto?

Klasa sbom-cve-check w Yocto 6.0. Uruchamia sbom-cve-check od Bootlin na wyjściu SPDX buildu. Wydania od 5.0 do 5.3 nadal mają cve-check, który dopasowywał nazwy i wersje receptur; informacje o wydaniu 5.2 ostrzegają, że jego raporty mogą pomijać podatności, ponieważ wiele CVE nie zawiera już danych CPE.

Jak uzyskać CVE jądra Linux dla własnej konfiguracji jądra?

Należy włączyć SPDX_INCLUDE_COMPILED_SOURCES dla receptury jądra i uruchomić improve_kernel_cve_report.py, który sprawdza, czy pliki, których dotyczy każde CVE, zostały skompilowane. Według security manual Yocto ogranicza to fałszywe alarmy CVE o 70% do 80%. Trzeba go uruchomić dla każdej konfiguracji maszyny, ponieważ każda konfiguracja buduje inny kod.

Czy cache shared state wpływa na SBOM?

Może wpływać. Zadania odtworzone z sstate pomijają pobieranie i kompilację, więc narzędzie, które opiera się na obserwowaniu tych kroków, widzi mniej. create-spdx z Yocto działa na podstawie metadanych receptur. Niezależnie od metody należy budować obrazy wydań ze znanego stanu cache i porównywać liczbę komponentów między buildami.

Czy wbudowany SBOM z Yocto wystarcza do CRA?

CRA wymaga SBOM obejmującego co najmniej zależności najwyższego poziomu, a SBOM z Yocto jest dokładny w odniesieniu do tego, co buduje BitBake. Nie wymienia pakietów hosta na maszynie buildu, GitHub Actions ani narzędzi pobranych poza recepturami. Czy to wystarczy, decydują Państwo; SBOM jest dowodem Państwa procesu, a nie samą zgodnością.