← नवीनतम पेपर
💻 computer science

Does Programming Language Matter? An Empirical Study of Fuzzing Bug Detection

यह अनुभवजन्य अध्ययन 559 OSS-Fuzz प्रोजेक्ट्स में 61,000 से अधिक फज़िंग बग्स का विश्लेषण करता है ताकि यह प्रदर्शित किया जा सके कि प्रोग्रामिंग भाषा फज़िंग प्रभावशीलता, बग विशेषताओं और पहचान दक्षता को महत्वपूर्ण रूप से प्रभावित करती है, जिससे भाषा-जागरूक फज़िंग रणनीतियों की आवश्यकता पर बल मिलता है।

मूल लेखक: Tatsuya Shirai, Olivier Nourry, Yutaro Kashiwa, Kenji Fujiwara, Hajimu Iida

प्रकाशित 2026-02-06
📖 6 मिनट में पढ़ें🧠 गहराई से पढ़ें

मूल लेखक: Tatsuya Shirai, Olivier Nourry, Yutaro Kashiwa, Kenji Fujiwara, Hajimu Iida

मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें

कल्पना कीजिए कि आप एक विशाल कारखाने में एक गुणवत्ता नियंत्रण निरीक्षक (quality control inspector) हैं जो विभिन्न प्रकार के वाहन बनाता है। कुछ कच्चे, लचीले स्टील (C/C++) से बने हैं, कुछ स्व-मरम्मत करने वाली, स्मार्ट सामग्री (Rust) से बने हैं, कुछ सख्त, पूर्व-निर्धारित नियमों (Java) के साथ असेंबल किए गए हैं, और अन्य त्वरित, अनुकूलन योग्य गोंद (Python) से बने हैं।

वर्षों से, निरीक्षकों ने दोषों को खोजने के लिए एक विशिष्ट विधि का उपयोग किया है जिसे "फज़िंग" (Fuzzing) कहा जाता है। फज़िंग ऐसा है जैसे हजारों यादृच्छिक (random), अजीब और अप्रत्याशित वस्तुओं को इन वाहनों पर फेंकना ताकि यह देखा जा सके कि वे दुर्घटनाग्रस्त होते हैं, टूटते हैं या खराब होते हैं। लक्ष्य यह है कि सड़क पर उतरने से पहले ही कमजोरियों को ढूंढ लिया जाए।

यह शोध पत्र एक सरल लेकिन महत्वपूर्ण प्रश्न पूछता है: क्या जिस सामग्री से वाहन बना है, वह इस बात को बदल देता है कि वह कितनी बार टूटता है, किस तरह के ब्रेक लगते हैं, और उन्हें ठीक करना कितना आसान है?

शोधकर्ताओं ने 550 से अधिक वास्तविक दुनिया के प्रोजेक्ट्स (इन "वाहनों") के डेटा का अध्ययन किया, जिनका गूगल के "OSS-Fuzz" सिस्टम द्वारा लगातार परीक्षण किया जा रहा है। यहाँ उन्होंने क्या पाया, इसे सरल शब्दों में समझाया गया है:

1. वे कितनी बार टूटते हैं? (आवृत्ति/Frequency)

एक लक्ष्य (target) पर तीर चलाने की कल्पना करें।

  • C++ और Rust ऐसे लक्ष्य हैं जो थोड़े "चंचल" हैं। वे हर समय नहीं टूटते, लेकिन जब वे टूटते हैं, तो उनकी आवृत्ति बहुत भिन्न होती है। कभी-कभी वे बहुत स्थिर होते हैं; अन्य समय में, वे बहुत अधिक दोष दिखाते हैं।
  • Python एक बहुत ही स्थिर, शांत लक्ष्य की तरह है। यह सबसे कम बार टूटता है, और इसका पैटर्न बहुत सुसंगत है।
  • C, Go और Java बिल्कुल बीच में आते हैं, जो एक स्थिर, औसत दर पर टूटते हैं।

निष्कर्ष: सामग्री मायने रखती है। कुछ भाषाएँ ऐसी हैं जो उन्हें छेड़ने पर दोष दिखाने के प्रति अधिक प्रवृत्त होती हैं, जबकि अन्य अधिक सुसंगत होती हैं।

2. किस तरह के ब्रेक लगते हैं? (बग के प्रकार)

जब वाहन वास्तव में टूटते हैं, तो टूटने का स्वरूप पूरी तरह से सामग्री पर निर्भर करता है।

  • "मेमोरी" की समस्या (C और C++): ये भाषाएँ ऐसी हैं जहाँ ड्राइवर को ईंधन टैंक और तेल का प्रबंधन मैन्युअल रूप से करना पड़ता है। यदि वे भूल जाते हैं, तो इंजन फट जाता है। शोध में पाया गया कि C और C++ मुख्य रूप से संसाधन प्रबंधन (Resource Management) बग्स से ग्रस्त होते हैं—जैसे मेमोरी खत्म होना या बफर ओवरफ्लो। ये "क्लासिक" क्रैश हैं।
  • "लॉजिक" की समस्या (Python, Java, Rust): इन भाषाओं में स्वचालित सुरक्षा सुविधाएँ (जैसे एक स्मार्ट ईंधन प्रणाली) होती हैं। इनमें मेमोरी खत्म होने की संभावना बहुत कम होती है। इसके बजाय, ये कंट्रोल फ्लो (Control Flow) के मुद्दों के कारण टूटते हैं—जैसे ड्राइवर का बाएं मुड़ने की कोशिश करना जब सड़क केवल दाएं जा रही हो।
  • "गंभीरता" का आश्चर्य:
    • Java कच्चे नंबरों के मामले में सबसे अधिक बार टूटता है, लेकिन इनमें से लगभग सभी ब्रेक मध्यम गंभीरता (जैसे टायर का पंचर होना) के होते हैं। ये परेशान करने वाले हैं लेकिन इंजन फटने जैसी विनाशकारी स्थिति पैदा नहीं करते क्योंकि Java की सुरक्षा सुविधाएँ इसे रोक लेती हैं।
    • Python और Rust कम बार टूटते हैं, लेकिन जब वे टूटते हैं, तो ब्रेक गंभीर (critical) होते हैं (जैसे ब्रेक फेल होना)।
    • C और C++ भी गंभीर, उच्च-स्तर के क्रैश की ओर प्रवृत्त होते हैं।

3. क्या हम ब्रेक को दोबारा उत्पन्न कर सकते हैं? (पुनरुत्पादकता/Reproducibility)

यदि एक कार दुर्घटनाग्रस्त होती है, तो क्या आप इसे बिल्कुल उसी तरह दोबारा दुर्घटनाग्रस्त कर सकते हैं ताकि एक मैकेनिक इसे ठीक कर सके?

  • Rust इसमें चैंपियन है। यह एक ऐसी कार की तरह है जो, एक बार दुर्घटनाग्रस्त होने के बाद, आप एक बटन दबाते हैं और यह 99% बार बिल्कुल उसी तरह दुर्घटनाग्रस्त होती है। यह इसे ठीक करना बहुत आसान बनाता है।
  • Go इसके विपरीत है। यह एक ऐसी कार की तरह है जो अचानक दुर्घटनाग्रस्त होती है। कभी-कभी यह दुर्घटनाग्रस्त होती है, कभी नहीं, और आप अनुमान नहीं लगा सकते कि यह कब होगा। यह मैकेनिकों के लिए यह समझना बहुत कठिन बना देता है कि क्या गलत है।
  • C, C++, और Python बीच में कहीं आते हैं, लेकिन Rust त्रुटियों को दोहराने के मामले में स्पष्ट रूप से सबसे विश्वसनीय है।

4. हम ब्रेक को कितनी तेज़ी से पाते हैं? (दक्षता/Efficiency)

यह यहाँ उल्टा (counter-intuitive) लगता है। आप सोच सकते हैं कि यदि कोई भाषा नए कोड का परीक्षण करने में "बेहतर" (उच्च कवरेज) है, तो वह बग्स को तेज़ी से खोज लेगी।

  • "हाई कवरेज" का जाल: Go और Python नए कोड का परीक्षण करने में बहुत अच्छे हैं (वे बहुत अधिक क्षेत्र कवर करते हैं)। हालाँकि, उन्हें वास्तव में बग खोजने में सबसे लंबा समय लगता है (कभी-कभी हफ्तों लग जाते हैं)।
  • "लो कवरेज" वाले तेज़ खिलाड़ी: C, C++, Java और Rust उतने नए कोड को कवर नहीं करते हैं, लेकिन वे बग्स को बहुत तेज़ी से खोज लेते हैं (अक्सर कुछ दिनों के भीतर)।

निष्कर्ष: केवल इसलिए कि आप बहुत सारे नए कोड का परीक्षण कर रहे हैं, इसका मतलब यह नहीं है कि आप बग्स को तेज़ी से खोज लेंगे। भाषा स्वयं खोज की गति को निर्धारित करती है।

सारांश: यह क्यों मायने रखता है?

शोध पत्र निष्कर्ष निकालता है कि "एक ही नियम सबके लिए लागू नहीं होता।"

यदि आप एक सुरक्षा निरीक्षक (या डेवलपर) हैं:

  • उम्मीद न करें कि C/C++ का व्यवहार Python जैसा होगा। वे अलग-अलग तरीकों से, अलग-अलग गति से और अलग-अलग गंभीरता के साथ टूटते हैं।
  • यदि आप Java का उपयोग करते हैं, तो कई बग्स की अपेक्षा करें, लेकिन वे ज्यादातर "परेशान करने वाले" प्रकार के होंगे, "विनाशकारी" प्रकार के नहीं।
  • यदि आप Rust का उपयोग करते हैं, तो आपको बहुत विश्वसनीय, पुनरुत्पादित बग मिलते हैं जिन्हें ठीक करना आसान है, लेकिन वे दुर्लभ होते हैं।
  • यदि आप Go का उपयोग करते हैं, तो ऐसे बगों के लिए तैयार रहें जिन्हें दोबारा उत्पन्न करना कठिन है।

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

अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?

आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।

Digest आज़माएँ →