Kūrėjas atidaro IDE, paprasta anglų kalba aprašo, ko nori, ir stebi, kaip DI agentas rašo funkciją per tą laiką, kiek jam reikia, kad gautų kavą. Programa kompiliuojasi. Ji praeina rankinį spustelėjimą. Ji išsiunčiama. Niekas neklausė, ar ji saugi, nes niekas nieko daug neklausė. Raginimas pakeitė pull request, o „veikia“ pakeitė „aš peržiūrėjau“. Tai yra vibracinis kodavimas, ir jis nebėra marginalus įprotis. Taip rašoma vis didesnė gamybinio kodo dalis, ir tai daro profesionalios komandos, o ne tik mėgėjai, savaitgalio programėles eksperimentuojantys. Ir būtent todėl vibracinio kodavimo saugumas tapo kiekvieno inžinerijos ir saugumo lyderio pokalbiu, nesvarbu, ar jie jau tai įvardijo, ar ne.
Ką iš tikrųjų reiškia „vibe coding“
„Vibe“ kodavimas yra programinės įrangos kūrimas, kai asmuo aprašo norimą rezultatą natūralia kalba, o dirbtinio intelekto modelis arba jo pagrindu sukurtas agentas sugeneruoja veikiantį kodą. Asmuo vadovaujasi rezultatu („sukurti login srautas“, „pridėti CSV eksportą“), o ne rašant ar peržiūrint įgyvendinimo eilutę. Šis terminas išpopuliarėjo, nes jis apibūdina kažką realaus: kūrėjas mano, kad rezultatas yra teisingas, o ne perskaito patį kodą.
Šis pokytis yra visa istorija. Kodo peržiūra anksčiau buvo kontrolinis punktas, integruotas į programinės įrangos rašymo procesą. „Vibe“ programuotojas jį apeina pagal savo dizainą. Greitis didėja. Įprotis klausti „ką tai iš tikrųjų daro“ mažėja.
Kodėl „veikia“ yra netinkama juosta
„Veikia“ reiškia, kad kodas atliko tai, ko buvo prašoma, testuotame scenarijuje. Tai nieko nesako apie tai, ką kodas veikia scenarijuose, apie kuriuos niekas neklausė: neteisingai suformuota įvestis, autentifikuotas vartotojas, tikrinantis galinį tašką, kuris juo per daug pasitikėjo, priklausomybė, kuri niekada nebuvo patikrinta, matomoje vietoje esanti užkoduota paslaptis. Štai čia vibracinio kodavimo saugumas sugenda dar prieš kam nors pastebint problemą.
Dirbtinio intelekto kodavimo modeliai yra apmokyti generuoti funkcinę išvestį, atitinkančią raginimo tikslą. Saugumas nėra tikslo funkcija. Modelis, optimizuojantis „tai atitinka užklausą“, mielai sugeneruos užklausą, sudarytą naudojant eilučių sujungimą, o ne parametrus, galinį tašką be prieigos kontrolės, nes raginime niekada nebuvo paminėta, kas neturėtų turėti prieigos, arba API iškvietimą, kuris pasitiki atsakymu, kurį turėtų patvirtinti. Jis kompiliuojasi. Jis veikia. Jis taip pat įveda tas pačias pažeidžiamumų klases, kurias „AppSec“ komandos dešimtmetį mokė kūrėjams, generuojamas tokiu tempu, kuriam nebuvo sukurtas joks rankinis peržiūros procesas.
Vidiniai dirbtinio intelekto sugeneruoto kodo tyrimai pateikia realius skaičius už intuicijos: nemaža dalis agentinių kodavimo įrankių sugeneruoto kodo turi išnaudojamą saugumo spragą jau pirmojo patikrinimo metu, dar prieš atliekant bet kokią peržiūrą. Tai nėra vieno modelio defektas. Tai yra tikėtinas optimizavimo rezultatas, siekiant „veikia“, o ne „laiko“, ir tai yra būtent ta spraga, kurią turi užpildyti kodavimo saugumas.
Rizikos paviršius yra platesnis nei pats kodas
Vibe kodavimas saugumas dažnai apibrėžiamas kaip kodo kokybės problema, bet poveikis vyksta per visą darbo eigą agentas paliečia, o ne tik funkciją, kurią jis rašo:
Kodėl tradiciniai „AppSec“ įrankiai čia atsilieka
Dauguma programų saugumo įrankių buvo sukurti pagal ritmą: kodas yra parašomas, tada jis nuskaitomas CI arba PR. Šis ritmas daro prielaidą, kad yra stabilus, žmogaus sukurtas artefaktas, į kurį galima nukreipti skaitytuvą, ir kad pokyčių apimtis yra kažkas, kas... pipeline gali sąmoningai peržiūrėti.
„Vibe“ kodavimas sutrikdo laiko tarpą, ir šis laiko tarpas yra pagrindinė „Vibe“ kodavimo saugumo problema. Kodas IDE viduje keičiasi per kelias sekundes, dažnai dar nepasiekęs reikiamo lygio. pull requestSkaitytuvas, veikiantis tik dirbtinio intelekto aplinkoje, problemą aptinka po fakto, kai nesaugus šablonas jau yra sujungtas ir jau yra kitos funkcijos, kurią kuria kažkas kitas, dalis. O skaitytuvas, kuris elgiasi su dirbtinio intelekto sugeneruotu kodu taip pat, kaip ir su bet kuriuo kitu kodu, praleidžia tas rizikos dalis, kurios yra būdingos tam, kaip jis buvo parašytas: paketą, kurį agentas pasirinko nepaprašęs pagrįsti, instrukcijų failą, kuris agentui nurodė, ką daryti, kol žmogus nepamatė skirtumo.
Kas iš tikrųjų panaikina atotrūkį
Organizacijos, kurios tai aplenkia, nestabdo vibracinio kodavimo. Jos į darbo eigą įtraukia tikrą vibracinio kodavimo saugumą: perkelia kontrolinį tašką atgal į vietą, kur kodas iš tikrųjų rašomas, ir traktuoja dirbtinio intelekto sugeneruotą kodą kaip nepatikimą įvestį, kol neįrodyta kitaip.
- Nuskaitykite IDE viduje, ne tik CI. Aptikti nesaugaus šablono, kol agentas vis dar generuoja funkciją, yra kita problema, nei jį aptikti po to, kai nuo jo priklauso dar trys funkcijos.
- Patvirtinkite kiekvieną agento įvestą priklausomybę, taip pat, kaip patikrintumėte kūrėjo rankiniu būdu įvestą kodą prieš jį įdiegiant.
- Konfigūracijos failus, kuriuos agentas skaito, traktuokite kaip kodą, o ne dokumentaciją. Taisyklių failuose, įgūdžių failuose ir MCP serverio konfigūracijose gali būti instrukcijos, kurios keičia agento veiksmus, todėl jos nusipelno tokios pat priežiūros kaip ir agento sukurtas kodas.
- Informuokite žmogų apie tai, kad išspręstų problemą, o ne tik vėliavą. Kūrėjas, kuris gali suprasti, kodėl kažkas yra pažeidžiama, o ne tik tai, kad tai suaktyvino taisyklę, kitą kartą išmoksta kitaip raginti ir peržiūrėti.
- Tarkime, kad „tai veikia“ niekada nebuvo apsaugos strypasir padarykite pačią juostą matomą darbo eigoje, užuot palikus ją atmintyje.
Kur tinka Xygeni
Būtent tokia siūlė Xygeni's DevAI buvo sukurtas uždarymui. „DevAI“ veikia kaip ištisinis saugumo sluoksnis IDE viduje, stebėdamas žmogaus parašytą ir dirbtinio intelekto sugeneruotą kodą kūrimo metu, o ne po to, kai jis patenka į pull requestJis nelaukia raginimo: pažymi galimas spragas, suprantama kalba paaiškina tikrąjį atakos kelią ir pasiūlo sprendimą, kurį kūrėjas gali peržiūrėti ir pritaikyti nepalikdamas savo srauto. Tiekimo grandinės pusėje, MEW (kenkėjiškų programų ankstyvasis įspėjimas) sugauna kenkėjiškus paketus dar prieš atsirandant parašui, o tai čia yra tiesiogiai svarbu, nes agentas pasirenka priklausomybę jūsų vardu būtent tada, kai į vidų patenka neatsargiai įsilaužęs ar pažeistas paketas.
Po abiem „CoreAI“ susieja tai, kas randama visoje kodo bazėje, priklausomybėse ir pipeline į vieną prioritetinės rizikos vaizdą, ir tas vaizdas neapsiriboja Ksigenis savo nuskaitymus. Taikoma ta pati Dirbtinio intelekto triažas, paaiškinimas ir ištaisymas remiantis jau veikiančių skaitytuvų išvadomis, todėl „Vibe“ kodavimo apsauga nereiškia jau veikiančio kodų rinkinio išplėšimo. Tai reiškia, kad reikia ant jo uždėti sluoksnį, kuris pagaliau juda tokiu greičiu, kokiu kodas rašomas dabar.
DUK
Ar „Vibe“ kodavimas iš esmės yra nesaugus?
Ne. „Vibe“ kodavimas yra kūrimo metodas, o ne pažeidžiamumas. Rizika kyla dėl to, kad praleidžiamas peržiūros etapas, kuris anksčiau aptikdavo nesaugius modelius, o ne dėl to, kad kodas iš viso naudojamas naudojant dirbtinį intelektą. Štai kodėl „Vibe“ kodavimo saugumas yra darbo eigos disciplina, o ne priežastis vengti šios praktikos.
Gali egzistuoti SAST or SCA įrankiai pagauna vibraciją kodavimo saugumo rizikas?
Jie aptinka dalį informacijos, bet dažniausiai po to, kai kodas jau sujungiamas, nes dauguma jų veikia CI, o ne IDE, kurioje kodas generuojamas, viduje. Jie taip pat paprastai neįvertina paties DI agento elgesio, pavyzdžiui, kokių paketų jis pasirenka ar kokių konfigūracijos failų skaito.
Koks yra didžiausias įmanomas būdas užtikrinti vibracijos kodavimo saugumą?
Perkelti saugumo patikras į IDE generavimo metu, o ne pasikliauti tik vėlesniu pipeline nuskaitymas. Problemos aptikimas prieš tai, kai ji tampa kitų trijų funkcijų, sukurtų ant jos, dalimi, yra visai kas kita, nei jos aptikimas vėliau.
Ar „Vibe“ kodavimo užtikrinimas reiškia kūrėjų darbo sulėtinimą?
Ne, jei patikrinimas atliekamas tiesiogiai, IDE aplinkoje, su paaiškinimu ir paruoštu taisymu. Tikslas – išlaikyti greitą kodavimą, tuo pačiu atkuriant rankinio peržiūros teikiamą sprendimų priėmimo lygį.
