Missä tekoälytyökalut jäävät vajaiksi ja mitä deterministinen buildin näyttö kattaa

Väite tarkasti rajattuna

Tämä ei ole kannanotto tekoälyä vastaan tietoturvassa. Mallit lukevat koodia hyvin, selittävät löydöksiä ja ehdottavat korjauksia, ja niitä hyvin käyttävät tiimit etenevät nopeammin. Väite on kapeampi: tallenteille, joiden on kestettävä tarkastelu myöhemmin, probabilistinen malli on väärä ensisijainen lähde. Tämä koskee viranomaiselle luovuttamaasi SBOM:ia, toimittamasi artefaktin alkuperätietoja ja vastausta kysymykseen ”koskiko tämä meitä?”

Kolme ominaisuutta ratkaisee, kestääkö tallenne. Kukin alla oleva osio käsittelee yhtä niistä esimerkein ja lähtein.

1. Toistettavuus: kysy kahdesti, saat saman vastauksen

Tietoturvatallenne on hyödyllinen vain, jos joku muu saa samasta syötteestä saman vastauksen. Kielimallit eivät lupaa sitä, ja toimittajat sanovat sen itse.

• Anthropicin dokumentaatio: ”Vaikka temperature olisi asetettu arvoon 0, tulokset eivät ole täysin deterministisiä, ja samat syötteet voivat tuottaa eri tuloksia eri API-kutsuissa.”
• GitHub Copilot Autofixista: ”Vaikka hälytys ja koodi olisivat samat, se ei välttämättä pysty tuottamaan toimivaa ehdotusta, tai ehdotus voi vaihdella yrityskerrasta toiseen.”
• SecLLMHolmes-kehyksen rakentaneet tutkijat testasivat kahdeksaa LLM:ää 228 koodiskenaariolla IEEE S&P 2024 -konferenssia varten. Heidän mukaansa mallit ”antavat epädeterministisiä vastauksia”, ja ”pelkästään funktioiden tai muuttujien nimiä muuttamalla tai lisäämällä lähdekoodiin kirjastofunktioita” PaLM2 ja GPT-4 antoivat väärän vastauksen 26 %:ssa ja 17 %:ssa tapauksista.

Esimerkki. Kaksi kehittäjää kysyy samalta avustajalta, koskeeko uusi tietoturvatiedote palvelua. Toinen saa vastauksen ”ei”, toinen ”mahdollisesti, tarkista transitiivinen puu”. Kumpikaan vastaus ei ole tallenne, eikä kumpaakaan voi toistaa auditoijalle puoli vuotta myöhemmin.

Tallennetulla buildilla tätä ongelmaa ei ole, koska mitään ei päätellä. CRACI havainnoi paketit, jotka jobi hakee pakettilähteistä ajon aikana, ja SBOM on tallenne tuosta havainnosta.

2. Auditoitavuus: näytä, mistä tiedät

Auditoinneissa kaikki kääntyy kysymykseen ”mistä tiedät?” Malli voi antaa sujuvan vastauksen, mutta sen selitys ei ole näyttöä. SecLLMHolmes-arvioinnissa havaittiin, että LLM:t esittävät ”virheellistä ja epäluotettavaa päättelyä” arvioimistaan haavoittuvuuksista, joten oikean johtopäätöksen mukana voi tulla selitys, joka ei pidä.

Standardit ovat siirtymässä kohti tallenteita, jotka selittävät oman alkuperänsä. Vuoden 2026 SBOM-vähimmäiselementit, jotka CISA julkaisi yhdessä NSA:n, FBI:n ja kansainvälisten kumppaneiden kanssa, lisäävät kentät SBOM Tool Name, SBOM Tool Version ja SBOM Generation Context, joka kertoo, tuotettiinko SBOM ”ennen buildia”, ”buildin” aikana vai ”buildin jälkeen”. Sama asiakirja varoittaa, että ”organisaatiot voivat ottaa virheet huomioon organisaation riskienhallintapäätöksissä, johtuivatpa ne SBOM:n laatijan käytännöistä tai riittämättömien työkalujen valinnasta”.

Esimerkki. Asiakkaan kyselylomakkeessa kysytään, miten SBOM:si tuotettiin. ”Avustaja luki repositorion ja kirjoitti sen” antaa generointikontekstin, mutta ei sellaista, jonka arvioija voi tarkistaa. ”Se tallennettiin CI-runnerissa julkaisubuildin aikana, ja jobin kattavuustila on Complete” on jotain, minkä arvioija voi todentaa buildia vasten.

3. Kattavuus: et voi raportoida sitä, mitä et koskaan nähnyt

Malli päättelee sen perusteella, mitä sille näytetään. Jos sen lukemat tiedostot eivät kuvaa ohjelmistoa, ei vastauskaan kuvaa, eikä mikään tuotoksessa kerro sitä. CISAn vuoden 2026 ohjeistus asettaa riman vastaanottajan päätökseen: heidän ”pitäisi voida päätellä, ettei uusi raportoitu haavoittuvuus koske heitä, jos SBOM ei luettele komponenttia”. Tämä toimii vain, jos se, ettei komponentti ole luettelossa, tarkoittaa, ettei sitä ole buildissa.

Esimerkki. anthropics/claude-code-repositoriossa versiossa v2.1.259 ei ole minkäänlaista riippuvuusmanifestia tai lukitustiedostoa. Julkaistu npm-paketti ilmoittaa nolla ajonaikaista riippuvuutta ja käärii valmiiksi käännetyn natiivin binäärin. Millä tahansa repositoriota lukevalla työkalulla, tekoälyllä tai muulla, ei ole juuri mitään luetteloitavaa, vaikka ajettava ohjelma on käännetty binääri.

Esimerkki. Tekoälypohjaiset koodaustyökalut voivat myös itse luoda aukon. GitHub varoittaa, että Copilot Autofix ”voi ehdottaa keksittyjä riippuvuuksia, jotka on julkaistu tilastollisesti todennäköisillä nimillä”. USENIX Security 2025 -tutkimus, jossa analysoitiin 576 000 koodinäytettä 16 mallilta, havaitsi hallusinoitujen pakettien osuudeksi keskimäärin vähintään 5,2 % kaupallisilla malleilla ja 21,7 % avoimen lähdekoodin malleilla, ja yksilöllisiä hallusinoituja paketinnimiä oli 205 474.

Deterministisyys on välttämätöntä, mutta ei riittävää

Rehellisen version tästä väitteestä on otettava mukaan seuraava kohta. SBOM-generaattorit ovat deterministisiä, ja silti ne ovat keskenään eri mieltä. Kun ne osoitetaan samaan expressjs/express-commitiin, ne voivat palauttaa eri luettelot, koska kukin päättää itse, mikä lasketaan komponentiksi ja mihin tiedostoihin luotetaan. Repositorioon ei ole commitoitu lukitustiedostoa, joten työkalulla, joka ratkaisee riippuvuudet lukitustiedostosta, ei ole raportoitavana yhtään package.json-riippuvuutta.

Deterministinen skanneri toistaa saman vajaan vastauksen joka kerta. Toistettavuus on välttämätöntä, mutta aukon sulkee havainnointi: sen tallentaminen, mitä buildi todella haki, ja sen kertominen, kun tallenne on vajaa. CRACI merkitsee jokaisen jobin ja välimuistin tilaan Complete, Complete with connections, Incomplete, Unavailable tai Not recorded.

Esimerkkitapaus: uuden tietoturvatiedotteen vaikutusten rajaus

Kuvitteellinen tilanne: laajasti käytetyn npm-paketin versiosta julkaistaan tietoturvatiedote. Kyberkestävyyssäädöksen (Cyber Resilience Act) mukaan valmistajilla on 24 tuntia aikaa ilmoittaa aktiivisesti hyödynnetystä haavoittuvuudesta ENISAlle, joten rajauksen on oltava nopea ja oikea.

Tekoäly edellä

Pyydät avustajaa tarkistamaan repositoriosi. Se lukee manifestit ja lukitustiedostot, ja ehkä Dockerfilen. Se ei näe CI-välimuistista palautettuja paketteja, build-vaiheen lataamia työkaluja eikä asennuksen aikana ratkaistuja versioita repositoriossa, jossa ei ole lukitustiedostoa. Kahdesti kysyttynä se voi vastata eri tavoin. Sen yhteenveto on hyödyllinen, mutta et voi allekirjoittaa raporttiasi sen varassa.

Tallenne edellä

CRACI kokoaa haavoittuvuudet kaikista buildeista ja repositorioista oletushaaraan rajattuna organisaation tasolla ja arvioi valvotut SBOM:t uudelleen, kun uusia haavoittuvuuksia ilmenee. API palauttaa jokaisen buildin CycloneDX-SBOM:n, sen verkkojäljen ja alkuperätiedot. Jos jobin tallenne on vajaa, sen kattavuustila kertoo, mistä etsiä käsin. Voit silti pyytää mallia tekemään tuloksesta yhteenvedon. Se tiivistää tallennetta, ei tuota sellaista.

Tallenteen avulla kysymys ”missä julkaisuissa tämä paketti toimitettiin?” on haku, ei tutkinta.

Rinnakkain

Käytä kutakin työkalua siellä, missä se on vahva

Käytä tekoälyä siellä, missä harkinnasta on apua ja ihminen tarkistaa tuloksen: koodikatselmointiin, löydöksen selittämiseen, korjauksen luonnosteluun. Käytä deterministisiä buildien tallenteita siellä, missä tulos on voitava toistaa, auditoida tai siihen on voitava luottaa kattavana: SBOM:t, alkuperätiedot ja poikkeamien rajaus. CRACI automatisoi merkittävän osan tästä toimitusketjun näytöstä laajempaa CRA-prosessia varten. Se ei yksinään tee sinusta vaatimustenmukaista.

Lue, miten tallenne syntyy: SBOM-generointi buildin aikana, tai aloita sivulta mitä CRA vaatii.