ओपन सोर्स वल्नरेबिलिटी स्कैन में LLM API को जोड़कर सुरक्षा समीक्षा समय कैसे कम करें
TuBrief 편집팀
2026년 4월 7일
0
Computing/Software원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
커뮤니티의 다른 글
댓글 (0)
Log in to leave a comment
아직 작성된 글이 없습니다
원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
ओपन सोर्स सुविधाजनक है, लेकिन यह उतना ही खतरनाक भी है। 2025 के एक सर्वेक्षण के अनुसार, जब से AI ने कोड लिखना शुरू किया है, बग दर पिछले वर्ष की तुलना में 41% बढ़ गई है। एक सुरक्षा अधिकारी के लिए, जिसे अकेले हजारों बाहरी लाइब्रेरीज़ की समीक्षा करनी पड़ती है, यह किसी आपदा से कम नहीं है। चूंकि सारा कोड पढ़ना असंभव है, इसलिए हमें AI को अपना साथी बनाना चाहिए। यहाँ बताया गया है कि कैसे आप Project Glasswing की तरह स्मार्ट तरीके से काम करने वाला सुरक्षा वर्कफ़्लो (Security Workflow) खुद बना सकते हैं।
सुरक्षा समीक्षा को स्वचालित करके, आप उन दोहराव वाले कार्यों को हटा सकते हैं जिनमें हर हफ्ते 10 घंटे से अधिक का समय लगता है। यह उन गलतियों को भी रोकता है जो मानवीय आंखों से छूट सकती हैं। गिटहब एक्शन वातावरण में LLM API को कॉल करके एक ऐसी पाइपलाइन बनाएं जो पुल रिक्वेस्ट (Pull Request) आने पर वास्तविक समय में स्कैन करे। कुंजी केवल प्रश्न पूछना नहीं है, बल्कि पहचान और ऑडिट को अलग करने की रणनीति अपनाना है।
LLM_API_KEY दर्ज करें। इसे Libsodium एन्क्रिप्टेड स्टोरेज में रखा जाना चाहिए ताकि की (Key) बाहर लीक होने जैसी दुर्घटनाओं से बचा जा सके।path-filter का उपयोग करके केवल उन संवेदनशील डायरेक्टरीज़ को स्कैन करें जो दुर्घटना होने पर विनाशकारी हो सकती हैं, जैसे कि src/auth या lib/core।एक बार यह सेटअप पूरा हो जाने के बाद, सुरक्षा अधिकारी को हजारों लाइनों के कोड के बजाय केवल AI द्वारा सारांशित सुरक्षा रिपोर्ट की समीक्षा करनी होगी।
AI उपकरण कमजोरियों को खोजने में अच्छे हैं, लेकिन वे कई फाल्स पॉजिटिव (False Positives) भी उत्पन्न करते हैं। यदि 100 कमजोरियां पाई जाती हैं और उनमें से 15 फर्जी हैं, तो विकास टीम (Development Team) का निराश होना स्वाभाविक है। सीमित विकास संसाधनों को बर्बाद होने से बचाने के लिए, वास्तविक खतरों की पहचान करने के लिए एक मानक की आवश्यकता होती है। प्राथमिकता निर्धारित करने के लिए CVSS 4.0 स्कोर और EPSS मेट्रिक्स का उपयोग करें, जो आपको बताते हैं कि क्या वर्तमान में वास्तव में हमले हो रहे हैं।
केवल 9.0 या उससे अधिक की तत्काल (Urgent) रेटिंग पर ध्यान केंद्रित करने से भी सुरक्षा स्तर में काफी वृद्धि होती है। अनावश्यक सुधार अनुरोधों को कम करने से विकास टीम के साथ घर्षण भी स्वाभाविक रूप से कम हो जाता है।
AI द्वारा सुझाए गए सुधार देखने में सही लग सकते हैं, लेकिन वे कभी-कभी चालू फंक्शन्स को खराब कर देते हैं। Shopify जैसी कंपनियां भी AI का उपयोग करती हैं, लेकिन वे उत्पन्न कोड पर आंख मूंदकर भरोसा नहीं करती हैं। Firecracker या gVisor जैसे पृथक वातावरण (Isolated Environment) में पैच कोड सुरक्षित है या नहीं, इसकी स्वचालित जांच के लिए एक प्रक्रिया होनी चाहिए।
sbx CLI का उपयोग करके एक माइक्रो-VM (MicroVM) लॉन्च करें जिसका रनटाइम वातावरण वर्तमान सेवा के समान हो।ये सुरक्षा उपाय AI द्वारा बनाए गए "लगभग सही लेकिन सूक्ष्म रूप से त्रुटिपूर्ण" कोड को प्रोडक्शन सर्वर पर जाने से रोकते हैं।
केवल अपनी सेवा को ठीक करना ही काफी नहीं है। उपयोग किए जा रहे ओपन सोर्स की कमियों की रिपोर्ट मूल प्रोजेक्ट को देना भी सुरक्षा अधिकारी की जिम्मेदारी है। मेंटेनर्स व्यस्त लोग होते हैं, इसलिए उन्हें स्पष्ट साक्ष्य देने की आवश्यकता होती है। जिम्मेदारी के साथ रिपोर्ट देने के लिए गिटहब के PVR चैनल का उपयोग करें।
शीर्षक में कमजोरी के प्रकार और स्थान को स्पष्ट रूप से लिखें। पुनः पेश करने के चरण (Reproduction steps) और स्क्रीनशॉट संलग्न करना बुनियादी जरूरत है। सबसे अच्छा यह है कि आप वह सुधार कोड भी भेजें जिसे आपने पहले सैंडबॉक्स में सत्यापित किया था। समीक्षा समय कम करने से पैच के स्वीकार होने की संभावना काफी बढ़ जाती है। एक अच्छी रिपोर्ट कंपनी की तकनीकी शक्ति को साबित करती है और आधिकारिक CVE नंबर प्राप्त करने का मार्ग प्रशस्त करती है।