Tekoäly haavoittuvuuksien korjauksessa: mihin tekoälyn korjaus-pull requestit pystyvät

Mitä tekoälypohjainen korjaus on

Tekoälypohjaisessa haavoittuvuuksien korjauksessa kielimalli tuottaa korjauksen tunnettuun haavoittuvuuteen. Sitä on kolmea muotoa:

• Koodikorjausehdotukset. Malli ehdottaa paikkausta staattisen analyysin hälytyksen viereen. Esimerkiksi GitHub Copilot Autofix ”luo automaattisesti koodimuutosehdotuksia CodeQL-hälytyksiin, jotka löytyvät pull requesteista ja oletushaarasta”.
• Riippuvuuspäivitykset, jotka sovittavat koodin. Version nostaminen on helppoa. Vaikea osa on uuden version mukana tuleva uudelleennimetty funktio tai muuttunut oletusarvo. Malli voi tehdä nämä jatkomuutokset samassa pull requestissa.
• Agenttipohjainen korjaus. Agentti vie korjauksen itsenäisesti läpi useiden vaiheiden: muuttaa koodia, ajaa buildin ja testit, lukee virheet, yrittää uudelleen ja avaa pull requestin vasta, kun checkit menevät läpi.

Missä tekoälyn korjaukset ansaitsevat paikkansa

Sääntöpohjaiset päivitysbotit avaavat jo pull requesteja, jotka nostavat haavoittuvan paketin korjattuun versioon. Ne pysähtyvät, kun päivitys rikkoo jotain, koska kutsuvan koodin sovittaminen ei ole sääntö. Juuri siihen jono kasautuu: tietoturvapäivitys jää auki kuukausiksi, koska kenelläkään ei ole aikaa käydä läpi pääversion muutosta.

Muutoslokin lukeminen, kutsukohtien löytäminen ja niiden uudelleenkirjoittaminen on juuri sellaista työtä, jossa kielimallit ovat hyviä. Tekoälyn korjaus, joka tulee päivityksen ja koodimuutosten kanssa buildattuna ja testattuna, muuttaa viikon keskittymisen yhdeksi tarkistukseksi.

Missä tekoälyn korjaukset menevät vikaan

Selkeimmät kuvaukset rajoituksista tulevat toimittajilta itseltään. Copilot Autofixista GitHub kirjoittaa:

• Se ”käyttää generatiivista mallia, joka on epädeterministinen. Vaikka hälytys ja koodi olisivat samat, se ei ehkä onnistu tuottamaan toimivaa ehdotusta, tai ehdotus voi vaihdella yrityskerrasta toiseen.”
• ”Järjestelmä ei tiedä, mitkä riippuvuusversiot ovat tuettuja tai turvallisia, ja se voi ehdottaa keksittyjä riippuvuuksia, jotka on julkaistu tilastollisesti todennäköisillä nimillä.”

Jälkimmäinen kohta ei ole teoreettinen. Koodia tuottavia malleja koskevassa tutkimuksessa on mitattu, kuinka usein ne suosittelevat paketteja, joita ei ole olemassa, eli nimiä, jotka hyökkääjä voi rekisteröidä ja täyttää haittaohjelmalla. Korjaus, joka asentaa hallusinoidun paketin, korvaa yhden haavoittuvuuden pahemmalla.

Kolme suojakaidetta kattaa suurimman osan riskistä:

1. Buildaa ja testaa jokainen korjaus ennen kuin ihminen tarkistaa sen, jotta tarkistusaika menee toimiviin korjauksiin.
2. Tarkista jokainen lisätty tai muutettu paketti rekisteriä ja odottamaasi versiota vasten.
3. Pidä ihminen yhdistämispäätöksessä. Tekoälyn korjaus on kehittäjän pull request, ei päätös.

Roskaa sisään, pull requesteja ulos

Tekoälypohjainen korjaustyökalu korjaa ne haavoittuvuudet, jotka sille annetaan. Jos luettelo on rekonstruoitu lukitustiedostoista tai skannatusta konttikuvasta, se perii jokaisen rekonstruktion aukon: työkalut, jotka buildi lataa mutta joita mikään manifesti ei ilmoita, versiot, jotka poikkeavat siitä, mitä buildi ratkaisi, ja välimuisteista palautetut paketit. Työkalu avaa sitten itsevarmoja pull requesteja osaan haavoittuvuuksista eikä koskaan kuule muista.

Jotkin tiimit menevät pidemmälle ja pyytävät mallia selvittämään riippuvuudet itse. Silloin myös inventaariosta tulee epädeterministinen, vaikka se on prosessin ainoa osa, jonka pitäisi tuottaa joka kerta sama tulos. Tekoälyn tuottamat SBOM:t kertoo, miksi arvattu inventaario ei ole näyttöä.

Toimiva malli on deterministinen data pohjalla ja tekoälyn harkinta sen päällä: tallennettu luettelo siitä, mitä kukin buildi todella sisältää, tietoturvatiedotteisiin haulla verrattuna, ja tekoäly kirjoittamassa korjauksen.

CRACI:n paikka

CRACI on deterministinen kerros. Se ajaa GitHub Actions -jobisi omilla runnereillaan ja kirjaa paketit, jotka kukin jobi todella haki, transitiiviset riippuvuudet ja välimuisteista palautetut paketit mukaan lukien, ja jokaiselle jobille kattavuustilan. Se arvioi seurattavat SBOM:t jatkuvasti uudelleen, joten uusi tietoturvatiedote näkyy niiden buildien kohdalla, joihin se vaikuttaa, ja tietoturvatiimit käyvät jokaisen löydöksen läpi triagessa ja lähettävät sen korjauksesta vastaavalle tiimille.

Siitä luettelosta tekoälyn korjauksen pitäisi lähteä liikkeelle, ja kun korjaus on yhdistetty, seuraavan buildin SBOM näyttää, onko korjattu versio se, jota buildi todella käytti. Katso koko ominaisuus sivulta haavoittuvuuksien seuranta ja sivulta tekoäly vai deterministinen tietoturva, mihin kumpikin lähestymistapa kuuluu.

Tekoäly haavoittuvuuksien korjauksessa: usein kysytyt kysymykset

Mitä on tekoälypohjainen haavoittuvuuksien korjaus?

Tekoälypohjaisessa haavoittuvuuksien korjauksessa kielimalli tuottaa korjauksen haavoittuvuuteen: koodimuutoksen staattisen analyysin löydökseen tai riippuvuuden päivityksen sekä päivityksen vaatimat koodimuutokset. Tulos on yleensä ehdotus tai pull request, jonka ihminen tarkistaa.

Mitä on agenttipohjainen korjaus?

Agenttipohjaisessa korjauksessa tekoälyagentti saa työkalut viedä korjauksen itsenäisesti läpi useiden vaiheiden: lukea löydöksen, muuttaa koodia, ajaa buildin ja testit ja toistaa, kunnes ne menevät läpi, ja avata sitten pull requestin. Ero kertaluontoiseen ehdotukseen on se, että agentti tarkistaa oman työnsä ennen kuin ihminen näkee sen.

Onko tekoälyn tuottamat tietoturvakorjaukset turvallista yhdistää?

Käsittele niitä kuten minkä tahansa muun kehittäjän pull requestia. GitHub kuvaa Copilot Autofixia epädeterministiseksi ja varoittaa, että se voi ehdottaa keksittyjä riippuvuuksia, joten tarkista muutos, aja testit ja varmista, että jokainen sen lisäämä paketti on olemassa ja juuri se, jota odotat.

Löytääkö tekoäly haavoittuvuuksia riippuvuuksista?

Se on väärä työkalu siihen osaan. Se, koskeeko tunnettu tietoturvatiedote tiettyä paketin versiota, on haku, ja sen tuloksen pitäisi olla joka kerta sama. Anna deterministisen työkalun tuottaa luettelo haavoittuvista paketeista tallennetusta SBOM:sta ja käytä tekoälyä siellä, missä harkinnasta on apua: korjauksen kirjoittamiseen ja sovittamiseen.

Mitä tekoälypohjainen korjaustyökalu tarvitsee toimiakseen hyvin?

Tarkan luettelon siitä, mikä on todella haavoittuvaa, buildin ja testisarjan, joita vasten se voi ajaa korjauksen, sekä ihmisen, joka päättää yhdistämisestä. Ensimmäinen puuttuu useimmin: korjaus-pull request paketille, jota tuote ei toimita, on kohinaa, ja haavoittuva paketti, joka jäi inventaariosta pois, ei koskaan saa korjausta.