De ce codul generat de IA rupe modelul dvs. de gestionare a vulnerabilităților

Generatorii de cod AI au făcut ceva ce ani de întreținere a unelte DevOps nu au reușit niciodată să facă: au făcut posibilă lansarea funcțiilor în câteva zile, care înainte dura săptămâni. Problema este că viteza se aplică la fel și vulnerabilităților.

De-a lungul anilor mei în securitatea cibernetică, am văzut organizații care trec printr-un model reactiv: descoperă o vulnerabilitate, se grăbesc să înțeleagă amploarea ei, se ceartă despre cine ar trebui să o remedieze și o remediază după săptămâni sau luni. IA nu a schimbat acest model. A accelerat doar ritmul la care nu se mai poate ține pasul. Media de timp de remediere a vulnerabilităților critice este de peste 60 de zile. Dezvoltarea asistată de IA nu vă oferă 60 de zile. Vă oferă o nouă bază de cod la fiecare sprint.

Problema dependențelor este acum o problemă de IA

Nuăzeci și șase la sută din aplicațiile enterprise conțin componente open source. Majoritatea nu au fost niciodată verificate riguros, ci doar extrase din registre publice pentru că funcționau și cineva le-a nevoie în acea după-amiază. Echipele de securitate au pierdut teren în acest sens de ani de zile, iar asistenții de codare AI au transformat o sângerare lentă în ceva mult mai greu de controlat.

Când un dezvoltator scrie cod manual, face alegeri deliberate cu privire la dependențe. Când un model de IA generează cod, extrage din tot ce a fost antrenat. Acest lucru înseamnă adesea pachete halucinate, versiuni învechite sau componente cu vulnerabilități cunoscute pe care modelul nu a avut niciun motiv să le evite. Codul pare curat. Riscul este îngropat în arborele de dependențe, la mai multe niveluri, invizibil pentru oricine nu caută în mod specific.

Am participat la revizuiri de securitate în care echipele au fost șocate să descopere o vulnerabilitate critică într-o dependență transmisă a unui pachet pe care l-au aprobat cu luni în urmă. Pachetul era în regulă. Ce a adus a fost problema. Această dinamică se întâmplă acum la scară mașină, pe sute de dezvoltatori care utilizează instrumente de IA care nu au nicio noțiune despre poziția de securitate a organizației dvs.

Scanning-ul după fapt este o strategie ineficientă

Modelul dominant pentru securitatea software-ului open source este scanarea și corectarea: rulează un scanner, triază rezultatele, alocă bilete și așteaptă. Acest model a fost întotdeauna reactiv și într-un mediu de dezvoltare accelerat de IA, este complet depășit.

Scanner-ele găsesc probleme după ce acestea sunt deja în cod. Fereastra dintre introducere și descoperire este locul în care trăiește expunerea dvs. Când IA generează cod la scară, acea fereastră se lărgeste și volumul de rezultate crește mai repede decât orice echipă poate remedia manual. Rezultatul este o listă de vulnerabilități care se extinde indefinit, prioritizarea devine un joc de ghicit și dezvoltatorii petrec 4 până la 8 ore pe vulnerabilitate la munca care nu produce nicio valoare comercială.

Adăugați la acestea și întreruperile de guvernanță care urmează și imaginea devine și mai gravă. Proprietatea remedierii este adesea neclară. Securitatea semnalează o vulnerabilitate, ingineria o numește o întrebare de configurație, iar operațiunile o numesc o problemă de cod. Am văzut acest model în urmă cu 20 de ani și nu a dispărut. IA face consecințele acestei ambiguități semnificativ mai greu de absorbit.

Schimbarea care funcționează cu adevărat: Controlați ceea ce intră

Organizațiile care iau înainte au încetat să încerce să-și scan-eze drumul către siguranță și au început să controleze ceea ce pot consuma dezvoltatorii și instrumentele de IA. Mecanismul este un catalog de componente open source, creat din sursă, monitorizat continuu și oferit ca registru intern privat care înlocuiește extragerea directă din ecosisteme publice precum PyPI, npm sau Maven.

Acest abordare mută securitatea mai la stânga în cel mai literal sens. Vulnerabilitățile sunt blocate la punctul de consum, înainte de a intra vreodată în pipeline-ul de construire. Dezvoltatorii utilizează aceleași instrumente pe care le-au folosit întotdeauna. Asistenții de codare AI rezolva dependențele din aceeași sursă guvernată. Echipa de securitate stabilește politica o singură dată, iar acea politică se aplică peste tot, inclusiv pentru codul generat de un model la 2 dimineața, fără nicio revizuire umană.

Ce arată acest lucru în practică

Pentru liderii de securitate care lucrează la acest lucru, câteva lucruri contează mai mult decât orice altceva:

1. Definiți setul de componente aprobate înainte de a extinde adoptarea IA. Dacă instrumentele dvs. de codare AI rezolva dependențe din registre publice, procesul dvs. de aprobare există doar pe hârtie. Stabiliți un registru intern guvernat, direcționați totul prin el și cereți ca componentele să fie create din sursă cu proveniență verificabilă.
2. Tratați remedierea ca pe un proces gestionat, nu ca pe o coadă de bilete. Organizațiile care rămân înainte de datoria de securitate nu se deplasează mai repede în remedierea manuală. Au eliminat remedierea manuală din ecuație. Când este disponibilă o corectură aprobată de comunitate, aceasta este reconstruită automat în catalog. Dezvoltatorii primesc actualizarea la următoarea extragere. Nimeni nu atribuie un bilet. Nimeni nu așteaptă 60 de zile.
3. Asociați lanțul de instrumente IA cu obligațiile dvs. de conformitate înainte de a fi forțați să o faceți. Am văzut echipe care au construit pe instrumente de IA timp de luni, doar pentru a se lovi de un perete atunci când un client a solicitat alinierea la FedRAMP sau dovezi SOC 2. Catalogul dvs. guvernat este și urma de audit a conformității. Înregistrările SBOM și ale provenienței ar trebui să fie livrate cu fiecare componentă, nu asamblate retroactiv sub presiunea termenului limită.
4. Atribuiți o proprietate clară la nivelul guvernanței, nu la nivelul biletului. Echipele care se deplasează cel mai repede în remediere nu sunt cele cu cei mai mulți dezvoltatori. Sunt cele în care echipa de securitate deține politica, echipa de platformă deține livrarea și niciuna nu așteaptă ca cealaltă să acționeze.

Securitatea care permite, nu blochează

Există o credință persistentă că securitatea și viteza de dezvoltare sunt în conflict fundamental. Nu am găsit niciodată acest lucru adevărat atunci când securitatea este proiectată în proces, în loc să fie atașată ulterior.

Organizațiile care vor naviga dezvoltarea condusă de IA fără a acumula o datorie de securitate insuportabilă nu sunt cele care rulează cei mai mulți scanneri. Sunt cele care au luat o decizie deliberată de a guverna ceea ce intră în lanțul de aprovizionare cu software înainte de a deveni o problemă de răspuns la incidente. Acea decizie aparține conducerii. Instrumentele pentru a o pune în aplicare există astăzi.