Распрацоўшчык адкрывае IDE, апісвае патрэбныя яму рэчы простай мовай і назірае, як агент штучнага інтэлекту піша функцыю за той час, які патрабуецца, каб атрымаць каву. Яна кампілюецца. Яна праходзіць ручное пераключэнне. Яна адпраўляецца. Ніхто не пытаўся, ці бяспечная яна, бо ніхто ні пра што асабліва не пытаўся. Запыт замяніў pull request, і «гэта працуе» замяніла «я гэта аглядаў». Гэта і ёсць вайбавы код, і гэта ўжо не маргінальная звычка. Менавіта так пішацца ўсё большая доля вытворчага кода прафесійнымі камандамі, а не проста аматарамі, якія эксперыментуюць з праграмамі на выходныя. І менавіта таму бяспека вайбавага кода стала тэмай размовы кожнага інжынера і кіраўніка па бяспецы, незалежна ад таго, далі яны ёй назву ці не.
Што насамрэч азначае «вібрацыйнае кадаванне»
Вайб-кадаванне — гэта распрацоўка праграмнага забеспячэння, у якой чалавек апісвае жаданы вынік натуральнай мовай, а мадэль штучнага інтэлекту або агент, пабудаваны на яе аснове, генеруе працоўны код. Чалавек кіруецца вынікам («стварыць login паток», «дадаць экспарт CSV»), а не шляхам напісання або пакрокавага агляду рэалізацыі. Тэрмін прыжыўся, таму што ён адлюстроўвае нешта рэальнае: распрацоўшчык зыходзіць з таго, што вынік правільны, а не з прачытання самога кода.
У гэтым зруху ўся гісторыя. Раней праверка кода была кантрольным пунктам, убудаваным у тое, як пісалася праграмнае забеспячэнне. Vibe абыходзіць яго пры распрацоўцы. Хуткасць павялічваецца. Звычка пытацца «што гэта насамрэч робіць» знікае.
Чаму «гэта працуе» — няправільны радок
«Працуе» азначае, што код выканаў запытаную задачу ў пратэставаным сцэнарыі. Нічога не гаворыцца пра тое, што код робіць у сцэнарыях, пра якія ніхто не пытаўся: няправільны ўвод, праверка аўтэнтыфікаванага карыстальніка на канчатковай кропцы, якая яму занадта давярала, залежнасць, якая ніколі не правяралася, жорстка закадаваны сакрэт, які ляжыць навідавоку. Вось тут бяспека Vibe-кадавання ламаецца, перш чым хто-небудзь заўважыць праблему.
Мадэлі кадавання штучнага інтэлекту навучаюцца ствараць функцыянальны вынік, які адпавядае намеру запыту. Бяспека — гэта не мэтавая функцыя. Мадэль, аптымізуемая для «гэта задавальняе запыт», з радасцю згенеруе запыт, пабудаваны з аб'яднаннем радкоў замест параметраў, канчатковую кропку без кантролю доступу, таму што ў запыту ніколі не згадвалася, хто не павінен мець доступ, або выклік API, які давярае адказу, які ён павінен праверыць. Ён кампілюецца. Ён працуе. Ён таксама ўводзіць тыя ж класы ўразлівасцяў, якім каманды AppSec патрацілі дзесяць гадоў на навучанне распрацоўшчыкаў, згенераваныя з тэмпам, для якога не быў створаны ні адзін ручны працэс праверкі.
Унутраныя даследаванні кода, згенераванага штучным інтэлектам, даюць рэальныя лічбы падставы для інтуіцыі: значная частка таго, што ствараюць інструменты агентнага кадавання, утрымлівае дэфект бяспекі, які можна выкарыстоўваць, пры першым праходжанні, яшчэ да таго, як адбудзецца якая-небудзь праверка. Гэта не дэфект адной мадэлі. Гэта чаканы вынік аптымізацыі для «працуе», а не для «трымаецца», і гэта менавіта той прабел, які павінна запоўніць бяспека кода Vibe.
Паверхня рызыкі шырэйшая за сам код
Вайб-кадаванне бяспека часта ўспрымаецца як праблема якасці кода, але ўздзеянне праходзіць праз увесь працоўны працэс дакранаецца агент, а не толькі яго функцыя піша:
Чаму традыцыйныя інструменты AppSec тут адстаюць
Большасць інструментаў бяспекі праграм была пабудавана вакол рытму: код пішацца, а затым скануецца ў неперарыўнай інтэграцыі або на этапе рэалізацыі праекта. Гэты рытм мяркуе наяўнасць стабільнага артэфакта, створанага чалавекам, на які можна накіраваць сканер, і што аб'ём змяненняў — гэта нешта... pipeline можа пераглядаць наўмысна.
Праграмнае забеспячэнне Vibe парушае сінхранізацыю, і гэты прабел у часе з'яўляецца асновай праблемы бяспекі праграмнага забеспячэння Vibe. Код змяняецца ўнутры IDE за лічаныя секунды, часта да таго, як ён дасягне патрэбнага ўзроўню. pull requestСканер, які працуе толькі ў неперарыўнай інтэграцыі, выяўляе праблему пасля таго, як небяспечны шаблон ужо аб'яднаны, ужо з'яўляецца часткай наступнай функцыі, над якой хтосьці іншы працуе. А сканер, які апрацоўвае код, згенераваны штучным інтэлектам, гэтак жа, як і любы іншы код, прапускае часткі рызыкі, якія характэрныя для таго, як ён быў напісаны: пакет, які агент выбраў без абгрунтавання, файл інструкцый, які сказаў агенту, што рабіць, перш чым чалавек убачыў адрозненне.
Што насамрэч закрывае разрыў
Арганізацыі, якія апярэджваюць гэта, не запавольваюць вібра-кадаванне. Яны ўбудоўваюць рэальную бяспеку вібра-кадавання ў працоўны працэс: перамяшчаюць кантрольную кропку назад туды, дзе фактычна пішацца код, і разглядаюць код, згенераваны штучным інтэлектам, як ненадзейны ўваход, пакуль не будзе даказана адваротнае:
- Сканіраваць унутры IDE, а не толькі ў CI. Перахоп ненадзейнага шаблону, пакуль агент усё яшчэ генеруе функцыю, — гэта іншая праблема, чым яго перахоп пасля таго, як ад яго залежаць яшчэ тры функцыі.
- Праверце кожную залежнасць, якую ўводзіць агентгэтак жа, як вы б праверылі той, які распрацоўшчык увёў уручную, перад усталёўкай.
- Разглядаць файлы канфігурацыі, якія агент чытае, як код, а не дакументацыю. Файлы правілаў, файлы навыкаў і канфігурацыі сервера MCP могуць утрымліваць інструкцыі, якія змяняюць дзеянні агента, і яны заслугоўваюць такой жа ўважлівасці, як і код, які стварае агент.
- Трымайце чалавека ў курсе праблем, а не толькі сцяг. Распрацоўшчык, які бачыць, чаму нешта з'яўляецца прыдатным для ўзлому, а не толькі тое, што гэта выклікала правіла, насамрэч вучыцца па-іншаму падказваць і ацэньваць наступны раз.
- Выкажам здагадку, што «гэта працуе» ніколі не было перашкодай бяспекіі зрабіць саму панэль бачнай у працоўным працэсе, а не захоўваць яе ў памяці.
Дзе падыходзіць Xygeni
Гэта менавіта той шво DevAI ад Xygeni быў створаны для закрыцця. DevAI працуе як бесперапынны ўзровень бяспекі ўнутры IDE, назіраючы за кодам, напісаным чалавекам і згенераваным штучным інтэлектам, па меры яго стварэння, а не пасля таго, як ён трапляе ў pull requestЁн не чакае падказкі: ён пазначае шаблоны, якія можна выкарыстоўваць, тлумачыць рэальны шлях атакі простай мовай і прапануе выпраўленне, якое распрацоўшчык можа праглядзець і прымяніць, не выходзячы са свайго патоку. З боку ланцужка паставак, MEW (ранняе папярэджанне аб шкоднасных праграмах) перахоплівае шкоднасныя пакеты да таго, як з'явіцца сігнатура, што тут мае значэнне, бо агент выбірае залежнасць ад вашага імя менавіта ў той момант, калі ў іх пранікае нядбайны або скампраметаваны пакет.
Пад абодвума CoreAI суадносіць тое, што знаходзіцца ў кодавай базе, залежнасцях і pipeline у адзін прыярытэтны погляд на рызыкі, і гэты погляд не абмяжоўваецца Ксігені уласныя сканы. Гэта тычыцца таго ж Штучны інтэлект — трыяж, тлумачэнне і санацыя з вынікамі іншых сканераў, якія ўжо выкарыстоўваюцца, таму забеспячэнне вібрацыйнага кадавання не азначае выдаленне ўжо працуючага стэка. Гэта азначае нанясенне пласта паверх яго, які, нарэшце, рухаецца з хуткасцю, з якой зараз пішацца код.
Часта задаваныя пытанні
Ці з'яўляецца вібрацыйнае кадаванне небяспечным па сваёй сутнасці?
Не. Vibe-кадаванне — гэта метад распрацоўкі, а не ўразлівасць. Рызыка ўзнікае з-за прапуску этапу праверкі, які раней выяўляў небяспечныя шаблоны, а не з-за выкарыстання штучнага інтэлекту для напісання кода. Вось чаму бяспека Vibe-кадавання — гэта дысцыпліна працоўнага працэсу, а не прычына пазбягаць гэтай практыкі.
Ці можа існуючы SAST or SCA інструменты выяўляюць рызыкі бяспекі вібрацыйнага кадавання?
Яны ловяць частку, але звычайна пасля таго, як код ужо аб'яднаны, бо большасць працуе ў неафіцыйнай інтэграцыі, а не ўнутры IDE, дзе генеруецца код. Яны таксама звычайна не ацэньваюць уласную паводзіны агента штучнага інтэлекту, напрыклад, выбіраныя ім пакеты або файлы канфігурацыі, якія ён чытае.
Якое самае эфектыўнае рашэнне для бяспекі вібрацыйнага кадавання?
Перанесці праверкі бяспекі ў IDE ў момант генерацыі, а не спадзявацца толькі на пазнейшыя змены. pipeline сканаванне. Выяўленне праблемы да таго, як яна стане часткай наступных трох функцый, пабудаваных на яе аснове, — гэта зусім іншая праблема, чым выяўленне яе пасля.
Ці азначае забеспячэнне бяспекі кадавання Vibe запаволенне распрацоўшчыкаў?
Не, калі праверка адбываецца ўнутрана, у IDE, з тлумачэннем і гатовым выпраўленнем. Мэта складаецца ў тым, каб захаваць хуткасць, якую прапануе кадаванне Vibe, і аднавіць меркаванне, якое раней забяспечваў ручны прагляд.
