एक डेव्हलपर आयडीई (IDE) उघडतो, त्याला काय हवे आहे ते सोप्या इंग्रजीत सांगतो आणि कॉफी आणायला लागणाऱ्या वेळेत एक एआय एजंट ते फीचर कसे लिहितो हे पाहतो. ते कंपाईल होते. ते मॅन्युअल क्लिक-थ्रू पास करते. ते वितरित केले जाते. ते सुरक्षित आहे की नाही हे कोणी विचारले नाही, कारण कोणी फार काही विचारतच नव्हते. प्रॉम्प्टने (prompt) त्याची जागा घेतली. pull requestआणि "मी त्याचे पुनरावलोकन केले" याच्या जागी "ते काम करते" असे म्हटले जाऊ लागले. यालाच व्हाईब कोडिंग म्हणतात, आणि ही आता काही दुर्मिळ सवय राहिलेली नाही. केवळ विकेंडला ॲपवर प्रयोग करणाऱ्या हौशी लोकांकडून नव्हे, तर व्यावसायिक टीम्सकडून वाढत्या प्रमाणात प्रोडक्शन कोड याच पद्धतीने लिहिला जातो. आणि नेमके याच कारणामुळे, व्हाईब कोडिंग सिक्युरिटी हा प्रत्येक इंजिनिअरिंग आणि सिक्युरिटी लीडरच्या चर्चेचा विषय बनला आहे, मग त्यांनी त्याला अजून नाव दिले असो वा नसो.
"व्हायब कोडिंग" चा खरा अर्थ काय आहे
व्हायब कोडिंग हे एक सॉफ्टवेअर डेव्हलपमेंट आहे, ज्यामध्ये एखादी व्यक्ती नैसर्गिक भाषेत अपेक्षित परिणामाचे वर्णन करते आणि एक एआय मॉडेल, किंवा त्यावर आधारित एजंट, कार्यरत कोड तयार करतो. ती व्यक्ती परिणामाच्या आधारे नियंत्रण करते (“एक तयार करा”). login अंमलबजावणी लिहून किंवा ओळी-ओळीने तपासून पाहण्याऐवजी, "प्रवाह" (flow), "CSV निर्यात जोडा" (add a CSV export) यांसारख्या पद्धती वापरल्या जातात. ही संज्ञा लोकप्रिय झाली कारण ती एक वास्तविक गोष्ट दर्शवते: विकसक प्रत्यक्ष कोड वाचून नव्हे, तर आउटपुट योग्य आहे या जाणिवेवर अवलंबून असतो.
तोच बदल ही सगळी कहाणी आहे. पूर्वी, सॉफ्टवेअर लिहिण्याच्या प्रक्रियेत कोड रिव्ह्यू हा एक अंतर्भूत तपासणीचा टप्पा असायचा. व्हायब कोडिंग मुद्दामहून तो टप्पा टाळते. त्यामुळे वेग वाढतो. “हे प्रत्यक्षात काय करते?” असा प्रश्न विचारण्याची सवय कमी होते.
“ते काम करते” हा चुकीचा बार का आहे
"ते काम करते" याचा अर्थ असा की, तपासलेल्या परिस्थितीत कोडने सांगितल्याप्रमाणे काम केले. पण ज्या परिस्थितींबद्दल कोणी विचारलेच नाही, त्यांमध्ये कोड काय करतो याबद्दल यात काहीही सांगितले जात नाही: जसे की, चुकीच्या स्वरूपातील इनपुट, प्रमाणीकृत वापरकर्त्याने एखाद्या एंडपॉइंटची चाचणी घेणे ज्याने त्याच्यावर गरजेपेक्षा जास्त विश्वास ठेवला आहे, कधीही न तपासलेले डिपेंडन्सी, किंवा उघडपणे दिसणारे हार्डकोडेड सिक्रेट. इथेच, कोणाच्याही लक्षात समस्या येण्याआधीच, व्हायब कोडिंगची सुरक्षा कोलमडते.
एआय कोडिंग मॉडेल्सना प्रॉम्प्टच्या हेतूशी जुळणारे कार्यात्मक आउटपुट तयार करण्यासाठी प्रशिक्षित केले जाते. सुरक्षा हे उद्दिष्ट नसते. "हे विनंती पूर्ण करते" यासाठी ऑप्टिमाइझ केलेले मॉडेल, पॅरामीटर्सऐवजी स्ट्रिंग कॉनकाटेनेशनने तयार केलेली क्वेरी, ॲक्सेस कंट्रोल नसलेला एंडपॉइंट (कारण प्रॉम्प्टमध्ये कोणाला ॲक्सेस नसावा याचा उल्लेखच नसतो), किंवा अशा प्रतिसादावर विश्वास ठेवणारा एपीआय कॉल, ज्याची पडताळणी करणे आवश्यक आहे, अशा गोष्टी सहजपणे तयार करेल. ते कंपाइल होते. ते काम करते. पण त्याचबरोबर ते त्याच प्रकारच्या असुरक्षितता निर्माण करते, ज्यांपासून डेव्हलपर्सना दूर ठेवण्यासाठी ॲपसेक टीम्सनी दशकभर प्रशिक्षण दिले आहे; आणि या असुरक्षितता इतक्या वेगाने निर्माण होतात की, त्यांच्याशी जुळवून घेण्यासाठी कोणतीही मॅन्युअल रिव्ह्यू प्रक्रिया तयार केली गेली नव्हती.
एआय-निर्मित कोडवरील अंतर्गत संशोधनातून या सहजज्ञानाला ठोस आकडेवारीचा आधार मिळतो: एजेंटिक कोडिंग टूल्सद्वारे तयार होणाऱ्या कोडच्या एका मोठ्या भागामध्ये, कोणतेही पुनरावलोकन होण्यापूर्वीच, पहिल्याच प्रयत्नात एक शोषणीय सुरक्षा त्रुटी आढळते. हा केवळ एका मॉडेलमधील दोष नाही. "तो चालेल" यासाठी ऑप्टिमाइझ केल्यावर, "तो टिकून राहील" यासाठी नाही, तर हेच अपेक्षित फलित आहे, आणि हीच ती दरी आहे जी कोडिंग सुरक्षेला भरून काढायची आहे.
जोखमीची व्याप्ती ही मूळ संहितेपेक्षाही अधिक व्यापक आहे.
व्हायब कोडिंग सुरक्षेला अनेकदा असे मांडले जाते कोडच्या गुणवत्तेची समस्या, पण उघडकीस संपूर्ण कार्यप्रवाहातून चालते एजंट फक्त फंक्शनलाच स्पर्श करत नाही लिहितात:
पारंपारिक ॲपसेक साधने येथे का मागे पडतात
बहुतेक ॲप्लिकेशन सुरक्षा साधने एका विशिष्ट लयीवर आधारित आहेत: कोड लिहिला जातो, मग तो CI मध्ये किंवा PR वर स्कॅन केला जातो. ही लय असे गृहीत धरते की, स्कॅनरला निर्देशित करण्यासाठी एक स्थिर, मानवनिर्मित दस्तऐवज उपलब्ध आहे आणि बदलांचे प्रमाण हे एक ठराविक मर्यादेपलीकडील आहे. pipeline हेतुपुरस्सर पुनरावलोकन करू शकतो.
व्हायब कोडिंगमुळे वेळेचे गणित बिघडते आणि वेळेतील हीच तफावत व्हायब कोडिंगच्या सुरक्षिततेच्या समस्येचे मूळ आहे. आयडीईमध्ये कोड काही सेकंदात बदलतो, अनेकदा तो अंतिम टप्प्यापर्यंत पोहोचण्यापूर्वीच. pull requestकेवळ CI मध्ये चालणारा स्कॅनर समस्या घडून गेल्यानंतर पकडतो, जेव्हा असुरक्षित पॅटर्न आधीच मर्ज झालेला असतो किंवा कोणीतरी तयार करत असलेल्या पुढच्या फीचरचा भाग बनलेला असतो. आणि जो स्कॅनर AI-निर्मित कोडला इतर कोणत्याही कोडप्रमाणेच हाताळतो, तो कोड कसा लिहिला गेला याच्याशी संबंधित धोक्याचे ते भाग चुकवतो: जसे की, एजंटने त्याचे समर्थन करण्यास न सांगता निवडलेले पॅकेज, किंवा मानवाने कधीही बदल (diff) पाहण्यापूर्वी एजंटला काय करायचे हे सांगणारी इन्स्ट्रक्शन फाईल.
प्रत्यक्षात दरी कशामुळे भरून निघते
यामध्ये आघाडी घेणाऱ्या संस्था व्हायब कोडिंगचा वेग कमी करत नाहीत. त्या कार्यप्रवाहातच खरी व्हायब कोडिंग सुरक्षा निर्माण करत आहेत: तपासणी बिंदू (चेकपॉईंट) पुन्हा जिथे कोड प्रत्यक्षात लिहिला जातो तिथे हलवत आहेत, आणि जोपर्यंत अन्यथा सिद्ध होत नाही तोपर्यंत एआय-निर्मित कोडला अविश्वसनीय इनपुट मानत आहेत.
- केवळ CI मध्येच नव्हे, तर IDE च्या आतही स्कॅन करा. एजंट फंक्शन तयार करत असतानाच असुरक्षित पॅटर्न पकडणे ही, त्यावर आणखी तीन फीचर्स अवलंबून राहिल्यानंतर तो पकडण्यापेक्षा एक वेगळी समस्या आहे.
- एजंटने सादर केलेल्या प्रत्येक अवलंबित्वाची पडताळणी करा.ज्याप्रमाणे तुम्ही इन्स्टॉल करण्यापूर्वी, डेव्हलपरने स्वतः टाईप केलेल्या गोष्टीची पडताळणी करता, त्याचप्रमाणे.
- एजंट वाचत असलेल्या कॉन्फिगरेशन फाइल्सना कोड समजा, डॉक्युमेंटेशन नव्हे. रूल्स फाइल्स, स्किल फाइल्स आणि एमसीपी सर्व्हर कॉन्फिग्समध्ये एजंटच्या कार्यात बदल करणाऱ्या सूचना असू शकतात आणि एजंटने तयार केलेल्या कोडइतकीच त्यांचीही कसून तपासणी होणे आवश्यक आहे.
- केवळ फ्लॅग न ठेवता, दुरुस्तीसाठी एखाद्या व्यक्तीलाही प्रक्रियेत सामील करून घ्या. जो डेव्हलपर एखादी गोष्ट केवळ नियम लागू करते म्हणून नाही, तर ती का वापरण्यायोग्य आहे हे पाहू शकतो, तो पुढच्या वेळी वेगळ्या पद्धतीने सूचना द्यायला आणि पुनरावलोकन करायला शिकतो.
- असे समजा की “ते काम करते” ही कधीच सुरक्षेची अट नव्हती.आणि बारला मेमरीमध्ये ठेवण्याऐवजी, प्रत्यक्ष बारला वर्कफ्लोमध्ये दृश्यमान करा.
झायगेनी कुठे बसतो
हाच तो सांधा आहे झायजेनीचा देवएआय ते बंद करण्यासाठी तयार केले गेले होते. DevAI हे IDE च्या आत एक सतत सुरक्षा स्तर म्हणून चालते, जे मानवाने लिहिलेल्या आणि AI ने तयार केलेल्या कोडवर तो तयार होत असतानाच लक्ष ठेवते, तो IDE मध्ये आल्यानंतर नाही. pull requestते कोणत्याही सूचनेची वाट पाहत नाही: ते शोषणीय नमुने (पॅटर्न्स) ओळखते, हल्ल्याचा खरा मार्ग साध्या भाषेत समजावून सांगते आणि एक उपाय सुचवते, ज्याचे डेव्हलपर आपले काम न सोडता पुनरावलोकन करून अंमलबजावणी करू शकतो. पुरवठा साखळीच्या (सप्लाय चेन) बाजूने, MEW (मालवेअर पूर्व चेतावणी) सिग्नेचर अस्तित्वात येण्यापूर्वीच दुर्भावनापूर्ण पॅकेजेस पकडते, जे येथे थेट महत्त्वाचे आहे, कारण जेव्हा एखादा एजंट तुमच्या वतीने डिपेंडन्सी निवडतो, नेमक्या त्याच क्षणी स्लोपस्क्वॅट केलेले किंवा कॉम्प्रोमाइज केलेले पॅकेज आत शिरण्याचा मार्ग मिळवते.
या दोन्हींच्या अंतर्गत, CoreAI कोडबेस, डिपेंडेंसीज आणि यांमध्ये आढळलेल्या गोष्टींचा सहसंबंध जोडते. pipeline एका प्राधान्यक्रमित जोखीम दृष्टिकोनामध्ये, आणि तो दृष्टिकोन यापुरता मर्यादित नाही झायजेनीचे स्वतःचे स्कॅन. ते तसेच लागू होते एआय ट्रायजस्पष्टीकरण, आणि उपाय आधीपासूनच अस्तित्वात असलेल्या इतर स्कॅनर्सच्या निष्कर्षांनुसार, व्हायब्रेशन कोडिंग सुरक्षित करणे म्हणजे आधीपासूनच कार्यरत असलेली रचना काढून टाकणे नव्हे. याचा अर्थ असा आहे की, त्यावर एक असा थर चढवणे, जो अखेरीस आता लिहिल्या जात असलेल्या कोडच्या गतीने कार्य करतो.
FAQ
व्हायब कोडिंग मुळातच असुरक्षित आहे का?
नाही. व्हायब कोडिंग ही एक विकास पद्धत आहे, असुरक्षितता नाही. धोका हा मुळात कोड लिहिण्यासाठी एआय वापरल्यामुळे नाही, तर असुरक्षित पॅटर्न पकडणारी पुनरावलोकन पायरी वगळल्यामुळे येतो. म्हणूनच व्हायब कोडिंग सुरक्षा ही एक कार्यप्रवाह शिस्त आहे, ती पद्धत टाळण्याचे कारण नाही.
अस्तित्वात असू शकते का? SAST or SCA साधने आणि कोडिंगमधील सुरक्षा धोके?
ते त्यातील काही भाग पकडतात, पण सहसा कोड आधीच मर्ज झाल्यानंतर, कारण बहुतेक कोड जिथे तयार होतो त्या IDE च्या आत चालण्याऐवजी CI मध्ये चालतात. तसेच, ते सामान्यतः AI एजंटच्या स्वतःच्या वर्तनाचे मूल्यांकन करत नाहीत, जसे की ते निवडत असलेले पॅकेजेस किंवा वाचत असलेल्या कॉन्फिगरेशन फाइल्स.
व्हाइब कोडिंग सुरक्षेसाठी सर्वात प्रभावी एकच उपाय कोणता आहे?
केवळ नंतरच्या आवृत्तीवर अवलंबून राहण्याऐवजी, सुरक्षा तपासण्या निर्मितीच्या टप्प्यावरच IDE मध्ये समाविष्ट करा. pipeline स्कॅन. एखादी समस्या तिच्यावर आधारित असलेल्या पुढील तीन वैशिष्ट्यांचा भाग बनण्यापूर्वी पकडणे आणि ती नंतर पकडणे या दोन वेगळ्या समस्या आहेत.
व्हायब कोडिंग सुरक्षित करणे म्हणजे डेव्हलपर्सचा वेग कमी करणे आहे का?
जर तपासणी IDE मध्येच, स्पष्टीकरण आणि तयार उपायासह होत असेल तर नाही. कोडिंगमुळे मिळणारा वेग कायम ठेवून, पूर्वी मॅन्युअल रिव्ह्यूमुळे मिळणारी निर्णयक्षमता पुन्हा प्रस्थापित करणे, हे उद्दिष्ट आहे.
