Një zhvillues hap IDE-në, përshkruan atë që dëshiron në anglisht të thjeshtë dhe shikon një agjent të IA-së duke shkruar veçorinë në kohën që i duhet për të marrë kafe. Ajo kompilohet. Kalon nëpër klikimin manual. Dërgohet. Askush nuk pyeti nëse ishte e sigurt, sepse askush nuk pyeti shumë për asgjë. Kërkesa zëvendësoi pull request, dhe "funksionon" zëvendësoi "e rishikova". Ky është kodimi me vibe dhe nuk është më një zakon i vogël. Është mënyra se si shkruhet një pjesë gjithnjë e në rritje e kodit të prodhimit, nga ekipe profesionale, jo vetëm nga hobistë që eksperimentojnë me një aplikacion fundjave. Dhe është pikërisht arsyeja pse siguria e kodimit me vibe është bërë biseda që bën çdo lider inxhinierie dhe sigurie, pavarësisht nëse ia kanë vënë emrin ende apo jo.
Çfarë do të thotë në të vërtetë "kodimi i vibrave"
Kodimi i Vibe-ve është zhvillim softuerësh ku një person përshkruan rezultatin e dëshiruar në gjuhë natyrore dhe një model i inteligjencës artificiale, ose një agjent i ndërtuar mbi të, gjeneron kodin funksional. Personi drejtohet nga rezultati ("ndërtoni një login "rrjedhë rrjedhe", "shtoni një eksport CSV") në vend që të shkruani ose të rishikoni zbatimin rresht pas rreshti. Termi u bë i përhapur sepse kap diçka reale: zhvilluesi mbështetet në idenë se rezultati është i saktë, jo në leximin e vetë kodit.
Ky ndryshim është e gjithë historia. Rishikimi i kodit dikur ishte një pikë kontrolli e integruar në mënyrën se si shkruhej softueri. Kodimi Viber e anashkalon atë me dizajn. Shpejtësia rritet. Zakoni i pyetjes "çfarë bën në të vërtetë kjo" zvogëlohet.
Pse "funksionon" është shiriti i gabuar
"Funksionon" do të thotë që kodi bëri atë që u kërkua, në skenarin që u testua. Nuk thotë asgjë për atë që bën kodi në skenarë për të cilët askush nuk pyeti: një hyrje e keqformuar, një përdorues i autentifikuar që kontrollon një pikë fundore që i besonte shumë, një varësi që nuk është kontrolluar kurrë, një sekret i koduar në mënyrë të qartë. Këtu prishet siguria e kodimit të Vibe-ve para se dikush të vërejë se ka një problem.
Modelet e kodimit të inteligjencës artificiale trajnohen për të prodhuar rezultate funksionale që përputhet me qëllimin e një prompti. Siguria nuk është funksioni objektiv. Një model që optimizohet për "kjo plotëson kërkesën" do të gjenerojë me kënaqësi një pyetje të ndërtuar me bashkim vargjesh në vend të parametrave, një pikë fundore pa kontroll aksesi sepse prompti nuk përmendi kurrë se kush nuk duhet të ketë akses, ose një thirrje API që i beson një përgjigjeje që duhet ta validojë. Ai kompilohet. Funksionon. Gjithashtu prezanton të njëjtat klasa dobësish që ekipet e AppSec kanë kaluar një dekadë duke i trajnuar zhvilluesit, të gjeneruara me një ritëm që asnjë proces rishikimi manual nuk është ndërtuar për t'u përputhur.
Hulumtimi i brendshëm mbi kodin e gjeneruar nga inteligjenca artificiale i vë numrat realë pas intuitës: një pjesë domethënëse e asaj që prodhojnë mjetet e kodimit agjent përmban një të metë sigurie të shfrytëzueshme në kalimin e parë, përpara se të ndodhë ndonjë shqyrtim. Ky nuk është një defekt në një model. Është rezultati i pritur i optimizimit për "funksionon", jo "qëndron" dhe është pikërisht boshllëku që siguria e kodimit duhet të mbyllë.
Sipërfaqja e rrezikut është më e gjerë se vetë kodi
Kodim Vibe siguria shpesh përkufizohet si një problem me cilësinë e kodit, por ekspozimi kalon nëpër të gjithë rrjedhën e punës agjenti prek, jo vetëm funksionin që ai shkruan:
Pse mjetet tradicionale të AppSec mbeten prapa këtu
Shumica e mjeteve të sigurisë së aplikacioneve janë ndërtuar rreth një ritmi: kodi shkruhet, pastaj skanohet, në CI ose në PR. Ky ritëm supozon se ekziston një objekt i qëndrueshëm, i krijuar nga njeriu, për të drejtuar një skaner, dhe se vëllimi i ndryshimit është diçka që... pipeline mund të rishikojë me qëllim.
Kodimi i Vibe-ve prish kohën, dhe kjo boshllëk kohor është thelbi i problemit të sigurisë së kodimit të Vibe-ve. Kodi ndryshon brenda IDE-së brenda sekondave, shpesh para se të arrijë ndonjëherë një pull requestNjë skaner që funksionon vetëm në CI e kap problemin më pas, pasi modeli i pasigurt është bashkuar tashmë, tashmë pjesë e veçorisë tjetër mbi të cilën dikush tjetër po ndërton. Dhe një skaner që e trajton kodin e gjeneruar nga IA njësoj si çdo kod tjetër nuk i kushton vëmendje pjesëve të rrezikut që janë specifike për mënyrën se si është shkruar: paketa që agjenti zgjodhi pa iu kërkuar ta justifikonte atë, skedari i udhëzimeve që i tregoi agjentit se çfarë të bënte përpara se një njeri të shihte ndonjëherë një ndryshim.
Çfarë në të vërtetë e mbyll hendekun
Organizatat që po ecin përpara kësaj nuk po e ngadalësojnë kodimin me anë të vibrave. Ato po ndërtojnë siguri të vërtetë të kodimit me vibra në rrjedhën e punës: duke e zhvendosur pikën e kontrollit përsëri aty ku është shkruar kodi në të vërtetë dhe duke e trajtuar kodin e gjeneruar nga inteligjenca artificiale si të dhëna të pabesueshme derisa të provohet e kundërta:
- Skano brenda IDE-së, jo vetëm në CI. Kapja e një modeli të pasigurt ndërsa agjenti është ende duke gjeneruar funksionin është një problem i ndryshëm nga kapja e tij pasi tre veçori të tjera varen prej tij.
- Validoni çdo varësi që prezanton një agjent, në të njëjtën mënyrë siç do të validonit një të shkruar manualisht nga një zhvillues, përpara se të instalohej.
- Trajtoni skedarët e konfigurimit që një agjent i lexon si kod, jo si dokumentacion. Skedarët e rregullave, skedarët e aftësive dhe konfigurimet e serverit MCP mund të përmbajnë udhëzime që ndryshojnë atë që bën një agjent dhe ato meritojnë të njëjtin shqyrtim si kodi që prodhon agjenti.
- Mbaj një njeri në dijeni për rregullimin, jo vetëm flamurin. Një zhvillues që mund të shohë pse diçka është e shfrytëzueshme, jo vetëm që shkaktoi një rregull, në të vërtetë mëson të nxisë dhe të shqyrtojë ndryshe herën tjetër.
- Supozoni se "funksionon" nuk ka qenë kurrë shiriti i sigurisë, dhe ta bëni shiritin aktual të dukshëm në rrjedhën e punës në vend që ta lini atë në memorie.
Ku përshtatet Xygeni
Kjo është pikërisht shtresa DevAI i Xygeni-t u ndërtua për t'u mbyllur. DevAI funksionon si një shtresë e vazhdueshme sigurie brenda IDE-së, duke vëzhguar kodin e shkruar nga njeriu dhe të gjeneruar nga IA ndërsa prodhohet, jo pasi ai bie në një pull requestNuk pret një kërkesë: ai sinjalizon modelet e shfrytëzueshme, shpjegon rrugën e vërtetë të sulmit me gjuhë të thjeshtë dhe propozon një zgjidhje që zhvilluesi mund ta shqyrtojë dhe zbatojë pa dalë nga rrjedha e tij. Nga ana e zinxhirit të furnizimit, MEW (Paralajmërim i Hershëm për Malware) kap paketat keqdashëse përpara se të ekzistojë një nënshkrim, gjë që ka rëndësi drejtpërdrejt këtu, pasi një agjent që zgjedh një varësi në emrin tuaj është pikërisht momenti kur një paketë e përvetësuar ose e kompromentuar futet brenda.
Nën të dyja, CoreAI lidh atë që gjendet në bazën e kodit, varësitë dhe pipeline në një këndvështrim të vetëm të riskut të prioritizuar, dhe ky këndvështrim nuk kufizohet vetëm në Xygeni's skanimet e veta. Zbatohet e njëjta gjë Triazhimi i inteligjencës artificiale, shpjegim dhe sanimi te gjetjet nga skanera të tjerë që janë tashmë në vend, kështu që sigurimi i kodimit me vibe nuk do të thotë heqja e një pirgu që tashmë funksionon. Do të thotë vendosja e një shtrese mbi të që më në fund lëviz me shpejtësinë që po shkruhet kodi tani.
FAQ
A është kodimi i Vibe-ve në thelb i pasigurt?
Jo. Kodimi Vibe është një metodë zhvillimi, jo një dobësi. Rreziku vjen nga anashkalimi i hapit të rishikimit që përdoret për të kapur modelet e pasigurta, jo nga përdorimi i inteligjencës artificiale për të shkruar kodin në radhë të parë. Kjo është arsyeja pse siguria e kodimit Vibe është një disiplinë e rrjedhës së punës, jo një arsye për të shmangur praktikën.
Mund të ekzistojë SAST or SCA mjetet kapin rreziqet e sigurisë së kodimit të Vibe?
Ata kapin një pjesë të saj, por zakonisht pasi kodi të jetë bashkuar, pasi shumica ekzekutohen në CI dhe jo brenda IDE-së ku gjenerohet kodi. Ata gjithashtu zakonisht nuk e vlerësojnë sjelljen e vetë agjentit të IA-së, siç janë paketat që zgjedh ose skedarët e konfigurimit që lexon.
Cila është zgjidhja më e mirë për sigurinë e kodimit në Vibe?
Zhvendosni kontrollet e sigurisë në IDE, në pikën e gjenerimit, në vend që të mbështeteni vetëm në një të mëvonshme pipeline skanim. Kapja e një problemi përpara se të jetë pjesë e tre veçorive të tjera të ndërtuara mbi të është një problem i ndryshëm nga kapja e tij më pas.
A do të thotë sigurimi i kodimit të Vibe-ve ngadalësimi i zhvilluesve?
Jo nëse kontrolli ndodh brenda linjës, në IDE, me një shpjegim dhe një rregullim të gatshëm. Qëllimi është të ruhen ofertat e kodimit me shpejtësi të lartë, duke rikthyer gjykimin që ofronte shqyrtimi manual.
