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

ज़ैद अल हमानी, बूस्ट सिक्योरिटी के सीईओ और संस्थापक, एक साइबर सुरक्षा और डेवसेकओप्स नेता हैं जिनके पास दो दशक से अधिक का अनुभव है वैश्विक प्रौद्योगिकी संचालन का निर्माण और स्केलिंग करना। बूस्ट सिक्योरिटी की स्थापना 2020 में करने के बाद, उन्होंने सॉफ्टवेयर विकास को सुरक्षित करने के तरीके को आधुनिक बनाने पर ध्यान केंद्रित किया है, जिसमें ट्रेंड माइक्रो में एप्लिकेशन सुरक्षा के वीपी और इम्यूनियो के सह-संस्थापक/सीईओ सहित पूर्व भूमिकाओं का लाभ उठाया गया है। इससे पहले, उन्होंने कैनोनिकल में वरिष्ठ नेतृत्व पदों पर काम किया, जहां उन्होंने उत्पाद, इंजीनियरिंग और वैश्विक समर्थन पहल का नेतृत्व किया, और एसआईटीए में जहां उन्होंने बड़े पैमाने पर, मिशन-महत्वपूर्ण आईटी संचालन का प्रबंधन किया। उनका करियर टीमों का निर्माण, प्रणालियों का अनुकूलन और आधुनिक सुरक्षा प्रथाओं को आगे बढ़ाने का एक मजबूत रिकॉर्ड प्रदर्शित करता है।
बूस्ट सिक्योरिटी एक साइबर सुरक्षा कंपनी है जो एक डेवलपर-फर्स्ट डेवसेकओप्स प्लेटफॉर्म के माध्यम से आधुनिक सॉफ्टवेयर सप्लाई चेन को सुरक्षित करने पर केंद्रित है। इसकी तकनीक सीआई/सीडी पाइपलाइनों में सीधे एकीकृत होती है ताकि स्वचालित रूप से कमजोरियों का पता लगाया जा सके, उन्हें प्राथमिकता दी जा सके और उन्हें ठीक किया जा सके, मैनुअल ओवरहेड को कम करते हुए विकास गति को बनाए रखा जा सके। एप्लिकेशन और सप्लाई चेन सुरक्षा को एक ही सिस्टम में एकीकृत करके, प्लेटफ़ॉर्म कोड, निर्भरताओं और बुनियादी ढांचे में पूरी दृश्यता प्रदान करता है, जो जटिल, क्लाउड-मूल वातावरण में लचीलापन को मजबूत करने में मदद करता है।
आप पहले ट्रेंड माइक्रो में एप्लिकेशन सुरक्षा का नेतृत्व करते थे और इम्यूनियो के सह-संस्थापक थे। बूस्ट सिक्योरिटी की स्थापना करने के लिए आपको क्या प्रेरित किया, और आप बाजार में किस अंतर को पहचानने के लिए विशिष्ट रूप से स्थित थे?
इम्यूनियो पहली आरएएसपी कंपनियों में से एक थी जिसकी स्थापना की गई थी – और हमारा अनुभव उस समय तक यह था कि रनटाइम सुरक्षा प्रौद्योगिकी के रूप में डब्ल्यूएएफ असंभव थे और बहुत प्रभावी नहीं थे। हमने एक तरीके की कल्पना की जिसमें डब्ल्यूएएफ को एक अधिक सटीक, रखरखाव में आसान समाधान से बदल दिया जाएगा – एप्लिकेशन को इंस्ट्रुमेंटिंग करके।
यह 2012 में था, डेवओप्स अभी भी शुरुआती चरण में था, और अधिकांश टीमें एगाइल नहीं थीं, और कुबेरनेट्स अभी तक एक चीज नहीं थी।
ट्रेंड माइक्रो ने 2017 में इम्यूनियो का अधिग्रहण किया। उस समय तक, डेवओप्स के अधिक अभ्यास थे: सीआई/सीडी पाइपलाइन, एगाइल विकास अभ्यास, तेज़ पुनरावृत्ति और रिलीज़ चक्र, क्लाउड, आदि। सॉफ्टवेयर विकास टीमें सॉफ्टवेयर बनाने में बेहतर हो गई थीं, और तेजी से शिपिंग कर रही थीं। सुरक्षा अभी भी टूटी हुई थी, हालांकि:
- स्कैन बहुत धीमे हैं, या परिणाम बहुत देर से आते हैं
- परिणाम विकासकर्ताओं के लिए कार्रवाई करने के लिए बहुत जटिल हैं
- एक सामान्य रूप से अस्वीकार्य झूठी सकारात्मक दर थी
- कई नए प्रकार के आर्टिफैक्ट्स स्कैन नहीं किए गए थे: इंफ्रास्ट्रक्चर के रूप में कोड, कंटेनर, एपीआई उदाहरण के लिए
सॉफ्टवेयर का उत्पादन तेजी से करना आसान था। सुरक्षित सॉफ्टवेयर का उत्पादन तेजी से करना अभी भी कठिन था।
यह मूल समस्या थी जिसे हम हल करने के लिए निर्धारित किया था। डेवसेकओप्स को वास्तविक दुनिया में काम करने दें; क्या आप एक सॉफ्टवेयर विकास टीम को आसानी से एसडीएलसी में सुरक्षा जोड़ने के लिए प्राप्त कर सकते हैं, नए वेलोसिटी मानकों से मेल खाने की गति से? क्या आप कवरेज को व्यापक बना सकते हैं – जहां एक प्लेटफ़ॉर्म सभी की जरूरत है? क्या आप इसे ऐसा बना सकते हैं कि विकासकर्ता, न केवल प्रौद्योगिकी को अपनाएं, बल्कि इसके लाभों को देखें और इसका स्वागत करें? क्या आप इसे ऐसा बना सकते हैं कि आपको सुरक्षा पेशेवरों की सेना की आवश्यकता नहीं है ताकि आप लिखे गए कोड की मात्रा के साथ तालमेल रख सकें…
हमने कंपनियों को एसडीएलसी के दौरान सुरक्षा को इंजेक्ट करने में मदद की। डेवओप्स युग में यह 1 से 10 तक जाना था। हम अब एजेंटिक कोडिंग के युग में हैं – जहां एजेंट बहुत सारा कोड लिख रहे हैं – लेकिन यह मूल रूप से वही समस्या है – गति और कोड की मात्रा केवल 10 से 100 तक चली गई है; और हम उसी दिशा को जारी रखने का लक्ष्य रखते हैं।
आप पहले कह चुके हैं कि सॉफ्टवेयर विकास जीवन चक्र (एसडीएलसी) मूल रूप से अपस्ट्रीम में बदल गया है। पारंपरिक डेवसेकओप्स दृष्टिकोण अब पर्याप्त नहीं होने का एहसास आपको कब हुआ?
यह हमलावरों को वास्तव में कैसे मिल रहा था, यह देखकर था। हमने एक ही पैटर्न को बार-बार देखा: एक एक्सपोज्ड गिटहब एक्शन वर्कफ्लो जिसे कोई समीक्षा नहीं की थी जब रिपॉजिटरी को फोर्क किया गया था, एक टोकन जिसमें उत्पादन क्लाउड एक्सेस शामिल था जो एक रनर कॉन्फ़िगरेशन में एम्बेडेड था, एक वैध सीआई जॉब जो हमलावर पेलोड को तैनात करने के लिए हाईजैक किया गया था। इन्हें “लिविंग ऑफ द पाइपलाइन” हमले के रूप में जाना जाता था, क्योंकि हमलावर आपके खिलाफ अपने स्वचालन का उपयोग करता है, जिसे आपकी सुरक्षा टीम ने पहले ही अनुमोदित कर दिया है।
हमने जो डेवसेकओप्स स्टैक बनाया था, उसका इसका कोई जवाब नहीं था। एसएएसटी स्कैन एप्लिकेशन सोर्स। एससीए स्कैन एप्लिकेशन निर्भरताएं। दोनों मानते हैं कि उन्हें चलाने वाला पाइपलाइन विश्वसनीय है। जबकि पाइपलाइन खुद एक याम्ल फ़ाइल है जिसमें शेल कमांड, नेटवर्क एक्सेस और संवेदनशील क्रेडेंशियल हैं, और लगभग कोई इसे समीक्षा नहीं करता है।
जब यह हमले का सबसे कम प्रतिरोध का मार्ग बन जाता है, तो आप साफ़ कोड शिप कर सकते हैं और अभी भी हमलावरों को अपना क्लाउड दे सकते हैं।
एआई एजेंटों द्वारा निरंतर कोड उत्पन्न करने की दुनिया में विकासकर्ताओं के बजाय एसडीएलसी को कैसे पुनः सोचा जाना चाहिए?
हमें एसडीएलसी को एक चेकपॉइंट की श्रृंखला के रूप में सोचना बंद करना होगा। एआई एजेंटों ने “किसी ने यह लिखा” और “यह उत्पादन में है” के बीच के समय को सप्ताह से मिनटों में बदल दिया है। पुराना मॉडल मानव कैडेंस के बीच मान लिया कोड समीक्षा, एसएएसटी, एससीए, और तैनाती, लेकिन हम अब उससे आगे हैं।
सुरक्षा को एजेंट के संचालन के स्थान पर रहना होगा: डेवलपर की मशीन पर, प्रॉम्प्ट संदर्भ के भीतर, एजेंट के एमसीपी सर्वर और बाहरी मॉडल से कनेक्शन में। जब कोड पाइपलाइन तक पहुंचता है, तो आप इसे आकार देने का मौका पहले ही खो चुके हैं। एजेंट ने पहले ही निर्भरता खींच ली है। मॉडल ने पहले ही साख देख ली है। नियंत्रणों को अपस्ट्रीम ले जाएं, जहां वास्तव में काम होता है।
कई संगठन अभी भी एआई कोडिंग टूल्स को साधारण उत्पादकता परतों के रूप में मानते हैं। आप क्यों मानते हैं कि वे मौजूदा कार्य प्रवाहों के विस्तार के बजाय एक पूरी तरह से नए हमले की सतह का प्रतिनिधित्व करते हैं?
एक एआई कोडिंग टूल को एक उत्पादकता परत के रूप में मानना एक जूनियर डेवलपर को रूट एक्सेस के साथ एक उत्पादकता परत के रूप में मानने जैसा है। लेबल तकनीकी रूप से सटीक है, लेकिन यह आपको कुछ भी गलत होने के बारे में सोचने के लिए कोई उपयोगी फ्रेमवर्क नहीं देता है।
एक कोडिंग एजेंट आपके फ़ाइल सिस्टम को पढ़ता है, पर्यावरण चर को संदर्भ के लिए स्क्रैप करता है, सार्वजनिक रजिस्ट्री से निर्भरता प्राप्त करता है, आउटबाउंड कनेक्शन खोलता है और दूरस्थ मॉडल प्रदाताओं और एमसीपी सर्वर के लिए शेल कमांड निष्पादित करता है। इनमें से प्रत्येक क्रिया के लिए मानव हस्तक्षेप की आवश्यकता होती थी। अब वे मिलीसेकंड में होते हैं, जिस डेवलपर ने एजेंट लॉन्च किया था उसके समान अधिकार के साथ।
यह डेवलपर की अधिकारिता, बाहरी टूल द्वारा प्राप्त की जा सकने वाली चीज़, और असुरक्षित कोड के निष्पादन के बीच विश्वास की सीमाओं को एक साथ मिलाता है। यह हमलावरों के लिए नए अवसर पैदा करता है और रक्षकों को देखने में भी असमर्थ बनाता है, छोड़ देता है बहुत सारे अंधे धब्बे।
बूस्ट डेवलपर लैपटॉप को नया नियंत्रण विमान के रूप में फ्रेम करता है। एंडपॉइंट पर कौन से जोखिम हैं जिन्हें सुरक्षा टीमें वर्तमान में अनदेखा कर रही हैं?
सबसे बड़ा एक इन्वेंट्री है। अधिकांश सुरक्षा टीमें आपको नहीं बता सकती हैं कि कौन से एआई एजेंट कौन से लैपटॉप पर चल रहे हैं, कौन से एमसीपी सर्वर उन एजेंटों से जुड़े हुए हैं, या कौन से आईडीई एक्सटेंशन वर्तमान में रिपॉजिटरी सामग्री को स्क्रैप कर रहे हैं। ईडीआर के पास एजेंट परत में दृश्यता नहीं है; एसआईईएम भी स्थानीय रूप से क्या करते हैं उन एजेंटों को नहीं देख सकता। यह एक शैडो आईटी समस्या है जिसमें कोड-निष्पादन अधिकार हैं।
इसके नीचे साख भ्रम है। हमने एक ओपन-सोर्स टूल बनाया जिसे बैगेल कहा जाता है जो इसे ठोस बनाने के लिए। एक सामान्य डेवलपर लैपटॉप में उत्पादन रिपॉजिटरी में लिखने के लिए गिटहब टोकन होते हैं, क्लाउड क्रेडेंशियल जो बुनियादी ढांचे को स्पिन कर सकते हैं, एनपीएम या पिपी टोकन जो लाखों उपयोगकर्ताओं को प्रकाशित कर सकते हैं, और एआई सेवा कुंजियाँ जिन्हें हमलावर फिर से बेचते हैं। इनमें से कोई भी सीआई रनर की तरह सख्ती से सुरक्षित नहीं है। उसी मशीन में जो इन क्रेडेंशियल्स को रखती है वह वेब भी ब्राउज़ करती है और यादृच्छिक वीएस कोड एक्सटेंशन भी इंस्टॉल करती है।
दोनों को जोड़िए और आपके पास वास्तविक हमला सतह है। एक असुरक्षित एक्सटेंशन जो डेवलपर विशेषाधिकारों के साथ चल रहा है जो क्लाउड कुंजियों से भरा वातावरण में है, सबसे अधिक लाभ वाला लक्ष्य है जो आधुनिक उद्यम में है। अधिकांश टीमें इसमें देखना शुरू नहीं किया है।
आप “संदर्भ जाल” के बारे में बताया है, जहां एआई एजेंट स्थानीय फ़ाइलों, पर्यावरण चर और कॉन्फ़िगरेशन तक पहुंच सकते हैं। संवेदनशील डेटा के रिसाव का जोखिम कितना व्यापक है, और यह इतना कठिन क्यों है इसका पता लगाने के लिए?
पर्याप्त रूप से व्यापक कि हम इसे किसी भी अनप्रबंधित डेवलपर वातावरण की डिफ़ॉल्ट स्थिति के रूप में मानते हैं। प्रत्येक कोडिंग एजेंट जिसे हमने जांचा है वह संदर्भ को आक्रामक रूप से खींचता है। वे डॉटफाइल्स पढ़ते हैं, पर्यावरण चर पढ़ते हैं, हाल की फ़ाइलें पढ़ते हैं, कभी-कभी पूरे डायरेक्टरी पेड़ पढ़ते हैं, और उस संदर्भ को दूरस्थ मॉडल में शिप करते हैं। टूल्स को इस तरह से काम करने के लिए डिज़ाइन किया गया है; आक्रामक संदर्भ चुनना उन्हें उपयोगी बनाता है।
पता लगाने की समस्या तब शुरू होती है क्योंकि रिसाव से यातायात सामान्य उत्पाद उपयोग जैसा दिखता है। यह api.openai.com या api.anthropic.com के लिए टीएलएस है। यह एक अनुमोदित व्यवसाय अनुप्रयोग से आता है। मानक डीएलपी एक डेवलपर को देखता है जो कंपनी द्वारा लाइसेंस प्राप्त एआई टूल का उपयोग कर रहा है। यह देखता है कि प्रॉम्प्ट में एक स्ट्रिंग है जो एक एएचएस सीक्रेट की है जिसे एजेंट ने एक भाई डायरेक्टरी में एक आधे भूले हुए .env फ़ाइल से खींचा है।
आपको इसे तब तक पकड़ते हैं जब तक आप लैपटॉप से बाहर निकलने से पहले प्रॉम्प्ट की जांच करते हैं, जो लगभग nowhere सुरक्षा स्टैक वर्तमान में स्थित है।
आप मशीन-स्पीड सप्लाई चेन हमलों का उल्लेख करते हैं। एक एआई एजेंट द्वारा एक दुर्वलता को पेश करने का एक वास्तविक दृश्य के माध्यम से चलने के लिए आप क्या कर सकते हैं जो पारंपरिक सुरक्षा उपकरणों द्वारा इसकी पहचान की जा सकती है?
यह एक है जिसे हमने बार-बार देखा है। डेवलपर एक एजेंट से एक फीचर जोड़ने के लिए कहता है जिसे एक एचटीटीपी रिट्री लाइब्रेरी की आवश्यकता होती है। एजेंट एक पैकेज नाम का सुझाव देता है। पैकेज ध्वनि-सounding है लेकिन वास्तव में एनपीएम पर मौजूद नहीं है। एक घंटे के भीतर, एक हमलावर इसे पंजीकृत करता है, इसे काम करने वाले रिट्री तर्क के साथ आबाद करता है जो एक छोटा सा पोस्ट-इंस्टॉल स्क्रिप्ट भी चलाता है जो ~/.aws/credentials को पढ़ता है और सामग्री को एक वेबहुक पर पोस्ट करता है। एजेंट npm install चलाता है क्योंकि एजेंट प्रतिष्ठा की जांच नहीं करते हैं। क्रेडेंशियल तब तक चला जाता है जब तक कि डेवलपर कोड भी नहीं चलाता।
हमला तकनीकी रूप से जटिल नहीं है, लेकिन पारंपरिक सप्लाई-चेन सुरक्षा ज्ञात पैकेजों में ज्ञात कमजोरियों के आसपास बनाई गई है: सीवीई, एसबीओएम, लाइसेंस स्कैनिंग। उस फ्रेमवर्क में एक पैकेज के लिए कुछ भी नहीं है जो तब मौजूद नहीं था जब स्कैन आखिरी बार चलाया गया था, जो एक एआई हॉलुसिनेशन से मेल खाने के लिए बनाया गया था, और स्कैन चलाने से पहले ही निगल लिया जाता है।
प्रकाशन से समझौता तक की खिड़की अब मिनटों में मापी जाती है। कुछ भी जो घटना के बाद जांच करता है बहुत देर से जांच कर रहा है।
क्या हॉलुसिनेटेड निर्भरताएं एआई-चालित विकास में सबसे बड़े जोखिमों में से एक बन रही हैं, और संगठन उन्हें बचाव के लिए व्यावहारिक कदम क्या उठा सकते हैं?
वे पहले से ही सबसे बड़े जोखिमों में से एक हैं। हमलावर लोकप्रिय एआई टूल की हॉलुसिनेशन की निगरानी करते हैं और सuggested पैकेज नामों को कुछ ही मिनटों में पंजीकृत करते हैं। शोधकर्ताओं ने कुछ साल पहले, जब यह पहली बार हुआ, तो इसे स्लोपस्क्वाटिंग कहा और नाम चिपक गया। एक बार जब एक निर्भरता नाम अक्सर हॉलुसिनेटेड हो जाता है, तो इसे बैठना एक निष्क्रिय सप्लाई-चेन हमला है जिसके लिए लगभग शून्य प्रयास की आवश्यकता होती है।
व्यावहारिक रक्षा वर्तमान में अधिकांश टीमों के पास मौजूद चीजों से अलग दिखती है। इंजेस्ट पर शुरू करें। डेवलपर की मशीन पर, npm install या pip install चलने से पहले, डिस्क पर कुछ भी हिट करने से पहले टाइपोस्क्वाटेड और नए पंजीकृत पैकेजों को ब्लॉक करें। सीआई में मरणोपरांत पता लगाना तब मदद नहीं करता है जब एक पोस्ट-इंस्टॉल स्क्रिप्ट पहले ही एक क्रेडेंशियल को एक्सफिलिट्रेट कर चुका हो। फिर एजेंट को गार्डरेल दें जिसके भीतर संचालित करना है। अपनी अनुमोदित-निर्भरता सूची को सीधे एजेंट के संदर्भ में इंजेक्ट करें, ताकि मॉडल पहले से ही जानता है कि क्या अनुमति है इससे पहले कि यह एक सुझाव उत्पन्न करे। डेवलपर्स को “सुरक्षित प्रॉम्प्ट” लिखने के लिए कहना एक रणनीति नहीं है। यदि आप रणनीतिक हो रहे हैं, तो इसका मतलब है कि सुरक्षा सीमा निर्धारित करती है, एजेंट इसे विरासत में मिलता है। और एक एआई बिल ऑफ मैटेरियल का ट्रैक रखना शुरू करें। अधिकांश टीमें आपको नहीं बता सकती हैं कि कौन से एजेंट, मॉडल और पैकेज कौन से रिपॉजिटरी को छू रहे हैं। आप जो नहीं देख सकते हैं उसे बचा नहीं सकते।
आपका कहना है कि सुरक्षा अब सीआई/सीडी पर शुरू नहीं हो सकती। जब सुरक्षा को विकास प्रक्रिया में पहले शुरू करने की आवश्यकता होती है तो एक आधुनिक सुरक्षा पाइपलाइन क्या दिखती है?
यदि सुरक्षा सीआई/सीडी पर शुरू होती है, तो आप पूरे प्री-कमिट चरण को एक वातावरण के लिए छोड़ देते हैं जिसे आप नियंत्रित नहीं करते हैं। एजेंट पहले ही संदर्भ को निगल चुका है, आपका क्रेडेंशियल शायद पहले ही किसी और के लॉग में है। आप एक लाश को स्कैन कर रहे हैं।
एक आधुनिक पाइपलाइन लैपटॉप पर शुरू होती है। इसका मतलब है कि वहां चलने वाले एजेंटों और एक्सटेंशनों को इन्वेंट्री करना, यह सत्यापित करना कि वे किन एमसीपी सर्वर और मॉडल से जुड़े हुए हैं, जो मशीन से बाहर निकलता है उसे सैनिटाइज करना, और मैलिशियस पैकेजों को स्थापित होने से पहले ब्लॉक करना। वहां से, नीति काम को आईडीई में अनुसरण करती है। हम सुरक्षा मानकों को सीधे एजेंट के संदर्भ विंडो में इंजेक्ट करते हैं ताकि उत्पन्न कोड पहले टोकन से सुरक्षित रहे। पाइपलाइन अभी भी चलती है, जो नियंत्रणों की पुष्टि करती है जो पहले से ही अपस्ट्रीम में लागू किए गए थे।
पाइपलाइन खुद गायब नहीं होती। इसकी भूमिका पुष्टि करना बन जाता है: यह पुष्टि करता है कि अपस्ट्रीम नियंत्रण पकड़े गए थे।
एआई कोडिंग एजेंटों को अपनाते रहने वाले संगठनों के लिए सबसे महत्वपूर्ण परिवर्तन क्या हैं जिन्हें आज अपने विकास वातावरण को सुरक्षित रखने के लिए अगले कुछ वर्षों में करने की आवश्यकता है?
सबसे बड़ी गलती केवल वही सुरक्षित करना है जो प्रतिबद्ध है। जोखिम अब उन आठ घंटों में रहता है जब कोई प्रतिबद्धता नहीं होती। लैपटॉप पर, प्रॉम्प्ट में, या पैकेज इंस्टॉल में अनदेखी नाटक हो सकता है। यदि आपके उपकरण पीआर पर शुरू होते हैं, तो आप गलत आधे कार्य प्रवाह की रक्षा कर रहे हैं।
निकटता से संबंधित: कोडिंग एजेंटों को उत्पादकता सॉफ्टवेयर के रूप में मानना बंद करें। वे शेल एक्सेस, रिपॉजिटरी लिखने के अधिकार, और आउटबाउंड नेटवर्क कनेक्शन के साथ गैर-मानव उपयोगकर्ता हैं। उन्हें किसी अन्य विशेषाधिकार प्राप्त पहचान की तरह शासित करें, एक इन्वेंट्री के साथ, अनुमोदित क्षमताओं के साथ, और ऑडिट लॉग के साथ।
आखिरी बदलाव कठिन है सांस्कृतिक रूप से। अधिकांश वर्तमान “एआई सुरक्षा” टूल खोज परिणामों को सतह पर लाते हैं और उन्हें मानवों को रूट करते हैं। मानव एजेंटों की गति से त्रि-स्तर नहीं कर सकते। जो कुछ भी आप अपनाते हैं उसे कार्य प्रवाह के भीतर स्वचालित रूप से मुद्दों को ठीक करना होगा, अनुसरणीय तर्क के साथ, या यह एक और डैशबोर्ड बन जाता है जिसे कोई नहीं पढ़ता।
धन्यवाद महान साक्षात्कार के लिए, पाठक जो और जानना चाहते हैं उन्हें बूस्ट सिक्योरिटी पर जाना चाहिए।












