दो इंजन, एक ऑडिट
वही कोड पढ़ने वाला दूसरा AI मॉडल सुरक्षा ऑडिट के नतीजे कैसे बदलता है, और दो रिपोर्टें शोर बढ़ाए बिना एक कैसे बनती हैं।
· 5 मिनट का लेख · Lina Source LLC
दो अनुभवी रिव्यूअर से एक ही पुल रिक्वेस्ट पढ़वाइए, आपको दो अलग सूचियाँ मिलेंगी। एक को दिखेगा कि URL में आया आइडेंटिफ़ायर कभी सेशन से मिलाया ही नहीं जाता; दूसरे को दिखेगा कि रिट्राई लूप हर विफलता पर एक डेटाबेस कनेक्शन खुला छोड़ देता है। कोई ग़लत नहीं है, और कोई पूरा भी नहीं है। भाषा मॉडल भी उसी कारण से ऐसा ही करते हैं: रिव्यूअर क्या नोटिस करता है, यह इस पर निर्भर है कि उसने पहले क्या देखा है।
सहमति एक संकेत है
अकेला मॉडल अपनी कॉन्फ़िडेंस बताता है। उस संख्या का मोल है, पर वह स्व-घोषित है: मॉडल अपनी ही कॉपी जाँच रहा है। जब अलग-अलग लैब में, अलग डेटा पर, अलग कमज़ोरियों के साथ प्रशिक्षित दो मॉडल स्वतंत्र रूप से एक ही फ़ाइल की एक ही कमज़ोरी तक पहुँचते हैं, तो यह सहमति मॉडल के बाहर से आया प्रमाण है। स्वचालित समीक्षा इससे ज़्यादा किसी दूसरी राय के पास नहीं पहुँच सकती।
उल्टा पक्ष भी उतना ही ज़रूरी है। जिस फाइंडिंग को केवल एक इंजन ने बताया, वह इसी वजह से ग़लत नहीं हो जाती; उसे हटाना ठीक उन्हीं बग्स को फेंकना होगा जिन्हें अकेला रिव्यूअर अच्छे से पकड़ता है। इसलिए वह भी रिपोर्ट होती है, उसी इंजन के नाम के साथ — तौल आप करें।
जहाँ एक इंजन चुप हो जाता है
व्यवहार में दोनों इंजन उन्हीं बग-श्रेणियों पर सबसे ज़्यादा अलग होते हैं जहाँ पैटर्न मिलान नहीं, तर्क चाहिए:
- लॉजिक की ख़ामियाँ: दो बार लगा डिस्काउंट, रिफ़ंड के बाद फिर रिफ़ंड स्वीकारती स्टेट मशीन, ग़लत ऑब्जेक्ट पर चलती ओनरशिप जाँच।
- फ़्रेमवर्क-विशिष्ट ऑथराइज़ेशन: मिडलवेयर जो रूट समूह को बचाता है, पर बगल में लगे API हैंडलर को नहीं।
- रिसोर्स और मेमोरी लीक: हर रिक्वेस्ट पर खुलने वाले और केवल सफल रास्ते पर छोड़े जाने वाले लिसनर, टाइमर और कनेक्शन।
- टिप्पणियों या फ़िक्स्चर में छिपा प्रॉम्प्ट इंजेक्शन, जो ढूँढे बिना निर्दोष पाठ जैसा पढ़ा जाता है।
दो रिपोर्टें एक कैसे बनती हैं
मर्ज ही वह जगह है जहाँ दूसरा इंजन या तो अपनी क़ीमत वसूल करता है या आपका शोर दुगुना कर देता है। हमारे तय किए नियम:
- फाइंडिंग्स शब्दों से नहीं, बग की पहचान से मिलाई जाती हैं: उसका CWE वर्ग और वह फ़ाइल जिसमें वह है।
- मेल खाने पर एक ही बार रिपोर्ट होती है, दोनों में से सख़्त गंभीरता के साथ, क्योंकि कार्रवाई सुरक्षित पाठ पर होती है।
- वही विवरण रखा जाता है जिससे डेवलपर काम कर सके: लंबा प्रमाण, ठोस पैच, क्रमबद्ध सुधार-कदम।
- पुष्ट फाइंडिंग की कॉन्फ़िडेंस उच्च कर दी जाती है और उस पर दोनों इंजन अंकित होते हैं।
- जिसे सिर्फ़ एक इंजन ने देखा, वह भी रहती है — खोजने वाले इंजन के नाम के साथ।
दोनों इंजन एक ही स्रोत एक साथ पढ़ते हैं, इसलिए ऑडिट दुगुना समय नहीं लेता; दुगुनी होती है चलाने की लागत, और इसीलिए यह Pro प्लान का हिस्सा है। दूसरा इंजन उपलब्ध न हो या बेकार उत्तर लौटाए, तो ऑडिट विफल नहीं होता — पहले इंजन से पूरा हो जाता है।
इनमें से कुछ भी रिपोर्ट को सच नहीं बनाता। दो इंजन सहमत होकर भी दोनों ग़लत हो सकते हैं; हर फाइंडिंग के नीचे उद्धृत प्रमाण इसीलिए है कि आप भरोसा करने के बजाय जाँच सकें। पुष्टि आपको एक क्रम देती है: जब सौ फाइंडिंग्स आएँ और आपके पास एक दोपहर हो, तो उनसे शुरू कीजिए जिन्हें दो स्वतंत्र रिव्यूअर ने देखा।