ओपन-सोर्स मेंटेनर Anthropic OSS Scanner में कैसे नामांकन करें और उसकी रिपोर्टों की छँटाई करें

Anthropic का OSS Scanner एक निःशुल्क, स्वैच्छिक सेवा है जो स्वीकृत ओपन-सोर्स परियोजनाओं को समय-समय पर अपने सबसे सक्षम मॉडलों से स्कैन करती है। Anthropic इसे परियोजनाओं के स्कैन होते ही रिपोर्ट पाने का तेज़ रास्ता बताता है, जो उसकी मानव-समीक्षित समन्वित प्रकटीकरण प्रक्रिया के साथ चलता है। रिपोर्ट मॉडल बनाते हैं और मानव समीक्षा के बिना भेजी जाती हैं। इसलिए नामांकन क्षमता से जुड़ा निर्णय है: परियोजना को ऐसे मेंटेनरों की आवश्यकता है जो सुरक्षा निष्कर्षों को स्वतंत्र रूप से सत्यापित कर सकें और तय कर सकें कि क्या ठीक करना है।

यह मार्गदर्शिका सुरक्षा-महत्वपूर्ण ओपन-सोर्स परियोजनाओं के मुख्य मेंटेनरों के लिए है। इसमें दस्तावेज़ीकृत नामांकन प्रक्रिया और किसी रिपोर्ट को सावधानी से संभालने का तरीका बताया गया है। निर्देश 9 अक्टूबर 2026 को देखे गए Anthropic दस्तावेज़ों पर आधारित हैं। BIG CHANGE ने कोई परियोजना नामांकित नहीं की, स्कैनर नहीं चलाया और किसी भेद्यता को दोहराया नहीं।

पहले तय करें कि आपकी परियोजना रिपोर्ट संभाल सकती है या नहीं

Anthropic कहता है कि वह उन स्थापित परियोजनाओं पर विचार करता है जिनका बुनियादी ढाँचे या उपयोगकर्ता सुरक्षा पर गंभीर प्रभाव हो। उसके बताए संकेतों में दूरस्थ हमलों के संपर्क में होना और सॉफ़्टवेयर पर निर्भर उपयोगकर्ताओं या अन्य परियोजनाओं की संख्या शामिल है। अनुरोधों की अलग-अलग समीक्षा होती है और आवेदक मुख्य मेंटेनर है या नहीं, यह मैन्युअल रूप से जाँचा जाता है। Anthropic के अनुसार, यह सेवा उन परियोजनाओं के लिए है जो पहले से सत्यापित उच्च और गंभीर स्तर की रिपोर्टें संभाल सकती हैं।

पुल रिक्वेस्ट खोलने से पहले अपनी परियोजना के प्रमाणों के आधार पर इन सवालों के जवाब दें:

1. क्या आप ऐसे मुख्य मेंटेनर हैं जो नामांकन अनुरोध भेज सकते हैं और गोपनीय सुरक्षा रिपोर्टें प्राप्त कर सकते हैं?
2. क्या परियोजना गंभीर प्रभाव के मानदंड पर खरी उतरती है? क्या आप बुनियादी ढाँचे या उपयोगकर्ता सुरक्षा में इसकी भूमिका, दूरस्थ इनपुट के संपर्क या डाउनस्ट्रीम उपयोग का प्रमाण दे सकते हैं?
3. क्या आपके पास अतिरिक्त अप्रमाणित रिपोर्टों की समीक्षा, निष्कर्षों को सुरक्षित रूप से दोहराने, ज़रूरत पड़ने पर प्रकटीकरण का समन्वय करने और सुधार बनाए रखने के लिए लोग और प्रक्रिया हैं?
4. क्या आप ऑफलाइन ऑडिट के लिए आवश्यक निर्भरताओं और परीक्षणों सहित दोहराने योग्य बिल्ड वातावरण दे सकते हैं?
5. क्या सूचीबद्ध संपर्क पता संवेदनशील रिपोर्टें प्राप्त करने के लिए उपयुक्त है? परियोजना का कॉन्फ़िगरेशन सार्वजनिक है, इसलिए सुरक्षा उपनाम या ऐसा दूसरा पता इस्तेमाल करें जिसे प्रकाशित करने में आपको आपत्ति न हो।

यदि आपकी टीम रिपोर्टों की शीघ्र समीक्षा नहीं कर सकती, तो Anthropic का कहना है कि उसकी मौजूदा समन्वित भेद्यता प्रकटीकरण प्रक्रिया उस रास्ते की ज़रूरत वाली परियोजनाओं को मानव-सत्यापित रिपोर्टें देती रहेगी। OSS Scanner एक अतिरिक्त तेज़ रास्ता है, आपकी सुरक्षा प्रक्रिया का विकल्प नहीं।

नामांकन अनुरोध तैयार करें

आपको अपना रिपॉज़िटरी और मेंटेनर अधिकार, एक कॉन्फ़िगरेशन फ़ाइल और बिल्ड रेसिपी चाहिए। नामांकन का अनुरोध Anthropic के oss-scanner रिपॉज़िटरी, जोड़कर projects/<project>/project.yaml. Anthropic के प्रोजेक्ट टेम्पलेट से शुरू करें और मौजूदा OSS Scanner FAQ भेजने से पहले पढ़ें; रिपॉज़िटरी के निर्देश बदल सकते हैं।

दस्तावेज़ में अनिवार्य कॉन्फ़िगरेशन फ़ील्ड ये हैं:

वैकल्पिक फ़ील्डों में auto_ccs, homepage, threat_model, pgp, और disabled शामिल हैं। Anthropic का कहना है कि PGP सार्वजनिक कुंजी ईमेल रिपोर्टों को एन्क्रिप्ट करती है और इसे auto_ccs के साथ नहीं जोड़ा जा सकता; PGP सेट होने पर रिपोर्ट केवल primary_contact को भेजी जाती हैं। कॉन्फ़िगर किए गए सभी ईमेल पतों को सार्वजनिक मानें। disabled: true नामांकन बनाए रखते हुए रिपोर्टें रोकता है; परियोजना निर्देशिका हटाने से नामांकन वापस हो जाता है।

ऑफलाइन ऑडिट के लिए उपयोगी बिल्ड तैयार करें

Dockerfile को वातावरण सेट करना, निर्भरताएँ स्थापित करना और परियोजना बिल्ड करनी चाहिए। Anthropic के अनुसार शुरुआती बिल्ड नेटवर्क पहुँच के साथ चलता है, लेकिन ऑडिट इंटरनेट पहुँच के बिना होता है। इसलिए ऑडिट के लिए आवश्यक निर्भरताएँ या परीक्षण सामग्री Dockerfile के शुरुआती सेटअप के दौरान डाउनलोड करनी होंगी।

Anthropic Dockerfile को अपने रिपॉज़िटरी में रखने की सलाह देता है, जहाँ आप नामांकन रिपॉज़िटरी में फिर से बदलाव किए बिना उसे अपडेट कर सकते हैं। थ्रेट मॉडल वैकल्पिक है, लेकिन इसकी प्रबल अनुशंसा की जाती है। इससे बताएँ कि कौन-सा कोड और इनपुट महत्वपूर्ण हैं, क्या दायरे से बाहर है, परियोजना गंभीरता कैसे आँकती है, निष्कर्षों को डुप्लिकेट-मुक्त कैसे किया जाना चाहिए और उपयोगी प्रूफ़-ऑफ़-कॉन्सेप्ट या संभावित पैच कैसा दिखेगा। यह स्कैनर के लिए मार्गदर्शन है, रिपोर्ट के सही होने का प्रमाण नहीं।

भेजने से पहले Anthropic दो जाँचों की सलाह देता है:

1. परियोजना कॉन्फ़िगरेशन जाँचने के लिए tools/validate.py चलाएँ।
2. Dockerfile को स्थानीय रूप से बिल्ड और टेस्ट करें। रिपॉज़िटरी का tools/check <name> स्कैनर की तरह इमेज बनाता है और पूरी बनी इमेज में नेटवर्क बंद करके शेल खोलता है। Anthropic अपने QEMU-आधारित सेटअप के लिए tools/check --qemu <name> भी दस्तावेज़ीकृत करता है।

ये जाँचें नामांकन निर्देशों में वैकल्पिक सुझाव हैं; ये इस बात का प्रमाण नहीं कि Anthropic परियोजना स्वीकार करेगा या बाद का निष्कर्ष सही होगा। रिपॉज़िटरी कहता है कि tools/check बिल्ड के दौरान परियोजना Dockerfile को नेटवर्क पहुँच के साथ चलाता है। उसकी सुरक्षा टिप्पणी चेताती है कि बिल्ड आपके कंप्यूटर और स्थानीय नेटवर्क की सेवाओं तक पहुँच सकता है; भरोसेमंद Docker बिल्ड के लिए उपयुक्त मशीन या पृथक वातावरण इस्तेमाल करें। मानक स्थानीय जाँच के लिए Git, Docker, Python 3 और PyYAML चाहिए। --qemu विकल्प Docker की जगह x86-64 Linux और QEMU इस्तेमाल करता है; Git, Python 3 और PyYAML भी आवश्यक हैं।

भेजें, फिर परियोजना के निर्णय की प्रतीक्षा करें

परियोजना कॉन्फ़िगरेशन और आवश्यक Dockerfile या वैकल्पिक थ्रेट मॉडल जोड़कर पुल रिक्वेस्ट खोलें। यदि परियोजना का गंभीर सुरक्षा महत्व अपने आप स्पष्ट न हो, तो संक्षिप्त विवरण दें। Anthropic मुख्य-मेंटेनर स्थिति की मैन्युअल पुष्टि करता है और अनिश्चित होने पर दूसरे रास्ते से परियोजना से संपर्क कर सकता है।

Anthropic की सार्वजनिक नामांकन सामग्री अलग-अलग मामलों में निर्णय का वर्णन करती है; स्वीकृति की गारंटी या जवाब की समयसीमा नहीं देती। भेजे गए पुल रिक्वेस्ट को स्वीकृति न मानें। स्वीकार किए जाने पर Anthropic कहता है कि वह पहले परियोजना स्कैन करेगा, फिर रिपोर्टों का पैकेट ईमेल से primary_contact और कॉन्फ़िगर किए गए CC पते पर भेजेगा। आगे नियमित स्कैन की योजना है, लेकिन उनकी आवृत्ति परियोजना पाइपलाइन और परियोजना कितनी व्यापक रूप से उपयोग होती है, इस पर निर्भर कर सकती है।

सेवा स्वयं निःशुल्क है। परियोजना को पात्रता विवरण, कंटेनर बनाने और बनाए रखने, रिपोर्ट छाँटने, निष्कर्ष दोहराने, प्रकटीकरण समन्वय और सुधार के लिए मेंटेनर समय देना होगा।

हर रिपोर्ट को सुराग मानें, अंतिम फैसला नहीं

Anthropic का कहना है कि रिपोर्टों में स्वयं-पूर्ण रीप्रोड्यूसर, विवरण, जहाँ संभव हो बग कब जुड़ा यह खोजने के लिए बाइसेक्शन, और उपलब्ध होने पर संभावित पैच शामिल हो सकता है। रिपोर्टें बिना मानव समीक्षा या छँटाई के मॉडल बनाते हैं। लॉन्च सामग्री चेताती है कि रिपोर्टें गलत हो सकती हैं; Anthropic खास तौर पर कहता है कि गंभीरता बढ़ा-चढ़ाकर बताई जा सकती है या स्कैनर परियोजना का थ्रेट मॉडल गलत समझ सकता है। सुझाया गया सुधार स्वीकृत सुधार नहीं है।

अपनी सामान्य सुरक्षा प्रक्रिया अपनाएँ और हर निष्कर्ष को रिपोर्ट के वास्तविक प्रमाण स्तर तक सीमित रखें:

1. रिपोर्ट सुरक्षित रखें और उसका दायरा सीमित करें।मूल ईमेल और रिपोर्ट पहचानकर्ता को परियोजना के प्रतिबंधित सुरक्षा कार्यप्रवाह में रखें। जाँचें कि प्रभावित रिपॉज़िटरी, ब्रांच, कमिट, घटक और दावा किया गया थ्रेट मॉडल आपकी परियोजना से मेल खाते हैं। पहुँच केवल ज़रूरतमंद लोगों तक सीमित रखें।
2. कुछ भी चलाने से पहले दावे को पढ़ें।कथित दोष, प्रभावित कोड पथ, हमलावर-नियंत्रित इनपुट, आवश्यक अनुमतियाँ या शर्तें और कथित प्रभाव पहचानें। इन्हें अपनी आर्किटेक्चर और थ्रेट मॉडल से मिलाएँ। यदि रिपोर्ट में उपयोगी पुनरुत्पादन विवरण नहीं हैं, तो छूटे चरण गढ़ने के बजाय Anthropic से स्पष्टीकरण माँगें।
3. अपने नियंत्रण वाले पृथक वातावरण में समस्या दोहराएँ।फेंके जा सकने वाले checkout या VM, ज्ञात रिविज़न और दस्तावेज़ीकृत रीप्रोड्यूसर का उपयोग करें। मॉडल-सुझाया पैच या प्रूफ़-ऑफ़-कॉन्सेप्ट उत्पादन, वास्तविक उपयोगकर्ता डेटा या तीसरे पक्ष के सिस्टम पर न चलाएँ। नेटवर्क बंद रखें, जब तक आपकी अपनी परीक्षण प्रक्रिया को इसकी आवश्यकता न हो और आपने पहुँच जानबूझकर सीमित न की हो।
4. परिणाम स्वतंत्र रूप से जाँचें।परियोजना के परीक्षणों या न्यूनतम रिग्रेशन टेस्ट से व्यवहार की पुष्टि करें। कथित प्रभावित संस्करण और परियोजना की वास्तविक ट्रस्ट सीमाओं में समस्या तक पहुँचना संभव है या नहीं, जाँचें। आंतरिक रिकॉर्ड में “दोहराया”, “संभव लेकिन दोहराया नहीं”, “डुप्लिकेट” और “लागू नहीं” अलग रखें।
5. बाइसेक्शन और पैच को प्रस्ताव की तरह जाँचें।उद्धृत कमिट और कोड बदलाव स्वयं सत्यापित करें। संभावित पैच केवल ब्रांच पर लागू करें, diff देखें, संबंधित परीक्षण चलाएँ और जहाँ उचित हो रिग्रेशन टेस्ट जोड़ें। केवल इसलिए merge न करें कि रिपोर्ट गंभीरता बताती है या कोड देती है।
6. प्रकटीकरण और सुधार का समन्वय करें।अपनी सुरक्षा नीति और संबंधित पारिस्थितिकी तंत्र की प्रकटीकरण प्रक्रिया अपनाएँ। Anthropic कहता है कि अप्रमाणित OSS Scanner निष्कर्षों पर 90-दिन की समन्वित प्रकटीकरण अवधि लागू नहीं होती और Anthropic उन्हें सार्वजनिक नहीं करेगा। यदि Anthropic बाद में CVD कार्यक्रम के ज़रिए किसी रिपोर्ट को मैन्युअल रूप से सत्यापित करता है, तो FAQ के अनुसार 90-दिन की अवधि मानव सत्यापन की सूचना से शुरू हो सकती है। इससे आपकी कानूनी, अनुबंधीय या पारिस्थितिकी तंत्र की जिम्मेदारियाँ समाप्त नहीं होतीं।
7. सीमित और ठोस प्रतिक्रिया दें।Anthropic मेंटेनरों को रिपोर्ट ईमेल का जवाब देकर प्रतिक्रिया देने के लिए आमंत्रित करता है। यदि कोई निष्कर्ष अमान्य, डुप्लिकेट, गलत प्राथमिकता वाला या थ्रेट मॉडल को गलत समझने वाला हो, तो विशिष्ट बिंदु और प्रमाण बताएँ ताकि रिपोर्ट सुधारी जा सके।

यदि आपकी क्षमता बदलती है, तो FAQ दो नियंत्रण बताता है: रिपोर्ट रोकने के लिए पुल रिक्वेस्ट में disabled: true सेट करें, या नामांकन वापस लेने के लिए परियोजना निर्देशिका हटाएँ। स्कैन रुक गया मानने से पहले रिपॉज़िटरी के ज़रिए बदलाव की पुष्टि करें।

Anthropic के सत्यापन आँकड़े क्या दिखाते हैं—और क्या नहीं

Anthropic रिपोर्ट करता है कि विशेषज्ञ पेनेट्रेशन टेस्टरों ने 48 परियोजनाओं में शुरुआती स्कैनर संस्करण के 97 गंभीर और उच्च-गंभीरता वाले निष्कर्ष जाँचे। Anthropic कहता है कि 85 उसके CVD मानदंड पर खरे उतरे; शेष 12 में से 11 वास्तविक थे लेकिन डुप्लिकेट या एक-दूसरे से मिलते-जुलते थे, और एक अमान्य था। Anthropic मेंटेनर प्रतिक्रिया का भी उल्लेख करता है और 90% से अधिक true-positive दर की अपेक्षा बताता है।

ये Anthropic द्वारा बताए गए सत्यापन परिणाम और अपेक्षा हैं, स्वतंत्र दोहराव या किसी नई रिपोर्ट की गारंटी नहीं। परीक्षण समूह शुरुआती स्कैनर आउटपुट से चुना गया था और 48 परियोजनाओं तक सीमित था; इससे यह सिद्ध नहीं होता कि हर भविष्य का परिणाम, गंभीरता रेटिंग या पैच सही होगा। उपयोगी संचालनात्मक निष्कर्ष सीमित है: प्रणाली रिपोर्ट जल्दी सामने ला सकती है, लेकिन सत्यापन, प्राथमिकता और सुधार की जिम्मेदारी मेंटेनरों की ही रहती है।

बड़ा बदलाव

OSS Scanner पात्र ओपन-सोर्स मेंटेनरों के लिए मानव समीक्षा से पहले नियमित, निःशुल्क, मॉडल-जनित सुरक्षा रिपोर्ट पाने का स्वैच्छिक रास्ता बनाता है। निर्णय केवल यह नहीं कि मुफ्त स्कैन स्वीकार करें या नहीं; सवाल यह है कि क्या परियोजना अप्रमाणित निष्कर्षों की तेज़ धारा को सुरक्षित रूप से संभाल और सत्यापित कर सकती है।

स्रोत और आगे पढ़ें

• Anthropic OSS Scanner FAQ और नामांकन निर्देश — पात्रता, मेंटेनर सत्यापन, कॉन्फ़िगरेशन फ़ील्ड, बिल्ड आवश्यकताएँ, रिपोर्ट आवृत्ति, प्रकटीकरण नीति और बाहर निकलने के नियंत्रण।
• Anthropic का oss-scanner रिपॉज़िटरी — नामांकन पुल रिक्वेस्ट प्रक्रिया, सत्यापन और स्थानीय बिल्ड-जाँच उपकरण तथा सुरक्षा विचार।
• परियोजना कॉन्फ़िगरेशन टेम्पलेट — रिपॉज़िटरी, संपर्क, Dockerfile, थ्रेट मॉडल, एन्क्रिप्शन और रिपोर्ट रोकने के मौजूदा फ़ील्ड उदाहरण।
• Anthropic: “ओपन-सोर्स सॉफ़्टवेयर के लिए वैकल्पिक भेद्यता-खोज सेवा शुरू करना” — लॉन्च विवरण, मॉडल-जनित रिपोर्टों की सामग्री और Anthropic से जुड़े शुरुआती सत्यापन आँकड़े।
• Anthropic: “Anthropic Cyber Mission का परिचय” — व्यापक कार्यक्रम का संदर्भ और OSS Scanner रिपोर्टों तथा मानव-समीक्षित प्रकटीकरण के बीच अंतर।

9 अक्टूबर 2026 को देखे गए दस्तावेज़ों पर आधारित मार्गदर्शिका। BIG CHANGE ने नामांकन नहीं किया, स्कैन नहीं चलाया और भेद्यता नहीं दोहराई।