Tekoälyn tuottama SBOM on arvaus buildistasi. Sääntelijät vaativat kirjausta.

Miksi tiimit kokeilevat sitä

Houkutus on todellinen. Liität repositorion tai lukitustiedoston koodausavustajaan, pyydät CycloneDX:ää, ja hyvin muotoiltu dokumentti palaa sekunneissa. Se voi jopa täyttää kenttiä, jotka skannerit tavallisesti jättävät tyhjiksi. Toimittajakenttä on tavallinen esimerkki: useimmilla generaattoreilla ei ole sille lähdettä, joten se jää tyhjäksi. Malli, jolta pyydetään täydellistä dokumenttia, voi kirjoittaa jotain jokaiseen kenttään.

Tuo viimeinen kohta on ongelma pienoiskoossa. Skanneri, joka ei tiedä toimittajaa, jättää kentän tyhjäksi. Malli, joka ei tiedä sitä, voi silti tuottaa uskottavan vastauksen. Dokumentti näyttää kattavammalta ja on epäluotettavampi.

Mitä malli todella näkee

SBOM:ia generoiva malli toimii edessään olevan tekstin pohjalta: manifestien, lukitustiedostojen, ehkä Dockerfilen. Se ei havainnoi buildia. Siksi se ei näe:

• mitkä versiot paketinhallinta ratkaisi, kun repositorioon ei ole tallennettu lukitustiedostoa,
• CI-välimuistista palautettuja paketteja,
• työkaluja, käyttöjärjestelmäpaketteja ja binäärejä, jotka buildin vaihe lataa suoraan,
• mitä meni käännettyyn binääriin, joka toimitetaan lähes tyhjän manifestin rinnalla.

Kaksi repositoriota näyttää, kuinka ohuita tiedostot voivat olla. expressjs/express 5.2.1 ei sisällä lukitustiedostoa, joten sen package.json listaa riippuvuudet versioalueina, ja todelliset versiot ratkeavat asennuksen aikana. anthropics/claude-code-repositoriossa versiossa v2.1.259 ei ole minkäänlaista riippuvuusmanifestia tai lukitustiedostoa, ja sen julkaistu npm-paketti ilmoittaa nolla ajonaikaista riippuvuutta, vaikka se paketoi valmiiksi käännetyn natiivin binäärin. Tähän repositorioon osoitettu deterministinen skanneri ei löydä mitään luettavaa, joka kuvaisi binääriä. Malli, jolle annetaan samat tiedostot, on yhtä vailla tietoa, mutta sillä on enemmän vapautta täyttää aukko.

Hallusinointi on dokumentoitu virhetyyppi

Kielimallit nimeävät paketteja, joita ei ole olemassa. Parhaiten mitattu tapaus koskee koodin generointia eikä SBOM:ien kirjoittamista, mutta sen osoittama virhe pätee yhtä lailla komponenttiluetteloon. USENIX Security 2025 -tutkimuksessa generoitiin 16 mallilla 576 000 koodinäytettä, ja hallusinoitujen pakettien osuus oli keskimäärin vähintään 5,2 % kaupallisilla malleilla ja 21,7 % avoimen lähdekoodin malleilla; yksilöllisiä hallusinoituja paketinnimiä oli 205 474. GitHubin oma Copilot Autofix -dokumentaatio varoittaa, että se "may suggest fabricated dependencies published under statistically probable names."

Mallit eivät myöskään anna samaa vastausta kahdesti. Anthropicin dokumentaation mukaan "even with temperature set to 0, the results will not be fully deterministic and identical inputs may produce different outputs across API calls." Kaksi samasta commitista generoitua SBOM:ia voi erota toisistaan, eikä kumpikaan kerro, kumpi on oikea.

SBOM:ssa hallusinoitu merkintä ei ole harmiton kirjoitusvirhe. Paketti, jota ei ole olemassa, tai olemassa olevan paketin väärä versio ohjaa haavoittuvuushaun väärään paikkaan, ja tulos palaa itsevarmana ja vääränä.

Mitä standardit edellyttävät SBOM:n sisältävän

NTIA:n vähimmäistiedot (2021)

NTIA:n perustaso määritteli seitsemän tietokenttää: toimittajan nimi, komponentin nimi, komponentin versio, muut yksilölliset tunnisteet, riippuvuussuhde, SBOM-tietojen laatija ja aikaleima. Niiden rinnalla olivat automaation tuki sekä joukko käytäntöjä ja prosesseja. Jokainen kenttä kuvaa ohjelmistoa koskevaa tosiasiaa, ei mielipidettä siitä.

CISA:n vuoden 2026 vähimmäistiedot

CISA, NSA, FBI ja kansainväliset kumppanit julkaisivat 29.7.2026 päivitetyt vähimmäistiedot, jotka korvaavat vuoden 2021 perustason. Useaa lisäystä on vaikea täyttää havainnoimatta buildia:

• SBOM Generation Context: "the relative software lifecycle phase and data available at the time the SBOM author generated the SBOM," esimerkkeinä "before build," "build," ja "after build". Repositoriota lukeva malli on parhaimmillaankin vaiheessa before build.
• Component Hash Value: "the output generated from applying a cryptographic hash algorithm to an executable component artifact." Jos laatijalla ei ole artefaktia, "the SBOM author should indicate the value is unknown." Malli, joka ei koskaan käsitellyt artefaktia, ei voi tuottaa tiivistettä, vain sellaiselta näyttävää tekstiä.
• SBOM Tool Name and Version: SBOM:n generoinnissa käytetty työkalu on nimettävä.
• Coverage: "An SBOM should include information for all components that make up the target software, including transitive dependencies. There is no minimum depth."
• Explicitly identifying unknown information: laatijan "should explicitly state whether the information is unknown." Keksitty arvo on tämän vastakohta.

EU:n kyberkestävyyssäädös

EU:n kyberkestävyyssäädös (Cyber Resilience Act, CRA) tekee SBOM:sta lakisääteisen velvoitteen digitaalisia elementtejä sisältävien tuotteiden valmistajille. Liitteen I osa II edellyttää, että ne tunnistavat ja dokumentoivat tuotteidensa haavoittuvuudet ja komponentit muun muassa laatimalla ohjelmistojen materiaaliluettelon yleisesti käytetyssä ja koneluettavassa muodossa, joka kattaa vähintään tuotteiden ylimmän tason riippuvuudet. Liite VII sijoittaa SBOM:n tekniseen dokumentaatioon, ja markkinavalvontaviranomainen voi pyytää sitä tarkistaakseen olennaisten vaatimusten noudattamisen.

Mikään näistä teksteistä ei kiellä tekoälytyökaluja. Ne vaativat tietoja, jotka kuvaavat todellista tuotetta, ja rehellisiä ilmoituksia siitä, mikä on tuntematonta. Päättelyn pohjalta kirjoitettu SBOM kamppailee molempien kanssa.

Miten CRACI tuottaa SBOM:n

CRACI ajaa GitHub Actions -jobisi omilla runnereillaan. Vaihdat runs-on-arvoksi craci, ja ajot näkyvät edelleen GitHubissa. Jobin ajon aikana pakettitietoinen välityspalvelin (proxy) havainnoi liikennettä pakettilähteisiin, joten SBOM kirjaa sen, mitä buildi todella haki, transitiiviset riippuvuudet mukaan lukien. Riippuvuuksien näyttö kulkee CI-välimuistien mukana, joten välimuistista palautettu paketti pysyy kirjauksessa.

• Ekosysteemit: npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, apt, apk ja Git-lähteet sekä latausesiasetukset.
• Kattavuus: jokainen jobi ja välimuisti merkitään tilaan Complete, Complete with connections, Incomplete, Unavailable tai Not recorded, joten tuntemattomat ilmoitetaan eikä niitä täytetä.
• Muodot: CycloneDX ja SPDX, ja ilmoitetut lisenssitiedot sisältyvät vientiin.
• Alkuperätiedot: API palauttaa SBOM:t, verkkojäljet ja alkuperätiedot.

CRACI automatisoi merkittävän osan siitä toimitusketjun näkyvyydestä ja näytöstä, jota laajempi CRA-vaatimustenmukaisuuden prosessi tarvitsee. Se ei yksinään tee tuotteesta vaatimustenmukaista. SBOM-generointi buildin aikana kertoo yksityiskohdat, ja CRA-katsauksemme kertoo aikataulun.

Missä tekoäly auttaa SBOM:ien kanssa

Kun sinulla on kirjattu SBOM, malli on hyvä käsittelemään sitä: se tiivistää, mitkä komponentit ovat riskialttiita, selittää tietoturvatiedotteen selkokielellä tai luonnostelee siihen liittyvän dokumentaation ihmisen tarkistettavaksi. Sääntö on yksinkertainen. Anna buildin tuottaa kirjaus ja anna mallin lukea se.