Miksi AI-luotujen koodien aiheuttama haavoittuvuus rikkoo haavoittuvuusmallisi

AI-koodigeneraattorit ovat onnistuneet siinä, mihin DevOps-työkalut eivät ole pystyneet vuosien aikana: ne ovat tehneet mahdolliseksi toimintojen toimittamisen päivissä, joita aiemmin kestäisi viikkoja. Ongelmana on, että nopeus koskee yhtä lailla haavoittuvuuksia.

Vuosiin cybersecurityssa olen nähnyt organisaatioiden kierrättävän samaa reaktiivista mallia: haavoittuvuuden löytäminen, sen laajuuden ymmärtäminen, kiistely siitä, kuka omistaa korjaamisen, ja korjaaminen viikkoja tai kuukausia myöhemmin. AI ei ole muuttanut tätä mallia. Se on kiihdyttänyt sitä tahdissa, jossa vanha malli ei enää pysty pitämään perässä. Teollisuuden keskiarvo MTTR:lle kriittisille CVE:ille on yli 60 päivää. AI-tukeutuva kehitys ei anna sinulle 60 päivää. Se antaa sinulle uuden koodipohjan jokaisessa sprintissä.

Riippuvuusongelma on nyt AI-ongelma

Yhdeksänkymmenenkuuden prosenttia yrityssovelluksista sisältää avoimen lähdekoodin komponentteja. Useimmat eivät ole koskaan käyneet läpi tarkasti, vaan ne on otettu julkisista rekistereistä, koska ne toimivat ja joku tarvitsi niitä samana iltapäivänä. Turvallisuustiimit ovat menettäneet maata tässä vuosien ajan, ja AI-koodausavustajat ovat muuttaneet hitaan verenvuodon joksikin, jota on paljon vaikeampi hallita.

Kun kehittäjä kirjoittaa koodia manuaalisesti, hän tekee tietoisia valintoja riippuvuuksista. Kun AI-malli generoi koodia, se hakee koulutusaineistosta. Se tarkoittaa usein kuvitteellisia paketteja, vanhentuneita versioita tai komponentteja, joilla on tunnettuja CVE:itä, joita malli ei ollut mitenkään voinut välttää. Koodi näyttää puhdas. Riski on upottaa riippuvuuspuuun useita tasoja alas, näkymättömiin kenellekään, joka ei ole tarkastelemassa sitä nimenomaan.

Olen istunut turvallisuuskatselmuksissa, joissa tiimit olivat šokissa löytäessään kriittisen CVE:n paketin transitiivisesta riippuvuudesta, jonka he olivat hyväksyneet kuukausia aikaisemmin. Paketti oli ok. Se, mitä se haki, ei ollut. Tämä dynamiikka tapahtuu nyt koneellisessa mittakaavassa, satojen kehittäjien keskuudessa, jotka käyttävät AI-työkaluja, joilla ei ole mitään käsitettä organisaation turvallisuusasenteesta.

Tarkastelu jälkikäteen ei ole strategia

Avoin lähdekoodin ohjelmistoturva malli on skannaa-ja-korjaa: suorita skanneri, priorisoi löydökset, määritä ticketit ja odota. Tämä malli on aina ollut reaktiivinen, ja AI-kiihdytetyn kehitysympäristössä se on täysin jäljessä.

Skannerit löytävät ongelmat jo sen jälkeen, kun ne ovat jo koodissasi. Ikku, joka on haavoittuvuuden esittelyssä ja havaitsemisessa, on se, missä altistumisesi elää. Kun AI generoi koodia laajassa mittakaavassa, ikkuna laajenee ja löytöjen määrä kasvaa nopeammin kuin mikään tiimi voi manuaalisesti korjata. Tuloksena on CVE-velka, joka laajenee loputtomiin, priorisointi, josta tulee arvaus, ja kehittäjät viettävät 4-8 tuntia haavoittuvuuden parissa työtä, josta ei synny liiketoimintaa arvoa.

Lisää siihen hallinnolliset murtumat, ja kuva pahenee. Korjaamisen omistajuus on usein epäselvä. Turvallisuus liputtaa CVE:tä, insinöörit kutsuvat sitä konfiguraatioasioiksi, ja operatiiviset tiimit kutsuvat sitä koodiongelmaaksi. Näin olen nähnyt 20 vuotta sitten, ja se ei ole poissa. AI tekee epäselvyyden seuraamuksista merkittävästi vaikeampia omaksua.

Toimiva muutos: Hallitse, mitä sisään tulee

Organisaatiot, jotka pääsevät tämän yli, ovat lopettaneet turvallisuuden tarkastamisen ja aloittaneet sen, mitä kehittäjillä ja AI-työkaluilla on mahdollista kuluttaa ensinnäkin. Mekanismi on kuraattori, joka noudattaa käytäntöä, avoimen lähdekoodin komponenttien luetteloa, joka on rakennettu lähteestä, jatkuvasti valvottuna ja toimitettuna yksityisenä sisäisenä rekisterinä, joka korvaa suoran vedon julkisista ekosysteemeistä kuten PyPI, npm tai Maven.

Tämä lähestymistapa siirtää turvallisuuden vasemmalle kirjaimellisessa merkityksessä. Haavoittuvuudet estetään kulutuspisteessä, ennen kuin ne pääsevät koskaan build-pipelineen. Kehittäjät käyttävät samoja työkaluja kuin aina ennen. AI-koodausavustajat ratkaisevat riippuvuudet samasta hallitusta lähteestä. Turvallisuustiimi asettaa käytännön kerran, ja se käytäntö koskee joka paikkaa, myös koodia, jonka malli on luonut kello 2 aamulla ilman, että kukaan on tarkastanut sitä.

Miten tämä näyttää käytännössä

Turvallisuusjohtajille, jotka työskentelevät tämän parissa, joitakin asioita on enemmän kuin mitään muuta:

1. Määrittele hyväksytty komponenttisi ennen kuin laajennat AI-ominaisuuksia. Jos AI-koodausavustajasi ratkaisee riippuvuudet julkisista rekistereistä, hyväksymisprosessisi on vain paperilla. Perustakaa hallittu sisäinen rekisteri, ohjatkaa kaikki sen kautta ja vaadi, että komponentit on rakennettu lähteestä todistettavalla alkuperällä.
2. Käsittele korjaamista hallituna prosessina, ei ticket-jonona. Organisaatiot, jotka pysyvät CVE-velan edellä, eivät siirry nopeammin manuaaliseen korjaamiseen. He ovat poistaneet manuaalisen korjaamisen yhtälöstä. Kun yhteisöhyväksytty korjaus on saatavilla, se rakennetaan automaattisesti katalogiin. Kehittäjät saavat päivityksen seuraavan kerran, kun he lataavat. Kukaan ei määritä tickettiä. Kukaan ei odota 60 päivää.
3. Kartuta AI-työkaluusi määräystesi velvoitteisiin ennen kuin olet pakotettu siihen. Olen nähnyt tiimien rakentavan AI-työkaluilla kuukausien ajan, vain törmätäkseen seinään, kun asiakas vaati FedRAMP:in tai SOC 2:n mukaisuutta. Kuraattorisi on myös määräystesi auditin polku. SBOM:t ja alkuperän tiedot tulisi toimittaa jokaisen komponentin mukana, ei koota retrospektiivisesti määräaikojen paineessa.
4. Määrittele selkeä omistajuus hallinnon tasolla, ei ticketin tasolla. Tiimit, jotka liikkuvat nopeimmin korjaamisessa, eivät ole niitä, joilla on eniten kehittäjiä. Ne ovat niitä, joissa turvallisuustiimi omistaa käytännön, alustatiimi omistaa toimituksen eikä kumpikaan ole odottamassa toista toimimaan.

Turvallisuus, joka mahdollistaa sen sijaan, että estää

On olemassa pysyvä uskomus, että turvallisuus ja kehityksen nopeus ovat perustavanlaatuisessa ristiriidassa. En ole koskaan löytänyt sitä tosiksi, kun turvallisuus on suunniteltu prosessiin sen sijaan, että se on kiinnitetty siihen. Kehittäjät, jotka työskentelevät kuraattorin komponenttijoukon kanssa, liikkuvat itse asiassa nopeammin, koska he eivät epäile hyväksymisiä, odota turvallisuuden tarkastuksia tai puhdistaa haavoittuvuuksia, jotka voitiin estää jo aiemmin.

Organisaatiot, jotka pystyvät navigoimaan AI-vetoisen kehityksen ilman, että kasaavat kestämätöntä turvallisuusvelkaa, eivät ole niitä, jotka ajavat eniten skannereita. Ne ovat niitä, jotka ovat tehneet tietoisen päätöksen hallita, mitä tulee heidän ohjelmistotoimintaketjuunsa ennen kuin se muuttuu vastausongelmaksi. Tämä päätös kuuluu johdolle. Työkalut sen toteuttamiseksi ovat olemassa tänään.