Shannon McWilliams, Orca Security में वैश्विक वितरण प्रमुख – साक्षात्कार श्रृंखला

Shannon McWilliams Orca Security में वैश्विक वितरण प्रमुख हैं। उनकी भूमिका में कंपनी का साझेदार नेटवर्क और उसे सहारा देने वाले टूल शामिल हैं। इससे पहले वे एक सॉफ्टवेयर विकास कंपनी की स्थापना कर चुके हैं, इसलिए उन्हें व्यावसायिक जरूरतों को ऐप्लिकेशन में बदलने का अनुभव है। हाल ही में, उन्होंने एआई विकास टूल का इस्तेमाल करके Orca के Partner Success Platform का शुरुआती संस्करण बनाया। इस परियोजना को सप्ताहांत के एक प्रोटोटाइप से उत्पादन के लिए तैयार प्रणाली बनाने की दिशा में आगे बढ़ाने के लिए उन्होंने सुरक्षा टीम के साथ काम किया।

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

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

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

एक सप्ताहांत में मैं उस चीज़ का पहला बुनियादी संस्करण बना पाया, जो आगे चलकर हमारा Partner Success Platform बना। इसमें ऐसी क्षमताएँ थीं जो पारंपरिक साझेदार पोर्टलों में मुझे दिखने वाली सुविधाओं से आगे थीं—जैसे आदर्श ग्राहक से मेल करना और सौदे के लिए मार्गदर्शन देना जैसी एआई-आधारित क्षमताएँ। हमने प्लेटफ़ॉर्म में कई और ऐप्लिकेशन जोड़े, जैसे प्रमाणन की प्रगति पर नज़र रखना, एआई से तैयार प्रश्नोत्तरी और अपने साझेदारों के लिए पूरी प्रमाणन प्रक्रिया को खेल जैसा बनाना। इसके बाद हमने अपने Salesforce प्लेटफ़ॉर्म के साथ डेटा का समन्वय शुरू किया। निर्णायक मोड़ तब आया जब हमारे सीईओ ने शुरुआती संस्करण देखा और उसकी क्षमता को पहचाना। उसी समय हमने प्रयोग के दायरे से आगे बढ़कर यह पूछना शुरू किया कि ऐसी चीज़ को सुरक्षित और उत्पादन के लिए तैयार बनाने में वास्तव में क्या लगेगा। हमारी सुरक्षा टीम इस काम में शामिल हुई और मैंने Dudi Peretz के साथ मिलकर परिवेश को सुरक्षित करने पर काम शुरू किया। अंततः, इस काम का स्वतंत्र सत्यापन एक बाहरी कंपनी से कराया गया।

आपने पहले एक सॉफ्टवेयर विकास कंपनी की स्थापना की थी, इसलिए आपको पारंपरिक तरीकों से ऐप्लिकेशन बनाने का अनुभव है। प्राकृतिक भाषा में एआई के ज़रिए सॉफ्टवेयर बनाना, डेवलपरों का प्रबंधन करने की तुलना में कैसा था? और इस प्रक्रिया में आपकी अपनी क्षेत्रीय विशेषज्ञता सबसे अधिक कहाँ काम आई?

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

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

Orca ने साझेदार प्लेटफ़ॉर्म के पहले कामकाजी संस्करण को ऐसी चीज़ बताया है जिसे आपने एक ही सप्ताहांत में बनाया था। एआई ने किन कामों को बहुत तेज़ कर दिया, और उत्पादन के लिए तैयार ऐप्लिकेशन बनाने के कौन-से हिस्से शुरू में जितने आसान लगे थे, उससे अधिक कठिन निकले?

एआई ने विचार और काम करने वाले ऐप्लिकेशन के बीच की दूरी को बहुत कम कर दिया। मैं सप्ताहांत में ऐसी सुविधाएँ बना सकता था जिनके लिए पारंपरिक रूप से कहीं अधिक लंबी विकास प्रक्रिया की ज़रूरत पड़ती, और मैं बहुत तेज़ी से सुविधाएँ जोड़ना और बदलना जारी रख सकता था। यह गति कमाल की भी है और थोड़ी डरावनी भी।

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

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

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

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

जब सुरक्षा टीम ने कमज़ोरियों की पहचान की, तो आप अक्सर उन निष्कर्षों को AI विकास परिवेश में वापस डालकर कुछ ही मिनटों में समाधान तैयार कर पाते थे। क्या AI सुरक्षा संबंधी समस्याओं के समाधान को लंबी विकास प्रक्रिया से बदलकर ऐप्लिकेशन बनाने वालों और सुरक्षा टीमों के बीच लगातार चलने वाली बातचीत में बदल सकता है?

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

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

लेकिन समस्याओं का तेज़ी से समाधान करने का यह मतलब नहीं कि हम सत्यापन के मानक घटा सकते हैं। AI तेज़ी से समाधान तैयार कर सकता है; फिर भी सुरक्षा टीमों को यह जाँचने का तरीका चाहिए कि समाधान ने सचमुच जोखिम दूर किया है या नहीं और उससे कोई दूसरा जोखिम तो पैदा नहीं हुआ।

इससे बने Partner Success Platform में AI सहायक, बिक्री-पाइपलाइन की जानकारी, अभियान तैयार करने और सौदों के लिए मार्गदर्शन जैसी सुविधाएँ शामिल हैं। आपने कैसे तय किया कि कौन-से काम AI सीधे करे और कौन-से फ़ैसले मानव साझेदार या विक्रेता के पास रहने चाहिए?

मेरे लिए लक्ष्य साझेदारी या बिक्री प्रक्रिया से इंसान को हटाना नहीं था। लक्ष्य था AI की मदद से लोगों को तेज़ी से काम करने और उनके पास पहले से उपलब्ध जानकारी का बेहतर इस्तेमाल करने में मदद देना। सौदों के लिए मार्गदर्शन इसका अच्छा उदाहरण है: AI बिक्री-पाइपलाइन में अटके अवसर को आगे बढ़ाने के तरीके पहचानने में मदद कर सकता है और किसी व्यक्ति को अतिरिक्त संदर्भ या अगला सुझाया गया कदम दे सकता है।

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

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

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

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

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

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

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

आपने AI से बने एप्लिकेशन के बढ़ते चलन की तुलना “शैडो IT” के और भी मुश्किल रूप से की है। इस पीढ़ी का शैडो सॉफ़्टवेयर संभावित रूप से ज़्यादा चुनौतीपूर्ण क्यों है, और संगठन उन एप्लिकेशन का पता कैसे लगा सकते हैं जिनके अस्तित्व की जानकारी सुरक्षा या IT टीमों को शायद हो ही नहीं?

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

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

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

आने वाले कई वर्षों को देखते हुए, क्या आपको लगता है कि ज़्यादातर ज्ञान-कर्मचारी AI की मदद से किसी न किसी रूप में सॉफ़्टवेयर बनाने लगेंगे? अगर ऐसा है, तो इससे उद्यमों में पेशेवर डेवलपरों, सुरक्षा टीमों और व्यावसायिक नेतृत्व की भूमिकाएँ कैसे बदलेंगी?

हम ऐसी दुनिया की ओर बढ़ रहे हैं जहाँ “सॉफ़्टवेयर बनाने वाले” की परिभाषा का दायरा कहीं ज़्यादा व्यापक होगा। AI की बदौलत, ऐसे लोग भी किसी विचार को बहुत तेज़ी से काम करने वाले एप्लिकेशन में बदल पा रहे हैं जो किसी व्यावसायिक समस्या को समझते हैं, लेकिन परंपरागत डेवलपर नहीं हैं। मैंने खुद इसका अनुभव किया है।

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

इस बेहतरीन साक्षात्कार के लिए धन्यवाद। जो पाठक क्लाउड सुरक्षा, AI से बने एप्लिकेशन और उद्यम परिवेशों को सुरक्षित रखने के बारे में और जानना चाहते हैं, वे Orca Security की वेबसाइट पर जाएँ।