Մշակողը բացում է IDE-ն, պարզ անգլերենով նկարագրում է, թե ինչ է ուզում, և դիտում է, թե ինչպես է արհեստական բանականության գործակալը գրում գործառույթը սուրճ ստանալու համար անհրաժեշտ ժամանակում։ Այն կոմպիլացվում է։ Այն անցնում է ձեռքով սեղմելու գործընթացը։ Այն առաքվում է։ Ոչ ոք չի հարցրել, թե արդյոք այն անվտանգ է, քանի որ ոչ ոք շատ բան չի հարցրել։ Հարցումը փոխարինել է... pull request, և «աշխատում է» բառը փոխարինեց «ես այն վերանայեցի» բառին։ Սա վիբ կոդավորում է, և այն այլևս ոչ սովորական սովորություն չէ։ Սա այն ձևն է, թե ինչպես է գրվում արտադրական կոդի աճող մասը՝ մասնագիտական թիմերի կողմից, այլ ոչ թե պարզապես սիրողականների կողմից, որոնք փորձարկում են հանգստյան օրերի հավելվածը։ Եվ հենց այդ պատճառով էլ վիբ կոդավորման անվտանգությունը դարձել է յուրաքանչյուր ինժեներական և անվտանգության ոլորտի ղեկավարի զրույցի թեման, անկախ նրանից՝ արդեն անուն են տվել դրան, թե ոչ։
Ի՞նչ է իրականում նշանակում «վիբ կոդավորումը»
Վիբ կոդավորումը ծրագրային ապահովման մշակում է, որտեղ անձը նկարագրում է ցանկալի արդյունքը բնական լեզվով, և արհեստական բանականության մոդելը կամ դրա վրա կառուցված գործակալը ստեղծում է աշխատանքային կոդը։ Անձը ղեկավարվում է արդյունքով («կառուցել») login հոսք», «ավելացնել CSV արտահանում»), այլ ոչ թե գրել կամ տող առ տող վերանայել իրականացումը։ Այս տերմինը տարածում գտավ, քանի որ այն արտացոլում է իրական բան. մշակողը հիմնվում է այն զգացողության վրա, որ արդյունքը ճիշտ է, այլ ոչ թե կոդի ընթերցման վրա։
Այդ փոփոխությունն է ամբողջ պատմությունը։ Կոդի վերանայումը նախկինում ծրագրային ապահովման ստեղծման գործընթացում ներկառուցված ստուգիչ կետ էր։ Vibe կոդավորումը նախագծված կերպով շրջանցում է այն։ Արագությունը մեծանում է։ «Իրականում ի՞նչ է սա անում» հարցնելու սովորությունը նվազում է։
Ինչու է «աշխատում» սյունակը սխալ
«Աշխատում է» նշանակում է, որ կոդը կատարել է այն, ինչ պահանջվել է փորձարկված սցենարում: Այն ոչինչ չի ասում այն մասին, թե ինչ է անում կոդը այն սցենարներում, որոնց մասին ոչ ոք չի հարցրել. սխալ մուտքային տվյալներ, հաստատված օգտատիրոջ կողմից իրեն չափազանց վստահող վերջնակետի ստուգում, երբեք չստուգված կախվածություն, հստակ կոդավորված գաղտնիք, որը գտնվում է տեսանելիության սահմաններում: Ահա թե որտեղ է խախտվում Vibe կոդավորման անվտանգությունը, նախքան որևէ մեկը նկատի, որ խնդիրը կա:
Արհեստական բանականության կոդավորման մոդելները մարզվում են՝ ստեղծելու ֆունկցիոնալ արդյունք, որը համապատասխանում է հարցման նպատակին: Անվտանգությունը նպատակային ֆունկցիան չէ: «Սա բավարարում է հարցումը» մոդելը կստեղծի տողերի միացմամբ կառուցված հարցում՝ պարամետրերի փոխարեն, վերջնակետ՝ առանց մուտքի վերահսկողության, քանի որ հարցման մեջ երբեք չի նշվել, թե ով չպետք է մուտք ունենա, կամ API կանչ, որը վստահում է այն պատասխանին, որը պետք է վավերացնի: Այն կոմպիլյացիա է կատարում: Այն աշխատում է: Այն նաև ներկայացնում է նույն խոցելիության դասերը, որոնց վերաբերյալ AppSec թիմերը տասնամյակներ շարունակ մարզել են մշակողներին՝ ստեղծվելով այնպիսի տեմպերով, որին համապատասխանելու համար չի կառուցվել որևէ ձեռքով վերանայման գործընթաց:
Արհեստական բանականության կողմից ստեղծված կոդի ներքին հետազոտությունները իրական թվերը հիմնավորում են ինտուիցիայով. գործակալական կոդավորման գործիքների կողմից ստեղծված կոդի զգալի մասը պարունակում է շահագործելի անվտանգության թերություն առաջին անցման ժամանակ, նախքան որևէ վերանայում տեղի ունենալը: Սա մեկ մոդելի թերություն չէ: Սա «աշխատում է» օպտիմալացման ակնկալվող արդյունքն է, այլ ոչ թե «դիմանում է» և հենց այն բացն է, որը Vibe կոդավորման անվտանգությունը պետք է լրացնի:
Ռիսկի մակերեսն ավելի լայն է, քան կոդն ինքնին
Vibe կոդավորում անվտանգությունը հաճախ ներկայացվում է որպես կոդի որակի խնդիր, բայց ազդեցությունը անցնում է ամբողջ աշխատանքային հոսքով գործակալը դիպչում է, ոչ միայն այն գործառույթին, որը այն ունի writes:
Ինչու՞ է ավանդական AppSec գործիքակազմը այստեղ հետ մնում
Կիրառական անվտանգության գործիքների մեծ մասը կառուցված է ռիթմի շուրջ. կոդը գրվում է, ապա սկանավորվում՝ CI-ում կամ PR-ում: Այդ ռիթմը ենթադրում է, որ կա կայուն, մարդու կողմից ստեղծված արտեֆակտ, որի վրա կարելի է ուղղորդել սկաները, և որ փոփոխության ծավալը ինչ-որ բան է, որը... pipeline կարող է դիտավորյալ վերանայել։
Vibe կոդավորումը խախտում է ժամանակի խախտումը, և այդ ժամանակի բացը Vibe կոդավորման անվտանգության խնդրի հիմքն է։ Կոդը փոխվում է IDE-ի ներսում վայրկյանների ընթացքում, հաճախ՝ նախքան այն երբևէ կհասնի նպատակակետին։ pull requestՍկաները, որը աշխատում է միայն CI-ում, հայտնաբերում է խնդիրը փաստից հետո, երբ անապահով պատկերն արդեն միաձուլված է, և արդեն հաջորդ գործառույթի մաս է կազմում, որի վրա ինչ-որ մեկը կառուցում է։ Իսկ սկաները, որը արհեստական բանականության կողմից ստեղծված կոդը դիտարկում է այնպես, ինչպես ցանկացած այլ կոդ, բաց է թողնում ռիսկի այն մասերը, որոնք հատուկ են դրա գրման եղանակին. գործակալի կողմից ընտրված փաթեթը՝ առանց դրա արդարացման խնդրանքի, հրահանգչական ֆայլը, որը գործակալին ասել է, թե ինչ անել, նախքան մարդը երբևէ տարբերություն տեսներ։
Ի՞նչն է իրականում փակում բացը
Այս ամենից առաջ անցնող կազմակերպությունները չեն դանդաղեցնում Vibe կոդավորումը։ Նրանք աշխատանքային հոսքում ներդնում են Vibe կոդավորման իրական անվտանգություն՝ տեղափոխելով ստուգիչ կետը այնտեղ, որտեղ իրականում գրվում է կոդը, և արհեստական բանականության կողմից ստեղծված կոդը համարելով անվստահելի մուտքային տվյալներ, մինչև հակառակը չապացուցվի։
- Սկանավորեք IDE-ի ներսում, ոչ միայն CI-ում։ Անապահով օրինաչափություն որսալը, երբ գործակալը դեռ գեներացնում է ֆունկցիան, այլ խնդիր է, քան այն որսալը, երբ դրանից ևս երեք գործառույթ կախված են։
- Հաստատեք գործակալի կողմից ներկայացված յուրաքանչյուր կախվածություն, նույն կերպ, ինչպես դուք կհաստատեիք մշակողի կողմից ձեռքով մուտքագրված ֆայլը, նախքան այն տեղադրելը։
- Գործակալի կողմից կարդացվող կոնֆիգուրացիայի ֆայլերը համարեք կոդ, այլ ոչ թե փաստաթղթեր։ Կանոնների ֆայլերը, հմտությունների ֆայլերը և MCP սերվերի կոնֆիգուրացիաները կարող են պարունակել հրահանգներ, որոնք փոխում են գործակալի գործողությունները, և դրանք արժանի են նույն մանրակրկիտ ուսումնասիրության, ինչ գործակալի կողմից ստեղծվող կոդը։
- Ուղղման մասին տեղյակ պահեք ոչ միայն դրոշին, այլև մարդուն։ Մշակողը, ով կարող է տեսնել, թե ինչու է ինչ-որ բան շահագործելի, այլ ոչ թե պարզապես որ այն կանոն է ակտիվացրել, իրականում սովորում է հաջորդ անգամ այլ կերպ հուշել և վերանայել։
- Ենթադրենք, որ «աշխատում է» նշանը երբեք անվտանգության նշան չի եղել, և իրական գիծը տեսանելի դարձնել աշխատանքային հոսքում, այլ ոչ թե այն հիշողության մեջ թողնել։
Որտեղ է տեղավորվում Xygeni-ն
Սա հենց կարն է Xygeni-ի DevAI-ը կառուցվել է փակելու համար։ DevAI-ը գործում է որպես IDE-ի ներսում շարունակական անվտանգության շերտ՝ հետևելով մարդու կողմից գրված և արհեստական բանականության կողմից ստեղծված կոդին, երբ այն ստեղծվում է, այլ ոչ թե հայտնվում է որևէ համակարգում։ pull requestԱյն չի սպասում հուշման. այն նշում է շահագործելի օրինաչափությունները, պարզ լեզվով բացատրում է հարձակման իրական ուղին և առաջարկում է լուծում, որը մշակողը կարող է վերանայել և կիրառել առանց իր հոսքից դուրս գալու։ Մատակարարման շղթայի կողմից՝ MEW (Վնասակար ծրագրերի վաղ նախազգուշացում) որսում է վնասակար փաթեթները նախքան ստորագրության գոյությունը, ինչը այստեղ ուղղակիորեն կարևոր է, քանի որ գործակալի կողմից ձեր անունից կախվածություն ընտրելը հենց այն պահն է, երբ անփույթ կերպով զավթված կամ կոտրված փաթեթը ներխուժում է։
Երկուսի տակ էլ CoreAI-ը համեմատում է կոդային բազայի, կախվածությունների և pipeline մեկ առաջնահերթ ռիսկի տեսանկյունից, և այդ տեսակետը չի սահմանափակվում միայն դրանով Քսիգենիի սեփական սկանավորումներ։ Նույնը կիրառվում է Արհեստական ինտելեկտի տեսակավորում, բացատրություն և շտկում այլ սկաներներից ստացված արդյունքներին, որոնք արդեն իսկ տեղադրված են, ուստի Vibe կոդավորումը ապահովելը չի նշանակում արդեն աշխատող կույտը պոկել։ Դա նշանակում է դրա վրա շերտ դնել, որը վերջապես կշարժվի այն արագությամբ, որով կոդը գրվում է հիմա։
ՀՏՀ
Վիբ կոդավորումը բնույթով անապահով է՞։
Ոչ։ Vibe կոդավորումը մշակման մեթոդ է, այլ ոչ թե խոցելիություն։ Ռիսկը առաջանում է անապահով օրինաչափությունները հայտնաբերելու համար նախատեսված վերանայման քայլը բաց թողնելուց, այլ ոչ թե կոդ գրելու համար արհեստական բանականություն օգտագործելուց։ Ահա թե ինչու Vibe կոդավորման անվտանգությունը աշխատանքային հոսքի առարկա է, այլ ոչ թե այդ պրակտիկայից խուսափելու պատճառ։
Կարող է գոյություն ունենալ SAST or SCA Գործիքները որսում են Vibe կոդավորման անվտանգության ռիսկերը:
Նրանք որսում են դրա մի մասը, բայց սովորաբար կոդի միաձուլումից հետո, քանի որ դրանց մեծ մասը աշխատում է CI-ում, այլ ոչ թե IDE-ի ներսում, որտեղ ստեղծվում է կոդը։ Նրանք նաև սովորաբար չեն գնահատում արհեստական բանականության գործակալի սեփական վարքագիծը, ինչպիսիք են նրա ընտրած փաթեթները կամ կարդացած կոնֆիգուրացիայի ֆայլերը։
Ո՞րն է Vibe կոդավորման անվտանգության ամենաբարձր արդյունավետությամբ միակ լուծումը։
Անվտանգության ստուգումները տեղափոխեք IDE՝ ստեղծման պահին, այլ ոչ թե հույսը դրեք միայն ավելի ուշ ստացված տվյալների վրա։ pipeline սկանավորում: Խնդիրը հայտնաբերելը նախքան դրա վրա կառուցված հաջորդ երեք գործառույթների մաս կազմելը բոլորովին այլ խնդիր է, քան այն հետագայում հայտնաբերելը:
Արդյո՞ք Vibe կոդավորման ապահովումը նշանակում է դանդաղեցնել մշակողներին։
Ոչ, եթե ստուգումը տեղի է ունենում IDE-ում, բացատրությամբ և պատրաստի շտկումով։ Նպատակն է պահպանել արագության թրթռման կոդավորման առաջարկները՝ միաժամանակ վերականգնելով այն դատողությունը, որը նախկինում ապահովում էր ձեռքով վերանայումը։
