Mitä avoimen lähdekoodin SBOM-generaattorit ohittavat

Näin generoit SBOM:n kullakin työkalulla

Kukin työkalu on yksi komento lähdekoodihakemistolle tai konttikuvalle, CycloneDX- tai SPDX-tulosteella:

# Syft: a source directory or a container image
syft ./my-project -o cyclonedx-json=sbom.cdx.json
syft my-image:latest -o spdx-json=sbom.spdx.json

# Trivy: a filesystem or a container image
trivy fs --format cyclonedx --output sbom.cdx.json .
trivy image --format spdx-json --output sbom.spdx.json my-image:latest

# cdxgen: the current directory, optionally with a project type
cdxgen -o bom.json .
cdxgen -t js -o bom.json .

Komennot ovat helppo osa. Se, mitä tiedostoon päätyy, riippuu siitä, mitä kukin työkalu lukee, eivätkä ne lue samoja asioita.

Mitä kukin työkalu lukee

Työkalu	Lähdekoodihakemisto	Konttikuva	Hyvä tietää
Syft	Hakemistoille tarkoitettu oletuskatalogoijien joukko, joka lukee ilmoitetut riippuvuudet	Konttikuville tarkoitettu oletuskatalogoijien joukko, joka lukee asennetut paketit	Katalogoijat valitaan skannaustyypin mukaan. syft cataloger list näyttää, mitkä ajetaan, ja --select-catalogers lisää tai poistaa niitä.
Trivy	Lukitustiedostot, Node.js:lle package-lock.json, yarn.lock, pnpm-lock.yaml ja bun.lock	Node.js:lle package.json-tiedostot hakemiston node_modules alla	Jättää kehitysriippuvuudet pois, ellet anna valitsinta --include-dev-deps.
cdxgen	Ensisijaisesti lukitustiedostot, joissa ovat mukana kehitysriippuvuudet; Node.js:lle se jäsentää myös koodin importit	Tuettu	Aseta projektityyppi valitsimella -t rajataksesi, mitä se etsii.

Miksi ne eroavat samassa repositoriossa

Osoita kaikki kolme samaan commitiin, niin saat kolme eri listaa. Mikään niistä ei ole rikki. Kukin noudattaa omia dokumentoituja sääntöjään:

• Ei lukitustiedostoa, ei riippuvuuksia. Express 5.2.1 ei sisällä lukitustiedostoa. Puhtaassa checkoutissa työkalulla, joka ratkaisee riippuvuudet lukitustiedostoista tai asennetuista paketeista, ei ole kumpaakaan, joten package.json-tiedostossa ilmoitetut npm-riippuvuudet eivät koskaan päädy SBOM:iin. Se kirjoittaa silti kelvollisen dokumentin siitä, mitä muuta se tunnisti.
• Asennettu vai ilmoitettu. Se, ajoitko asennuksen ennen skannausta, voi merkitä enemmän kuin se, mitä työkalua käytät. Saman repositorion asennetussa kopiossa yksi Syftin katalogoija-asetus ratkaisee, näkyvätkö asennetut npm-paketit lainkaan.
• Kehitysriippuvuudet. Trivy jättää ne oletuksena pois ja cdxgen ottaa ne mukaan, joten sama lukitustiedosto antaa kaksi vastausta kysymykseen "mitä tässä projektissa on".
• Nimeäminen ja versiot. Työkalut tunnistavat osan komponenteista eri package URL -tyypeillä, tai yksi kiinnittää GitHub Actionin commitin SHA-tiivisteeseen siinä missä toinen raportoi tagin. Väärään tunnisteeseen perustuva haavoittuvuushaku antaa itsevarman väärän vastauksen.
• Ei manifestia lainkaan. anthropics/claude-code-repositoriossa ei ole riippuvuusmanifestia, ja sen npm-paketti paketoi valmiiksi käännetyn binäärin. Se, mitä kukin työkalu palauttaa, kertoo enemmän työkalusta kuin projektista.

Mitä kaikki ohittavat: piilotetut riippuvuudet

Syvempi rajoitus on yhteinen. Skanneri lukee lukitustiedoston tai buildin tuotoksen ja päättelee siitä jälkikäteen, mitä buildiin meni. Kaikki, mitä buildi haki näiden tiedostojen ulkopuolelta, jää SBOM:n ulkopuolelle. Nämä ovat piilotettuja riippuvuuksia:

• Asennushookit. npm:n preinstall- ja postinstall-skriptit ajetaan asennuksen aikana, ja ne voivat ladata lisää koodia. Näin Shai-Hulud-mato toimi.
• Build-skriptit, kuten Rustin build-skriptit, jotka lataavat tarvitsemansa buildin aikana.
• Peruskonttikuvat ja niiden käyttöjärjestelmäkerrokset konttibuildissa, joita mikään kielen lukitustiedosto ei listaa.
• CI-välimuisteista palautetut paketit, jotka eivät välttämättä vastaa nykyistä lukitustiedostoa. Katso mitä GitHub Actionsin välimuisti piilottaa.
• Build-työkalut, jotka asennusvaiheet asentavat omine riippuvuuspuineen.
• Buildin aikana ratkaistut transitiiviset versiot, kun lukitustiedosto puuttuu, on vanhentunut tai frozen-asennus ei käytä sitä. Katso transitiiviset riippuvuudet.

Tuotoksen skannaaminen jälkikäteen ei sulje aukkoa. Valmis binääri, varsinkin käännetty koodi kuten Rust, jättää skannerin arvailemaan, mitä siihen meni. Kaupalliset SCA-skannerit toimivat samanlaisista tiedostoista ja jakavat samat sokeat pisteet. CRACI on löytänyt haavoittuvia paketteja, joita Snyk ja Aikido eivät raportoineet, koska komponentit eivät koskaan olleet siinä, mitä ne skannasivat.

Saman ongelman Yocto-buildeissa käsittelee miksi SBOM-skannerit ohittavat sen, mitä Yocto-buildeissa on.

Työkalut ovat myös osa toimitusketjuasi

Skanneri ajetaan CI:ssäsi pääsyllä koodiisi ja usein myös salaisuuksiisi. Maaliskuussa 2026 Aqua Securityn tietoturvatiedote (CVE-2026-33634) kuvasi haitallisen Trivy v0.69.4 -julkaisun sekä myrkytetyt trivy-action- ja setup-trivy-tagit, jotka varastivat tunnistetietoja CI-runnereilta. Kiinnitä skanneri-actionit täysiin commit-SHA-tiivisteisiin ja tarkista tiedotteesta käyttämäsi versiot.

Näin tarkistat oman SBOM:isi

1. Aja kaksi generaattoria samalle commitille ja vertaa niiden raportoimia package URL -tunnisteita.
2. Tarkista, onko repositorioon tallennettu lukitustiedosto ja asentaako CI siitä frozen-asennuksella.
3. Skannaa sekä asennusvaiheen jälkeen että ennen sitä, ja vertaa.
4. Vertaa listaa siihen, mitä build-lokisi näyttää ladatun, asennusvaiheet ja välimuistin palautukset mukaan lukien.

Jos listat eroavat, julkaisemasi SBOM riippuu siitä, minkä työkalun satuit ajamaan, ei siitä, mitä toimitit.

Kirjaa buildi sen sijaan

CRACI näkee liikenteen; skannerit eivät. Se on GitHub Actions -runneri, joka näkee kuhunkin buildiin tulevan verkkoliikenteen, joten sen SBOM kirjaa jokaisen paketin, jonka jobi haki, puun jokaisella tasolla, piilotetut riippuvuudet ja CI-välimuisteista palautetut paketit mukaan lukien. Ei ole hakemistoa, johon osoittaa, eikä katalogoijaa valittavana. Kun kirjaus ei nähnyt kaikkea, esimerkiksi koska jobi salli valvomatonta liikennettä, SBOM kertoo sen kattavuustilallaan.

Kirjaaminen on tärkeää myös siksi, että buildit ovat harvoin toistettavia. Rakenna sama commit kahdesti peräkkäin, ja paketinhallinta voi ratkaista ja asentaa eri järjestyksessä, joten toinen buildi voi sisältää eri paketit. Vain julkaisun tuottaneen buildin aikana kirjattu SBOM todistaa, mitä julkaisu sisältää.

Pidä Syft tai Trivy kolmansien osapuolten konttikuville ja binääreille, joita et itse rakentanut. Omista julkaisuistasi lue buildin aikaiset SBOM:t tai varaa demo ja vertaa kirjattua SBOM:ia nykyisen työkalusi SBOM:iin yhdessä repositoriossasi.

Avoimen lähdekoodin SBOM-generaattorit: usein kysytyt kysymykset

Kumpi on parempi SBOM:eihin, Syft vai Trivy?

Ne on tehty eri tehtäviin. Syft on SBOM:ien generointiin erikoistunut työkalu, jossa on monta katalogoijaa ja allekirjoitetut attestaatiot; Trivy on tietoturvaskanneri, joka kirjoittaa SBOM:ja yhtenä tulosteistaan. Molemmat lukevat edessään olevat tiedostot, joten samassa repositoriossa suurempi ero on yleensä se, onko lukitustiedosto tallennettu ja asennettiinko riippuvuudet ennen skannausta.

Miksi SBOM:ini ei näytä riippuvuuksia?

Useimmiten siksi, että repositorioon ei ole tallennettu lukitustiedostoa eikä mitään asennettu ennen skannausta. Lukitustiedostoja tai asennettuja paketteja lukevalla generaattorilla ei silloin ole mitään luettavaa, ja se kirjoittaa silti kelvollisen SBOM:n. Tallenna lukitustiedosto tai skannaa asennusvaiheen jälkeen.

Ottaako Trivy kehitysriippuvuudet mukaan SBOM:iin?

Ei oletuksena. Trivyn Node.js-dokumentaation mukaan se ei raportoi kehitysriippuvuuksia, ellet anna valitsinta --include-dev-deps. cdxgen sen sijaan jäsentää lukitustiedostot ja ottaa kehitysriippuvuudet mukaan. Kaksi työkalua voi olla eri mieltä samasta projektista jo pelkästään tästä syystä.

Voiko avoimen lähdekoodin generaattorin SBOM:iin luottaa?

Sen osalta, mitä se luki, kyllä. Kysymys on siitä, mitä se ei lukenut: välimuisteja, build-työkaluja, latauksia, asennusskriptejä ja binäärejä ilman pakettimetatietoja. Pidä skannattua SBOM:ia kuvauksena tiedostoista, joihin osoitit työkalun, ei julkaisusi tuottaneesta buildista.

Mikä on paras SBOM-työkalu?

Itse rakentamillesi ohjelmistoille kattavin SBOM syntyy buildin kirjaamisesta eikä tiedostojen skannaamisesta. CRACI kirjaa jokaisen paketin, jonka kukin GitHub Actions -jobi hakee, myös välimuisteista, ja on löytänyt haavoittuvia paketteja, joita Snyk ja Aikido eivät raportoineet. Kolmansien osapuolten konttikuville ja binääreille, joita et itse rakentanut, Syftin tai Trivyn kaltainen skanneri on edelleen käytännöllinen valinta.