बदलते सुरक्षा परिदृश्य के लिए एक समन्वित प्रतिक्रिया
Linux Foundation ने Akrites लॉन्च किया है, एक नई उद्योग पहल जिसका उद्देश्य व्यापक रूप से उपयोग किए जाने वाले open-source software में सुरक्षा खामियों को खोजने, सत्यापित करने और ठीक करने के तरीके को अधिक सख्त बनाना है। यह प्रयास लगभग 20 तकनीकी कंपनियों, AI labs और वित्तीय संस्थानों को एक सरल सिद्धांत के इर्द-गिर्द साथ लाता है: software vulnerability discovery की अर्थव्यवस्था बदल चुकी है, और attackers को बड़ा लाभ मिलने से पहले defenders को अधिक संगठित प्रतिक्रिया की जरूरत है।
घोषणा के अनुसार, Akrites इसलिए बनाया गया क्योंकि आधुनिक AI systems अब बड़े codebases को हफ्तों के बजाय मिनटों में inspect कर सकते हैं। यह गति महत्वपूर्ण है। Vulnerability discovery के लिए पहले दोनों पक्षों पर पर्याप्त expertise और समय की जरूरत होती थी, जिससे attackers और defenders के बीच एक मोटा-सा संतुलन बना रहता था। Akrites इस दृष्टि से शुरू होता है कि यह संतुलन बदल रहा है। यदि advanced code analysis व्यापक रूप से उपलब्ध हो जाती है, तो कम-कुशल attackers को ऐसे tools मिल सकते हैं जो उन्हें open-source ecosystem के patch करने से कहीं तेज़ गंभीर कमजोरियों का पता लगाने और उनका exploitation करने में मदद करें।
नई पहल का उद्देश्य उस अंतर को भरना है, जिसे Linux Foundation एक fragmented, duplicative security response model कहता है, उसे बदलकर। कई कंपनियों द्वारा अलग-अलग समान packages scan करने, overlapping reports file करने और maintainers को परस्पर-विरोधी patches भेजने के बजाय, Akrites एक shared process और एक single coordination layer प्रस्तावित करता है।
कौन शामिल है
घोषणा में नामित founding members में Amazon Web Services, Anthropic, Cisco, Citi, Google, IBM, JPMorganChase, Microsoft, NVIDIA, OpenAI, Red Hat, Rust Foundation, Vodafone और Zscaler शामिल हैं। यह roster इसलिए महत्वपूर्ण है क्योंकि इसमें open-source software के कुछ सबसे बड़े users, frontier AI systems बनाने वाली कई कंपनियां, और software supply-chain risk के सीधे संपर्क वाले बड़े संस्थान शामिल हैं।
समूह की संरचना यह भी संकेत देती है कि अब इस मुद्दे को कितनी व्यापकता से समझा जा रहा है। Open-source security अब केवल maintainers की संकीर्ण समस्या या back-office compliance issue नहीं मानी जाती। यह cloud providers, banks, enterprise software vendors, AI developers और infrastructure companies के लिए एक strategic concern बन गई है, जो सभी shared software components पर निर्भर हैं।
Akrites को इस साझा निर्भरता के लिए एक व्यावहारिक mechanism के रूप में रखा गया है। विचार केवल अधिक flaws ढूंढने का नहीं है। लक्ष्य एक ऐसा system बनाना है जो वास्तविक maintainers को credible reports पर कार्रवाई करने में मदद करे, बिना low-quality या duplicated findings के बोझ के।
एक साझा incident response team
Akrites के केंद्र में एक shared Security Incident Response Team, या SIRT है। इसकी भूमिका open-source projects के maintainers के लिए संपर्क के एकल बिंदु के रूप में काम करना है, बजाय इसके कि उन्हें कई संगठनों की समानांतर outreach की बाढ़ को संभालना पड़े। टीम incoming vulnerability reports की समीक्षा करेगी, duplicates हटाएगी, और fixes का समन्वय करेगी।
यह संरचना software security में बढ़ती operational समस्या को संबोधित करती है: अधिक scanning अपने आप बेहतर परिणाम नहीं देती। यदि कई संगठन स्वतंत्र रूप से एक ही issue का पता लगाते हैं, तो maintainers repeated submissions को छांटने में समय लगा सकते हैं, बजाय सबसे महत्वपूर्ण समस्याओं को ठीक करने के। Akrites का उद्देश्य इस noise को कम करना और validated, actionable vulnerabilities पर ध्यान केंद्रित करना है।
यह पहल एक standardized confidential disclosure process का भी उपयोग करेगी, जिसे आम तौर पर Coordinated Vulnerability Disclosure कहा जाता है। व्यवहार में इसका मतलब है कि flaws को तकनीकी विवरण सार्वजनिक होने से पहले निजी रूप से रिपोर्ट और उन पर काम किया जा सकता है, जिससे discovery और patching के बीच के समय में ज्ञात कमजोरियों के exploited होने का जोखिम कम होता है।
जब maintainers उपलब्ध नहीं होते
घोषणा का एक अधिक उल्लेखनीय पहलू abandoned या undermaintained projects के लिए Akrites की योजना है। Open-source ecosystems में कई packages ऐसे हैं जो व्यापक रूप से उपयोग में रहते हैं, भले ही उनके मूल maintainers के पास समय, funding या organizational support सीमित हो। ऐसे मामलों में, यहां तक कि confirmed vulnerabilities भी लंबे समय तक बनी रह सकती हैं क्योंकि कोई स्पष्ट रूप से fix तैयार करने और जारी करने की स्थिति में नहीं होता।
Akrites का कहना है कि वह abandoned projects के लिए आवश्यक patches स्वयं ship करेगा। यह एक महत्वपूर्ण वादा है क्योंकि यह पहल को केवल coordination से आगे ले जाकर, आवश्यकता पड़ने पर सीधे remediation तक पहुंचाता है। यह software supply chain की एक कठिन सच्चाई को भी दर्शाता है: critical infrastructure अक्सर ऐसे components पर निर्भर करता है जिनके पास उनकी अहमियत के अनुरूप staffing या institutional backing नहीं होती।
यदि Akrites ecosystem के उपेक्षित हिस्सों में vulnerability discovery और patch availability के बीच की देरी को सार्थक रूप से कम कर सके, तो यह open-source security के सबसे स्थायी weak points में से एक को बंद करने में मदद कर सकता है।
समय क्यों महत्वपूर्ण है
घोषणा में बताई गई urgency अमूर्त नहीं है। Source material में उद्धृत Endor Labs के chief executive Varun Badhwar ने कहा कि हाल के महीनों में सत्यापित open-source vulnerabilities की हजारों की संख्या में से पांच प्रतिशत से भी कम को patch किया गया है। अतिरिक्त संदर्भ के बिना भी, यह आंकड़ा remediation backlog के पैमाने को दर्शाता है जिसे Akrites संबोधित करने की कोशिश कर रहा है।
AI का पहलू इस मुद्दे को और तीखा बनाता है। यदि model-assisted analysis flaws को खोजने की दर को नाटकीय रूप से बढ़ा देती है, तो triage और patching भी अधिक efficient न होने पर backlog और खराब हो सकता है। Akrites मूलतः open-source security के response side को industrialize करने का प्रयास है, इससे पहले कि discovery tooling और तेज़ हो जाए।
इसका अर्थ यह नहीं कि AI को केवल एक खतरे के रूप में पेश किया गया है। अप्रत्यक्ष रूप से, यह पहल यह भी मानती है कि defenders पर दबाव डालने वाले उसी technological shift का सामना shared processes, pooled expertise और बेहतर coordination से किया जा सकता है। Akrites AI-era security tooling की अस्वीकृति से कम और यह सुनिश्चित करने के प्रयास से अधिक है कि remediation का human और organizational पक्ष उसके साथ तालमेल रख सके।
क्या collective defense scale कर सकती है, इसकी परीक्षा
Akrites का महत्व अंततः execution पर निर्भर करेगा। Reports को केंद्रीकृत करना, duplicates फ़िल्टर करना, confidential disclosure का समन्वय करना, और abandoned projects को patch करना, ये सभी अधिक noisy और तेज़ी से बदलते vulnerability environment के लिए तर्कसंगत प्रतिक्रियाएँ हैं। कठिन हिस्सा होगा maintainers के साथ trust बनाए रखना, सही issues को प्राथमिकता देना, और यह साबित करना कि एक cross-industry body पर्याप्त तेज़ी से काम कर सकती है।
फिर भी, यह पहल इसलिए अलग दिखती है क्योंकि यह open-source security को अलग-अलग घटनाओं की श्रृंखला के बजाय collective defense problem के रूप में देखती है। यह एक महत्वपूर्ण बदलाव है। Shared software पर सबसे अधिक निर्भर कंपनियां स्वीकार कर रही हैं कि fragmented reporting और duplicated effort अब पर्याप्त नहीं हैं, खासकर जब AI उच्च-प्रभाव वाले attacks की बाधा को कम कर सकता है।
यदि Akrites सफल होता है, तो इसकी विरासत इस बात में कम हो सकती है कि उसने कितनी vulnerabilities खोजीं, और इस बात में अधिक कि क्या उसने open-source world को गंभीर flaws पर कम noise, कम delay और attackers के लिए कम gaps के साथ प्रतिक्रिया देने में मदद की।
यह लेख The Decoder की रिपोर्टिंग पर आधारित है। मूल लेख पढ़ें.
Originally published on the-decoder.com