ओपन सोर्स सुरक्षा को साथ मिलकर सुरक्षित रखने के लिए Akrites का खुला पत्र

 (akrites.org)
1 पॉइंट द्वारा GN⁺ 6 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • AI-आधारित vulnerability खोज maintainers की प्रतिक्रिया गति से आगे निकल रही है, और इसी कारण Akrites की शुरुआत core open source software को मिलकर मजबूत बनाने के लिए उद्योग-स्तरीय सहयोग के रूप में हुई है
  • गंभीर vulnerabilities ढूँढना पहले experts को कई हफ्ते लगने वाला काम था, लेकिन अब AI models कुछ ही मिनटों में कई vulnerabilities खोज सकते हैं, जिससे प्रतिक्रिया का बोझ तेज़ी से बढ़ गया है
  • AWS, Anthropic, Chainguard, Cisco, Citi, Ericsson, Google, IBM, Microsoft और GitHub, NVIDIA, OpenAI, Red Hat, Rust Foundation आदि ने upstream fixes और responsible disclosure को coordinate करने पर सहमति जताई है
  • Akrites duplicate reports और टकराने वाले patches को कम करने के लिए एक confidential coordination point और समर्पित Security Incident Response Team उपलब्ध कराता है, और maintainer-विहीन core packages के लिए अंतिम विकल्प maintainer की भूमिका भी निभाता है
  • patch सार्वजनिक होने के बाद हमलावर AI की मदद से vulnerabilities को reverse engineer कर सकते हैं, इसलिए सफलता का मानदंड केवल disclosure नहीं बल्कि patches का वास्तविक systems तक deploy होना है

AI ने ओपन सोर्स सुरक्षा की रफ्तार कैसे बदल दी

  • open source अब बैंकिंग, telecom, utilities जैसी core infrastructure और services की नींव बन चुका है, जिन पर लोग हर दिन निर्भर रहते हैं
  • पूरे technology stack में वही open source components व्यापक रूप से उपयोग होने के कारण, कई systems अब वही संभावित defects साझा करते हैं
  • AI ने attackers और defenders के बीच संतुलन बदल दिया है, और vulnerability discovery व reuse की लागत संरचना को कम कर दिया है
    • गंभीर vulnerabilities ढूँढने में पहले experts को कई हफ्ते लगते थे, लेकिन अब मशीनें यह काम कुछ मिनटों में कर सकती हैं
    • कई बार AI models एक ही run में कई vulnerabilities वापस कर देते हैं
    • यही क्षमता defense में भी इस्तेमाल हो सकती है, लेकिन दुरुपयोग होने पर vulnerability discovery pipeline-आधारित हो सकती है

duplicate reports कैसे maintainers पर दबाव बढ़ाती हैं

  • मौजूदा security response और disclosure process कई organizations और teams में ढीले तौर पर बंटी हुई है, इसलिए एक ही समस्या पर एक साथ काम होना, टकराने वाले patches बनना, और कई reports निकलना संभव हो जाता है
  • अगर दर्जनों कंपनियाँ एक ही library को स्वतंत्र रूप से scan करके अपनी-अपनी reports भेजें, तो maintainer शोर में दब जाता है
  • जिन लोगों को अभी तक patch न हुई vulnerability की जानकारी होती है, उनकी संख्या जितनी बढ़ती है, fix से पहले leak होने की संभावना भी उतनी बढ़ती है, और यह जोखिम पूरे ecosystem में फैल जाता है
  • बिना coordination के की गई सद्भावनापूर्ण प्रतिक्रिया भी समस्या को और बढ़ा सकती है और समय बर्बाद कर सकती है

Akrites की संयुक्त प्रतिक्रिया पद्धति

  • Akrites की शुरुआत core open source software की vulnerabilities को खोजने, ठीक करने और जिम्मेदारी के साथ सार्वजनिक करने के लिए साझा systems और tools तैनात करने वाले प्रयास के रूप में हुई है
  • प्रतिभागियों में Amazon Web Services, Anthropic, Chainguard, Cisco, Citi, Endor Labs, Ericsson, Google, IBM, JPMorganChase, Microsoft और GitHub, NVIDIA, OpenAI, RapidFort, Red Hat, Rust Foundation, Sonatype, Vodafone, Zscaler आदि शामिल हैं
  • प्रतिक्रिया का केंद्र upstream maintainers हैं
    • यह vulnerability discovery, fix और disclosure को coordinate करने के लिए एक confidential और trust-based साझा स्थान देता है
    • समर्पित Security Incident Response Team maintainers के लिए असंख्य uncoordinated reports के बजाय एक अनुमानित single partner की भूमिका निभाती है
    • fixes को हर project के मूल repository और maintainer workflow में वापस ले जाया जाता है
  • अगर किसी core package का maintainer नहीं है, तो Akrites ने कहा है कि वह fix समय पर पहुँचाने के लिए अंतिम विकल्प maintainer की भूमिका निभाएगा

patch disclosure से ज़्यादा deployment क्यों महत्वपूर्ण है

  • patch सार्वजनिक होते ही हमलावर AI की मदद से वास्तविक vulnerability को तेज़ी से reverse engineer कर सकते हैं, exploit विकसित कर सकते हैं और हमले शुरू कर सकते हैं
  • इसलिए Akrites की सफलता को इस आधार पर नहीं मापा जाना चाहिए कि patch सार्वजनिक हुआ या नहीं, बल्कि इस आधार पर कि वह वास्तविक systems में deploy हुआ या नहीं
  • Akrites core infrastructure owners और operators, civil society efforts, और governments के साथ मिलकर coordination का स्तर बढ़ाना चाहता है
  • confidentiality पर कोई समझौता नहीं हो सकता, क्योंकि व्यापक रूप से deployed packages में undisclosed defects व्यावहारिक रूप से हथियार जैसे होते हैं, इसलिए leaks को रोकना प्राथमिकता है

भाग लेने वाले संगठनों ने बोझ और प्रतिबद्धता पर क्या ज़ोर दिया

  • Endor Labs ने कहा कि हाल के महीनों में सत्यापित हज़ारों open source vulnerabilities में patch की गई vulnerabilities का अनुपात 5% से कम है
  • OpenInfra ने कहा कि OpenStack community ने केवल इस quarter में 20 security advisories जारी कीं, जबकि पूरे 2025 में यह संख्या 2 थी
  • JPMorganChase का मानना है कि AI ने vulnerability discovery और exploitation के बीच के समय को लगभग real-time तक संकुचित कर दिया है, इसलिए fix से deployment तक का समय भी घटाना होगा
  • Chainguard, Sonatype, RapidFort, Red Hat आदि ने कहा कि vulnerability fixes forks या निजी दीवारों के पीछे बिखरने के बजाय upstream coordination के ज़रिए मूल software और maintainer workflow के भीतर होने चाहिए
  • भाग लेने वाले संगठनों ने engineering talent, security expertise, funding और AI technology लगाकर साझा software को मजबूत करने का वादा किया है

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

1 टिप्पणियां

 
GN⁺ 6 시간 전
Hacker News की राय

  • कई open source से जुड़े लोग इस भाग लेने वाली कंपनियों की सूची को देखकर संदेहपूर्ण हुए बिना नहीं रह सकते, और इसकी वजह भी है
    असली सवाल यह है कि “महत्वपूर्ण open source software की vulnerabilities को ढूँढकर उन्हें ठीक करना और जिम्मेदारी से public करना” व्यवहार में कैसे लागू किया जाएगा। अगर मौजूदा channels और pull requests के ज़रिए योगदान दिया जाए तो community के साथ चला जा सकता है, लेकिन अगर ‘security’ के नाम पर fork किया गया तो community हाशिए पर चली जाएगी, resources बँट जाएंगे, और लंबे समय में कई projects मर सकते हैं। bug bounty में संभावना है, लेकिन critical bugs के मामले में speed और disclosure timing मेल नहीं खा सकती, और financial support भी maintainer support के साथ न जुड़ी हो तो उसका असर सीमित रहता है

    • मैं Linux Foundation में employed हूँ, लेकिन इस project के अंदरूनी हालात नहीं जानता। हाँ, जिन projects को मैं support करता हूँ वे क्या करते हैं, यह बता सकता हूँ: HackerOne program में signal से ज़्यादा noise है, इसलिए उसे छोटा किया जा रहा है
      PQCA AWS credits के ज़रिए hardware access देता है ताकि proofs और CI चलाए जा सकें, और paid mentorship भी चलाता है। OWF भी AWS credits और testing के लिए service hosting देता है। LFDT paid mentorship, Trail of Bits review की लागत, event operations, New York maintainer summit, बड़े GitHub CI runners support आदि देता रहा है। हमारी team में OWF/PQCA/LFDT developer relations के हिसाब से केवल 3 full-time लोग, 1 contractor और 1 manager हैं, लेकिन developers की मदद के लिए हम काफ़ी मेहनत करते हैं
      LFDT: https://www.lfdecentralizedtrust.org/
      OWF: https://openwallet.foundation/
      PQCA: https://pqca.org/
      PQCA benchmark उदाहरण: https://pq-code-package.github.io/mldsa-native/dev/bench/
    • किसने भाग लिया है और वे क्या करना चाहते हैं, यह देखते ही मेरे मन में भी पहला विचार यही आया। commons को मुनाफ़ाखोर कंपनियों के हाथ में नहीं जाना चाहिए
      उसका स्वरूप चाहे जैसा भी हो, उसे इस तरह distributed होना चाहिए कि कोई एक केंद्रीय स्थान या एकल इकाई नियंत्रण न चला सके
    • यह कहना अजीब है कि “जैसे ये कंपनियाँ open source से जुड़ी हुई नहीं हैं।” open source कोई exclusive club नहीं है
    • जो मैंने पढ़ा, उससे मुझे समझ आया कि जहाँ संभव है वहाँ मौजूदा तरीकों से योगदान दिया जाएगा, और जहाँ ज़रूरी होगा वहाँ अलग कदम उठाए जाएँगे। अगर Linux Foundation है, तो स्वाभाविक रूप से open source और community पहले होने चाहिए
      financial contribution की बात होती है, लेकिन कैसे और किसलिए की जाएगी, यह भी महत्वपूर्ण है। ज़्यादातर projects donations लेने या उनका उपयोग करने के लिए तैयार नहीं हैं। लेकिन अच्छा होगा अगर सभी open source projects को इतना AI access मिल सके कि वे codebase और pull requests की समीक्षा कर पाएं और maintenance burden कम हो; ऐसी कुछ कोशिशें पहले से मौजूद भी हैं

  • यह सिर्फ corporate दिखावा है
    Microsoft कहता है कि वह “vulnerabilities की जिम्मेदारी से पहचान और remediation में expertise, resources और AI technology का योगदान देगा,” लेकिन Microsoft NPM और GitHub चलाता है, उसके पास बेहतरीन AI models और विशाल data centers तक पहुँच है। इसके बावजूद उसके अपने products की security तेज़ी से खराब हो रही है, और उसकी services कई exploits के फैलने का केंद्रीय hub बनती जा रही हैं
    अगर देखना हो कि Microsoft अपने open source projects की security issues को कैसे संभालता है, तो यह GitHub thread देखने लायक है: https://github.com/dotnet/efcore/issues/38257
    EF Core इस समय SQLite का एक ऐसा version ship कर रहा है जिसमें गंभीर vulnerability है। यह issue एक साल से भी पहले पाया गया था, और SQLite ने इसे एक हफ्ते के भीतर ठीक कर दिया था, लेकिन EF Core ने driver को vulnerable के रूप में mark नहीं किया, जब तक कि हाल ही में users ने इसे फिर से report करके developers से बहस नहीं की। मौजूदा stable version .NET Core में इसका fix लगभग दो महीने बाद ही आने वाला है

    • CVE-2025-70873 को गंभीर vulnerability कहना थोड़ा बढ़ा-चढ़ाकर कहना लगता है। यह तभी संभव है जब attacker को कोई arbitrary ZIP file import करने दिया जाए, इसलिए जब तक user को arbitrary ZIP files import नहीं करने दिए जाते, यह उतना गंभीर नहीं है
    • Microsoft के acquisition से पहले GitHub JavaScript में IDE बनाना चाहता था और उसने Electron तक बना दिया था; वह मज़ेदार था और आखिरकार बिल्कुल अलग लेकिन उपयोगी चीज़ बन गया। तकनीकी innovation अक्सर ऐसे ही होती है
      acquisition के बाद Microsoft ने VSCode के ज़रिए उस दिशा को आगे बढ़ाने के बजाय Electron को नीचा दिखाने वाला माहौल बनाया, और अब बहुत से लोग बिना वजह ठीक से समझाए Electron से नफ़रत करते हैं। VSCode ने Atom को fork भी नहीं किया, बल्कि शुरू से वैसी ही चीज़ बनाई, जो और बड़ी और धीमी हो गई, और अब उसमें Copilot भी जुड़ गया है। मैं आखिरकार Atom के अच्छे fork Pulsar पर लौट गया
      Microsoft हमेशा मौकों और competitive landscape को देखकर acquisition करता है, लेकिन जो खरीदता है उसका सही इस्तेमाल बहुत कम करता है। अच्छे कर्मचारियों और अच्छे code को हटाकर product को खराब कर देता है। फिर भी सब लोग अब भी Microsoft products का इस्तेमाल करते हैं, यह मेरी समझ से बाहर है। LinkedIn छोड़ देना चाहिए, और सबको मिलकर किसी दूसरे version control system पर जाना चाहिए। जब तक open source developers सिर्फ़ बातों से आगे बढ़कर action नहीं लेते, Microsoft और बदतर होता जाएगा

  • हम ऐसा नहीं करेंगे। बड़ी-बड़ी घोषणाएँ करके, commercial कंपनियों को सब कुछ बिगाड़ने के लिए छोड़ देना, और फिर जबकि हमने खुद कुछ भी नहीं किया हो, हालत पर जोर-जोर से शिकायत करना — ऐसा नहीं होगा
    आगे चलकर मुझे लगता है कि एक प्रवृत्ति उभरेगी जिसे मैं undo fork कहता हूँ। यह ऐसा fork है जो पागलपन शुरू होने से पहले के बिंदु पर लौटकर फिर से सोचता है, और यह काम सिर्फ वे लोग कर सकते हैं जो commercial माँगों से बँधे नहीं हैं

    • एक मायने में यह बदलाव उसी क्षण शुरू हो गया था जब Free Software से Open Source की ओर संक्रमण हुआ, और इसकी रफ्तार कम नहीं हो रही है
    • इससे भी बुरा। open source पर अतिशयोक्तिपूर्ण marketing कंपनियाँ कब्ज़ा कर सकती हैं, और यह उस चीज़ को बनाने के लिए मुफ़्त श्रम निचोड़ने का साधन बन सकता है जो वे चाहती हैं, न कि जो हम चाहते हैं
    • उपयोगी open source का 95% commercial कंपनियाँ बनाती हैं या maintain करती हैं। Linux, Postgres जैसी चीज़ें इसका उदाहरण हैं; छोटी-मोटी utility श्रेणी की चीज़ों को छोड़कर यह बात कही जा रही है
    • आज का Linux Foundation वस्तुतः किसी राजनीतिक एजेंडा वाले दूसरे global corporate संगठन जैसा है। पैसे का प्रवाह देखें तो साफ दिखता है कि नियंत्रण कंपनियों के हाथ में है, Torvalds को निष्प्रभावी कर दिया गया है, और उनके साथ काम करना भी ज़्यादातर एक बुरे सपने जैसा माना जा सकता है
      open source में रुचि रखने वालों को मैं हमेशा Linux Foundation से दूर रहने की सलाह देता हूँ। आजकल यह software freedom को संभव बनाने से ज़्यादा उसे रोकने वाली बाधा बन गया है

  • open source की रक्षा करनी है तो शुरुआत बातों से नहीं, बल्कि projects और developers के लिए वास्तविक समर्थन से होनी चाहिए
    OpenBSD developer के नज़रिए से देखें तो developers को नया hardware उपलब्ध कराना सचमुच बहुत महत्वपूर्ण है। कई developer अब भी 5–10 साल पुराने ThinkPad पर काम कर रहे हैं जिन्हें बदले जाने की ज़रूरत है
    https://www.openbsd.org/want.html
    OpenBSD Foundation अपने 2026 fundraising लक्ष्य से अभी भी लगभग 50% दूर है
    https://www.openbsdfoundation.org/campaign2026.html

    • जिन open source projects का आप उपयोग करते हैं, उन्हें funding देने के साथ-साथ, अगर संभव हो, तो उन projects पर काम करने वाले व्यक्तिगत contributors और developers को भी सीधे समर्थन देना अच्छा होगा। बहुत से लोग volunteer हैं, और छोटा-सा monthly sponsorship भी बड़ा फर्क ला सकता है
      https://brynet.ca/wallofpizza.html
    • Debian पर upload कर सकने वाली GPG keys की सुरक्षा के लिए मैं कुछ YubiKey खरीदना चाहता था, लेकिन माहौल ऐसा है कि ज़रूरत पड़े तो आखिरकार उन्हें मुझे अपनी जेब से ही खरीदना होगा

  • “Amazon Web Services साथ है” वाली पंक्ति पर आते ही इस लेख की विश्वसनीयता पूरी तरह खत्म हो जाती है

  • यह centralization और control की कोशिश जैसा लगता है। Akrites कोई भी हो, इससे बस Google समेत बड़ी tech कंपनियों को open source पर नियंत्रण की ताकत मिलेगी
    धन्यवाद, लेकिन नहीं। मुझे याद है कि इस सितंबर Google Android में .apk के ज़रिए third-party installation को रोकने की कोशिश कर रहा है

    • मेरी भी यही चिंता है। अगर महत्वपूर्ण open source packages इन कंपनियों की “security” release पर निर्भर हो जाएँ, तो क्या वे उदाहरण के लिए package पर identity verification थोप नहीं सकेंगी?
      इसी संदर्भ में, मेरे जानने वाले ज़्यादातर समझदार लोग मानते हैं कि open source AI, Anthropic और OpenAI को आर्थिक रूप से असंभव बना देता है। यहाँ नाम लिखने वाली कई कंपनियाँ उन दोनों से गहराई से जुड़ी हुई हैं, और ग्राहकों को कीमत का झटका महसूस होने से पहले open source AI को कमजोर करने की उनकी प्रेरणा काफी मजबूत है। मैं इंतज़ार कर रहा था कि उनका अगला कदम क्या होगा; यह उसका एक हिस्सा भी हो सकता है

  • सबसे महत्वपूर्ण जानकारी यह है कि “प्रतिभागी engineering resources योगदान देंगे”
    यह योजना के मुताबिक चलेगा या नहीं, यह देखना बाकी है। इसके अलावा इस project के दावों से मैं बहुत प्रभावित नहीं हूँ। इसकी संरचना centralization और corporate-केंद्रित network के पक्ष में है, इसलिए यह उस दिशाा के बिलकुल उलट है जिसे अच्छे कारणों से hacker ethic ने प्रोत्साहित किया है

    • यह समावेशी नहीं लगता। यह आने वाली vulnerabilities को केंद्र में जमा करने, जानकारी इकट्ठा करने और उसे गोपनीय तरीके से संभालने वाली एक और परत जैसा दिखता है
      यह दबाव का एक और स्रोत भी बन सकता है। शायद यह वास्तविक vulnerabilities को अच्छी तरह छाँट ले, लेकिन उसका नतीजा maintainers पर high priority के साथ धकेला जाएगा। कई maintainers AI noise के बिना भी पहले से थके हुए हैं, और patch दिया जाए तब भी review की ज़रूरत रहती है
      सबसे अच्छे हाल में यह noise कम कर सकता है, लेकिन काम फिर भी बाकी रहता है। उद्योग को व्यापक रूप से funding देनी चाहिए ताकि open source projects के पास चीज़ों को खुद संभालने की क्षमता हो। संभावना है कि गुणवत्ता के लिए भी वही सबसे अच्छा होगा। अगर AI noise को फ़िल्टर करना है तो वह सुविधा जोड़ी जा सकती है, लेकिन संरचना ऐसी गुप्त और opaque नहीं होनी चाहिए जो सब कुछ नियंत्रित करे
    • संक्षेप में कहें तो, यह ऐसा नकली सहयोग लगता है जिसमें कंपनियाँ समय छीन लेती हैं और बदले में कुछ भी नहीं लौटातीं। मैं सहमत हूँ कि यह hacker ethic द्वारा प्रोत्साहित मूल्यों के ठीक विपरीत है

  • मैं उस दिन का इंतज़ार कर रहा हूँ जब headline होगी, “हम सब open source पर निर्भर हैं। हम मिलकर funding करेंगे”

    • बड़ी कंपनियों में से काफी पहले से ही कर्मचारियों को नियुक्त करके भागीदारी करवाने के तरीके से “open source को funding” दे रही हैं। उदाहरण के लिए LKML पर दिखने वाले corporate email addresses देखकर यह समझा जा सकता है

  • “Akrites” नाम अच्छा है
    जो लोग Greek नहीं हैं, उनके लिए शायद यह कम प्रभावशाली हो, लेकिन Greek लोगों के लिए यह काफ़ी शक्तिशाली छवि पैदा करता है

    • जो लोग इसे खोजेंगे उनके लिए संक्षेप में, akritai 9वीं से 11वीं सदी के Byzantine Empire में पूर्वी सीमा की रक्षा करने वाले सीमांत सैनिकों के लिए इस्तेमाल होने वाला शब्द था
      akron का अर्थ किनारा या सीमा होता है, इसलिए इसका अर्थ लगभग “सीमांतवासी” या “सीमा के लोग” है। यहाँ मुख्य बात यह है कि आज के संघर्षों या पूर्वाग्रहों को ज्यों-का-त्यों एक हज़ार साल पुरानी इतिहास-स्थितियों पर नहीं चढ़ाया जा सकता। ऐतिहासिक संदर्भ में यह अलग-अलग सभ्यताओं के बीच मौजूद कई सीमाओं जैसा था, और महत्वपूर्ण बात यह है कि यह अपनी ज़मीन की रक्षा के लिए इकट्ठा हुआ सामूहिक संगठन था
    • एक अधिक हालिया उदाहरण Mark Carney का Davos भाषण है। खासकर यह पंक्ति याद आती है: “मध्यम शक्तियों को मिलकर काम करना चाहिए। अगर हम मेज़ पर नहीं बैठे होंगे, तो हम मेन्यू में होंगे”
      [1] https://en.wikipedia.org/wiki/Mark_Carney%27s_Davos_speech

  • मुझे नहीं लगता कि Hacker News पर ऐसी पोस्ट डालने का कोई खास मतलब है। यहाँ ज़्यादातर लोग AI लहर को गहराई से स्वीकार कर चुके हैं और उन्हें इसकी ज़्यादा परवाह नहीं है
    इसके अलावा, सूची में शामिल कई कंपनियाँ open source की मौजूदा हालत के लिए प्रमुख संदेह के दायरे में आती हैं

    • मैं AI कचरे को स्वीकार नहीं करता, और मुझे ठीक से समझ नहीं आता कि ऐसा निष्कर्ष कहाँ से आ रहा है। ज़्यादातर टिप्पणियाँ तो AI कचरे के काफ़ी खिलाफ़ हैं
      लेकिन इस बात से सहमत हूँ कि सूची में मौजूद कई कंपनियाँ open source की स्थिति की प्रमुख संदिग्ध हैं। यह उन कंपनियों को whitewashing करने वाली PR विज्ञापन जैसी लगती है, और यह मानना मुश्किल है कि उन्हें सच में open source ethics की परवाह है