Miksi SBOM-skannerit eivät näe, mitä Yocto-buildeissa on

Miten Yocto-buildi eroaa siitä, mitä skannerit odottavat

Yocto-buildi ei ole paketinhallinnan asennus. Suurin osa siitä, mitä laitteelle päätyy, ratkaistaan buildin aikana BitBaken sisällä viidessä kerroksessa. Skannerit katsovat jälkikäteen yhtä kerrosta ja joutuvat arvaamaan loput.

1. Build-kone

BitBake toimii build-koneen työkaluilla. HOSTTOOLS-muuttuja luettelee build-koneen työkalut, joita build-tehtävät saavat kutsua, ja build-järjestelmä luo niihin symboliset linkit hakemistoon ${TMPDIR}/hosttools. BitBake rakentaa myös omat työkalunsa -native- ja -cross-reseptien kautta. Koneen työkalut vaikuttavat kuvaan, mutta suunnitellusti ne eivät ole osa sitä.

2. Haku

Reseptit nimeävät lähteensä SRC_URI-muuttujassa, ja hakija (fetcher) lataa ne hakemistoon DL_DIR. Se katsoo ensin DL_DIR-hakemistosta, sitten PREMIRRORS-peileistä, sitten upstreamista ja lopuksi MIRRORS-peileistä. Rust-cratet tulevat crate://-hakijan kautta, ja ne luetellaan -crates.inc-tiedostossa, jonka cargo-update-recipe-crates generoi Cargo.lock-tiedostosta. Go-moduulit tulevat go-mod-luokan kautta tai ne vendoroidaan go-vendor-luokalla. BB_NO_NETWORK ja BB_ALLOWED_NETWORKS määräävät, mihin hakija pääsee.

3. Reseptit ja patchit

Jokainen resepti kiinnittää upstream-version PV-muuttujaan ja soveltaa patchit sen päälle. Patch, jonka otsakkeessa on CVE:-rivi, merkitsee kyseisen CVE:n paikatuksi. Versionumero pysyy upstreamin numerona, joten resepti voi olla korjattu, vaikka sen versio kertoo muuta.

4. Käännetty koodi

Staattiset kirjastot (-staticdev-paketit), Rust-cratet ja Go-moduulit päätyvät niitä käyttävien binäärien sisään. Ydin ja sen moduulit käännetään tuotekohtaisesta konfiguraatiosta, joten kaksi samaa ytimen versiota käyttävää alustaa sisältää eri koodia.

5. Kuva

Juuritiedostojärjestelmä. package-management-kuvaominaisuus asentaa paketinhallinnan työkalut ja säilyttää paketinhallinnan tietokannan. Ilman sitä paketinhallinnan datatiedostot poistetaan juuritiedostojärjestelmästä, mikä on tavallista tuotantokuvissa.

Shared state (sstate) -välimuisti

BitBake voi palauttaa tehtävän tuloksen jaetun tilan välimuistista (shared state cache) ajamatta tehtävää. Yocton yleiskatsausmanuaali sanoo sen suoraan: jos valmiiksi käännetyt objektit ovat saatavilla, kääntäjää ei tarvita, ”joten kääntäjää ei edes ladata”. sstate-välimuistista palautetut tehtävät ohittavat haun, käännöksen ja asennuksen, millä on merkitystä jokaiselle työkalulle, joka perustuu näiden vaiheiden seuraamiseen. Lisää tästä alempana välimuisteja käsittelevässä osiossa.

Miksi kuva- ja tiedostojärjestelmäskannerit eivät näe suurinta osaa

• Ei pakettitietokantaa. Ilman package-management-ominaisuutta rakennettu tuotantokuva ei anna skannerille luetteloa luettavaksi, joten se turvautuu tiedostoheuristiikkaan tai raportoi lähes ei mitään. Tulos näyttää kattavalta ja on lähes tyhjä.
• Staattinen ja vendoroitu koodi. Staattinen kirjasto tai crate, joka on käännetty tiedostoon /usr/bin/foo, ei jätä pakettimerkintää. librsvg on esimerkki: nykyinen oe-core-resepti luettelee yli 350 Rust-cratea, ja laitteella se on yksi jaettu kirjasto.
• Build-kone ja haetut työkalut. Ne eivät koskaan ole kuvassa, joten eivät myöskään kuvan skannauksessa, vaikka vaarantunut koneen työkalu tai GitHub Action voi vaarantaa kuvan. xz utilsin takaovi (CVE-2024-3094) päätyi kirjastoon sen buildin aikana julkaisutarballeista eikä Git-repositoriosta. Maaliskuussa 2025 CISA raportoi, että GitHub Actionin tj-actions/changed-files jokainen versio oli vaarantunut kolmen päivän ajan.
• Sovelletut patchit. Kuvan mukaan openssl on upstream-versiossa. Resepti sovelsi korjauksen tätä versiota koskevaan CVE:hen ja merkitsi patchin CVE:-tunnisteella. Versioaluevertailu liputtaa sen silti. Tämä on Yocton muoto jakeluiden backport-ongelmasta ja yksi suurimmista kohinan lähteistä, joita käsitellään sivulla miten haavoittuvuuskohinaa vähennetään.

Lopputulos on sekoitus puuttuvia komponentteja ja vääriä löydöksiä, eikä mikään tuloksessa kerro, kumpi on kumpaa. Sama perustelu pätee kontteihin sivulla Docker-kuvien SBOM:t ja ohjelmointikielten projekteihin sivulla avoimen lähdekoodin SBOM-generaattorit.

Miksi laiteohjelmiston binääriskannaus joutuu arvaamaan

Binäärianalyysi vertaa puretun laiteohjelmiston merkkijonoja, symboleja ja koodin tunnisteita tunnettuihin komponentteihin ja päättelee sitten versiot. Kun binäärissä on selvää näyttöä, se toimii. Yocto-kuvassa sen on usein arvattava:

• riisutut binäärit, joissa ei ole versiomerkkijonoja;
• staattisesti linkitetty koodi, josta kirjastojen rajat ovat kadonneet;
• käännetty Rust, jossa cratejen rajat katoavat yhteen suoritettavaan tiedostoon;
• backportatut patchit, jotka eivät näy versionumerossa;
• ytimen koodi, jonka konfiguraatio käänsi mukaan tai jätti pois.

Binäärianalyysi on oikea työkalu laiteohjelmistolle, jota et itse rakentanut: toimittajien blobit, ostetut moduulit, laite, jota arvioit. Jos buildia ei ole käytettävissäsi, binäärin analysointi on ainoa vaihtoehto. Päätössääntö on yksinkertainen: jos rakennat sen, tallenna se; jos vain vastaanotat sen, analysoi se ja pyydä toimittajalta SBOM sen buildista.

Missä Yocton oma SBOM- ja CVE-työkalusto on hyvä

Yocto Projectin SBOM-työ on hyvää insinöörityötä, ja se tietää asioita, joita mikään ulkopuolinen työkalu ei voi tietää. Sen dokumentaation mukaan SBOM on ”kuvaus kaikista käyttämistäsi komponenteista, niiden lisensseistä, niiden riippuvuuksista, niiden lähteistä, niihin tehdyistä muutoksista ja korjatuista tunnetuista haavoittuvuuksista”.

create-spdx julkaisuittain

• 4.3 (Nanbield): SPDX-generointi on oletuksena päällä.
• 5.1 (Styhead): oletuksena SPDX 3.0 version 2.2 sijaan sekä vex-luokka, joka antaa ulkoisille CVE-työkaluille niiden tarvitsemat tiedot.
• 5.3 (Whinlatter): SPDX_INCLUDE_COMPILED_SOURCES, joka sisällyttää vain käännöksessä käytetyt lähteet.
• 6.0 (Wrynose, pitkäaikainen tuki): SPDX 2.2 poistettu; SPDX_INCLUDE_KERNEL_CONFIG ja SPDX_INCLUDE_PACKAGECONFIG lisätty; Cargo-, Go-, PyPI-, npm- ja CPAN-luokilla rakennetut reseptit saavat ekosysteemin package URLin.

SBOM kattaa sen, mitä BitBake rakentaa, mukaan lukien natiivit työkalut, jotka se rakentaa build-koneelle. Se on perusteellinen kaikesta, jolla on resepti.

CVE-tila VEX-muodossa SBOM:n sisällä

SPDX 3:ssa build-järjestelmä kirjoittaa kunkin reseptin CVE-tilan VEX-suhteina: paikatusta CVE:stä tulee ”fixed”, linkitettynä patch-tiedostoihin, paikkaamattomasta ”affected” ja ohitetusta ”not affected”, jolloin syy on vaikutuslausuntona. SPDX_INCLUDE_VEX määrää, kuinka paljon otetaan mukaan: none, current (oletus, haavoittuvuudet, joita ei ole jo korjattu upstream-lähteessä) tai all.

CVE_STATUS ja patchin tunniste

CVE_STATUS tallentaa päätöksen CVE:tä kohden syynä ja valinnaisena kuvauksena. Syyt vastaavat tiloja paikattu (backported-patch, cpe-stable-backport, fixed-version ja muut), paikkaamaton (vulnerable-investigating) ja ohitettu (cpe-incorrect, disputed, not-applicable-config, not-applicable-platform, upstream-wontfix). CVE_STATUS_GROUPS soveltaa yhtä päätöstä CVE-ryhmään, ja CVE_PRODUCT asettaa vertailussa käytettävän tuotenimen.

# 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]

cve-check-luokasta sbom-cve-check-luokkaan

cve-check vertasi reseptien nimiä (CVE_PRODUCT) ja versioita haavoittuvuustietoihin. Version 5.2 julkaisutiedotteet varoittavat, että vuoden 2024 alusta lähtien NVD:n ylläpitäjät lakkasivat merkitsemästä monille CVE:ille niiden koskemia CPE:itä, joten ”nykyiset CVE-raportit voivat näyttää hyviltä, mutta todellisuudessa osaa haavoittuvuuksista ei yksinkertaisesti raportoida”. Versio 5.2 teki myös FKIE-syötteestä oletuksen NVD:n sijaan. Yocto 6.0 poisti cve-check-luokan ja korvasi sen sbom-cve-check-luokalla, joka ajaa Bootlinin sbom-cve-check-työkalun SPDX-tulosteen yli. Versioissa 5.0–5.3 sinulla on vielä cve-check; pidä sitä vanhentuneena.

Mihin Yocton SBOM loppuu

Yocto ei näe mitään BitBaken metatietojen ulkopuolelta. Rakensimme core-image-sato-kuvan kahdesti natiivilla 32 vCPU:n ARM64-runnerilla, kerran Yocton SBOM-generoinnin kanssa ja kerran ilman sitä, ja vertasimme Yocton SPDX 3.0.1 -muotoista SBOM:ia, joka kirjoitettiin 1 632 tiedostoksi, CRACI:n tallentamaan CycloneDX-SBOM:iin:

• Komponentit. CRACI:n tallentamassa SBOM:ssa oli jokainen Yocton SBOM:n komponentti sekä 88, jotka siltä puuttuivat: 23 build-koneen pakettia (kuten Ubuntun cpio), 10 GitHub-lähdettä, mukaan lukien GitHub Action actions/upload-artifact, ja 55 muuta buildin aikana haettua lähdettä ja työkalua.
• Rust-cratet. Molemmat luettelivat samat 653 Rust-craten versiota. Rakentamassamme julkaisussa Yocton SBOM luetteli ne vain .crate-tiedostoina latauspaikan kanssa ilman pkg:cargo-package URLia, joten niitä ei voitu verrata tietoturvatiedotteisiin. Yocto 6.0:sta lähtien Cargo-luokalla rakennetuilla resepteillä on package URL itse reseptille, kuten pkg:cargo/librsvg; nykyisessä koodissa yksittäisillä craten latauksilla sitä ei vieläkään ole. Tarkista, mitä oma julkaisusi kirjoittaa.
• Kustannus. Buildi Yocton SBOM-generoinnin kanssa kesti 155 min 40 s ja kirjoitti 1 632 SPDX-tiedostoa. Ilman sitä buildi kesti 88 min 48 s, 43 % vähemmän. SPDX_INCLUDE_SOURCES, SPDX_INCLUDE_COMPILED_SOURCES, SPDX_INCLUDE_KERNEL_CONFIG ja SPDX_INCLUDE_PACKAGECONFIG olivat päällä, joten oletuskonfiguraatio maksaa vähemmän. Yocton oma dokumentaatio varoittaa, että käännetyt lähteet mukaan lukien core-image-minimal-kuvan pakkaamaton SBOM ”voi kasvaa satojen megatavujen koosta useisiin gigatavuihin”.

Natiivit reseptit, kuten cmake, llvm, ninja ja qemu, ovat Yocton SBOM:ssa. Menetelmä, molemmat SBOM:t ja koko raportti ovat sivulla Yocto-buildit CRACI:lla.

Linux-ytimen CVE:t: konfiguraatiokohtainen ongelma

Linux-ytimen projekti ilmoitti 13.2.2024 ryhtyneensä CVE Numbering Authorityksi, ja se antaa CVE-tunnisteita korjauksille auliisti. Sen CVE-dokumentaation mukaan minkä tahansa yksittäisen CVE:n soveltuvuus ”on Linuxin käyttäjän määritettävä”, koska ”emme tiedä käyttötapaustasi emmekä tiedä, mitä ytimen osia käytät”.

Ytimen version vertailu tuottaa siis satoja löydöksiä, joista useimmat koskevat koodia, jota konfiguraatiosi ei koskaan käännä. Neljä laitealustaa neljällä ytimen konfiguraatiolla antaa samasta ytimen versiosta neljä eri vastausta. Tähän on neljä tapaa:

1. Pelkkä versiovertailu. Jokainen version CVE raportoidaan. Suurin mahdollinen kohina.
2. Kuratoidut poissulkulistat. Ytimen CVE-tiedoista generoidut CVE_STATUS-merkinnät. Toukokuussa 2026 oe-core poisti generoidun listansa linux-yocto-reseptiltä, koska sbom-cve-check tekee tämän itse ytimen syöttämästä CVE-listasta, jolloin CVE-raportti pysyi ennallaan ja SPDX pieneni lähes 20 Mt.
3. Suodatus käännetyn perusteella. Kun SPDX_INCLUDE_COMPILED_SOURCES on päällä ytimen reseptissä, improve_kernel_cve_report.py tarkistaa, käytettiinkö CVE:n koskemia tiedostoja ytimen buildissa. Yocton tietoturvamanuaalin mukaan se ”vähentää CVE-vääriä positiivisia 70–80 %”.
4. Konfiguraation tallentaminen. SPDX_INCLUDE_KERNEL_CONFIG (6.0) kirjoittaa ytimen konfiguraation SBOM:iin, jotta vastauksen voi tarkistaa myöhemmin.

Esimerkki. Yksi ytimen CVE verkkoajurissa. Alusta A kääntää ajurin; alusta B ei.

Alusta	Ajuri käännetty?	Versiovertailu	Käännettyjen lähteiden suodatin
A	Kyllä	Raportoidaan	Raportoidaan: koskevat tiedostot käännettiin
B	Ei	Raportoidaan	Ei raportoida: koskevia tiedostoja ei käännetty

Alustakohtaisia ytimen CVE-raportteja varten aja nykyään Yocton käännettyjen lähteiden työkalut kerran kutakin konekonfiguraatiota kohden. Konfiguraatio ratkaisee vastauksen, joten raportin on tultava kunkin konfiguraation buildista.

Välimuistit, peilit ja vendorointi: missä jokaisen tallentajan on oltava tarkkana

• Buildi, joka palauttaa kaiken sstate-välimuistista tai täytetystä DL_DIR-hakemistosta, hakee vähän tai ei mitään. Hakuja seuraavan tallentajan on kuljetettava näyttönsä näiden välimuistien mukana, tai tallenne kutistuu.
• Resepti, joka osoittaa valmiiksi vendoroituun tarballiin, näyttää yhden latauksen, ei sen sisältämiä crateja tai moduuleja.
• Mitä tahansa käytätkin, rakenna julkaisukuvat tunnetusta välimuistin tilasta, pidä peilit omassa hallinnassasi ja vertaa komponenttimääriä buildien välillä.

CRACI:ssa CI-välimuisteista palautetut paketit pysyvät SBOM:ssa, ja kunkin jobin kattavuustila liputtaa sen, mitä tallennus ei nähnyt.

Mitä ajaa: päätöstaulukko

Tilanne	Mitä käyttää	Mitä saat	Mitä vielä puuttuu
Rakennat kuvan GitHub Actionsissa	Tallenna buildi (CRACI); pidä create-spdx, jos luotat sen patch- ja CVE-tilaan	Koneen paketit, haetut lähteet ja Actionit, pkg:cargo-URL jokaiselle cratelle, jatkuva seuranta	Konfiguraatiokohtainen ytimen suodatus: käytä Yocton työkaluja
Rakennat Yoctolla toisessa CI-järjestelmässä tai build-palvelimella	create-spdx ja sbom-cve-check (tai cve-check vanhemmissa julkaisuissa), ytimen suodatus käännetyillä lähteillä	Reseptit, patchit, CVE-tila VEX-muodossa	Erikseen ylläpidetty inventaario koneen paketeista ja haetuista työkaluista
Vastaanotat laiteohjelmistoa, jota et rakenna	Binäärianalyysi ja toimittajalta buildin SBOM	Binääristä päätellyt komponentit	Varmuus versioista, patcheista ja buildin syötteistä
Tarvitset ytimen CVE:t alustakohtaisesti	Yocton käännettyjen lähteiden työkalut konekonfiguraatiota kohden	CVE:t koodille, jonka kukin konfiguraatio kääntää	Muut kuin ytimen komponentit, SBOM:istasi
Sinulla on vain kuvaskanneri	Käytä sitä asennettuihin paketteihin, jos pakettitietokanta säilytetään	Osa ajonaikaisesta pakettiluettelosta	Kaikki sisään käännetty, paikattu tai build-koneelle jäänyt; puhdas tulos ei ole näyttöä

Mitä kukin menetelmä näkee

Komponenttiluokka	Kuvaskanneri	Binäärianalyysi	Yocto create-spdx	Buildin tallennus (CRACI)
Asennetut paketit	Vain jos pakettitietokanta säilytetään	Päätelty tiedostoista	Kyllä	Kyllä, buildin hakemista lähteistä
Staattiset kirjastot	Ei	Päätelty tunnisteista	Kyllä, resepteinä	Kyllä, buildin hakemista lähteistä
Rust-cratet	Ei	Päätelty; cratejen rajat katoavat	.crate-latauksina, ilman cratekohtaista package URLia	Kyllä, jokainen pkg:cargo-package URLilla
Go-moduulit	Ei	Päätelty binääristä	Reseptin moduulilatauksina	Kyllä, kun ne haetaan buildin aikana
Sovelletut patchit ja CVE-tila	Ei	Ei	Kyllä, VEX-muodossa	Ei
Ytimen konfiguraatio	Ei	Ei	Kyllä, SPDX_INCLUDE_KERNEL_CONFIG-asetuksella (6.0)	Ei
Build-koneen työkalut	Ei	Ei	Ei (natiivit reseptit kyllä)	Kyllä
Reseptien ulkopuolelta haetut build-työkalut ja GitHub Actions	Ei	Ei	Ei	Kyllä

Mihin CRACI sijoittuu

GitHub Actionsissa ajettaville Yocto-buildeille CRACI on runneri, jossa on enintään 32 vCPU:ta ja 96 Gt RAM-muistia. Se tallentaa, mitä buildi haki, mukaan lukien build-koneen paketit, GitHub-lähteet ja Actionit sekä muut haetut lähteet, ja jokaiselle Rust-cratelle package URLin: julkaistussa vertailussa jokaisen Yocton SBOM:n komponentin sekä 88, jotka siltä puuttuivat. Se vertaa komponentteja tietoturvatiedotteisiin, arvioi SBOM:n uudelleen aina, kun uusia julkaistaan, ja näyttää, mitkä buildit sisälsivät haavoittuvan riippuvuuden.

BitBake voi jo rajoittaa hakijaansa BB_ALLOWED_NETWORKS-muuttujalla. CRACI:n egress-käytäntö lisää toisen kontrollin runnerille: se tarkistetaan ennen jobin käynnistymistä ja se estää liikenteen virhetilanteessa (fail closed), joten hakijan ohittava skripti tai työkalu ei silti pääse palvelimeen, jota et sallinut.

Toimitusketjun kattavuuden osalta CRACI:n SBOM voi korvata create-spdx-luokan. Yocton SPDX sisältää kuitenkin edelleen sovelletut patchit ja korjatuiksi merkityt CVE:t, joita CRACI ei tallenna, joten pidä create-spdx päällä, jos luotat niihin. CRACI:n dokumentaatiossa on esimerkki, joka rakentaa core-image-sato-kuvan. Miksi tallentaminen voittaa skannauksen yleisesti, kerrotaan sivulla buildin aikaiset SBOM:t; Yocto-työkaluja verrataan sivuilla sulautettujen järjestelmien tietoturvatyökalut vertailussa ja CRACI vs. Timesys Vigiles.

Milloin CRACI ei ole vastaus

• Luotat patch-tason CVE-tilaan, kuten CVE_STATUS-päätöksiin ja paikattuihin tai ohitettuihin CVE:ihin VEX-muodossa. Se on Yocton SPDX:ssä: pidä se.
• Tarvitset konfiguraatiokohtaiset ytimen CVE-raportit jo nyt. Käytä Yocton käännettyjen lähteiden työkaluja.
• Et rakenna laiteohjelmistoa itse. Käytä binäärianalyysia.
• Yocto-buildisi ajetaan GitHub Actionsin ulkopuolella tai niiden on toimittava omalla infrastruktuurillasi. CRACI tarjoaa nyt hallinnoituja runnereita eurooppalaisella infrastruktuurilla; muut CI-järjestelmät ja asiakkaan ylläpitämät runnerit ovat tiekartalla.
• Tarvitset Yocto-jobin SBOM:n nimenomaan SPDX-muodossa. Julkaistussa vertailussa CRACI:n SBOM oli CycloneDX-muodossa; Yocton oma SBOM on SPDX.

Rakennatko verkkoon kytkettyjä laitteita EU:n markkinoille? Lue mitä CRA vaatii, miten VEX toimii ja miten CRACI sopii tietoliikenne- ja verkkolaitteisiin, teolliseen IoT:hen ja kuluttajaelektroniikkaan.

Yocton CVE-tarkistukset ja SBOM:t: usein kysytyt kysymykset

Miksi SCA-työkalumme ei pysty skannaamaan Yocto-pohjaisia tuotteitamme?

Koska useimmat SCA-työkalut lukevat manifesteja, lukitustiedostoja tai kuvan pakettitietokantaa, ja Yocto-buildi ratkaisee sisältönsä BitBaken sisällä. Tuotantokuvista jätetään usein pakettitietokanta pois, staattiset kirjastot ja Rust-cratet käännetään binääreihin, reseptien patchit jättävät upstream-versionumerot ennalleen, eivätkä build-koneen työkalut koskaan päädy kuvaan.

Voinko skannata Yocto-kuvan tai laiteohjelmiston Trivyllä, Grypellä tai binääriskannerilla?

Voit, ja saat osittaisen vastauksen. Kuvaskanneri lukee asennetut paketit, jos pakettitietokanta säilytetään, eikä näe sisään käännettyä. Binääriskanneri päättelee komponentit merkkijonoista ja tunnisteista ja joutuu arvaamaan riisuttujen binäärien, staattisen koodin ja käännetyn Rustin kohdalla. Kumpikaan ei näe build-konetta eikä patcheja, joita resepti sovelsi.

Sisältääkö Yocton SBOM Rust-cratet ja Go-moduulit?

Se luettelee ne niitä käyttävän reseptin lähteinä. Rakentamassamme julkaisussa jokainen Rust-crate näkyi .crate-latauksena latauspaikan kanssa ilman pkg:cargo-package URLia. Yocto 6.0:sta lähtien Cargo- ja Go-luokilla rakennetut reseptit saavat ekosysteemin package URLin itse reseptille, ei kullekin cratelle tai moduulin lataukselle.

Miksi skannerini raportoi CVE:itä, jotka Yocto-reseptimme jo paikkaavat?

Koska se vertaa versionumeroita. Yocto-resepti säilyttää upstream-version ja soveltaa tietoturvakorjaukset patcheina, jotka on merkitty CVE:-rivillä tai kirjattu CVE_STATUS-muuttujaan. Versioaluevertailu ei näe patchia. Yocton oma SPDX kirjaa nämä CVE:t korjatuiksi ja linkittää ne patch-tiedostoihin.

Mikä korvasi cve-checkin Yoctossa?

sbom-cve-check-luokka Yocto 6.0:ssa. Se ajaa Bootlinin sbom-cve-check-työkalun buildin SPDX-tulosteen yli. Julkaisuissa 5.0–5.3 on vielä cve-check, joka vertasi reseptien nimiä ja versioita; version 5.2 julkaisutiedotteet varoittavat, että sen raporteista voi puuttua haavoittuvuuksia, koska monissa CVE:issä ei enää ole CPE-tietoja.

Miten saan Linux-ytimen CVE:t omalle ytimen konfiguraatiolleni?

Ota SPDX_INCLUDE_COMPILED_SOURCES käyttöön ytimen reseptissä ja aja improve_kernel_cve_report.py, joka tarkistaa, käännettiinkö kunkin CVE:n koskemat tiedostot. Yocton tietoturvamanuaalin mukaan se vähentää CVE-vääriä positiivisia 70–80 %. Aja se kutakin konekonfiguraatiota kohden, koska jokainen konfiguraatio kääntää eri koodia.

Vaikuttaako shared state -välimuisti SBOM:iin?

Voi vaikuttaa. sstate-välimuistista palautetut tehtävät ohittavat haun ja käännöksen, joten näiden vaiheiden seuraamiseen perustuva työkalu näkee vähemmän. Yocton create-spdx toimii reseptien metatietojen pohjalta. Menetelmästä riippumatta rakenna julkaisukuvat tunnetusta välimuistin tilasta ja vertaa komponenttimääriä buildien välillä.

Riittääkö Yocton sisäänrakennettu SBOM CRA:ta varten?

CRA edellyttää SBOM:ia, joka kattaa vähintään ylimmän tason riippuvuudet, ja Yocton SBOM on perusteellinen siitä, mitä BitBake rakentaa. Se ei luettele build-koneen paketteja, GitHub Actionseja eikä reseptien ulkopuolelta haettuja työkaluja. Riittääkö se, on sinun päätöksesi; SBOM on näyttöä prosessiasi varten, ei itsessään vaatimustenmukaisuutta.