क्यों एआई-जनरेटेड कोड आपके वल्नरेबिलिटी मैनेजमेंट मॉडल को तोड़ रहा है

एआई कोड जनरेटर ने ऐसा कुछ हासिल किया है जो वर्षों के डेवओप्स टूलिंग ने कभी नहीं किया था: वे सुविधाओं को सप्ताहों में लाने की अनुमति देते हैं जो पहले दिनों में लाई जाती थीं। समस्या यह है कि गति कमजोरियों पर भी लागू होती है।

मैंने साइबर सुरक्षा में अपने वर्षों में, संगठनों को एक ही प्रतिक्रियात्मक पैटर्न के माध्यम से चक्र देखा है: एक कमजोरियों का पता लगाएं, इसके दायरे को समझने के लिए संघर्ष करें, इसके समाधान के मालिक के बारे में तर्क दें, और इसे हफ्तों या महीनों बाद ठीक करें। एआई ने उस पैटर्न को नहीं बदला है। इसने इसे एक ऐसी गति तक तेज कर दिया है जहां पुराना मॉडल अब नहीं रख सकता। गंभीर सीवीई के लिए उद्योग का औसत एमटीटीआर 60 दिनों से अधिक है। एआई-सहायता प्राप्त विकास आपको 60 दिन नहीं देता है। यह आपको हर स्प्रिंट में एक नया कोडबेस देता है।

निर्भरता समस्या अब एक एआई समस्या है

96 प्रतिशत उद्यम अनुप्रयोगों में खुले स्रोत घटक शामिल हैं। अधिकांश को कभी भी सख्ती से जांचा नहीं गया था, बस सार्वजनिक रजिस्ट्रियों से खींचा गया था क्योंकि वे काम करते थे और किसी को उस दोपहर की आवश्यकता थी। सुरक्षा टीमें वर्षों से इस पर जमीन खो रही हैं, और एआई कोडिंग सहायकों ने एक धीमी से खून बहने को कुछ और नियंत्रित करने में मुश्किल में बदल दिया है।

जब एक डेवलपर मैन्युअल रूप से कोड लिखता है, तो वे निर्भरताओं के बारे में जानबूझकर निर्णय लेते हैं। जब एक एआई मॉडल कोड बनाता है, तो यह जिस पर प्रशिक्षित किया गया था उस पर निर्भर करता है। इसका अक्सर मतलब होता है हॉलुसिनेटेड पैकेज, पुराने संस्करण, या ज्ञात सीवीई वाले घटक जिनसे मॉडल को बचने का कोई कारण नहीं था। कोड साफ दिखता है। जोखिम निर्भरता पेड़ में निहित है, कई परतों नीचे, किसी को भी दिखाई नहीं दे रहा है जो विशेष रूप से इसकी तलाश में नहीं है।

मैंने सुरक्षा समीक्षा में बैठा है जहां टीमें एक पैकेज की परिवर्तित निर्भरता में एक महत्वपूर्ण सीवीई पाने के लिए आश्चर्यचकित थीं जिसे उन्होंने महीनों पहले अनुमोदित किया था। पैकेज ठीक था। जो यह खींचता था वह नहीं था। यह गतिविधि अब मशीन स्केल पर हो रही है, सैकड़ों डेवलपर्स के माध्यम से जो आपके संगठन की सुरक्षा मुद्रा की कोई概念 नहीं होने वाले एआई टूलिंग का उपयोग कर रहे हैं।

तथ्य के बाद स्कैनिंग एक रणनीति नहीं है

खुले स्रोत सॉफ्टवेयर सुरक्षा के लिए प्रचलित मॉडल स्कैन-एंड-पैच है: एक स्कैनर चलाएं, खोज को वर्गीकृत करें, टिकट सौंपें, और प्रतीक्षा करें। यह मॉडल हमेशा प्रतिक्रियात्मक रहा है, और एक एआई-त्वरित विकास वातावरण में, यह पूरी तरह से पिछड़ गया है।

स्कैनर समस्याओं का पता लगाते हैं जब वे पहले से ही आपके कोड में होते हैं। परिचय और खोज के बीच का समय आपके जोखिम में रहता है। जब एआई बड़े पैमाने पर कोड बना रहा है, तो वह समय बढ़ जाता है और खोज की मात्रा मैन्युअल रूप से समाधान करने वाली किसी भी टीम से तेजी से बढ़ती है। परिणाम एक सीवीई बैकलॉग है जो अनंत रूप से बढ़ता है, प्राथमिकता जो अनुमान का काम बन जाती है, और डेवलपर्स 4 से 8 घंटे प्रति कमजोरियों पर काम करते हैं जो शून्य व्यवसाय मूल्य का काम करते हैं।

गवर्नेंस ब्रेकडाउन जो इसका अनुसरण करते हैं और तस्वीर और भी खराब हो जाती है। समाधान की मालिकी अक्सर अस्पष्ट होती है। सुरक्षा एक सीवीई को झंडा दिखाती है, इंजीनियरिंग इसे एक कॉन्फ़िगरेशन प्रश्न कहती है, और संचालन इसे एक कोड समस्या कहती है। मैंने 20 साल पहले इस पैटर्न को देखा और यह नहीं गया है। एआई उस अस्पष्टता के परिणामों को महत्वपूर्ण रूप से कठिन बना देता है।

वास्तव में काम करने वाला परिवर्तन: जो अंदर जाता है उसे नियंत्रित करें

जो संगठन इस पर आगे बढ़ रहे हैं उन्होंने सुरक्षित होने के लिए स्कैन करने की कोशिश करना बंद कर दिया है और इसके बजाय पहले स्थान पर अपने डेवलपर्स और एआई टूल्स को क्या खपत कर सकते हैं इसे नियंत्रित करना शुरू कर दिया है। तंत्र एक क्यूरेटेड, नीति-शासित खुले स्रोत घटकों की सूची है, जो स्रोत से बनाई गई है, निरंतर निगरानी की जाती है, और एक निजी आंतरिक रजिस्ट्री के रूप में परोसी जाती है जो सार्वजनिक पारिस्थितिकी तंत्र जैसे पिपी, नपम या मेवन से सीधे खींचतान को बदल देती है।

यह दृष्टिकोण सुरक्षा को सबसे वास्तविक अर्थ में बाएं ओर स्थानांतरित करता है। कमजोरियों को बिल्ड पाइपलाइन में प्रवेश करने से पहले ही ब्लॉक कर दिया जाता है। डेवलपर्स वही उपकरण का उपयोग करते हैं जो उन्होंने हमेशा उपयोग किया है। एआई कोडिंग सहायक निर्भरताओं को उसी शासित स्रोत से हल करते हैं। सुरक्षा टीम नीति को एक बार सेट करती है, और वह नीति हर जगह लागू होती है, जिसमें एक मॉडल द्वारा 2 बजे के बिना किसी मानवीय समीक्षा के साथ उत्पन्न किया गया कोड भी शामिल है।

व्यावहारिक रूप से यह कैसा दिखता है

सुरक्षा नेताओं के लिए जो इस पर काम कर रहे हैं, कुछ चीजें अधिक मायने रखती हैं:

1. एआई अपनाने के पैमाने को बढ़ाने से पहले अपने अनुमोदित घटक सेट को परिभाषित करें। यदि आपके एआई कोडिंग टूल सार्वजनिक रजिस्ट्रियों से निर्भरताओं को हल कर रहे हैं, तो आपकी अनुमोदन प्रक्रिया केवल कागज पर मौजूद है। एक शासित आंतरिक रजिस्ट्री स्थापित करें, सब कुछ इसके माध्यम से रूट करें, और घटकों को स्रोत से बने हुए और सत्यापित प्रोवेनेंस के साथ बनाने की आवश्यकता है।
2. समाधान को एक प्रबंधित प्रक्रिया के रूप में मानें, न कि एक टिकट कतार के। सीवीई ऋण से आगे रहने वाले संगठन मैनुअल समाधान पर तेजी से नहीं बढ़ रहे हैं। उन्होंने मैनुअल समाधान को समीकरण से हटा दिया है। जब एक सामुदायिक-अनुमोदित पैच उपलब्ध होता है, तो यह स्वचालित रूप से कैटलॉग में फिर से बनाया जाता है। डेवलपर्स अगली बार जब वे खींचते हैं तो अपडेट प्राप्त करते हैं। कोई टिकट सौंपा नहीं जाता है। कोई 60 दिनों का इंतजार नहीं करता है।
3. अपने एआई टूलचेन को अपने अनुपालन दायित्वों से मैप करें इससे पहले कि आप मजबूर हों। मैंने टीमों को महीनों तक एआई टूलिंग पर बनाने के लिए देखा है, केवल तभी जब एक ग्राहक ने फेडआरएएमपी संरेखण या एसओसी 2 प्रमाण की आवश्यकता की। आपकी क्यूरेटेड कैटलॉग आपका अनुपालन ऑडिट ट्रेल भी है। एसबीओएम और प्रोवेनेंस रिकॉर्ड प्रत्येक घटक के साथ जहाजों को चाहिए, न कि समय सीमा के दबाव में संकलित किया जाना चाहिए।
4. सरकार के परत पर स्पष्ट स्वामित्व को सौंपें। जो टीमें तेजी से आगे बढ़ रही हैं वे सबसे अधिक डेवलपर्स वाली नहीं हैं। वे वह हैं जहां सुरक्षा टीम नीति का स्वामित्व रखती है, प्लेटफ़ॉर्म टीम वितरण का स्वामित्व रखती है, और न तो दूसरे पर कार्रवाई करने के लिए प्रतीक्षा कर रही है।

सुरक्षा जो ब्लॉक करने के बजाय सक्षम बनाती है

एक लंबे समय से चली आ रही धारणा है कि सुरक्षा और विकास वेग में मूलभूत विरोधाभास है। मैंने कभी नहीं पाया है कि जब सुरक्षा प्रक्रिया में डिज़ाइन की जाती है, न कि इसमें जोड़ा जाता है, तो यह सच है। एक क्यूरेटेड घटक सेट से काम करने वाले डेवलपर्स वास्तव में तेजी से आगे बढ़ते हैं, क्योंकि वे अनुमोदन पर संदेह नहीं कर रहे हैं, सुरक्षा समीक्षा की प्रतीक्षा नहीं कर रहे हैं, या उन कमजोरियों को साफ नहीं कर रहे हैं जिन्हें अपस्ट्रीम में ब्लॉक किया जा सकता था।

जो संगठन एआई-संचालित विकास के बिना अस्थिर सुरक्षा ऋण को जमा किए बिना नेविगेट करेंगे वे सबसे अधिक स्कैनर चलाने वाले नहीं हैं। वे वह हैं जिन्होंने सॉफ्टवेयर सप्लाई चेन में प्रवेश करने से पहले क्या जाने का जानबूझकर निर्णय लिया है, इससे पहले कि यह एक घटना प्रतिक्रिया समस्या बन जाए। वह निर्णय नेतृत्व का है। इसे निष्पादित करने के लिए उपकरण आज मौजूद हैं।