प्रौद्योगिकी

CodeQL के नए नियम पुराने अलर्ट बदलेंगे—सिर्फ संख्या देखकर न घबराएँ

|लेखक: QUASA संपादकीय टीम|6 मिनट पढ़ने का समय| 1
CodeQL के नए नियम पुराने अलर्ट बदलेंगे—सिर्फ संख्या देखकर न घबराएँ

GitHub ने 3 सितंबर 2026 को बताया कि जारी CodeQL 2.26.4 ने GitHub Actions की पहचान और कई भाषाओं के विश्लेषण को बदला है। GitHub की घोषणा के मुताबिक, पुनः उपयोग योग्य कार्यप्रवाहों के बदल सकने वाले संदर्भ अब पकड़े जा सकते हैं और Rust डेटा-प्रवाह अलर्ट अधिक सटीक स्रोत तथा सिंक स्थान दिखा सकते हैं।

इसका अर्थ है कि उन्नयन के बाद पुराने अलर्टों की संख्या और स्थिति बदल सकती है, भले संबंधित कोड हाल में न बदला हो। GitHub Actions में पहले छूटा विन्यास नया अलर्ट बन सकता है; Rust में वही अंतर्निहित समस्या दूसरी जगह नया अलर्ट दिखाकर पुराने स्थान वाला अलर्ट बंद कर सकती है। इसलिए केवल खुले और बंद अलर्टों का कुल जोड़ नए जोखिम या सुधार का पर्याप्त प्रमाण नहीं है।

पुनः उपयोग योग्य कार्यप्रवाहों में अब क्या पकड़ा जाएगा

पुनः उपयोग योग्य GitHub Actions कार्यप्रवाह में बदल सकने वाला टैग-संदर्भ सुरक्षा निष्कर्ष के रूप में पहचाना गया

CodeQL की actions/unpinned-tag क्वेरी अब पुनः उपयोग योग्य कार्यप्रवाहों के बदल सकने वाले संदर्भ भी पहचानती है। किसी बाहरी कार्यप्रवाह को पूर्ण कमिट पहचान के बजाय टैग या शाखा से बुलाने पर उस संदर्भ का लक्ष्य बाद में बदला जा सकता है; बुलाने वाली फ़ाइल जस की तस रहने के बावजूद अगली बार अलग कोड चल सकता है।

इसलिए उन्नयन के बाद मिला ऐसा अलर्ट जरूरी नहीं कि हाल की कमिट से पैदा हुई कमजोरी हो। जोखिमपूर्ण संदर्भ पहले से मौजूद हो सकता है और CodeQL 2.26.4 की विस्तारित पहचान ने उसे पहली बार सामने लाया हो। इस स्थिति को नई खोज माना जाएगा, लेकिन जोखिम की उम्र जानने के लिए संबंधित कार्यप्रवाह और उसकी कमिट-इतिहास को अलग से मिलाना होगा।

GitHub Actions में एक दूसरा बदलाव घटना-पेलोड से पढ़े गए अभिनेता-संबंधी क्षेत्रों पर लागू होता है। अब कोई शर्त तभी सुरक्षा अवरोध मानी जाती है जब संबंधित घटना का पेलोड वह क्षेत्र वास्तव में भरता हो। ऐसी शर्त जो उपलब्ध ही न होने वाले क्षेत्र पर निर्भर थी, अब पर्याप्त सुरक्षा नहीं मानी जा सकती; इससे ControlCheck वर्ग का उपयोग करने वाली क्वेरियों में अतिरिक्त अलर्ट आ सकते हैं।

Rust में पुराना अलर्ट बंद और नया क्यों दिख सकता है

Rust डेटा-प्रवाह अलर्ट का स्रोत और सिंक अधिक सटीक कोड स्थानों पर दिखाया गया

Rust के लिए बदलाव किसी नई कमजोरी-श्रेणी की घोषणा नहीं है। डेटा-प्रवाह क्वेरियों में अलर्ट का स्थान अब उस वास्तविक स्रोत या सिंक नोड पर आधारित है जहाँ डेटा प्रवाह में प्रवेश करता है या संवेदनशील उपयोग तक पहुँचता है। इससे पहले किसी व्यापक कॉल पर लगा संकेत अब उसके भीतर की अधिक सटीक अभिव्यक्ति पर दिखाई दे सकता है।

CodeQL 2.26.4 के आधिकारिक परिवर्तन-विवरण में साफ कहा गया है कि कुछ Rust अलर्टों का स्थान बदलेगा, वे नए अलर्ट की तरह दिखाई देंगे और पुराने स्थान वाले अलर्ट गायब होंगे। इसीलिए एक बंद और एक नए अलर्ट को स्वतः दो अलग सुरक्षा घटनाएँ मानना गलत हो सकता है।

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

नए, स्थानांतरित और हटे निष्कर्ष अलग कैसे होंगे

दो CodeQL स्कैन आधाररेखाओं के निष्कर्ष नई खोज, बदले स्थान, हटे गलत-सकारात्मक और सुधार में अलग किए गए

पुराने तथा नए स्कैन की तुलना में पहले क्वेरी और संबंधित कोड को मिलाना चाहिए, फिर स्थान और डेटा-प्रवाह देखना चाहिए। इस क्रम से संस्करण के कारण बदली प्रस्तुति को वास्तव में नए जोखिम से अलग रखा जा सकता है।

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

यह तुलना तभी विश्वसनीय है जब दोनों स्कैन समान कोड-स्नैपशॉट, क्वेरी समूह और तुलनीय निर्माण-विन्यास पर चले हों। यदि अनुप्रयोग और CodeQL दोनों एक साथ बदले हैं, तो केवल अलर्ट की संख्या से यह तय नहीं होगा कि अंतर किस बदलाव ने पैदा किया।

अन्य भाषा बदलाव भी आधाररेखा पर असर डाल सकते हैं

CodeQL 2.26.4 में Go 1.27 समर्थन जोड़ा गया है। Java/Kotlin के लिए Spring R2DBC के DatabaseClient और R2DBC SPI को SQL इंजेक्शन सिंक के रूप में मॉडल किया गया है, जबकि Python में list.extend और list.insert से दूषित डेटा के प्रवाह का समर्थन जुड़ा है। ये परिवर्तन पहले छूटे डेटा-पथ सामने ला सकते हैं।

C# की कुछ क्वेरियों में ऐसे सुधार भी हुए हैं जिनका उद्देश्य गलत-सकारात्मक परिणाम घटाना है। सितंबर का स्वतंत्र रिलीज़ संकलन भी Go 1.27 समर्थन, Rust के बदले अलर्ट स्थान, Spring R2DBC सिंक और अधिक कठोर GitHub Actions जाँच को CodeQL 2.26.4 के प्रमुख प्रभावों में गिनता है।

इसलिए अलग भाषाओं में संख्या बदलने का अर्थ भी एक जैसा नहीं होगा। नया सिंक या डेटा-प्रवाह मॉडल अतिरिक्त वास्तविक निष्कर्ष ला सकता है, जबकि अधिक सटीक क्वेरी पुराने गलत-सकारात्मक नतीजे हटा सकती है। रिपॉजिटरी-स्तर का कुल आँकड़ा इन विपरीत कारणों को एक ही संख्या में मिला देता है।

उपलब्धता अलग होने से नतीजे एक साथ नहीं बदलेंगे

GitHub.com की कोड-स्कैनिंग सेवा में CodeQL के नए संस्करण स्वतः लागू होते हैं। GitHub Enterprise Server में CodeQL 2.26.4 की कार्यक्षमता किसी भावी रिलीज़ में शामिल होगी; पुराने सर्वर संस्करण वाले संगठन CodeQL को अलग से उन्नत कर सकते हैं। इसलिए समान कोड वाली दो व्यवस्थाओं में भी नया व्यवहार अलग समय पर दिखाई दे सकता है।

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

यह भी पढ़ें:

साझा करें:

हमारे न्यूज़लेटर की सदस्यता लें

Web3, AI और क्रिप्टो की नवीनतम खबरें सीधे अपने इनबॉक्स में पाएँ।

0