Binuksan ng isang developer ang IDE, inilalarawan kung ano ang gusto nila sa simpleng Ingles, at pinapanood ang isang AI agent na sumusulat ng feature sa oras na kailangan para makakuha ng kape. Nagko-compile ito. Ipinapasa nito ang manual click-through. Ipinapadala nito. Walang nagtanong kung ligtas ito, dahil walang masyadong nagtanong. Pinalitan ng prompt ang pull request, at pinalitan ng "gumagana ito" ang "Sinuri ko na." Iyan ay vibe coding, at hindi na ito isang nakagawian na lamang. Ito ang paraan kung paano isinusulat ang lumalaking bahagi ng production code, ng mga propesyonal na pangkat, hindi lamang ng mga hobbyist na nag-eeksperimento sa isang weekend app. At ito mismo ang dahilan kung bakit ang seguridad ng vibe coding ay naging usapan ng bawat pinuno ng engineering at seguridad, pinangalanan na man nila ito o hindi.
Ang tunay na ibig sabihin ng "vibe coding"
Ang vibe coding ay isang software development kung saan inilalarawan ng isang tao ang ninanais na resulta sa natural na wika at isang AI model, o isang agent na binuo mula rito, ang bubuo ng gumaganang code. Ang tao ay nagmamaneho ayon sa resulta ("bumuo ng isang login daloy,” “magdagdag ng CSV export”) sa halip na sa pamamagitan ng pagsulat o pagrepaso nang linya-por-linya sa implementasyon. Nakuha ang terminong ito dahil nakukuha nito ang isang bagay na totoo: ipinapalagay ng developer na tama ang output, hindi sa pagbasa mismo ng code.
Iyan ang buong kwento. Ang pagsusuri ng code ay dating isang checkpoint na nakapaloob sa kung paano isinusulat ang software. Ang vibe coding ay dinisenyo upang umikot dito. Tumataas ang bilis. Nababawasan na ang ugali ng pagtatanong ng "ano nga ba talaga ang ginagawa nito".
Kung bakit ang "gumagana ito" ay ang maling bar
Ang ibig sabihin ng "gumagana ito" ay ginawa ng code ang hiniling, sa senaryo na sinubukan. Wala itong sinasabi tungkol sa ginagawa ng code sa mga senaryo na walang nagtanong: isang maling porma ng input, isang authenticated user na sumusubok sa isang endpoint na labis na nagtiwala sa kanila, isang dependency na hindi kailanman nasuri, isang hardcoded na sikreto na nakatago lamang. Dito nasisira ang seguridad ng vibe coding bago pa man mapansin ng sinuman na may problema.
Ang mga modelo ng AI coding ay sinanay upang makagawa ng functional output na tumutugma sa layunin ng isang prompt. Ang seguridad ay hindi ang objective function. Ang isang modelo na nag-o-optimize para sa "ito ay nakakatugon sa kahilingan" ay masayang bubuo ng isang query na binuo gamit ang string concatenation sa halip na mga parameter, isang endpoint na walang access control dahil hindi kailanman binanggit ng prompt kung sino ang hindi dapat magkaroon ng access, o isang API call na nagtitiwala sa isang tugon na dapat nitong i-validate. Nagko-compile ito. Gumagana ito. Ipinakikilala rin nito ang parehong mga klase ng kahinaan na ginugol ng mga koponan ng AppSec sa isang dekada sa pagsasanay sa mga developer, na nabuo sa bilis na walang manu-manong proseso ng pagsusuri na binuo upang tumugma.
Ang panloob na pananaliksik sa code na binuo ng AI ay naglalagay ng mga totoong numero sa likod ng intuwisyon: ang isang makabuluhang bahagi ng nalilikha ng mga tool sa agentic coding ay naglalaman ng isang maaaring pagsamantalahang depekto sa seguridad sa unang pagpasa, bago pa man mangyari ang anumang pagsusuri. Hindi iyon isang depekto sa isang modelo. Ito ang inaasahang output ng pag-optimize para sa "pagtakbo nito," hindi "pagtagal nito," at ito ang eksaktong puwang na kailangang tapusin ng seguridad sa coding.
Mas malawak ang saklaw ng panganib kaysa sa mismong kodigo
Vibe coding ang seguridad ay kadalasang itinuturing na isang problema sa kalidad ng code, ngunit ang pagkakalantad tumatakbo sa buong daloy ng trabaho ang ahente ay nakakaapekto, hindi lamang sa tungkulin nito nagsusulat:
Bakit nahuhuli rito ang tradisyonal na tooling ng AppSec
Karamihan sa mga kagamitan sa seguridad ng aplikasyon ay binuo sa paligid ng isang ritmo: isinusulat ang code, pagkatapos ay ini-scan ito, sa CI o sa PR. Ipinapalagay ng ritmong iyon na mayroong isang matatag, gawa ng tao na artifact na ituturo sa isang scanner, at ang dami ng pagbabago ay isang bagay na pipeline maaaring magrepaso nang may layunin.
Binabasag ng vibe coding ang timing, at ang timing gap na iyon ang sentro ng problema sa seguridad ng vibe coding. Nagbabago ang code sa loob ng IDE sa loob ng ilang segundo, kadalasan bago pa man ito umabot sa isang pull requestAng isang scanner na tumatakbo lamang sa CI ay nakakatugon sa problema pagkatapos ng katotohanan, kapag ang hindi ligtas na pattern ay na-merge na, bahagi na ito ng susunod na feature na binubuo ng ibang tao. At ang isang scanner na tinatrato ang AI-generated code kapareho ng anumang iba pang code ay hindi nakakasagabal sa mga bahagi ng panganib na partikular sa kung paano ito isinulat: ang package na pinili ng agent nang hindi hinihiling na bigyang-katwiran ito, ang instruction file na nagsasabi sa agent kung ano ang gagawin bago pa man makakita ang isang tao ng diff.
Ano talaga ang nagsasara ng puwang
Ang mga organisasyong nauuna rito ay hindi nagpapabagal sa vibe coding. Nagbubuo sila ng tunay na seguridad ng vibe coding sa daloy ng trabaho: inililipat ang checkpoint pabalik sa kung saan talaga isinulat ang code, at tinatrato ang AI-generated code bilang hindi mapagkakatiwalaang input hanggang sa mapatunayang hindi:
- I-scan sa loob ng IDE, hindi lang sa CI. Ang paghuli ng isang hindi ligtas na pattern habang binubuo pa rin ng ahente ang function ay ibang problema kaysa sa paghuli nito pagkatapos ng tatlo pang feature na nakasalalay dito.
- Patunayan ang bawat dependency na ipinakilala ng isang ahente, katulad ng pag-validate mo sa isang manu-manong na-type ng isang developer, bago ito i-install.
- Ituring ang mga configuration file na binabasa ng isang agent bilang code, hindi dokumentasyon. Ang mga rules file, skill file, at MCP server config ay maaaring magdala ng mga tagubilin na nagbabago sa ginagawa ng isang agent, at nararapat sa mga ito ang parehong pagsusuri gaya ng code na ginagawa ng agent.
- Ipaalam sa isang tao ang tungkol sa pag-aayos, hindi lang ang bandila. Ang isang developer na nakakakita kung bakit maaaring gamitin ang isang bagay, hindi lamang dahil nag-trigger ito ng isang panuntunan, ay talagang natututong mag-prompt at mag-review nang iba sa susunod.
- Ipagpalagay na ang "gumagana ito" ay hindi kailanman naging hadlang sa seguridad, at gawing nakikita ang aktwal na bar sa workflow sa halip na iwan ito sa memorya.
Kung saan nababagay ang Xygeni
Ito mismo ang tahi DevAI ni Xygeni ay ginawa para magsara. Ang DevAI ay tumatakbo bilang isang tuluy-tuloy na security layer sa loob ng IDE, binabantayan ang code na isinulat ng tao at binuo ng AI habang ginagawa ito, hindi pagkatapos nitong mapunta sa isang pull requestHindi ito naghihintay ng prompt: minamarkahan nito ang mga pattern na maaaring gamitin, ipinapaliwanag ang tunay na landas ng pag-atake sa simpleng wika, at nagmumungkahi ng isang solusyon na maaaring suriin at ilapat ng developer nang hindi umaalis sa kanilang daloy. Sa panig ng supply chain, MEW (Maagang Babala sa Malware) nakakahuli ng mga malisyosong pakete bago pa man magkaroon ng lagda, na direktang mahalaga rito, dahil ang isang ahente na pumipili ng dependency para sa iyo ay eksaktong sandaling makapasok ang isang slopsquatted o nakompromisong pakete.
Sa ilalim ng pareho, iniuugnay ng CoreAI ang mga bagay na matatagpuan sa codebase, mga dependency, at pipeline sa isang priyoridad na pananaw sa panganib, at ang pananaw na iyon ay hindi limitado sa Xygeni's sariling mga scan. Ganito rin ang nalalapat Triage ng AI, paliwanag, at remediation sa mga natuklasan mula sa ibang mga scanner na nakalagay na, kaya ang pag-secure ng vibe coding ay hindi nangangahulugang pagbunot ng isang stack na gumagana na. Nangangahulugan ito ng paglalagay ng layer sa ibabaw nito na sa wakas ay kikilos sa bilis ng pagsulat ng code ngayon.
FAQ
Likas bang hindi ligtas ang vibe coding?
Hindi. Ang vibe coding ay isang paraan ng pag-develop, hindi isang kahinaan. Ang panganib ay nagmumula sa paglaktaw sa hakbang ng pagsusuri na dating ginagamit upang mahuli ang mga hindi ligtas na pattern, hindi sa paggamit ng AI upang magsulat ng code sa simula pa lang. Kaya naman ang seguridad ng vibe coding ay isang disiplina sa daloy ng trabaho, hindi isang dahilan upang iwasan ang pagsasanay.
Maaaring umiiral SAST or SCA Nasasalat ba ng mga tool ang mga panganib sa seguridad ng vibe coding?
Nahuhuli nila ang ilan dito, ngunit kadalasan pagkatapos na maisama ang code, dahil karamihan ay tumatakbo sa CI sa halip na sa loob ng IDE kung saan nabubuo ang code. Karaniwan din nilang hindi sinusuri ang sariling kilos ng AI agent, tulad ng mga package na pinipili nito o ang mga configuration file na binabasa nito.
Ano ang nag-iisang pinakamataas na leverage na solusyon para sa seguridad ng vibe coding?
Ilipat ang mga security check sa IDE, sa punto ng pagbuo, sa halip na umasa lamang sa mas bagong bersyon pipeline i-scan. Ang pagtuklas ng isang isyu bago pa man ito maging bahagi ng susunod na tatlong feature na nakapaloob dito ay ibang problema kaysa sa pagtuklas nito pagkatapos.
Ang pag-secure ba ng vibe coding ay nangangahulugan ng pagpapabagal sa mga developer?
Hindi kung ang pagsusuri ay nangyayari nang online, sa IDE, na may paliwanag at handa nang solusyon. Ang layunin ay panatilihin ang bilis ng coding habang ibinabalik ang dating paghatol na ibinibigay ng manu-manong pagsusuri.
