Tekoälytyökalut lukevat koodisi. Jonkin on silti tallennettava buildisi.

Tiimisi luultavasti tuo jo tekoälyä tietoturvaan

Useimmilla kehitystiimeillä on nykyään tietoturvaprosessissa vähintään yksi tekoälytyökalu. Malli katselmoi pull requestit. Toinen ehdottaa korjauksia staattisen analyysin hälytyksiin. Kolmas lajittelee skannerien löydökset luokkiin "katso tämä" ja "luultavasti kohinaa". Nämä työkalut säästävät todellista aikaa, eikä mikään tällä sivulla puhu niitä vastaan.

Hyödyllinen kysymys on, mitkä tehtävät niiden pitäisi hoitaa ja mitkä tehtävät tarvitsevat tallenteen, joka on joka kerta sama. Siihen liittyvä kysymys on, mitä tekoälytyökalusi lukevat, kun ne tekevät päätelmiä riippuvuuksistasi.

Missä tekoälypohjaiset tietoturvatyökalut ovat hyviä

• Tekoälyn koodikatselmointi. GitHub Copilot code review jättää pull requesteihin luonnollisen kielen kommentteja ja koodiehdotuksia, ja se voi noudattaa repositoriokohtaisia ohjeita. Se on hyvä siinä lukutyössä, jonka kiireinen katselmoija ohittaa.
• Tekoälyn korjaukset. GitHub Copilot Autofix "generoi automaattisesti koodimuutosehdotuksia CodeQL-hälytyksiin, jotka löytyvät pull requesteista ja oletushaarasta". Kehittäjä saa hälytyksen viereen ehdotetun paikkauksen linkin sijaan CWE-sivulle.
• Tekoälyn triage. Semgrepin tekoälyominaisuudet luokittelevat ja priorisoivat (autotriage) Semgrep Coden löydöksiä ja ehdottavat korjauksia. Semgrep dokumentoi kohinasuodatuksensa olevan "yli 95-prosenttisen tarkka Semgrep Coden löydösten luokittelussa vääriksi positiivisiksi".

Huomaa kahden jälkimmäisen yhteinen piirre. Copilot Autofix toimii CodeQL-hälytysten pohjalta. Semgrepin triage toimii Semgrepin sääntöpohjaisen moottorin löydösten pohjalta. Tekoäly lisää harkintaa deterministisen tuloksen päälle. Se ei tuota varsinaisia löydöksiä itse.

Mitä toimittajat itse sanovat rajoituksista

Selkeimmät kuvaukset siitä, mihin tekoälytyökalujen kyvyt loppuvat, tulevat toimittajilta itseltään, mikä on heille eduksi.

• Koodikatselmoinnista GitHub kirjoittaa, että "Copilot ei välttämättä tunnista kaikkia koodissa olevia ongelmia" ja että siihen "liittyy hallusinaation riski", eli se voi nostaa esiin ongelmia, joita ei ole olemassa.
• Autofixista GitHub kirjoittaa, että se "käyttää generatiivista mallia, joka ei ole deterministinen. Samallakin hälytyksellä ja koodilla se voi epäonnistua toimivan ehdotuksen tuottamisessa, tai ehdotus voi vaihdella yrityskerrasta toiseen."
• Myös Autofixista: "Järjestelmä ei tiedä, mitkä riippuvuusversiot ovat tuettuja tai turvallisia, ja se voi ehdottaa keksittyjä riippuvuuksia, jotka on julkaistu tilastollisesti todennäköisillä nimillä."

Mikään tästä ei tee työkaluista vähemmän hyödyllisiä. Se määrittelee niiden tehtävän: ne tuottavat ehdotuksia ihmisen tarkistettaviksi. Se on eri tehtävä kuin sen tallenteen tuottaminen, johon ihminen ehdotuksia vertaa.

Kaksi kerrosta, kaksi tehtävää

CRACI toimii tallennekerroksessa. Se korvaa GitHub Actions -runnerin (vaihdat runs-on-arvoksi craci), ja paketit tunnistava välityspalvelin seuraa buildin liikennettä pakettilähteisiin jobin ajon aikana. Tuloksena on SBOM siitä, mitä jobi todella haki, kattavuustila jokaiselle jobille ja välimuistille sekä verkkojälki. API palauttaa SBOM:t, verkkojäljet ja alkuperätiedot (provenance).

Missä tarvitaan determinististä näkyvyyttä

"Koskeeko tämä meitä?"

Kun uusi tietoturvatiedote julkaistaan, ensimmäinen kysymys on, sisältyikö haavoittuva versio johonkin buildeistasi. CISA:n vuoden 2026 SBOM-vähimmäiselementit sanovat vaatimuksen suoraan: SBOM:n vastaanottajan "pitäisi voida päätellä, että äskettäin raportoitu haavoittuvuus ei koske häntä, jos SBOM ei luettele komponenttia". Päätelmä pitää vain, jos luettelo on kattava. Malli voi auttaa sinua lukemaan vastauksen. Sen ei pitäisi olla se, joka päättää, mitä buildissa oli.

CRACI kokoaa haavoittuvuudet kaikista buildeista ja repositorioista ja arvioi valvotut SBOM:t uudelleen aina, kun uusia haavoittuvuuksia julkaistaan, joten kysymykseen vastataan sen perusteella, mitä tallennettiin.

Tekoälyn lisäämät riippuvuudet

Tekoälyavusteiset koodausavustajat lisäävät riippuvuuksia, ja tutkimusten mukaan ne joskus nimeävät paketteja, joita ei ole olemassa. USENIX Security 2025 -konferenssissa esitelty tutkimus generoi 576 000 koodinäytettä 16 mallilla ja havaitsi, että hallusinoitujen pakettien keskimääräinen osuus oli vähintään 5,2 % kaupallisilla malleilla ja 21,7 % avoimen lähdekoodin malleilla. Nimen, jota ei tänään ole olemassa, voi rekisteröidä huomenna. Lisäsipä riippuvuuden kuka tai mikä tahansa, CRACI tallentaa paketin, jonka buildi todella latasi, ja verkon egress-käytännöt voivat rajata jobin hyväksymiisi pakettilähteisiin.

Auditoinnit ja asiakkaiden kysymykset

Auditoija tai asiakkaan tietoturvatiimi kysyy, mistä tiedät, mitä julkaisuun päätyi. "Malli sanoi niin" on heikko vastaus. "Tässä on julkaisubuildin aikana tallennettu SBOM, sen kattavuustila ja kyseisen jobin verkkojälki" on vahva vastaus. SBOM:t viedään CycloneDX- tai SPDX-muodossa haavoittuvuuksineen, ja API palauttaa SBOM:t, verkkojäljet ja alkuperätiedot.

Toistettavat vastaukset

Jotkin kysymykset tarvitsevat saman vastauksen riippumatta siitä, kuka kysyy ja milloin. Mitä paketteja viime tiistain julkaisu haki? Generatiivinen malli voi muotoilla vastauksen hyvin, mutta sen toimittajien omien sanojen mukaan se voi muotoilla sen joka kerta eri tavalla. Tallennettu buildi antaa yhden vastauksen.

Miten nämä kaksi sopivat yhteen

Toimiva malli on se, jota Copilot Autofix ja Semgrep jo käyttävät: deterministinen data alla, tekoälyn harkinta päällä.

1. Anna tekoälyn koodikatselmoinnin ja korjausten toimia pull requesteissa niin, että ihminen hyväksyy jokaisen muutoksen.
2. Anna CRACI:n tallentaa, mitä kukin buildi toi mukanaan, ja ilmoittaa, onko tallenne kattava.
3. Kun haluat tekoälyn apua riippuvuusriskeihin, anna mallille tallennettu SBOM. CRACI:n julkinen REST-API palauttaa SBOM:n CycloneDX-muodossa, jobin verkkojäljen ja artefaktin alkuperätiedot.
4. Säilytä näyttönä tallennettu SBOM, älä mallin tiivistelmää siitä.

Jos tiimisi kirjoittaa suuren osan koodistaan tekoälyavustajien avulla, sivumme tekoälykehityksen tietoturvasta käsittelee juuri sitä tilannetta, ja buildin aikainen SBOM-generointi kertoo, miten tallenne syntyy.