Vale-CVE:t, tekoälyn tuottamat raportit ja varmentamisen tarve

Uskottavien haavoittuvuusraporttien laatiminen käy yhä halvemmaksi, mikä kasvattaa ohjelmistojen ylläpitäjille ja tietoturvatiimeille aiheutuvia seurauksia. SQLitea koskevia yleisiä haavoittuvuuksia ja altistumisia (CVE) julkaistiin heinäkuussa 2026 kuusi, ja kahdelle niistä annettiin vakavuusarvosanaksi 9,8. Raportit vaikuttivat uskottavilta: niissä kuvattiin muistiturvallisuusvirheitä ja esitettiin teknisiä selityksiä sekä konseptitodistekoodia.

JFrogin tutkijat kuitenkin havaitsivat, että osa näiden raporttien mainitsemista funktioista ei ollut haavoittuvissa versioissa. Lisäksi yksikään konseptitodisteista (PoC) ei pystynyt toistamaan väitettyjä haavoittuvuuksia. SQLiten omalla CVE-sivulla todetaan tällä hetkellä, etteivät nämä kuusi raportoitua tapausta ole virheitä; CVE-tietueet hylättiin myöhemmin.

Ongelma ei rajoitu SQLiteen. Daniel Stenberg, curlin ylläpitäjä, arvioi viime vuonna, että noin 20 % saapuvista tietoturvaraporteista oli tekoälyn tuottamaa roskaa. GitHubin CVE-numerointiviranomainen (CNA) vastaanotti toukokuussa 2026 lähes 4 000 CVE-pyyntöä; määrä oli noin 10-kertainen edellisvuoteen verrattuna. GitHub ei syyttänyt kasvusta tekoälyä eikä maininnut ilmoitusten laadun heikentyneen, mutta ilmoitusten määrän valtava kasvu korostaa haavoittuvuuksien ilmoitusprosessin ylikuormitusta.

Tekoäly helpottaa yksityiskohtaisten haavoittuvuusväitteiden laatimista, mutta niiden paikkansapitävyyden selvittäminen vie aikaa. Kun CVE on päätynyt tietoturvasyötteisiin ja julkisiin tietokantoihin, alkuperäisen tietueen korjaaminen ei myöskään automaattisesti tarkoita, että kaikki kopiot korjataan. Siksi on yhä tärkeämpää erottaa ilmoitettu haavoittuvuus teknisesti varmennetusta haavoittuvuudesta.

Mikä on ”vale-CVE”?

Ihmiset käyttävät usein termiä ”vale-CVE” viitatessaan CVE:hen, joka on todennäköisesti ilmoitettu virheellisesti. Vale ei kuitenkaan tarkoita tahallista harhaanjohtamista. Kyse voi olla staattisesta analyysistä, jossa validointitarkistus jää huomaamatta tai syöte tulkitaan virheellisesti hyökkääjän hallittavissa olevaksi. Raportissa voidaan kuvailla todellista funktiota mutta väittää virheellisesti, että sitä voisi käyttää hyökkäysreittinä. Tunniste (CVE-tunnus) voidaan myöntää ja myöhemmin hylätä, jos ilmoitettu tilanne ei todellisuudessa ollut haavoittuvuus. Tämä on eri asia kuin tarkoituksella sepitetty raportti.

Myöskään kiistanalainen CVE ei ole vale-CVE. Toimittaja voi kiistää tutkijan havainnot haavoittuvuuden hyväksikäytettävyydestä, uhkarajoista tai siitä, oliko funktio tarkoitettu käsittelemään epäluotettua syötettä. Kiistäminen ei kuitenkaan todista, että tutkija olisi erehtynyt. CVE:n hylkääminen ei myöskään välttämättä tarkoita, että se olisi sepitetty: se voidaan hylätä esimerkiksi kaksoiskappaleena tai hallinnollisista syistä. Vaikka CVE-tunniste ei itsessään ole riippumaton tekninen varmennus, alan on suhtauduttava todellisiin ilmoituksiin vakavasti.

Miksi vale-CVE:t ovat ongelma

Yksi havaitsemistamme ongelmista on se, että ihmiset käyttävät tekoälyä haavoittuvuusraporttien laatimiseen tarkistamatta havaintoja asianmukaisesti. Raportit voivat sisältää yksityiskohtaisia teknisiä selityksiä, koodiviittauksia ja jopa konseptin toimivuutta osoittavia esimerkkejä (PoC), mikä saa ne vaikuttamaan uskottavilta. Kuten SQLitea koskevista CVE-ilmoituksista kävi ilmi, joitakin niissä mainituista funktioista ei ollut kyseisissä versioissa lainkaan.

GitHub ilmoitti haavoittuvuusilmoitusten määrän kasvaneen merkittävästi vuonna 2026, mutta ei yhdistänyt kasvua tekoälyyn eikä kertonut ilmoitusten laadun heikentyneen. Huolena on, että ilmoitusten määrän kasvaessa myös niiden tutkimiseen tarvittava työmäärä lisääntyy riippumatta siitä, pitävätkö havainnot paikkansa.

Haavoittuvuusilmoituksia tutkineiden on helppo tunnistaa käytännön haaste. Tekoälymalli voi havaita epäilyttävän API-kutsun, hahmotella hyväksikäyttöskenaarion ja laatia nopeasti ammattimaiselta näyttävän raportin. Sen selvittäminen, onko skenaario toteuttamiskelpoinen, voi edellyttää tarkan julkaisuversion tarkistamista, ohjausvirran seuraamista, sen selvittämistä, miten tieto päätyy funktioon, testiympäristön rakentamista ja väitetyn hyväksikäytön kokeilemista. Sama prosessi tarvitaan riippumatta siitä, pitääkö raportti paikkansa, ja se voi tulla kalliiksi.

Vale-CVE:t voivat myös vahingoittaa mainetta. Haavoittuvuusilmoitus voi levitä nopeasti skannereiden syötteisiin, tietoturvatietokantoihin ja hakutuloksiin. Myöhempi oikaisu ei kuitenkaan välttämättä leviä yhtä laajalle. Vaikka raportti olisi kiistetty tai hylätty, toimittajat voivat silti joutua puolustuskannalle niiden asiakkaiden edessä, jotka näkivät alkuperäisen ilmoituksen.

On myös olemassa riski, että todelliset haavoittuvuudet jäävät huomaamatta tai niiden tutkiminen viivästyy, kun tiimit käyttävät aikaa virheellisten ilmoitusten selvittämiseen. Kun ylläpitäjien ja tietoturvatiimien resurssit ovat rajalliset, jokainen väärän positiivisen tuloksen kumoamiseen käytetty tunti on pois ajasta, jonka olisi voinut käyttää todellisen tietoturvaongelman tutkimiseen.

Vastaisku automaation avulla

Monet tutkijat käsittelevät yhä uutta ilmoitustulvaa manuaalisesti, mutta se ei ole kestävää. Automaatio on suureksi avuksi haavoittuvuusväitteen tarkistamisessa todellisen haavoittuvan julkaisu- ja kokoonpanoversion perusteella. Esitä nämä viisi kysymystä:

• Ovatko hyökkäyksen edellytykset uskottavia, myös kokoonpanon ja käyttöoikeuksien osalta?
• Onko väitetty funktio olemassa kyseisessä versiossa?
• Pääseekö hyökkääjä käsiksi haavoittuvaan koodiin? Selvitä, voiko kyseinen koodi suorittua haavoittuvuuden vallitessa ja voiko hyökkääjä antaa syötteen, joka päätyy siihen.
• Pystyvätkö testaajat toistamaan toiminnan hallitussa testissä tai PoC:n avulla?
• Ilmeneekö havaitussa toiminnassa tietoturvailmoituksessa kuvattu tietoturvavaikutus?

Agenttipohjaisilla työkaluilla voidaan luoda testiympäristöjä, analysoida koodin suorituspolkuja, tuottaa PoC-todisteita ja tallentaa suorituksesta näyttöä tarkastelua varten. Ne eivät pysty automaattisesti ratkaisemaan kaikkia väitteitä. Vaikka haavoittuvuus olisi aito, PoC voi epäonnistua, jos ympäristö on puutteellinen tai laukaisin on väärä. Testaajat voivat saada kaatumisen toistumaan todistamatta, että väitetty hyväksikäyttö todella onnistuu. Siksi ihmisen harkinta on edelleen ratkaisevan tärkeää. Nämä työkalut voivat kuitenkin auttaa tiimejä pääsemään lähemmäs toistettavissa olevaa vastausta, ennen kuin raportin käsittely vie lisää aikaa ohjelmistokehitykseltä, haavoittuvuuksien hallinnalta ja asiakastuelta.

CVE-ekosysteemin tietotulvan hallinta

Mikään yksittäinen, tiivis käytäntö ei ratkaise tekaistujen CVE-tietueiden ongelmaa kuin taikaiskusta. Ongelmia auttaisi kuitenkin vähentämään se, että ilmoitusten yhteydessä vaadittaisiin vahvempaa näyttöä ja että toistettavuuden tila ilmoitettaisiin selkeämmin. Myös kiistanalaisten tietueiden käsittelyn selkeyttäminen ja niistä periytyvien tietojen nopeampi korjaaminen auttaisivat. Tutkijoita tulisi kannustaa varmistamaan tekoälyn avulla tehtyjen havaintojensa paikkansapitävyys ennen niiden ilmoittamista.

Tietoturvatiimien ja toimittajien on keskityttävä näytön tarkasteluun. Kriittinen CVE-pistemäärä ei kerro, pääseekö haavoittuvaan koodipolkuun heidän ympäristössään. Se, että PoC epäonnistuu, ei tarkoita, että kaikki olisi kunnossa. CVE-tunnuksen saaminenkaan ei vapauta tiimejä tekemästä sitä teknistä työtä, jota ongelman ymmärtäminen edellyttää.

Tekoäly parantaa kykyä löytää haavoittuvuuksia, mutta mahdollistaa myös uskottavan näköisten, virheellisten väitteiden tuottamisen. Raporttien määrän kasvaessa organisaatioiden on investoitava varmentamiseen. Se tarkoittaa testien rakentamista, tulosten toistamista, oletusten tarkistamista ja näytön arvioinnin helpottamista. Agenttipohjaisella tietoturvatestauksella voisi olla tässä tärkeä rooli.