Greg Kroah-Hartman – LLM युग में सुरक्षा [वीडियो]

दावे कि Anthropic का Mythos AI दर्जनों गंभीर Linux kernel vulnerabilities लेकर आया, अब इस रोशनी में फिर से देखे जा रहे हैं कि उनमें से सिर्फ कुछ ही वास्तविक थे, और वे भी ज़्यादातर छोटे बग थे जिन्हें ठीक करने में डेवलपर का लगभग एक घंटा लगा। टिप्पणीकार कहते हैं कि यह बड़े language models की क्षमताओं को, खासकर security में, ज़रूरत से ज़्यादा बढ़ा-चढ़ाकर पेश करने की व्यापक प्रवृत्ति दिखाता है, जहाँ false positives बहुत अधिक हैं और media तथा management अक्सर marketing को सच मान लेते हैं। चर्चा training data से जुड़े कानूनी जोखिम, open source maintainers पर LLM-generated noise के असर, और इन tools को autonomous experts के बजाय कड़ी निगरानी वाले assistants की तरह रखने के महत्व पर भी जाती है।

कर्नेल बग्स पर Mythos के नतीजे

  • चर्चा में 79 रिपोर्ट किए गए “vulnerabilities” की समीक्षा पर जोर दिया गया: कई में कोई उपयोगी विवरण नहीं था, कुछ बिल्कुल बग नहीं थे, कुछ में मनगढ़ंत डेटा इस्तेमाल हुआ था, और लगभग 15 पहले ही ठीक किए जा चुके थे।
  • करीब 20 मामलों में किसी भी कोड परिवर्तन की जरूरत थी, और केवल लगभग 10 को “real” बग माना गया जिनका संभावित प्रभाव था; कई बहुत ही बनावटी हमले की सेटअप पर निर्भर थे।
  • Mythos ने अपनी ही कुछ समस्याओं की गिनती गलत की, जिससे यह धारणा और मजबूत हुई कि LLMs बुनियादी चीज़ों, जैसे गिनती, में भी नाज़ुक हैं।
  • कुछ टिप्पणीकारों का कहना है कि Mythos ने कहीं और गंभीर बग्स ज़रूर पाए (जैसे NFS, BSD/OpenBSD stacks), इसलिए यह बेकार नहीं है, लेकिन Linux में “smoking guns” नहीं मिले।

शोर, false positives, और CVEs

  • maintainers बताते हैं कि automated और LLM-based security reports लंबे-चौड़े, अति-आत्मविश्वासी false positives से भरे होते हैं, जिन्हें जांचना महंगा पड़ता है।
  • kernel practice के तहत लगभग हर bugfix के लिए CVEs दिए जाते हैं, इसलिए CVE की संख्या ऊँची दिखती है; Mythos से मिले मुद्दों को भी CVEs मिले, लेकिन वे ज़्यादातर कम-प्रभाव वाले थे।
  • LLM tools के लिए लगभग 50% false-positive rate की तुलना पुराने static analyzers के लगभग 20% से की गई, जिन्हें भी अपनाना मुश्किल रहा था।
  • मुख्य असमानता: अब bug reports बनाना लगभग मुफ़्त है, लेकिन experts के लिए उनकी verification cost वही बनी हुई है।

टूल्स के रूप में LLMs: क्षमता बनाम सीमाएँ

  • कई लोग मौजूदा frontier models को शक्तिशाली pattern matchers के रूप में देखते हैं: बार-बार आने वाले code patterns खोजने में अच्छे, लेकिन real-world context और threat modeling में कमजोर।
  • तुलना “overconfident intern” से लेकर “speed पर top-percentile grad” तक की जाती है, लेकिन कई लोग तर्क देते हैं कि यह LLMs को ज़रूरत से ज़्यादा श्रेय देता है; interns सीखते हैं और ज़िम्मेदारी लेते हैं, models नहीं।
  • दूसरे लोग जवाब देते हैं कि “pattern matching” तो इंसान भी यही करते हैं, और अगर मशीनें ऐसे defects ढूँढ लेती हैं जो इंसान चूक जाते हैं, तो दार्शनिक स्थिति चाहे जो हो, वह उपयोगी है।

Hype, मीडिया, और भरोसा

  • Mythos को व्यापक रूप से overhyped माना गया: इसे खतरनाक रूप से शक्तिशाली और कड़े access control वाला बताकर प्रचारित किया गया, लेकिन Linux में इससे ज़्यादातर तुच्छ या पहले से ठीक किए जा चुके issues ही निकले।
  • टिप्पणीकार इसे व्यापक AI PR से जोड़ते हैं (“too dangerous to release”, “sentient” models, Pope के पास visits जैसी बातें) और पत्रकारों द्वारा vendor narratives को बिना आलोचना के बढ़ाने से भी।
  • हर छह महीने पर आने वाले “इस बार तो कमाल है” चक्रों ने skepticism बढ़ा दिया है, यहाँ तक कि उन users में भी जो LLMs को व्यावहारिक रूप से उपयोगी मानते हैं।

सुरक्षा के निहितार्थ और threat models

  • कुछ लोगों का तर्क है कि एक भी real bug और उसे exploit chain करने वाले agents चिंताजनक हैं; LLMs bug से working exploit तक का समय भी घटाते हैं।
  • अन्य लोग ज़ोर देते हैं कि मिले हुए kernel bugs ज़्यादातर non-critical और/या niche थे (जैसे malicious filesystem images, exotic networking cases)।
  • भविष्य के “autonomous, self-replicating AI worms” पर बहस हुई: कुछ इसे plausible मानते हैं जब सक्षम local models आम हो जाएँगे; दूसरे वर्तमान hardware और deployment constraints की ओर इशारा करते हैं।

कानूनी और प्रक्रिया संबंधी चिंताएँ

  • एक उद्धृत दावा: common training corpora का केवल एक minority हिस्सा स्पष्ट रूप से कानूनी है; बाकी एक gray zone है।
  • इससे kernel जैसे projects में LLM-generated patches को शामिल करने पर सवाल उठते हैं, अगर outputs copyrighted training data जैसे लगें।
  • Developer Certificate of Origin जैसे मौजूदा mechanisms को आवश्यक माना गया, लेकिन वे नए risks को पूरी तरह हल नहीं करते; लंबित court decisions का परिणाम अनिश्चित माना गया।

व्यावहारिक उपयोग के तरीके और सलाह

  • कई लोगों ने सलाह दी:
    • LLMs को केवल सहायक tools की तरह इस्तेमाल करें, autonomous developers की तरह नहीं।
    • “comments को ignore करो, code देखो” – generated explanations अक्सर गलत होती हैं; असली चीज़ code है।
    • non-public या संवेदनशील data को कभी SaaS models पर न डालें; संभव हो तो open-weights models को local चलाएँ।
    • उम्मीद रखें कि LLM use तकनीकी collaboration को तनावग्रस्त करेगा, क्योंकि कुछ contributors अब human review के बजाय “मेरे model ने ऐसा कहा” पर निर्भर होने लगते हैं।