कमज़ोरी रिपोर्ट अब विशेष नहीं रही

 (words.filippo.io)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • ओपन सोर्स मेंटेनेंस में सामान्य issues और PRs को वैकल्पिक रूप से संभाला जा सकता है, लेकिन अतीत में कमज़ोरी रिपोर्ट एक ऐसा अपवाद थीं जिनके लिए उपयोगकर्ताओं की सुरक्षा के कारण अलग प्रतिक्रिया ज़रूरी मानी जाती थी
  • यह अपवादात्मक स्थिति शोधकर्ता को हमलावरों से पहले fix करने का मौका देने वाली दुर्लभ अंतर्दृष्टि और गोपनीयता पर आधारित थी, और बदले में प्रोजेक्ट से तेज़ प्रतिक्रिया, जांच, प्रगति साझा करना और credit देने की अपेक्षा की जाती थी
  • 2026 में maintainers और attackers, दोनों LLM चला सकते हैं, इसलिए bottleneck संभावित issues खोजने से हटकर वास्तविक कमज़ोरियों की छंटाई पर आ गया है
  • जिन बाहरी शोधकर्ताओं के साथ भरोसे का संबंध नहीं है, वे इस छंटाई में बहुत अधिक योगदान नहीं कर पाते, और LLM output की समीक्षा तथा security@ inbox की समीक्षा का signal-to-noise ratio लगभग समान हो गया है
  • maintainers का समय रिपोर्टों पर प्रतिक्रिया देने से अधिक वर्गीकरण, तेज़ fixes, और prevention पर लगना चाहिए, और CI में LLM analysis चलाने के तरीकों की भी ज़रूरत है

कमज़ोरी रिपोर्ट पहले अपवाद क्यों थीं

  • सार्वजनिक रूप से काम करने वाले ओपन सोर्स maintainers issues, PRs, और feedback को उपहार की तरह लेते हैं, और ज़रूरत के अनुसार उन्हें स्वीकार, अनदेखा, या आंशिक रूप से उपयोग कर सकते हैं
  • अतीत की कमज़ोरी रिपोर्ट इस सिद्धांत से अलग एक विशेष मामला थीं
    • security researchers तत्काल सार्वजनिक खुलासा करने के बजाय निजी रिपोर्टिंग चुनते थे ताकि प्रोजेक्ट को पहले fix करने का समय मिल सके
    • आम अपेक्षा यह थी कि प्रोजेक्ट रिपोर्ट की जल्दी पुष्टि करे, जांच करे, रिपोर्ट करने वाले के साथ प्रगति साझा करे, और अंत में खोज का credit दे
  • यह अपेक्षा इस धारणा से निकली थी कि रिपोर्ट करने वाला bug fix या feature implementation की मांग नहीं कर रहा, बल्कि प्रोजेक्ट को एक सेवा दे रहा है
    • मुख्य मूल्य अंतर्दृष्टि और गोपनीयता था, जिससे हमलावर exploit जारी करने से पहले patch वितरित किया जा सके
    • कमज़ोरी रिपोर्ट को अनदेखा करना इस संकेत की तरह देखा जाता था कि प्रोजेक्ट उपयोगकर्ता सुरक्षा की परवाह नहीं करता

2026 में टूट चुकी धारणाएँ

  • 2026 में वे धारणाएँ, जो कमज़ोरी रिपोर्ट को विशेष बनाती थीं, अब टिकना मुश्किल हो गया है
    • LLM लगभग किसी भी security researcher जितना अच्छा काम करता है, और इसे कोई भी चला सकता है
    • यही tools maintainers भी चला सकते हैं और attackers भी
  • कमी संभावित issues खोजने की क्षमता में नहीं, बल्कि उनमें से कौन-सी चीज़ सचमुच कमज़ोरी है, इसकी वर्गीकरण प्रक्रिया में है
  • जिन बाहरी शोधकर्ताओं के साथ पहले से भरोसे का संबंध नहीं है, उनके लिए इस वर्गीकरण प्रक्रिया में सार्थक योगदान देना कठिन है
    • LLM output की समीक्षा करना और security@ inbox खंगालना, दोनों का signal-to-noise ratio लगभग एक जैसा है
  • गोपनीयता, embargo, और coordination का महत्व भी पहले की तुलना में घट गया है
    • हमलावरों को पूर्ण public disclosure का इंतज़ार नहीं करना पड़ता; वे अपने LLM से ही कमज़ोरियों के बारे में पूछ सकते हैं
    • हालांकि, हमलावरों को भी रक्षकों की तरह उसी वर्गीकरण bottleneck का सामना करना पड़ सकता है

maintainers की प्राथमिकताओं में बदलाव

  • कमज़ोरी रिपोर्टों के विशेष होने का दौर शायद समाप्त हो चुका है
  • अब अधिक महत्वपूर्ण काम वर्गीकरण, तेज़ fixes, और prevention है
  • CI में LLM analysis चलाने के तरीके खोजने चाहिए
  • यह दृष्टिकोण Go Security टीम की आधिकारिक राय नहीं, बल्कि Go Security टीम के पूर्व लीड की व्यक्तिगत राय है
  • जब कमज़ोरी रिपोर्ट हैंडलिंग और Code of Conduct enforcement में टकराव हो, तो कोई आसान सही उत्तर नहीं होता
    • निर्णय व्यवहार की गंभीरता, यह निजी मामला है या समुदाय को प्रभावित करता है, और security@ संभालने वाली टीम के संसाधनों पर निर्भर होना चाहिए
  • public disclosure practices का इतिहास जटिल रहा है
    • अतीत में सद्भावनापूर्ण शोधकर्ताओं को कानूनी धमकियों या अभियोजन का सामना करना पड़ा है
    • 2026 के ओपन सोर्स परिदृश्य में ऐसे शोधकर्ता नहीं हैं जो कमज़ोरी रिपोर्ट के कारण अभियोजन से डरते हों, और प्रोजेक्ट्स को documented reporting policy के विकल्प के रूप में अभियोजन का संकेत भी नहीं देना चाहिए
  • curl द्वारा एक महीने के लिए vulnerability reporting channel बंद करना शुरुआत में अतिशयोक्ति लगा, लेकिन उपयोगकर्ताओं की सुरक्षा के लिए क्या कमज़ोरी रिपोर्टों पर प्रतिक्रिया देना समय का सबसे अच्छा उपयोग है, यह अब उतना स्पष्ट नहीं रहा

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 4 시간 전
Lobste.rs की राय

  • जल्दबाज़ी में vulnerability disclosure अब भी defenders की तुलना में attackers के लिए कहीं ज़्यादा मददगार लगती है। मैंने खुद अनुभव किया है कि frontier models इस्तेमाल करने पर भी false positive rate कभी-कभी 90% के करीब होती है
    जोड़कर कहूँ तो, “open source cryptographic protocols की sustainable maintenance और development, blockchain technology को व्यापक रूप से अपनाने के लिए महत्वपूर्ण है” यह पंक्ति दिखी, और यह देखकर हैरानी हुई कि अब भी कोई blockchain technology पर विश्वास करता है

    • मैं भी उलझ गया था कि वह पंक्ति वहाँ क्यों थी, फिर पता चला कि वह Fillippo के sponsors में से एक का भेजा हुआ संदेश था
      इस समय blockchain technology ने दुनिया को जो सबसे मूल्यवान चीज़ दी हो सकती है, वह शायद सचमुच सुरक्षित cryptographic protocol implementations बनाने के लिए मज़बूत आर्थिक प्रोत्साहन है। उनमें से कुछ आगे चलकर बाकी सबके लिए भी उपयोगी हो सकती हैं
    • यहाँ false positive से क्या मतलब है, यह जानने की जिज्ञासा है। क्या इसका मतलब यह है कि model ने vulnerability मिलने का दावा किया, लेकिन जाँचने पर वह वास्तव में समस्या नहीं निकली?
      मुझे लगा था कि अब तक vulnerabilities ढूँढना और सामान्य रूप से code को समझना, ये दोनों काम LLM अच्छी तरह कर लेते हैं—क्या सच में ऐसा है, यह जानना चाहता हूँ। अगर आप अपने अनुभव के बारे में थोड़ा और बता सकें या पढ़ने लायक कोई reference दे सकें तो अच्छा होगा। मैं LLM इस्तेमाल नहीं करता, इसलिए आजकल उनकी क्षमता का अंदाज़ा लगाना मुश्किल है, और मैं सच में जानना चाहता हूँ कि क्या मुझे अपनी धारणाएँ बदलनी चाहिए

  • विशेष vulnerability reports के साथ विशेष व्यवहार होना चाहिए, और defenders की तरफ़ से बेहतर validation methods तथा public threat model तैयार होने चाहिए। तभी लोग किसी report को शानदार माने जाने के लिए ज़रूरी ऊँचे मानकों को पूरा और verify कर पाएँगे

    • अंत में बात शायद वहीं जाकर टिके। सामान्य रूप से vulnerability reports कोई विशेष चीज़ नहीं हैं, लेकिन उच्च severity या उच्च confidence वाली कुछ reports को विशेष vulnerability reports माना जाना चाहिए

  • मैं इस बात से सहमत हूँ कि security issues ढूँढना आसान हो गया है और entry barrier कम हो गया है, इसलिए security mailing lists में पहले से ज़्यादा noise आ गया होगा। फिर भी Trail of Bits या Zellic जैसी प्रतिष्ठित security consulting companies की bug reports को मैं अब भी निश्चित रूप से priority दूँगा
    सिर्फ इसलिए नहीं कि मुझे भरोसा है कि वे लापरवाह reports नहीं भेजेंगी, बल्कि इसलिए भी कि CI में LLM को बस यूँ ही चलाने की तुलना में शीर्ष security researchers और LLM का combination बेहतर है

    • मैंने हाल ही में ऐसे vendors के साथ काम किया है, और लापरवाह reports अब भी आती हैं। बस reports की quality अपेक्षाकृत बेहतर होती है
      LLM, चाहे कोई भी उसे चला रहा हो, threat model को गलत समझ सकता है और “exploit” साबित करने के तरीक़े में आलसी हो सकता है। जब security researcher ऐसी गलतियाँ पकड़ नहीं पाता, तो आखिरकार वे हमारे जैसे maintainers तक पहुँचती हैं। containerd को ऐसे vendors, LLM research companies, पहले से चर्चित foundation model companies, और इंटरनेट के J Random User से भी लापरवाह reports मिली हैं
      Filippo ने यहाँ जिस एक और कठिनाई पर पर्याप्त बात नहीं की, वह है duplicate reports। containerd की हाल की advisories देखें तो साफ़ दिखता है कि triage और ध्यान बाँटने में duplication एक और बड़ी समस्या है। उदाहरण के लिए, 9 separate researchers/groups को credit दिया गया, जिनमें ऊपर बताई गई प्रतिष्ठित groups भी शामिल थीं। यह दिखाता है कि (a) LLM, चाहे कोई भी इस्तेमाल करे, अक्सर वही issues ढूँढ निकालते हैं, और (b) सिर्फ़ किसी जाने-पहचाने reporter की report होना ही उसे विशेष नहीं बना देता। दूसरी ओर, this one में वास्तव में कोई duplicate report नहीं थी, इसलिए credit सिर्फ़ एक व्यक्ति को दिया गया, और वह reporter ऐसा व्यक्ति नहीं था जिसे हम पहले से जानते हों या जिससे हमारा कोई संबंध रहा हो