Four Ways to Forge a Bundle My Own Verifier Calls Clean: Refusal-Site Mutation Testing of an Evidence-Bundle Verifier

आधुनिक डिजिटल दुनिया में, सॉफ्टवेयर सिस्टम अक्सर एक सरल लेकिन शक्तिशाली विचार पर निर्भर करते हैं: विश्वास करो, लेकिन सत्यापन करो। जब कोई कंप्यूटर प्रोग्राम दावा करता है कि उसने किसी कठिन समस्या को हल कर लिया है या विशाल डेटासेट का विश्लेषण कर लिया है, तो वह एक रिपोर्ट प्रस्तुत करता है। यह सुनिश्चित करने के लिए कि यह रिपोर्ट ईमानदार है, अन्य प्रोग्राम ऑडिटरों (auditors) के रूप में कार्य करते हैं। ये ऑडिटर गणित की जांच करते हैं, यह सत्यापित करते हैं कि डेटा फाइल के साथ छेड़छाड़ नहीं की गई है, और पुष्टि करते हैं कि सारांश में दिए गए अंक कच्चे साक्ष्यों से मेल खाते हैं। यदि सब कुछ सही रहता है, तो ऑडिटर एक 'ग्रीन लाइट' देता है, और परिणाम दुनिया के देखने के लिए प्रकाशित किया जाता है। यह प्रक्रिया विश्वसनीय सॉफ्टवेयर की रीढ़ है, जो अजनबियों को एक-दूसरे के काम को जानने की आवश्यकता के बिना एक-दूसरे पर भरोसा करने की अनुमति देती है। हालाँकि, इस प्रणाली के काम करने के लिए, ऑडिटर का स्वयं पूर्ण होना आवश्यक है। यदि ऑडिटर झूठ पकड़ने में विफल रहता है, या इससे भी बदतर, यदि वह साक्ष्य देखे बिना ही एक झूठ को सच घोषित कर देता है, तो पूरी प्रणाली ढह जाती है। खतरा केवल यह नहीं है कि एक बुरा परिणाम निकल जाए, बल्कि यह है कि ऑडिटर इतना टूटा हुआ हो सकता है कि वह बिना वास्तव में परीक्षण किए ही टेस्ट को पास कर दे।

एरिक हिल नामक एक शोधकर्ता ने ऐसे ही एक ऑडिटर की जांच करने का निर्णय लिया, जो एक ऑफलाइन सिस्टम के लिए साक्ष्यों के बंडलों को सत्यापित करने के लिए डिज़ाइन किया गया था। वह एक विशिष्ट, परेशान करने वाले प्रश्न को जानना चाहता था: यह प्रोग्राम कितनी बार "पास" कहता है जब उसने वास्तव में कुछ भी जांचा ही नहीं होता? यह पता लगाने के लिए, उसने केवल बग्स की तलाश नहीं की; बल्कि उसने अपने स्वयं के ऑडिटर को व्यवस्थित रूप से तोड़ने के लिए एक उपकरण बनाया। उसने प्रोग्राम के कोड की हर एक लाइन ली जो एक खराब बंडल को खारिज करने के लिए बनाई गई थी, और एक-एक करके उन्हें बंद कर दिया। फिर, उसने देखा कि क्या उसका टेस्ट सुइट इसे नोटिस करता है। यदि रिजेक्शन लाइन (rejection line) हटाने के बाद भी टेस्ट पास हो जाते थे, तो इसका मतलब था कि वह रिजेक्शन लाइन बेकार थी—वह वास्तव में कोई काम नहीं कर रही थी। परिणाम चौंकाने वाले थे। अध्ययन की शुरुआत में, ऑडिटर के दो-तिहाई रिजेक्शन पॉइंट्स टेस्ट के लिए अदृश्य थे। प्रोग्राम को "ना" कहने की अधिकांश क्षमता से खाली किया जा सकता था, और फिर भी वह एक आदर्श स्कोर रिपोर्ट करता। यह ऐसा था जैसे किसी सुरक्षा गार्ड को चोरी की वस्तुओं की जांच करने के लिए प्रशिक्षित किया गया हो, लेकिन प्रशिक्षण अभ्यासों में कभी भी चोरी की वस्तु शामिल ही नहीं की गई, इसलिए गार्ड ने कभी भी उसे खोजने के लिए सीखना ही नहीं।

अध्ययन की शुरुआत एक बाहरी विशेषज्ञ के झटके से हुई। एक स्वतंत्र इंजीनियर ने साक्ष्यों का एक ऐसा बंडल प्रस्तुत किया जहाँ मुख्य आंकड़े पूरी तरह से गलत थे, फिर भी ऑडिटर ने एक आदर्श 'पास' प्रिंट किया। उस धोखाधड़ी को उत्पन्न करने में केवल चार बाइट्स का खर्च आया था। इंजीनियर ने एक फाइल को एक छोटे, खाली प्लेसहोल्डर से बदल दिया था, और क्योंकि ऑडिटर यह जांचने में विफल रहा कि वह फाइल वास्तव में वहां है या नहीं, उसने मान लिया कि सब कुछ ठीक है। हिल ने इस विशिष्ट छेद को ठीक किया, लेकिन फिर उन्होंने अपने मरम्मत किए गए प्रोग्राम पर अपना व्यवस्थित उपकरण लागू किया। उन्होंने पाया कि समस्या केवल एक गलती नहीं, बल्कि एक पैटर्न थी। उन्होंने ऑडिटर को मूर्ख बनाने के चार और तरीके खोजे, और हर बार यह पाया कि प्रोग्राम एक चेक को पूरी तरह से छोड़ रहा था। इनमें से एक ट्रिक में गंभीरता लेबल (severity label) में एक सिंगल कैपिटल लेटर को बदलना शामिल था, जिससे प्रोग्राम ने विफल चेक के भार (weight) को अनदेखा कर दिया। एक अन्य में एक लिस्ट से एक की (key) को हटाना शामिल था, जिससे प्रोग्राम तुलना करने से बच गया क्योंकि वह आइटम जिसे उसे तुलना करनी थी, गायब था। हर मामले में, प्रोग्राम किसी कठिन गणना में विफल नहीं हो रहा था; वह बस गणना शुरू करने में ही विफल हो रहा था।

इस मुद्दे के कितने व्यापक होने को मापने के लिए, हिल ने ऑडिटर के कोड के विरुद्ध अपने डिलीशन टूल को चलाया। उन्होंने पाया कि 112 स्थान थे जहाँ प्रोग्राम को "ना" कहना चाहिए था। जब उन्होंने उन्हें एक-एक करके हटाया, तो 75 को बिना किसी टेस्ट फेल हुए हटाया जा सका। इसका अर्थ था कि 112 रिजेक्शन पॉइंट्स में से 75 प्रभावी रूप से सिस्टम के सुरक्षा जांचों के लिए अदृश्य थे। प्रोग्राम का स्कोर 0.330 था, जो यह दर्शाता है कि इसके रिफ्यूज़ल मैकेनिज्म का केवल लगभग एक तिहाई ही वास्तव में टेस्ट किया जा रहा था। शेष दो-तिहाई "वैक्युअस पासेस" (vacuous passes) थे—ऐसे चेक जो सफलता की रिपोर्ट करते थे जबकि उन्होंने कभी साक्ष्यों का परीक्षण ही नहीं किया था। यह कोई दुर्लभ ग्लिच नहीं है; यह एक संरचनात्मक दोष है जहाँ सुरक्षा जाल में ऐसे छेद हैं जिनमें कभी किसी के गिरने की कोशिश ही नहीं की गई। टेस्ट यह जांच रहे थे कि प्रोग्राम चल रहा है, न कि यह कि वह वास्तव में डेटा देख रहा है।

हिल ने ऐसी समस्याओं को ठीक करने के एक सामान्य दृष्टिकोण का परीक्षण किया: केवल उन विशिष्ट बग्स को ठीक करना जो पाए गए थे और प्रत्येक के लिए एक टेस्ट जोड़ना। उन्होंने खोजे गए चार फोर्जरी (forgeries) को ठीक किया और यह सुनिश्चित करने के लिए नए टेस्ट जोड़े कि वे विशेष ट्रिक्स दोबारा काम न करें। आश्चर्यजनक रूप से, इससे समग्र सुरक्षा स्कोर में सुधार नहीं हुआ। प्रोग्राम में अभी भी वही 75 अदृश्य रिजेक्शन पॉइंट्स थे। नए टेस्ट केवल उन्हीं नए छेदों को कवर करते थे जिन्हें उन्होंने अभी पैच किया था, जिससे बाकी सिस्टम पहले की तरह ही अंधा बना रहा। यह तभी हुआ जब उन्होंने अपनी रणनीति बदली। बग्स को ठीक करने के बजाय, उन्होंने प्रत्येक एक में से 75 अदृश्य रिजेक्शन पॉइंट्स के लिए एक नया टेस्ट लिखा, जिससे प्रोग्राम को यह साबित करने के लिए मजबूर किया गया कि वह वास्तव में प्रत्येक को सक्रिय (fire) कर सकता है। इस व्यवस्थित दृष्टिकोण ने स्कोर को 0.330 से बढ़ाकर 1.000 कर दिया, जिससे यह सिद्ध हुआ कि प्रत्येक रिजेक्शन पॉइंट को वास्तव में ट्रिगर किया जा सकता है। सबक स्पष्ट था: ज्ञात बग्स को ठीक करना सिस्टम को सुरक्षित नहीं बनाता; आपको यह सिद्ध करना होगा कि प्रत्येक सुरक्षा तंत्र वास्तव में काम कर सकता है।

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

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

कार्य का अंतिम निष्कर्ष एक अलग प्रकार के परीक्षण के लिए आह्वान है। शोधकर्ता का तर्क है कि हम सिस्टम को सुरक्षित रखने के लिए ज्ञात बग्स की सूची पर भरोसा नहीं कर सकते। यदि किसी सिस्टम में एक सुरक्षा द्वार (safety gate) है जिसे कभी विफल होते नहीं देखा गया, तो उसे कभी काम करते हुए भी नहीं देखा गया है। एकमात्र तरीका यह है कि व्यवस्थित रूप से प्रत्येक द्वार का परीक्षण किया जाए ताकि यह सुनिश्चित हो सके कि वह वास्तव में सक्रिय हो सकता है। अध्ययन ने दिखाया कि एक सिस्टम कागज पर पूर्ण दिखाई दे सकता है जबकि व्यवहार में मौलिक रूप से टूटा हुआ हो सकता है। हर संभव तरीके से खराब डेटा को खारिज करने में सक्षम होने का प्रमाण देकर, शोधकर्ता ने एक ऐसे सिस्टम को बदल दिया जो अपनी विफलताओं के प्रति अंधा था, एक पूरी तरह से सत्यापित सिस्टम में। यह कार्य एक अनुस्मारक है कि डिजिटल विश्वास की दुनिया में, सबसे खतरनाक त्रुटि एक विफल चेक नहीं है, बल्कि एक ऐसा चेक है जो हुआ ही नहीं।