Yocto-SBOM ja buildit CRACI:lla

Näin generoit SBOM:n Yoctolla

OpenEmbedded-build-järjestelmä kirjoittaa SPDX-SBOM:t create-spdx-luokan avulla. Se, onko luokka käytössä ja mitä SPDX-versiota se kirjoittaa, riippuu Yocto-julkaisusta:

• Kirkstone (4.0): oletuksena pois päältä. Lisää INHERIT += "create-spdx". SPDX 2.2.
• Nanbield (4.3): SBOM-generointi on oletuksena käytössä tästä julkaisusta alkaen.
• Scarthgap (5.0): oletuksena käytössä, SPDX 2.2. SPDX 3.0 on saatavilla create-spdx-3.0-luokalla.
• Styhead (5.1) ja uudemmat: oletuksena käytössä, SPDX 3.0.

Asetus tehdään konfiguraatiotiedostossa, kuten conf/local.conf. Nykyisessä julkaisussa lisättävää ei yleensä ole; poista se käytöstä komennolla INHERIT_DISTRO:remove = "create-spdx".

# conf/local.conf

# Kirkstone (4.0): SBOM generation is off by default, so turn it on
INHERIT += "create-spdx"

# Scarthgap (5.0): switch the output from SPDX 2.2 to SPDX 3.0
INHERIT_DISTRO:remove = "create-spdx"
INHERIT_DISTRO:append = " create-spdx-3.0"

# Any release: indented JSON you can read in an editor
SPDX_PRETTY = "1"

Muut SPDX_-muuttujat lisäävät yksityiskohtia. SPDX_INCLUDE_SOURCES kuvaa kunkin isäntätyökalun ja kohdepaketin taustalla olevat lähdetiedostot, mikä kasvattaa tuotosta huomattavasti. Uusimmat julkaisut tuovat asetukset ytimen konfiguraatiolle, PACKAGECONFIG-ominaisuuksille, toimittajatiedoille sekä package URLeille Cargo-, Go-, PyPI-, npm- ja CPAN-lähteistä.

Mihin SBOM-tiedostot päätyvät

Kun rakennat levykuvan, ylimmän tason SBOM ilmestyy sen viereen tiedostoksi IMAGE-MACHINE.spdx.json build-hakemiston sisällä olevaan hakemistoon tmp/deploy/images/MACHINE/. Niihin liittyvät tiedostot ovat samassa hakemistossa ja hakemistossa tmp/deploy/spdx. Kirkstonessa reseptikohtaiset dokumentit tulevat IMAGE-MACHINE.spdx.tar.zst-arkistona.

bitbake core-image-minimal

# The image SBOM
ls tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.spdx.json

# Per-recipe and package documents
ls tmp/deploy/spdx/

# Current releases: an SBOM for one recipe, from its metadata only
bitbake busybox -c create_recipe_sbom

CycloneDX meta-cyclonedx-kerroksella

Yocto itse kirjoittaa vain SPDX:ää. CycloneDX:ää varten meta-cyclonedx-kerros generoi SBOM:n levykuvan juuritiedostojärjestelmästä sekä erillisen VEX-tiedoston niistä paikatuista ja ohitetuista CVE:istä, jotka build-järjestelmä tuntee. Hae kerroksen julkaisuasi vastaava haara, lisää se kerroksiisi ja peri sen luokka:

# In your sources directory, on the branch for your release
git clone https://github.com/iris-GmbH/meta-cyclonedx.git
cd meta-cyclonedx
git checkout scarthgap

# conf/bblayers.conf
BBLAYERS += "${BSPDIR}/sources/meta-cyclonedx"

# conf/local.conf
INHERIT += "cyclonedx-export"
# Optional: include build-time packages, not only what is in the image
CYCLONEDX_RUNTIME_PACKAGES_ONLY = "0"

Tiedostot päätyvät levykuvan viereen hakemistoon DEPLOY_DIR_IMAGE päätteillä .cyclonedx.bom.json ja .cyclonedx.vex.json. Oletus on CycloneDX 1.6, ja sen voi asettaa muuttujalla CYCLONEDX_SPEC_VERSION. Oletuksena mukaan otetaan vain ajonaikaiset paketit, mikä pitää SBOM:n pienenä, mutta siitä voi jäädä pois komponentteja, jotka päätyvät levykuvaan ilman, että ne asennetaan paketteina.

Mitä Yocton SBOM:sta jää pois

Yocton SBOM on perusteellinen sen suhteen, mitä BitBake rakentaa. SPDX 3:ssa se kattaa levykuvan, jokaisen reseptin build-aikaiset natiivireseptit mukaan lukien, niiden lähteet, sovelletut paikkaukset ja korjatuiksi merkityt haavoittuvuudet. core-image-sato-kuvalle tämä tarkoitti 1,632 erillistä tiedostoa. Nähdäksemme, mitä siitä jää pois, rakensimme levykuvan CRACI-runnerilla, natiivi ARM64 ja 32 vCPU:ta, ja vertasimme Yocton SBOM:ia CRACI:n tallentamaan komponentti kerrallaan, kun nimet oli ensin normalisoitu kaikissa noissa tiedostoissa.

CRACI:n SBOM:n 953 komponentista 865 oli myös Yocton SBOM:ssa. Yksikään ei ollut vain Yocton SBOM:ssa. Erot ovat siinä, mitä Yocto ei näe, ja siinä, miten se tunnistaa luettelemansa.

Rust-cratet ilman package URLia

Molemmat SBOM:t sisältävät samat 653 versiota 559 Rust-cratesta, kuten cairo-rs ja zune-jpeg, jotka librsvg kääntää mukaansa. Yocto luettelee jokaisen niistä vain .crate-tiedostona ja crates.io-latausosoitteena sen käyttävän reseptin sisällä. Yhdelläkään ei ole pkg:cargo-package URLia. CRACI tallentaa jokaisen craten sellaisen kanssa.

Tämä ratkaisee, voitko valvoa niiden haavoittuvuuksia. Haavoittuvuuksien vertailu perustuu package URLeihin: craten tietoturvatiedote nimeää sen muodossa pkg:cargo/..., eikä toisen reseptin lähdeluettelossa oleva tiedostonimi anna SBOM- ja haavoittuvuustyökaluille mitään, mihin sitä verrata. Pelkällä Yocton SBOM:lla levykuvasi haavoittuva crate jää raportoimatta.

CRACI:n SBOM:lla jokaista cratea verrataan tietoturvatiedotteisiin, jokainen buildin paketti näyttää haavoittuvuustilansa, ja CRACI arvioi SBOM:n jatkuvasti uudelleen uusien tietoturvatiedotteiden julkaisun myötä, kauan sen jälkeen kun buildi valmistui.

Mitä vain CRACI löysi

Yocton SBOM:sta puuttuneet 88 komponenttia tulivat BitBaken metatietojen ulkopuolelta:

• 23 isäntäpakettia, jotka on asennettu build-koneelle, kuten Ubuntun cpio 2.15, libc6, locales ja python3-jinja2. BitBake toimii niiden varassa, eikä Yocton SBOM luettele niitä.
• 10 GitHub-lähdettä, mukaan lukien patchelf, btrfs-progs ja GitHub Action actions/upload-artifact, kiinnitettyinä committiin, jolla työnkulku ajettiin
• Muut buildin aikana haetut lähteet ja työkalut, kuten pseudo-prebuilt, tzdata ja Pythonin build-työkalut, kuten hatchling ja setuptools_scm

Yhtäkään näistä ei ole asennettu levykuvaan, mutta kaikki ovat buildin kriittisellä polulla: vaarantunut isäntätyökalu tai Action voi vaarantaa levykuvasi olematta koskaan osa sitä. CRACI luettelee ne, koska se näkee buildiin tulevan liikenteen.

Mitä sisäänrakennettu SBOM maksaa

Yocton SBOM-generointi ei ole ilmaista. Samalla 32 vCPU:n runnerilla buildi sen kanssa kesti 155 min 40 s ja kirjoitti SBOM:n 1,632 erillisenä SPDX-tiedostona. Buildi ilman sitä, CRACI:n tallentaessa, kesti 88 min 48 s. CRACI:n hinnalla $0.002 vCPU-minuutilta se on noin $9.96 vastaan $5.68 buildia kohden, ennen kuin lasketaan aika, jonka tiimisi käyttää odottamiseen.

Ero on suurempi GitHubin ylläpitämiin runnereihin verrattuna. CRACI ajaa buildit noin kaksi kertaa nopeammin nopeamman laitteiston, lyhyempien jonotusaikojen ja välimuistin ansiosta, joten sama buildi Yocton SBOM:n kanssa GitHubin ylläpitämällä 32-ytimisellä ARM64-runnerilla kestäisi noin 5 h 11 min. Hinnalla $0.050 minuutilta se tekee $15.60. CRACI-buildi maksaa $5.68: 64% vähemmän eli noin 2,7 kertaa halvemmalla. GitHubin listahinnat syyskuulta 2026 ennen sisältyvää käyttöä.

Yocton SPDX-tuotos sisältää kuitenkin asioita, joita CRACI ei tallenna, kuten reseptin soveltamat paikkaukset ja CVE:t, jotka se merkitsee korjatuiksi. Jos prosessisi nojaa niihin, pidä create-spdx käytössä ja käytä CRACI:n SBOM:ia sen rinnalla. Muussa tapauksessa CRACI:n SBOM kattaa yksinään jokaisen Yocton SBOM:n komponentin ja enemmän.

Miksi tällä on merkitystä toimitusketjun tietoturvalle

Se, mitä buildiin menee, ratkaisee, mitä siitä tulee ulos, olipa se asennettu levykuvaan tai ei. Hyökkääjät tietävät tämän, ja viimeaikaiset toimitusketjuhyökkäykset ovat tulleet sisään juuri buildin kautta:

• Hyökkäykset piiloutuvat buildiin. xz utilsin takaovi (CVE-2024-3094) oli versioissa 5.6.0 ja 5.6.1. Sen laukaisin oli julkaisutarballeissa eikä Git-repositoriossa, ja haitallinen koodi päätyi kirjastoon sitä rakennettaessa. Lähdekoodin lukeminen ei paljastanut sitä; sen tietäminen, minkä tarballin buildi tarkalleen haki, paljastaa.
• Myös CI-riippuvuudet ovat kohteita. Maaliskuussa 2025 CISA raportoi, että GitHub Actionin tj-actions/changed-files jokainen versio oli vaarantuneena kolmen päivän ajan. Action ajetaan build-jobisi sisällä, minkä vuoksi CRACI luettelee työnkulkusi käyttämät Actionit kiinnitettyinä ajettuun committiin.
• Rust-cratet katoavat binääreihin. Cargo kääntää cratet niitä käyttäviin ohjelmiin, joten haavoittuva crate toimitetaan levykuvan sisällä ilman, että se koskaan näkyy pakettina. Jos SBOM luettelee sen vain tiedostonimellä, haavoittuvuustyökalut eivät myöskään pysty vertaamaan sitä. Valmiin binäärin skannaaminen jälkikäteen joutuu arvaamaan, mitä siihen meni; buildin tallentaminen ei.
• Et voi reagoida siihen, mitä et näe. Kun crateen tai build-työkaluun kohdistuva tietoturvatiedote julkaistaan, sinun on tiedettävä, mitkä buildit käyttivät sitä. CRACI säilyttää jokaisen buildin SBOM:n ja näyttää, missä buildeissa haavoittuva riippuvuus oli, suora tai transitiivinen, joten tiedät, minkä ajanjakson haavoittuvuus koski sinua. Tämä toimii vain, kun jokaisella komponentilla on package URL, johon verrata.
• Buildin pitäisi tavoittaa vain se, mitä se tarvitsee. CRACI:n egress-käytäntö estää yhteydet palvelimiin, joita buildi ei tarvitse, joten vaarantunut riippuvuus, joka yrittää lähettää salaisuutesi hyökkääjän palvelimelle, pysäytetään, myös hyökkäyksessä, jota kukaan ei ole ennen nähnyt.

Asiakkaat ja sääntely, kuten EU:n kyberkestävyyssäädös (Cyber Resilience Act), edellyttävät myös verkkoon liitettyjen laitteiden valmistajilta tietoa siitä, mitä niiden tuotteisiin menee. Koko buildin kattava SBOM on näyttöä, joka kestää, kun sitä kysytään.

Miksi Yocto-buildeja on vaikea ajaa CI:ssä

Koko levykuvan buildi kääntää työkaluketjun, ytimen ja satoja paketteja lähdekoodista. Useimpien CI-palveluiden tavallisilla 2-ytimisillä runnereilla se voi kestää tunteja, joten moni sulautettujen järjestelmien tiimi pitää erillistä build-palvelinta pöydän alla tai räkissä, ja siitä palvelimesta tulee jälleen yksi kone, joka pitää paikata, varmuuskopioida ja selittää auditoijalle.

Yocto-buildi myös lataa paljon: lähdetarballeja, Git-repositorioita ja paikkauksia upstream-projekteista ja peileistä. Juuri nämä lataukset SBOM:si on pystyttävä selittämään, ja juuri niistä sääntely, kuten EU:n kyberkestävyyssäädös (Cyber Resilience Act), edellyttää verkkoon liitettyjen laitteiden valmistajien tietävän ja pitävän kirjaa.

Mitä CRACI antaa Yocto-buildille

BitBakelle mitoitetut runnerit

CRACI-runnerit skaalautuvat 1–32 laskentayksikköön, ja kukin yksikkö on 1 vCPU ja 3 Gt RAM-muistia. Yocto-buildi voi pyytää suurinta kokoa, 32 vCPU:ta ja 96 Gt RAM-muistia, suoraan työnkulusta. Jobit ajetaan eristetyissä virtuaalikoneissa, ja ajot näkyvät edelleen GitHubissa kuten mikä tahansa muu Actions-jobi.

Minuutit mitataan sekunneittain ja laskutetaan vCPU-minuuteittain, joten suuri runneri maksaa minuutilta enemmän ja valmistuu nopeammin. Ajantasaiset hinnat löydät hinnoittelusta.

Verkkoyhteydet, joista päätät itse

BitBake voi jo rajata hakijansa (fetcher) listaan palvelimia BB_ALLOWED_NETWORKS-muuttujalla. CRACI lisää runnerille toisen kontrollin: egress-käytännön, joka tarkistetaan ennen jobin alkua ja joka toimii fail closed -periaatteella, joten resepti, skripti tai vaarantunut työkalu, joka kiertää hakijan, ei silti tavoita palvelinta, jota et sallinut. CRACI hälyttää käytäntörikkomuksista.

Tallenne siitä, mitä buildi haki

CRACI havainnoi liikenteen, jonka jobi lähettää paketti- ja lähdepalvelimille, ja tallentaa sen buildin näytöksi. Yocto-buildissa tämä tarkoittaa riippumatonta selvitystä lähteistä, jotka todella tulivat verkon yli, Yocton itse kirjoittaman SBOM:n rinnalla.

Minimaalinen työnkulku

CRACI:n dokumentaation Yocto-esimerkki rakentaa core-image-sato-kuvan kohteelle qemux86-64. CRACI:n kannalta olennaiset osat ovat runnerin koko ja hakijan konfiguraatio, joka käyttää Yocton virallista lähdepeiliä:

jobs:
  build:
    runs-on: craci
    steps:
      - uses: cracicorp/setup@v1
        with:
          size: "32"
      # install the host packages from the Yocto quick start, then:
      - run: |
          echo 'SOURCE_MIRROR_URL = "https://downloads.yoctoproject.org/mirror/sources/"' >> conf/local.conf
          echo 'BB_ALLOWED_NETWORKS = "downloads.yoctoproject.org"' >> conf/local.conf
          bitbake core-image-sato

Dokumentaation ohjeessa on koko työnkulku isäntäriippuvuuksineen ja lokaaliasetuksineen, ja runnerin konfiguraatioviite luettelee kaikki asetukset.

Hyvä tietää

• Buildit ajetaan GitHub Actionsista CRACI:n hallinnoiduilla runnereilla eurooppalaisella infrastruktuurilla. Asiakkaan omat runnerit ja muut CI-järjestelmät ovat tiekartalla.
• Ohjaa BitBake peileihin, jotka CRACI näkee, kuten Yocton viralliseen lähdepeiliin, äläkä mielivaltaisiin palvelimiin. Dokumentaation ohje näyttää toimivan kokoonpanon.
• Lataushakemiston ja jaetun tilan välimuistin (shared state cache) säilyttäminen ajojen välillä tekee toistuvista buildeista nopeita.
• Natiivit ARM64-runnerit ovat saatavilla samaan hintaan kuin x86-64.

Rakennatko verkkoon liitettyjä laitteita EU:n markkinoille? Lue mitä CRA vaatii ja miten CRACI toimii teollisessa IoT:ssä ja kuluttajaelektroniikassa. Käytätkö Black Duckia? Lue, miten Black Duckin BitBake-tunnistin eroaa. Vertailetko Yocton SBOM-työkaluja? Katso CRACI vs. Timesys Vigiles.

Yocto-SBOM:t ja CRACI: usein kysytyt kysymykset

Generoiko Yocto SBOM:n?

Kyllä. OpenEmbedded-build-järjestelmä generoi SPDX-SBOM:n oletuksena Yocto 4.3:sta (Nanbield) lähtien create-spdx-luokan avulla. Levykuvalle se kirjoittaa tiedoston IMAGE-MACHINE.spdx.json hakemistoon tmp/deploy/images/MACHINE/, ja tiedosto kattaa komponentit, lisenssit, riippuvuudet, lähteet, sovelletut paikkaukset ja korjatut haavoittuvuudet. Kirkstonessa (4.0) ota se käyttöön lisäämällä INHERIT += "create-spdx".

Mitä SPDX-versiota Yocto tuottaa?

Oletuksena SPDX 3.0:aa Yocto 5.1:stä (Styhead) lähtien; se korvasi oletuksena 2.2:n. Scarthgap (5.0) tuottaa oletuksena SPDX 2.2:ta ja voi siirtyä 3.0:aan create-spdx-3.0-luokalla.

Miten saan Yoctosta CycloneDX-SBOM:n?

Lisää meta-cyclonedx-kerros julkaisuasi vastaavasta haarasta ja peri cyclonedx-export tiedostossa local.conf. Se kirjoittaa levykuvan viereen .cyclonedx.bom.json-SBOM:n ja .cyclonedx.vex.json-tiedoston, oletuksena CycloneDX 1.6 -muodossa.

Mitä Yocton SBOM:sta puuttuu?

Rinnakkain tehdyssä core-image-sato-buildissa CRACI:n tallentamassa SBOM:ssa olivat kaikki 865 komponenttia Yocton SBOM:sta ja lisäksi 88 muuta: build-koneen isäntäpaketit, kuten Ubuntun cpio, GitHub-lähteet ja Actionit sekä muut buildin aikana haetut lähteet. Yocto myös luettelee 653 Rust-crate-versiotaan vain tiedostonimellä ja latausosoitteella, ilman package URLia, johon haavoittuvuuksien vertailu perustuu. Miksi yleiskäyttöiset skannerit jättävät huomaamatta vielä enemmän, kerrotaan sivulla miksi SBOM-skannerit eivät näe kaikkea Yocto-buildeissa.

Voinko valvoa Yocto-buildin haavoittuvuuksia?

Kyllä, CRACI:lla. Haavoittuvuuksien vertailu perustuu package URLeihin, ja Yocton sisäänrakennettu SBOM luettelee Rust-cratet vain tiedostonimellä ja latausosoitteella, joten niitä ei voi verrata. CRACI tallentaa Rust-cratet ja build-koneen paketit niillä package URLeilla, joita vasten tietoturvatiedotteet julkaistaan (pkg:cargo, pkg:deb), mukaan lukien kaikki 653 crate-versiota core-image-sato-kuvassa. Se näyttää kunkin paketin haavoittuvuustilan ja arvioi SBOM:n jatkuvasti uudelleen uusien tietoturvatiedotteiden julkaisun myötä.

Voiko CRACI korvata Yocton SBOM:n?

Toimitusketjun kattavuuden osalta kyllä. Samassa vertailussa CRACI:n SBOM:ssa oli jokainen Yocton sisäänrakennetun SBOM:n komponentti, 88 lisää ja package URL jokaiselle Rust-cratelle, ja buildi ilman Yocton SBOM-generointia kesti 43 % vähemmän aikaa. Yocton SPDX-tuotos sisältää silti reseptien metatietoja, joita CRACI ei tallenna, kuten sovelletut paikkaukset ja CVE:t, jotka resepti merkitsee korjatuiksi. Jos tarvitset niitä, pidä create-spdx käytössä.

Pystyykö CRACI-runneri koko Yocto-levykuvan buildiin?

CRACI-runnerit skaalautuvat 32 vCPU:hun ja 96 Gt:n RAM-muistiin asti, ja koko asetetaan työnkulussa. CRACI:n dokumentaatiossa on Yocto-esimerkki, joka rakentaa core-image-sato-kuvan suurimmalla koolla.

Mitä CI:tä Yocto-buildi CRACI:lla käyttää?

GitHub Actionsia. Työnkulkusi ajetaan CRACI:n hallinnoiduilla runnereilla, ja ajot näkyvät GitHubissa kuten mikä tahansa muu Actions-jobi. Muut CI-järjestelmät ja asiakkaan omat runnerit ovat tiekartalla.