ओपन सोर्स वल्नरेबिलिटी स्कैन में LLM API को जोड़कर सुरक्षा समीक्षा समय कैसे कम करें

ओपन सोर्स सुविधाजनक है, लेकिन यह उतना ही खतरनाक भी है। 2025 के एक सर्वेक्षण के अनुसार, जब से AI ने कोड लिखना शुरू किया है, बग दर पिछले वर्ष की तुलना में 41% बढ़ गई है। एक सुरक्षा अधिकारी के लिए, जिसे अकेले हजारों बाहरी लाइब्रेरीज़ की समीक्षा करनी पड़ती है, यह किसी आपदा से कम नहीं है। चूंकि सारा कोड पढ़ना असंभव है, इसलिए हमें AI को अपना साथी बनाना चाहिए। यहाँ बताया गया है कि कैसे आप Project Glasswing की तरह स्मार्ट तरीके से काम करने वाला सुरक्षा वर्कफ़्लो (Security Workflow) खुद बना सकते हैं।

गिटहब एक्शन (GitHub Actions) में AI सुरक्षा इंजन स्थापित करना

सुरक्षा समीक्षा को स्वचालित करके, आप उन दोहराव वाले कार्यों को हटा सकते हैं जिनमें हर हफ्ते 10 घंटे से अधिक का समय लगता है। यह उन गलतियों को भी रोकता है जो मानवीय आंखों से छूट सकती हैं। गिटहब एक्शन वातावरण में LLM API को कॉल करके एक ऐसी पाइपलाइन बनाएं जो पुल रिक्वेस्ट (Pull Request) आने पर वास्तविक समय में स्कैन करे। कुंजी केवल प्रश्न पूछना नहीं है, बल्कि पहचान और ऑडिट को अलग करने की रणनीति अपनाना है।

• API की (Key) सुरक्षा: गिटहब सीक्रेट्स में LLM_API_KEY दर्ज करें। इसे Libsodium एन्क्रिप्टेड स्टोरेज में रखा जाना चाहिए ताकि की (Key) बाहर लीक होने जैसी दुर्घटनाओं से बचा जा सके।
• टारगेट डायरेक्टरी सेटिंग: सभी फाइलों को देखने की जरूरत नहीं है। YAML कॉन्फ़िगरेशन में path-filter का उपयोग करके केवल उन संवेदनशील डायरेक्टरीज़ को स्कैन करें जो दुर्घटना होने पर विनाशकारी हो सकती हैं, जैसे कि src/auth या lib/core।
• क्रॉस-सत्यापन (Cross-validation): पहले चरण में LLM को कोड संरचना का विश्लेषण करने और नोट्स लिखने दें, फिर दूसरे चरण में उन नोट्स के आधार पर 3 या अधिक बार बार-बार स्कैन चलाएं। AI भी कभी-कभी गलत जानकारी दे सकता है, इसलिए परिणामों की कई बार जांच करना और उनका मिलान करना आवश्यक है।

एक बार यह सेटअप पूरा हो जाने के बाद, सुरक्षा अधिकारी को हजारों लाइनों के कोड के बजाय केवल AI द्वारा सारांशित सुरक्षा रिपोर्ट की समीक्षा करनी होगी।

CVSS और EPSS के साथ असली खतरों की पहचान करना

AI उपकरण कमजोरियों को खोजने में अच्छे हैं, लेकिन वे कई फाल्स पॉजिटिव (False Positives) भी उत्पन्न करते हैं। यदि 100 कमजोरियां पाई जाती हैं और उनमें से 15 फर्जी हैं, तो विकास टीम (Development Team) का निराश होना स्वाभाविक है। सीमित विकास संसाधनों को बर्बाद होने से बचाने के लिए, वास्तविक खतरों की पहचान करने के लिए एक मानक की आवश्यकता होती है। प्राथमिकता निर्धारित करने के लिए CVSS 4.0 स्कोर और EPSS मेट्रिक्स का उपयोग करें, जो आपको बताते हैं कि क्या वर्तमान में वास्तव में हमले हो रहे हैं।

1. बेस स्कोर की जाँच करें: सबसे पहले CVSS 4.0 बेस स्कोर के साथ तकनीकी गंभीरता को देखें।
2. पर्यावरण स्कोर समायोजन: कोड बाहरी इंटरनेट के संपर्क में है या केवल आंतरिक नेटवर्क पर चल रहा है, इसके आधार पर स्कोर घटाएं या बढ़ाएं।
3. हमले की संभावना का मिलान: EPSS डेटाबेस की जाँच करें और देखें कि क्या वह विशेष कमजोरी वर्तमान में हमलावरों के बीच लोकप्रिय है। यदि हमले की संभावना 50% से अधिक है, तो बाकी सब छोड़कर उसे तुरंत पैच किया जाना चाहिए।

केवल 9.0 या उससे अधिक की तत्काल (Urgent) रेटिंग पर ध्यान केंद्रित करने से भी सुरक्षा स्तर में काफी वृद्धि होती है। अनावश्यक सुधार अनुरोधों को कम करने से विकास टीम के साथ घर्षण भी स्वाभाविक रूप से कम हो जाता है।

सैंडबॉक्स में पैच कोड सत्यापित और तैनात करना

AI द्वारा सुझाए गए सुधार देखने में सही लग सकते हैं, लेकिन वे कभी-कभी चालू फंक्शन्स को खराब कर देते हैं। Shopify जैसी कंपनियां भी AI का उपयोग करती हैं, लेकिन वे उत्पन्न कोड पर आंख मूंदकर भरोसा नहीं करती हैं। Firecracker या gVisor जैसे पृथक वातावरण (Isolated Environment) में पैच कोड सुरक्षित है या नहीं, इसकी स्वचालित जांच के लिए एक प्रक्रिया होनी चाहिए।

• आइसोलेशन वातावरण बनाना: sbx CLI का उपयोग करके एक माइक्रो-VM (MicroVM) लॉन्च करें जिसका रनटाइम वातावरण वर्तमान सेवा के समान हो।
• हमले का सिमुलेशन: एक अटैक स्क्रिप्ट के साथ पुष्टि करें कि क्या कमजोरी वास्तव में भेद्य है, फिर AI द्वारा दिए गए पैच को लागू करें और फिर से हमला करके देखें कि क्या वह रुक गया है।
• फंक्शनल टेस्टिंग: पैच लागू होने के साथ मौजूदा यूनिट टेस्ट चलाएं। यदि सुरक्षा तो ठीक हो गई लेकिन लॉगिन काम नहीं कर रहा है, तो इसका कोई मतलब नहीं है।

ये सुरक्षा उपाय AI द्वारा बनाए गए "लगभग सही लेकिन सूक्ष्म रूप से त्रुटिपूर्ण" कोड को प्रोडक्शन सर्वर पर जाने से रोकते हैं।

रिपोर्ट लिखना जिसे ओपन सोर्स मेंटेनर्स तुरंत स्वीकार करें

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

शीर्षक में कमजोरी के प्रकार और स्थान को स्पष्ट रूप से लिखें। पुनः पेश करने के चरण (Reproduction steps) और स्क्रीनशॉट संलग्न करना बुनियादी जरूरत है। सबसे अच्छा यह है कि आप वह सुधार कोड भी भेजें जिसे आपने पहले सैंडबॉक्स में सत्यापित किया था। समीक्षा समय कम करने से पैच के स्वीकार होने की संभावना काफी बढ़ जाती है। एक अच्छी रिपोर्ट कंपनी की तकनीकी शक्ति को साबित करती है और आधिकारिक CVE नंबर प्राप्त करने का मार्ग प्रशस्त करती है।