AI सुरक्षा को दूसरी राय की ज़रूरत है

AI सॉफ़्टवेयर इतनी तेज़ी से लिख रहा है कि हम उसे सुरक्षित नहीं रख पा रहे। क्या आप इस गति के साथ कदम मिला पा रहे हैं?

जब तक आप यह वाक्य पढ़कर पूरा करेंगे, डेवलपर और उनके AI एजेंट कोड में लगभग दो हज़ार बदलाव दर्ज कर चुके होंगे। पिछले साल इसी समय यह संख्या लगभग 150 होती।

पिछले एक साल में AI से तैयार सॉफ़्टवेयर की रफ़्तार हैरतअंगेज़ स्तर तक पहुँच गई है। GitHub ने सिर्फ़ सितंबर 2026 में 7.38 अरब कमिट दर्ज किए—एक साल पहले की कुल संख्या से पाँच गुने से भी ज़्यादा। इस विस्फोट के सुरक्षा पर गहरे असर पड़ रहे हैं। इन कमिट में से हर एक कोड है, जिसे किसी को समझना, बनाए रखना और सुरक्षित करना चाहिए। क्लाउड सिक्योरिटी अलायंस ने पाया कि Fortune 50 कंपनियों में AI की मदद से काम करने वाले डेवलपर अपने सहकर्मियों की तुलना में तीन से चार गुना तेज़ी से कोड कमिट करते हैं, जबकि हर महीने सामने आने वाली सुरक्षा समस्याओं की संख्या लगभग दस गुना बढ़ गई।

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

नवीनतम मॉडल का मोह

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

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

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

इनमें से किसी बात का मतलब यह नहीं कि हम AI के ख़िलाफ़ हैं। बात यह है कि सुरक्षा के लिए दूसरी राय ज़रूरी है। आप जो भी इंजन चुनें, उससे तीन सवाल पूछें।

पहला सवाल: विश्वसनीयता

जब स्कैनर किसी गड़बड़ी की सूचना देता है, तो क्या उस पर समय लगाना फ़ायदेमंद है?

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

यहीं निरंतरता अहम होती है। नियतात्मक विश्लेषण एक ही कोड पर हर बार एक ही जवाब देता है, जिससे भरोसा बढ़ता है और नतीजों का ऑडिट करना संभव होता है।

दूसरा सवाल: सटीकता

क्या आप उन सभी समस्याओं का पता लगा रहे हैं जो सबसे ज़्यादा मायने रखती हैं?

विश्वसनीयता बताती है कि किसी समस्या पर समय लगाना फ़ायदेमंद है या नहीं, लेकिन यह नहीं बताती कि स्कैनर से कौन-सी समस्याएँ छूट गईं। हम डेटा विज्ञान में इस्तेमाल होने वाले एक माप का उपयोग करते हैं, जिसे F1 स्कोर कहते हैं। F1 दो कारकों के आधार पर प्रदर्शन को 1-0 के पैमाने पर मापता है:

• परिशुद्धता: बताई गई समस्याओं में से असली समस्याओं का अनुपात। उच्च परिशुद्धता का अर्थ है कम ग़लत चेतावनियाँ।
• रिकॉल: असली कमज़ोरियों में से वह अनुपात जिसका स्कैनर वास्तव में पता लगाता है। उच्च रिकॉल का अर्थ है कि बहुत कम समस्याएँ नज़र से छूटती हैं।

कोई स्कैनर लगभग कुछ भी चिह्नित न करके सटीक दिख सकता है, या हर चीज़ चिह्नित करके व्यापक जाँच करने वाला—लेकिन दोनों ही स्थितियों में उसका F1 स्कोर कम हो सकता है। उद्योग का औसत लगभग 0.20 है। हम इस चुनौती पर कड़ी मेहनत कर रहे हैं और हमें मानक स्कैनर की तुलना में तीन से चार गुना अधिक सटीकता वाले नतीजे मिले हैं।

बेहतर सटीकता से डेवलपर के लिए आगे का हर काम आसान हो जाता है। आपकी टीम समस्याओं की पुष्टि करने में कम और उन्हें ठीक करने में ज़्यादा समय लगाती है।

तीसरा सवाल: निवेश पर लाभ

हम निवेश और संसाधनों का अधिकतम लाभ कैसे उठाएँ?

पायलट चरण में इस सवाल को सबसे ज़्यादा अनदेखा किया जाता है, और उत्पादन में इसका जवाब देना सबसे ज़्यादा तकलीफ़देह होता है।

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

किसी कंपनी के हर कमिट, पुल अनुरोध और रिपॉज़िटरी पर इस लागत का हिसाब लगाइए। Uber, जो हर साल अनुसंधान एवं विकास पर 3.4 अरब डॉलर खर्च करता है, ने AI कोडिंग टूल लागू करने के कुछ ही महीनों के भीतर कथित तौर पर 2026 के लिए अपना पूरा AI बजट ख़र्च कर दिया।

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

एप्लिकेशन सुरक्षा को विकसित होना होगा

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

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

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

कोड चल रहा है। क्या आप उसके साथ कदम मिला सकते हैं?

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

इसलिए आँकड़ों में उलझें नहीं। किसी भी कार्यक्रम के बारे में तीन सवाल पूछें: क्या मैं उसके निष्कर्षों पर भरोसा कर सकता हूँ? क्या वह उन चीज़ों में से पर्याप्त का पता लगाता है जो मायने रखती हैं? क्या इसे मेरे पूरे संगठन में लागू करना व्यावहारिक है? नियतात्मक सटीकता को फ्रंटियर तर्क-क्षमता के साथ जोड़ने से, इन तीनों सवालों का जवाब ‘हाँ’ होने की संभावना सबसे अधिक होती है।

सॉफ़्टवेयर की रफ़्तार धीमी नहीं हो रही है। अब हमारा काम जोखिम के अंतर को पाटना है: सॉफ़्टवेयर जितनी तेज़ी से बनता है और जोखिमों का पता लगाकर उन्हें ठीक करने में जितना समय लगता है, उन दोनों के बीच का फ़ासला।