ज़ैद अल हमानी, बूस्ट सिक्योरिटी के सीईओ और संस्थापक – साक्षात्कार श्रृंखला

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

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

आप पहले ट्रेंड माइक्रो में एप्लिकेशन सुरक्षा का नेतृत्व करते थे और इम्यूनियो के सह-संस्थापक थे। आपको बूस्ट सिक्योरिटी की स्थापना करने के लिए क्या प्रेरित किया, और आप किस बाजार की कमी को जल्दी से पहचानने के लिए अनोखे रूप से स्थित थे?

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

यह 2012 में था, डेवओप्स अभी भी शुरुआती था, अधिकांश टीमें एगाइल नहीं थीं, और कुबेरनेट्स अभी तक एक चीज नहीं थी।

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

• स्कैन बहुत धीमे हैं, या परिणाम बहुत देर से आते हैं
• परिणाम डेवलपर्स के लिए कार्रवाई करने के लिए बहुत जटिल हैं
• एक सामान्य रूप से अस्वीकार्य झूठी सकारात्मक दर है
• स्कैन किए जाने वाले कई नए प्रकार के कलाकृतियों नहीं हैं: इन्फ्रास्ट्रक्चर के रूप में कोड, कंटेनर, एपीआई उदाहरण के लिए

सॉफ्टवेयर को तेजी से बनाना आसान था। सुरक्षित सॉफ्टवेयर को तेजी से बनाना अभी भी कठिन था।

यह मूल समस्या थी जिसका समाधान हमने करने का फैसला किया। डेवसेकओप्स को वास्तविक दुनिया में काम करें; क्या आप एक सॉफ्टवेयर विकास टीम को आसानी से एसडीएलसी में सुरक्षा जोड़ने के लिए प्राप्त कर सकते हैं, नए वेलोसिटी मानकों से मेल खाने की गति से? क्या आप कवरेज को व्यापक बना सकते हैं – जहां एक प्लेटफ़ॉर्म सभी की जरूरत है? क्या आप इसे इतना स्केल कर सकते हैं कि आपको सुरक्षा पेशेवरों की सेना की जरूरत नहीं है ताकि आप कोड की मात्रा के साथ तालमेल रख सकें…

हमने कंपनियों को डेवओप्स युग के दौरान एसडीएलसी में सुरक्षा को इंजेक्ट करने में मदद की। यह 1 से 10 तक जाना था। हम अब एजेंटिक कोडिंग के युग में हैं – जहां एजेंट एक बड़ी मात्रा में कोड लिख रहे हैं – लेकिन यह मूल रूप से वही समस्या है – गति और कोड की मात्रा केवल 10 से 100 तक चली गई है; और हम उसी ट्रेजेक्टरी को जारी रखने का लक्ष्य रखते हैं।

आप तर्क देते हैं कि सॉफ्टवेयर विकास जीवन चक्र (एसडीएलसी) में मूल रूप से अपस्ट्रीम बदल गया है। पारंपरिक डेवसेकओप्स दृष्टिकोण अब पर्याप्त नहीं होने का एहसास आपको कब हुआ?

यह हमलावरों को वास्तव में कैसे मिल रहा था, यह देखकर था। हमने एक ही पैटर्न को बार-बार देखा:

एक्सपोज्ड गिटहब एक्शन्स वर्कफ्लो, जिसे कोई समीक्षा नहीं की गई थी जब रिपॉजिटरी को फोर्क किया गया था, एक टोकन जिसमें उत्पादन क्लाउड एक्सेस शामिल था जो एक रनर कॉन्फ़िगरेशन में एम्बेडेड था, एक वैध सीआई नौकरी जो हमलावर पेलोड को तैनात करने के लिए हाईजैक की गई थी। इन्हें “लिविंग ऑफ द पाइपलाइन” हमले के रूप में जाना जाता था, क्योंकि हमलावर आपके खिलाफ अपने स्वचालन का उपयोग करता है, जिसे आपकी सुरक्षा टीम ने पहले ही अनुमोदित कर दिया है।

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

जब यह हमले का सबसे कम प्रतिरोध का मार्ग बन जाता है, तो आप साफ़ कोड शिप कर सकते हैं और अभी भी हमलावरों को आपके क्लाउड दे सकते हैं।

एजेंट कोड लगातार बना रहे हैं, न कि डेवलपर्स के चरणबद्ध रूप से – एक ऐसी दुनिया में एसडीएलसी को कैसे पुनः सोचें?

हमें एसडीएलसी को एक चेकपॉइंट की श्रृंखला के रूप में सोचना बंद करना होगा। एजेंटों ने “किसी ने यह लिखा” और “यह उत्पादन में है” के बीच के समय को हफ्तों से मिनटों में बदल दिया है। पुराने मॉडल ने मानव कैडेंस के बीच माना जाता था कोड समीक्षा, एसएएसटी, एससीए, और तैनाती, लेकिन हम अब उससे परे हैं।

सुरक्षा को एजेंट के संचालन के स्थान पर रहना होगा: डेवलपर की मशीन पर, प्रॉम्प्ट संदर्भ के भीतर, एजेंट के एमसीपी सर्वर और बाहरी मॉडल से कनेक्शन में। पाइपलाइन तक पहुंचने से पहले ही आप इसे आकार देने का मौका खो चुके हैं। एजेंट पहले ही निर्भरता खींच ली है। मॉडल पहले ही साख देख चुका है। नियंत्रण को ऊपर ले जाएं, जहां वास्तव में काम होता है।

कई संगठन अभी भी एआई कोडिंग टूल्स को साधारण उत्पादकता परतों के रूप में मानते हैं। आप उन्हें एक पूरी तरह से नए हमले की सतह के रूप में क्यों मानते हैं, न कि केवल मौजूदा कार्य प्रवाह के विस्तार के रूप में?

एक कोडिंग एजेंट को उत्पादकता परत के रूप में मानना उसी तरह है जैसे जूनियर डेवलपर को रूट एक्सेस के साथ उत्पादकता परत के रूप में मानना। लेबल तकनीकी रूप से सटीक है, लेकिन यह आपको क्या गलत हो सकता है इसके बारे में कोई उपयोगी फ्रेमवर्क नहीं देता है।

एक कोडिंग एजेंट आपके फ़ाइल सिस्टम को पढ़ता है, पर्यावरण перемен्चों को संदर्भ के लिए खंगालता है, सार्वजनिक रजिस्ट्रियों से निर्भरता लाता है, बाहरी मॉडल प्रदाताओं और एमसीपी सर्वरों के लिए आउटबाउंड कनेक्शन खोलता है, और शेल कमांड निष्पादित करता है। इनमें से प्रत्येक क्रिया के लिए पहले मानव हस्तक्षेप की आवश्यकता होती थी। अब वे मिलीसेकंड में होते हैं, जिसमें उसी विशेषाधिकार होते हैं जो डेवलपर के पास होते हैं जिसने एजेंट लॉन्च किया था।

यह विश्वास की सीमाओं को जोड़ती है जो पहले अलग थीं: डेवलपर की अधिकार, बाहरी टूल क्या प्राप्त कर सकता है, और अविश्वसनीय कोड क्या निष्पादित कर सकता है। यह हमलावरों के लिए नए अवसर पैदा करता है और रक्षकों को देखने में असमर्थ बनाता है, जो रक्षा नहीं कर सकते हैं।

बूस्ट डेवलपर लैपटॉप को नया नियंत्रण विमान के रूप में फ्रेम करता है। सुरक्षा टीमें वर्तमान में जिस जोखिम को अनदेखा कर रही हैं वह एंडपॉइंट पर मौजूद है?

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

इसके नीचे क्रेडेंशियल गड़बड़ी है। हमने इसे ठोस बनाने के लिए बैगेल नामक एक ओपन-सोर्स टूल बनाया। एक典型 डेवलपर लैपटॉप में उत्पादन रिपॉजिटरी में लिखने के लिए गिटहब टोकन होते हैं, क्लाउड क्रेडेंशियल जो बुनियादी ढांचे को स्पिन कर सकते हैं, एनपीएम या पीआईपीआई टोकन जो लाखों उपयोगकर्ताओं को प्रकाशित कर सकते हैं, और एआई सेवा कुंजियां जिन्हें हमलावर पुनर्विक्रय करते हैं। इनमें से कोई भी सीआई रनर की तरह सख्त नहीं है। उसी मशीन में जो इन क्रेडेंशियल्स को रखती है वह वेब भी ब्राउज़ करती है और यादृच्छिक वीएस कोड एक्सटेंशन इंस्टॉल करती है।

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

आप “संदर्भ जाल” के बारे में बताते हैं, जहां एआई एजेंट स्थानीय फ़ाइलों, पर्यावरण перемен्चों और कॉन्फ़िगरेशन तक पहुंच सकते हैं। संवेदनशील डेटा के रिसाव का जोखिम कितना व्यापक है, और यह इतना कठिन क्यों है पता लगाने के लिए?

पर्याप्त रूप से व्यापक यह है कि हम इसे किसी भी अनप्रबंधित डेवलपर वातावरण की वास्तविक स्थिति के रूप में मानते हैं। प्रत्येक कोडिंग एजेंट जिसे हमने जांचा है वह संदर्भ को आक्रामक रूप से खींचता है। वे डॉटफाइल्स पढ़ते हैं, पर्यावरण перемен्चों को संदर्भ के लिए खंगालते हैं, हाल की फ़ाइलें, कभी-कभी पूरे डायरेक्टरी पेड़, और इस संदर्भ को दूरस्थ मॉडल में शिप करते हैं। उपकरण इस तरह से काम करने के लिए डिज़ाइन किए गए हैं; आक्रामक संदर्भ抓bing उन्हें उपयोगी बनाता है।

पता लगाने की समस्या तब शुरू होती है क्योंकि रिसाव से यातायात सामान्य उत्पाद उपयोग के समान दिखता है। यह api.openai.com या api.anthropic.com के लिए टीएलएस है। यह एक अनुमोदित व्यावसायिक अनुप्रयोग से आता है। मानक डीएलपी एक डेवलपर को देखता है जो कंपनी द्वारा खरीदी गई लाइसेंस वाली एआई टूल का उपयोग कर रहा है। यह नहीं देखता है कि प्रॉम्प्ट में से एक स्ट्रिंग एक एएचएस सीक्रेट की है जिसे एजेंट ने एक भाई डायरेक्टरी में एक आधे भूले हुए .env फ़ाइल से खींचा है।

आपको इसे तब तक पकड़ते हैं जब तक आप लैपटॉप पर प्रॉम्प्ट की जांच करते हैं इससे पहले कि वे निकल जाएं, जो लगभग कोई सुरक्षा स्टैक वर्तमान में स्थित नहीं है।

आप मशीन-गति आपूर्ति श्रृंखला हमलों का उल्लेख करते हैं। एक वास्तविक दृश्य के माध्यम से चलें जहां एक एआई एजेंट पारंपरिक सुरक्षा उपकरणों की तुलना में तेजी से एक कमजोरियों का परिचय देता है?

यह एक है जिसे हमने बार-बार देखा है। डेवलपर एक एजेंट से एक सुविधा जोड़ने के लिए कहता है जिसे एक एचटीटीपी रिट्री लाइब्रेरी की आवश्यकता होती है। एजेंट एक पैकेज नाम का सुझाव देता है। पैकेज ध्वनि-युक्त है लेकिन वास्तव में एनपीएम पर मौजूद नहीं है। एक घंटे के भीतर, एक हमलावर इसे पंजीकृत करता है, इसे काम करने वाले रिट्री तर्क के साथ भर देता है साथ ही एक छोटा सा पोस्ट-इंस्टॉल स्क्रिप्ट जो ~/.aws/credentials पढ़ता है और सामग्री को एक वेबहुक पर पोस्ट करता है। एजेंट npm install चलाता है बिना प्रतिष्ठा की जांच के, क्योंकि एजेंट प्रतिष्ठा की जांच नहीं करते हैं। क्रेडेंशियल गायब हो जाता है इससे पहले कि डेवलपर甚至 कोड चलाता है।

हमला तकनीकी रूप से जटिल नहीं है, लेकिन पारंपरिक आपूर्ति श्रृंखला सुरक्षा ज्ञात पैकेजों में ज्ञात कमजोरियों के आसपास बनाई गई है: सीवीई, एसबीओएम, लाइसेंस स्कैनिंग। उस फ्रेमवर्क में कुछ भी नहीं है जो एक पैकेज के बारे में कहा जा सकता है जो तब मौजूद नहीं था जब स्कैन आखिरी बार चलाया गया था, विशेष रूप से एक एआई हॉलुसिनेशन से मेल खाने के लिए बनाया गया था, और स्कैन चलाने के बाद से पहले ही इंजेक्ट किया गया था।

प्रकाशन से समझौता करने की खिड़की अब मिनटों में मापी जाती है। कुछ भी जो事実 के बाद जांच करता है वह बहुत देर से जांच कर रहा है।

क्या हॉलुसिनेटेड निर्भरताएं एआई-चालित विकास में सबसे बड़े जोखिमों में से एक बन रही हैं, और संगठन उनसे बचाव के लिए व्यावहारिक कदम क्या उठा सकते हैं?

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

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

आप कहा है कि सुरक्षा अब सीआई/सीडी पर शुरू नहीं हो सकती है। सुरक्षा का एक आधुनिक पाइपलाइन क्या दिखता है जब सुरक्षा को विकास प्रक्रिया में पहले शुरू करने की आवश्यकता होती है?

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

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

पाइपलाइन खुद गायब नहीं होती है। इसकी भूमिका पुष्टि करना बन जाता है: यह पुष्टि करना कि अपस्ट्रीम नियंत्रण पकड़े गए थे।

जैसे ही संगठन एआई कोडिंग एजेंटों को अपनाते रहते हैं, वे अपने विकास वातावरण को सुरक्षित रखने के लिए अगले कुछ वर्षों में किन सबसे महत्वपूर्ण परिवर्तनों को करने की आवश्यकता है?

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

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

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

साक्षात्कार के लिए धन्यवाद, पाठक जो और जानना चाहते हैं उन्हें बूस्ट सिक्योरिटी पर जाना चाहिए।