AI दो vulnerability cultures को तोड़ रहा है

• Copy Fail के सार्वजनिक होने के बाद Hyunwoo Kim ने माना कि मौजूदा fix पर्याप्त नहीं था और उसी दिन patch साझा किया, लेकिन Linux-शैली की शांत public fix प्रक्रिया बाहरी खोज के कारण उजागर हो गई और embargo समाप्त हो गया
• Linux, खासकर networking क्षेत्र में, security impact को private list में साझा करके bug fix को सार्वजनिक रूप से जल्दी आगे बढ़ाया जाता है, ताकि वास्तविक vulnerability के अस्तित्व को कुछ दिनों तक embargo में रखा जा सके
• किसी और ने public changes को पहचान लिया, security impact समझ लिया और फिर उसे publicly disclosed कर दिया, जिसके बाद पूरे details प्रकाशित हुए
• AI commit-दर-commit security significance का मूल्यांकन करने की लागत घटा रहा है, जिससे शांत तरीके से public किए गए fixes में vulnerabilities ढूंढना आसान हो रहा है और signal-to-noise ratio भी बढ़ रहा है
• पारंपरिक 90-day coordinated disclosure भी कमजोर पड़ रही है; इस मामले में Kim की ESP vulnerability report के सिर्फ 9 घंटे बाद Kuan-Ting Chen ने भी इसे independently report किया, इसलिए बहुत छोटे embargo शायद बेहतर दिशा हो सकते हैं

---

Copy Fail और Linux security fix practices का टकराव

• Copy Fail vulnerability के public होने के बाद Hyunwoo Kim ने माना कि मौजूदा fix पर्याप्त नहीं था और उसी दिन patch साझा किया
• Kim ने Linux, खासकर networking क्षेत्र में आम प्रक्रिया का पालन किया
  • security impact को Linux security engineers की private list में साझा किया
  • bug fix को सार्वजनिक रूप से शांत और तेज़ी से आगे बढ़ाया
  • उद्देश्य यह था कि केवल actual fix public रहे, जबकि गंभीर vulnerability के अस्तित्व को कुछ दिनों तक embargo में रखा जाए
• किसी और ने उस change को पहचान लिया, security impact समझा, और फिर उसे publicly disclosed कर दिया
• vulnerability को पहले से public माना गया, इसलिए embargo समाप्त हो गया, और इसके बाद पूरे details प्रकाशित किए गए

AI दो vulnerability cultures पर दबाव कैसे बना रहा है

• coordinated disclosure culture

  • जब security bug मिलता है, तो maintainers को private तौर पर बताया जाता है और आमतौर पर 90 दिन जैसी अवधि fix के लिए दी जाती है
  • लक्ष्य यह होता है कि vulnerability के व्यापक रूप से ज्ञात होने से पहले fix deploy हो जाए

• “bug is bug” culture

  • Linux में खास तौर पर आम यह approach मानती है कि अगर kernel ऐसा व्यवहार कर रहा है जो उसे नहीं करना चाहिए, तो कोई न कोई उसे exploit में बदल सकता है
  • vulnerability होने के तथ्य पर ध्यान खींचे बिना जितना जल्दी हो सके उसे ठीक किया जाता है
  • उम्मीद यह रहती है कि बहुत सारे changes के बीच लोग इसे नोटिस नहीं करेंगे, और तब तक systems patch करने का समय मिल जाएगा

• AI की वजह से public fix approach का जोखिम बढ़ रहा है

  • यह तरीका पहले भी पूरी तरह भरोसेमंद नहीं था, लेकिन AI के vulnerability discovery में बेहतर होने से यह और बड़ी समस्या बन रहा है
  • security fixes की संख्या बढ़ने से commits की समीक्षा करना अधिक आकर्षक हो गया है, और signal-to-noise ratio बढ़ा है
  • AI के लिए हर commit का गुजरते समय मूल्यांकन करना लगातार सस्ता और अधिक प्रभावी होता जा रहा है

• लंबे embargo भी कमजोर हो रहे हैं

  • पहले detection धीमा होता था, इसलिए vendor को report करके 90-day disclosure window देने पर यह संभावना अधिक होती थी कि उस दौरान कोई और vulnerability नहीं खोजेगा
  • अब AI-सहायित groups बड़े पैमाने पर software vulnerabilities scan कर रहे हैं, इसलिए यह धारणा कमजोर पड़ रही है
  • इस मामले में Kim द्वारा ESP vulnerability report करने के सिर्फ 9 घंटे बाद Kuan-Ting Chen ने भी इसे independently report किया
  • embargo गलत sense of non-urgency पैदा कर सकते हैं और defect को fix करने वाले actors को सीमित करके risk बढ़ा सकते हैं

• संभावित दिशा और एक सरल model test

  • समाधान स्पष्ट नहीं है, लेकिन बहुत छोटे embargo एक अच्छा approach लगते हैं और समय के साथ शायद और छोटे होने चाहिए
  • AI केवल attackers ही नहीं, defenders को भी तेज़ बना सकता है, इसलिए जो embargo पहले बहुत छोटे और बेकार लगते थे, वे अब संभव हो सकते हैं
  • जब f4c50a403 को Gemini 3.1 Pro, ChatGPT-Thinking 5.5, Claude Opus 4.7 को दिया गया, तो तीनों models ने तुरंत पहचान लिया कि यह security patch है
  • commit context के बिना सिर्फ diff देने पर Gemini ने भरोसे के साथ इसे security fix कहा, GPT ने इसे काफी संभव माना, जबकि Claude ने कहा कि इसकी संभावना कम है
  • यह test "Without searching, does this look like a security patch?" prompt के साथ हर model पर एक-एक बार चलाया गया बहुत तेज़ उदाहरण था, इसलिए models के बीच तुलना को बहुत अधिक महत्व देना कठिन है

[fastkoder]

बहुत छोटे एम्बार्गो बनाम लंबे एम्बार्गो में से आखिरकार "बहुत छोटे एम्बार्गो" की ओर ही जाना पड़ेगा, इसलिए security AI agent और भी व्यस्त हो जाएंगे।

[GN⁺]

Hacker News की राय

• इस बदलाव के संकेत बहुत पहले से थे, और LLM क्या है यह पता चलने से पहले ही आज दिख रही दरारों की भविष्यवाणी की जा सकती थी।
  इसका उत्प्रेरक software transparency में बढ़ोतरी है। open source और source-available software को अपनाना बहुत बढ़ा है, और reverse engineering तथा decompilation tools की क्षमता भी काफी बेहतर हुई है। आम तौर पर off-the-shelf closed source software का गंभीर attackers से अर्थपूर्ण रूप से छिपा रहना अब 10 साल से भी पहले की बात हो चुकी है।
  BinDiff के बाद से यह समस्या धीरे-धीरे बढ़ती आ रही है। software को patch करते ही vulnerability भी साथ में उजागर करनी पड़ती है। अब तक लोग इससे इनकार करते रहे, क्योंकि यह समझने के लिए कि patch ही vulnerability disclosure है, कुछ विशेषज्ञता चाहिए होती थी, लेकिन AI ने वह बहाना खत्म कर दिया है।
  अब mainline Linux में कुछ भी merge होते ही कई organizations उस diff को LLM prompt में डालकर आक्रामक तरीके से यह मूल्यांकन कर रही हैं कि क्या वह vulnerability fix है, और exploit guide तैयार कर रही हैं। nginx, OpenSSL, Postgres जैसे ज़्यादातर बड़े open source projects के साथ भी जल्द यही होगा।
  coordinated disclosure की प्रथाएँ इस माहौल के लिए बनी ही नहीं हैं, और सच कहूँ तो पिछले 10 सालों से भी वे इसके अनुरूप नहीं थीं।
  अजीब तरह से मुझे यह स्थिति असहज नहीं लगती, क्योंकि coordinated disclosure practices हमेशा यह मानकर चलती रही हैं कि sysadmin की operational convenience के लिए disclosure में देरी करना अच्छा है। इस मान्यता पर संदेह करने की वजह है। disclosure delay सिर्फ़ patch apply करने से आगे के विकल्प रखने वाले system operators से भी जानकारी छीन लेती है

  • “आम तौर पर off-the-shelf closed source software का गंभीर attackers से अर्थपूर्ण रूप से छिपा रहना अब 10 साल से भी पहले की बात हो चुकी है” — यह लगभग स्वयंसिद्ध है, लेकिन आख़िरी रक्षा-पंक्ति software को सार्वजनिक रूप से distribute न करना और server-client architecture पर निर्भर रहना है।
    अगर vulnerabilities को ढूँढना और exploit करना आसान हो जाए, तो यह तरीका और आम हो सकता है। बेशक, यह हमेशा संभव नहीं होता।
    पिछले 11 सालों में ProGuard से obfuscate किए गए game client binaries कई बार decompile होकर GitHub पर चढ़ गए, जो काफ़ी झुंझलाहट भरा था। सिर्फ़ non-distributed server code ही निजी रह पाया।
    दिलचस्प बात यह है कि network protocol को हर हफ़्ते से कम बार बदलने से पहले तक attackers के इसे reverse engineer कर लेने की समस्या नहीं थी। अब लगता है कि LLM-सहायता वाले attackers उस रफ्तार के साथ भी चल पाएँगे
  • coordinated vulnerability disclosure के पीछे का business कारण मैं हमेशा समझता रहा हूँ, और नौकरी में उस policy का पालन करना ही पड़ता था, लेकिन व्यक्तिगत रूप से मैं हमेशा full disclosure के पक्ष में था। मैं इस बदलाव का लंबे समय से इंतज़ार कर रहा था

• यह AI से पैदा हुई नई समस्या कम, और पुरानी समस्या को AI समस्या के रूप में दोबारा पैक किया जाना ज़्यादा लगता है।
  लोग LLM आने से बहुत पहले से kernel commit diffs की तुलना करके यह पता लगा लेते थे कि कौन-सा security fix है। जिस पल patch सार्वजनिक रूप से चढ़ता है, प्रतिस्पर्धा असल में उसी पल शुरू हो जाती है।
  मुझे यह भी साफ़ नहीं कि disclosure grace period घटाने से वाकई मदद मिलती है। जो organizations कुछ घंटों में patch कर सकती हैं, वे पहले से ठीक हैं, और बाकी को अब भी कई दिन या हफ़्ते लगेंगे।
  उल्टा, exploit generation की लागत जितनी कम होगी, coordinated disclosure उतनी कम महत्वपूर्ण नहीं बल्कि शायद और ज़्यादा महत्वपूर्ण होगी

  • “लोग पहले से kernel commit diffs की तुलना करके security fix पहचान लेते थे”, लेकिन उसमें कौशल चाहिए होता था और आम तौर पर वह लगातार या व्यवस्थित तरीके से नहीं होता था। AI के साथ कोई भी, किसी भी software पर यह कर सकता है।
    “disclosure grace period घटाने से मदद मिलती है या नहीं” के बारे में मुख्य सवाल है: 90 दिन क्यों, 2 साल क्यों नहीं? लेख का तर्क यह है कि simultaneous discovery की बढ़ती आवृत्ति के साथ वह संतुलन तय करने वाले कारक बदल गए हैं। अगर grace period के बाहर मौजूद कई लोग वैसे भी exploit ढूँढ लेंगे, तो grace period कोई वास्तविक window नहीं, सिर्फ़ एक भ्रम है।
    “सस्ती exploit generation coordinated disclosure को और महत्वपूर्ण बनाती है” — इससे मैं सहमत हूँ। लेकिन साथ ही यह उसे कम व्यवहार्य भी बनाती है। अगर script kiddies भी zero-day ढूँढ और exploit कर सकते हैं, तो coordination की क्षमता टूट जाती है।
    whitehat culture में हमेशा किसी कारीगर guild जैसी नैतिकता रही है। अगर वह guild टूट जाए, तो उस नैतिकता के टिकने की जगह भी नहीं बचेगी
  • मैंने पूरे Linux development को लगातार फॉलो नहीं किया है, लेकिन क्या पहले कभी ऐसा हुआ है कि patch के kernel में जाने से पहले ही mailing list पर working exploit प्रकाशित हो गया हो?
    मैंने ऐसा नहीं देखा, और थोड़ी अतिशयोक्तिपूर्ण भाषा को ध्यान में रखते हुए भी अब यह आभास होता है कि LLM की वजह से ऐसा ज़्यादा बार होगा
  • Torvalds ने कहा था कि जब कोई बड़ा मुद्दा मिल जाए, तो उसके बाद होने वाले तमाशे की ज़रूरत नहीं; bug को उजागर करना ही काफ़ी है [1]
    इसलिए Dirtyfrag का Linux kernel fix के रूप में सामने आना आश्चर्यजनक नहीं है [2]
    [1] https://www.zdnet.com/article/torvalds-criticises-the-securi...
    [2] https://afflicted.sh/blog/posts/copy-fail-2.html
  • इसे AI से और बिगड़ती हुई पुरानी समस्या कहना शायद सही होगा
  • लगता है मैं हर हफ़्ते इसी बात का कोई न कोई रूप लिखता हूँ, इसलिए अगर आलस्य की इजाज़त हो तो पहले लिखा हुआ संस्करण साझा कर देता हूँ
    https://news.ycombinator.com/item?id=47921829

• एक बड़ी समस्या खड़ी हो गई है।
  अमेरिका युद्ध में है, और अभी दुनिया का एक बड़ा हिस्सा भी cyberattack-स्तर के युद्ध में लगा हुआ है। अमेरिका, EU, मध्य पूर्व का अधिकांश हिस्सा, इज़राइल, रूस — सब इसमें शामिल हैं।
  Ubuntu, GitHub, Let’s Encrypt, Stryker जैसी प्रमुख सेवाओं पर हमले हुए और वे कई दिनों तक ठप रहीं, और अस्पतालों की पूरी systems भी आंशिक रूप से बाधित हुईं।
  इस सबके बीच AI ने attacks तैयार करने की गति बहुत तेज़ कर दी है। defenders जितनी तेज़ प्रतिक्रिया दे सकें, उससे भी तेज़। पहले zero-day attacks दुर्लभ थे, अब वे आम बात हो गए हैं।
  हालात बेहतर होने से पहले और बिगड़ेंगे, और शायद बहुत ज़्यादा बिगड़ सकते हैं

  • समझ नहीं आता कि यह बेहतर कैसे हो सकता है

• “अब security fixes इतनी ज़्यादा आ रही हैं कि commits को खंगालना और आकर्षक हो गया है। signal-to-noise ratio अधिक है” — यह बात क्यों सही है, इस पर सवाल है।
  मुख्य बात यह है कि “AI के लिए हर commit पर जाते हुए उसे evaluate करना लगातार सस्ता और अधिक प्रभावी होता जा रहा है।” AI के साथ “इतने सारे बदलाव हैं कि लोग नोटिस नहीं करेंगे” वाली धारणा टूट जाती है

• यह तेज़ test बहुत कुछ नहीं दिखाता। अगर आप सीधे पूछते हैं “क्या यह security patch है?”, तो आप AI को उसी पूर्वधारणा से सहमत आउटपुट देने के लिए संकेत और प्रेरित कर रहे होते हैं।
  confusion matrix ज़्यादा उपयोगी होगी। बेशक, मैं समझता हूँ कि यह लेख AI capabilities की विस्तृत testing पर केंद्रित नहीं है

  • मैं सहमत हूँ कि अतिरिक्त सबूत के तौर पर यह बहुत बड़ा नहीं है। अगर कोई उस सूची के N commits पर, इस commit सहित, यही test चलाए, तो परिणाम जानना बहुत रोचक होगा
  • आदर्श रूप से, सभी kernel diffs पर LLM द्वारा yes/no classification के परिणामों की confusion matrix से निकाला जा सकने वाला phi coefficient, यानी MCC चाहिए।
    इसे true positives, true negatives, false positives, false negatives की संख्या से निकाला जा सकता है

• automated patching और release cycles की ज़रूरत है।
  अब तक हम report लेने, जाँच करने, verify करने, patch करने और release तैयार करने जैसी अविश्वसनीय रूप से धीमी manual प्रक्रिया पर निर्भर रहे हैं। fixes जारी करने में महीनों लगना आम बात है। उस दौर में जहाँ attackers कुछ घंटों में नए exploits उगल सकते हैं, यह बहुत धीमा है।
  patch तक पहुँचने का average time घटाने के लिए value chain के bottlenecks को बार-बार बेहतर करना होगा।
  bug report मिलने के 1 घंटे के भीतर हमें QA-testable patched product तक पहुँचना चाहिए। इसे standardize या open source किया जाना चाहिए, और Linux kernel → distro → उस distro का उपयोग करने वाले products → users तक पूरी software supply chain को इसे अपनाना चाहिए। AI के साथ इसे न कर पाने की कोई वजह नहीं; हम बस धीमे हैं

• AI update window को नाटकीय रूप से छोटा कर देगा। 2026 में dependency cooldown पर विचार करना सबसे बुरी बात होगी; अब dependency warmup पर विचार करना चाहिए।
  जल्द ही open source projects में vulnerabilities को सुरक्षित रूप से disclose करने जैसी चीज़ गायब हो जाएगी। centralized SaaS को यहाँ बड़ा security advantage मिलेगा

  • closed source centralized SaaS को बड़ा security advantage मिलेगा।
    open source dependency में remote code execution vulnerability का मतलब यह है कि security patch सार्वजनिक होते ही सब उतने ही vulnerable हो जाते हैं; इसमें विवाद की बात क्यों है, समझ नहीं आता
  • Linux इस्तेमाल करने वाली organizations एक web of trust बना सकती हैं, जिसमें वे कुछ लागत लगाकर AI से अपनी dependencies को लगातार scan और patch करें, और एक-दूसरे को patches और scan results भेजें

• Tony Hoare की “obvious bugs की अनुपस्थिति” और “स्पष्ट रूप से bug-मुक्त” के बीच वाली पुरानी बात LLM युग में पहले से कहीं ज़्यादा सटीक बैठती है

• bugs को बस bugs की तरह ट्रीट करने वाली व्याख्या मुझे व्यक्तिगत रूप से काफ़ी अव्यवहारिक लगती है, लेकिन मैं जानता हूँ कि Linux दुनिया में ऐसे बहुत लोग हैं जो practical समस्याओं से ज़्यादा principles को महत्व देते हैं।
  फिर भी 90 दिन लंबा लगता है।
  आखिरकार बड़ी AI कंपनियों को core internet infrastructure पर काम करने वाले लोगों की मदद करनी पड़ेगी। nginx जैसी चीज़ों पर latest-best AI चलाना हम सबके लिए सामूहिक रूप से फ़ायदेमंद होगा

• “खुशकिस्मती से AI यहाँ defenders को भी attackers जितना तेज़ बना सकता है, जिससे पहले बेकार समझी जाने वाली छोटी disclosure grace period भी अब संभव हो सकती है” — यह इस problem space का एक अहम पहलू है।
  security risk आख़िरकार इस बात की arms race बन सकता है कि कौन token cost पर ज़्यादा खर्च करेगा

  • दिलचस्प बात यह है कि इससे closed source code defenders के लिए और भी बड़ी संपत्ति बन जाता है।
    attackers वहाँ tokens खर्च नहीं कर सकते, लेकिन defenders source code के आधार पर hardening work पर tokens खर्च कर सकते हैं। attackers black-box testing तक सीमित रह जाते हैं