AI-translated from English; not yet reviewed by a fluent editor.

# اوپن سورس مینٹینرز Anthropic OSS Scanner میں کیسے اندراج کریں اور اس کی رپورٹس کی جانچ کریں

> Anthropic OSS Scanner کی اہلیت، اندراج، آف لائن build کی تیاری، اور انسانی جائزے سے محروم ماڈل سے تیار کردہ رپورٹس کی محفوظ توثیق پر دستاویزات پر مبنی رہنما۔

By BIG CHANGE Editorial

Published: 2026-10-09T17:01:09.330Z
Updated: 2026-10-09T17:01:09.330Z
Canonical: https://bigchange.ai/blog/anthropic-oss-scanner-maintainer-enrollment-triage-guide

![A seated maintainer studies a blank report sheet beside a dark, unbranded monitor.](https://bigchange.ai/api/media/file/anthropic-oss-scanner-maintainer-triage-hero-v1.png)
Conceptual illustration of a maintainer reviewing an unverified scanner report; it does not depict a real report, finding or test. AI-generated illustration by BIG CHANGE.

Anthropic کا OSS Scanner ایک مفت، رضاکارانہ سروس ہے جو منظور شدہ اوپن سورس پروجیکٹس کو وقتاً فوقتاً اپنے طاقتور ترین ماڈلز سے scan کرتی ہے۔ Anthropic اسے پروجیکٹس کے scan ہوتے ہی رپورٹس وصول کرنے کا تیز راستہ بتاتا ہے، جو اس کے انسانی جائزے والے coordinated disclosure عمل کے ساتھ چلتا ہے۔ رپورٹس ماڈلز بناتے اور انسانی جائزے کے بغیر بھیجتے ہیں۔ اس لیے اندراج صلاحیت کا فیصلہ ہے: پروجیکٹ کو ایسے مینٹینرز درکار ہیں جو سکیورٹی کے نتائج کی آزادانہ توثیق کر سکیں اور طے کریں کہ کیا درست کرنا ہے۔

یہ رہنما سکیورٹی کے لحاظ سے اہم اوپن سورس پروجیکٹس کے بنیادی مینٹینرز کے لیے ہے۔ اس میں دستاویزی اندراج کا طریقہ اور رپورٹ کو احتیاط سے سنبھالنے کا طریقہ بتایا گیا ہے۔ ہدایات 9 اکتوبر 2026 کو دیکھی گئی Anthropic کی دستاویزات پر مبنی ہیں۔ BIG CHANGE نے کوئی پروجیکٹ درج نہیں کیا، scanner نہیں چلایا، اور کسی vulnerability کو دوبارہ پیدا نہیں کیا۔

## پہلے طے کریں کہ آپ کا پروجیکٹ رپورٹس سنبھال سکتا ہے یا نہیں

Anthropic کہتا ہے کہ وہ ایسے قائم شدہ پروجیکٹس پر غور کرتا ہے جن کے بنیادی ڈھانچے یا صارفین کی سکیورٹی پر اہم اثرات ہوں۔ اس کے بتائے ہوئے اشاروں میں remote attacks سے exposure اور اس software پر منحصر صارفین یا دوسرے پروجیکٹس کی تعداد شامل ہے۔ درخواستیں الگ الگ دیکھی جاتی ہیں اور دستی طور پر جانچا جاتا ہے کہ درخواست گزار بنیادی مینٹینر ہے۔ Anthropic کے مطابق یہ سروس ان پروجیکٹس کے لیے ہے جو پہلے ہی تصدیق شدہ high اور critical severity رپورٹس سنبھال سکتے ہیں۔

pull request کھولنے سے پہلے اپنے پروجیکٹ کے شواہد سے ان سوالات کے جواب دیں:

1. کیا آپ بنیادی مینٹینر ہیں جو اندراج کی درخواست جمع کر سکتے اور خفیہ سکیورٹی رپورٹس وصول کر سکتے ہیں؟
2. کیا پروجیکٹ critical-impact معیار پر پورا اترتا ہے؟ کیا آپ بنیادی ڈھانچے یا صارفین کی سکیورٹی میں اس کا کردار، remote input سے exposure یا downstream استعمال دکھا سکتے ہیں؟
3. کیا آپ کے پاس اضافی غیر تصدیق شدہ رپورٹس کا جائزہ لینے، نتائج کو محفوظ طور پر دوبارہ پیدا کرنے، ضرورت پر disclosure کا رابطہ کرنے، اور fixes برقرار رکھنے کے لیے لوگ اور طریقۂ کار ہے؟
4. کیا آپ offline audit کے لیے ضروری dependencies اور tests سمیت بار بار بنائے جا سکنے والا build environment دے سکتے ہیں؟
5. کیا درج کردہ رابطہ پتہ حساس رپورٹس وصول کرنے کے لیے موزوں ہے؟ پروجیکٹ کی configuration عوامی ہے، اس لیے security alias یا ایسا دوسرا پتہ استعمال کریں جسے شائع کرنے پر آپ راضی ہوں۔

اگر آپ کی ٹیم رپورٹس کا فوری جائزہ نہیں لے سکتی، تو Anthropic کہتا ہے کہ اس کا موجودہ coordinated vulnerability disclosure عمل اس راستے کے ضرورت مند پروجیکٹس کو انسانی طور پر تصدیق شدہ رپورٹس دیتا رہے گا۔ OSS Scanner اضافی تیز راستہ ہے، آپ کے security عمل کا متبادل نہیں۔

## اندراج کی درخواست تیار کریں

آپ کو اپنا repository اور مینٹینر اختیار، ایک configuration file، اور build recipe درکار ہیں۔ اندراج کی درخواست Anthropic کے [`oss-scanner` repository](https://github.com/anthropics/oss-scanner) میں pull request کے ذریعے دی جاتی ہے، جس میں `projects/<project>/project.yaml` شامل کیا جاتا ہے۔ Anthropic کے [project template](https://github.com/anthropics/oss-scanner/blob/main/templates/project.yaml) سے شروع کریں اور جمع کرانے سے پہلے تازہ [OSS Scanner FAQ](https://red.anthropic.com/oss-scanner/) پڑھیں؛ repository کی ہدایات بدل سکتی ہیں۔

دستاویزات میں درج لازمی configuration fields یہ ہیں:

| Field | کیا فراہم کریں |
| --- | --- |
| `repo` | clone کرنے کے لیے HTTPS Git repository URL۔ Anthropic کا template revision pin کرنے کے لیے `#branch` یا `#tag` suffix کی اجازت دیتا ہے۔ |
| `primary_contact` | رپورٹس اور سوالات کے لیے ایک email address۔ configuration میں یہ عوامی ہوتا ہے۔ |
| Dockerfile کا مقام | repository کے لحاظ سے Dockerfile کا راستہ `project.yaml` میں، یا `Dockerfile` کے ساتھ رکھی گئی `project.yaml` نام کی file، اندراج repository میں۔ ان میں سے عین ایک اختیار دیں۔ |

اختیاری fields میں `auto_ccs`, `homepage`, `threat_model`, `pgp`, اور `disabled` شامل ہیں۔ Anthropic کہتا ہے کہ PGP public key ای میل سے بھیجی گئی رپورٹس کو encrypt کرتی ہے اور اسے `auto_ccs` کے ساتھ نہیں ملایا جا سکتا؛ PGP ترتیب دینے پر رپورٹس صرف `primary_contact` پر جاتی ہیں۔ ترتیب دیے گئے تمام email addresses کو عوامی سمجھیں۔ `disabled: true` اندراج برقرار رکھتے ہوئے رپورٹس روک دیتا ہے؛ پروجیکٹ directory ہٹانے سے اندراج واپس ہو جاتا ہے۔

### Offline audit کے لیے مفید build بنائیں

Dockerfile کو environment تیار کرنا، dependencies نصب کرنا اور پروجیکٹ build کرنا چاہیے۔ Anthropic کہتا ہے کہ ابتدائی build نیٹ ورک رسائی کے ساتھ چلتا ہے، مگر audit انٹرنیٹ کے بغیر ہوتا ہے۔ لہٰذا audit کے لیے درکار dependencies یا test assets Dockerfile کی ابتدائی تیاری کے دوران حاصل کرنا ضروری ہے۔

Anthropic مشورہ دیتا ہے کہ Dockerfile اپنے repository میں رکھیں تاکہ اندراج repository میں دوبارہ تبدیلی کیے بغیر اسے اپ ڈیٹ کر سکیں۔ threat model اختیاری ہے مگر اس کی پُرزور سفارش کی گئی ہے۔ اس سے واضح کریں کہ کون سا code اور input اہم ہے، کیا دائرے سے باہر ہے، پروجیکٹ severity کیسے طے کرتا ہے، findings کی تکرار کیسے ہٹائی جائے، اور مفید proof of concept یا ممکنہ patch کیسا ہو۔ یہ scanner کی رہنمائی ہے، رپورٹ کے درست ہونے کا ثبوت نہیں۔

جمع کرانے سے پہلے Anthropic دو checks تجویز کرتا ہے:

1. پروجیکٹ configuration جانچنے کے لیے `tools/validate.py` چلائیں۔
2. Dockerfile مقامی طور پر build اور test کریں۔ repository کا `tools/check <name>` scanner کی طرح image بناتا ہے اور مکمل image میں نیٹ ورک بند کرکے shell کھولتا ہے۔ Anthropic اپنی QEMU پر مبنی ترتیب کے لیے `tools/check --qemu <name>` بھی دستاویز کرتا ہے۔

یہ checks اندراج کی ہدایات میں اختیاری تجاویز ہیں، اس بات کا ثبوت نہیں کہ Anthropic پروجیکٹ قبول کرے گا یا آئندہ finding درست ہو گی۔ repository کہتا ہے کہ `tools/check` build کے دوران پروجیکٹ Dockerfile کو نیٹ ورک رسائی کے ساتھ چلاتا ہے۔ اس کا security note خبردار کرتا ہے کہ build آپ کے کمپیوٹر اور مقامی نیٹ ورک کی سروسز تک پہنچ سکتا ہے؛ قابلِ اعتماد Docker build کے لیے موزوں مشین یا الگ تھلگ ماحول استعمال کریں۔ عام مقامی check کے لیے Git، Docker، Python 3 اور PyYAML درکار ہیں۔ `--qemu` variant Docker کے بجائے x86-64 Linux اور QEMU استعمال کرتا ہے، ساتھ میں Git، Python 3 اور PyYAML بھی۔

## جمع کریں، پھر پروجیکٹ کے فیصلے کا انتظار کریں

پروجیکٹ configuration اور درکار Dockerfile یا اختیاری threat model شامل کرنے والا pull request کھولیں۔ اگر پروجیکٹ کی critical security اہمیت خود واضح نہیں تو مختصر وضاحت دیں۔ Anthropic بنیادی مینٹینر کی حیثیت دستی طور پر تصدیق کرتا ہے اور غیر یقینی ہونے پر دوسرے راستے سے پروجیکٹ سے رابطہ کر سکتا ہے۔

Anthropic کے عوامی اندراج مواد میں ہر معاملے کے مطابق فیصلے بیان ہیں؛ قبولیت کی ضمانت یا جواب کے وقت کا SLA نہیں۔ جمع شدہ pull request کو قبولیت نہ سمجھیں۔ قبول ہونے پر Anthropic پہلے پروجیکٹ scan کرتا ہے، پھر رپورٹس کا مجموعہ email کے ذریعے `primary_contact` اور ترتیب دیے گئے CC پتے پر بھیجتا ہے۔ بعد میں باقاعدہ scans کا منصوبہ ہے، مگر ان کی تعداد Anthropic کے پروجیکٹ pipeline اور پروجیکٹ کے پھیلاؤ پر منحصر ہو سکتی ہے۔

سروس بذاتِ خود مفت ہے۔ اہلیت کی تفصیل، container بنانے اور برقرار رکھنے، رپورٹس کی triage، reproduction، disclosure coordination اور remediation کے لیے پروجیکٹ کو پھر بھی مینٹینرز کا وقت دینا ہوگا۔

## ہر رپورٹ کو سراغ سمجھیں، فیصلہ نہیں

Anthropic کہتا ہے کہ رپورٹس میں خودکفیل reproducer، وضاحت، ممکن ہو تو bug کب متعارف ہوا یہ تلاش کرنے کے لیے bisection، اور دستیاب ہو تو ممکنہ patch شامل ہو سکتا ہے۔ رپورٹس ماڈلز بناتے ہیں، انسانی جائزے یا triage کے بغیر۔ لانچ مواد خبردار کرتا ہے کہ رپورٹس غلط ہو سکتی ہیں؛ Anthropic خاص طور پر کہتا ہے کہ severity بڑھا چڑھا کر بتائی جا سکتی ہے یا scanner پروجیکٹ کا threat model غلط سمجھ سکتا ہے۔ تجویز کردہ fix منظور شدہ fix نہیں۔

اپنا معمول کا security عمل استعمال کریں اور ہر finding کو رپورٹ کے اصل شواہد کی سطح تک محدود رکھیں:

1. **رپورٹ محفوظ رکھیں اور اس کا دائرہ محدود کریں۔**اصل email اور report identifier پروجیکٹ کے محدود security workflow میں رکھیں۔ جانچیں کہ متاثرہ repository، branch، commit، component اور دعویٰ کردہ threat model آپ کے پروجیکٹ سے میل کھاتے ہیں۔ رسائی صرف ضرورت مند افراد کو دیں۔
2. **کچھ چلانے سے پہلے دعویٰ پڑھیں۔**مبینہ خامی، متاثرہ code path، حملہ آور کے قابو میں input، درکار اجازتیں یا شرائط اور دعویٰ کردہ اثر معلوم کریں۔ ان کا اپنے architecture اور threat model سے موازنہ کریں۔ اگر رپورٹ میں قابلِ استعمال reproduction تفصیل نہیں تو غائب مراحل گھڑنے کے بجائے Anthropic سے وضاحت مانگیں۔
3. **اپنے قابو کے الگ تھلگ ماحول میں مسئلہ دوبارہ پیدا کریں۔**عارضی checkout یا VM، معلوم revision، اور دستاویزی reproducer استعمال کریں۔ ماڈل کا تجویز کردہ patch یا proof of concept production، حقیقی صارف کے data یا تیسرے فریق کے system پر نہ چلائیں۔ نیٹ ورک رسائی بند رکھیں، الا یہ کہ آپ کے اپنے test طریقے کو اس کی ضرورت ہو اور آپ نے رسائی جان بوجھ کر محدود کی ہو۔
4. **نتیجہ آزادانہ جانچیں۔**پروجیکٹ کے tests یا کم سے کم regression test سے رویے کی تصدیق کریں۔ دعویٰ کردہ متاثرہ versions اور آیا مسئلہ پروجیکٹ کی حقیقی trust boundaries میں پہنچ سکتا ہے، جانچیں۔ داخلی ریکارڈ میں “reproduced”، “ممکن مگر reproduced نہیں”، “duplicate”، اور “لاگو نہیں” الگ رکھیں۔
5. **Bisection اور patch کو تجاویز سمجھ کر دیکھیں۔**حوالہ دیے گئے commits اور code تبدیلیوں کی خود تصدیق کریں۔ ممکنہ patch صرف branch پر لگائیں، diff دیکھیں، متعلقہ tests چلائیں اور مناسب ہو تو regression test شامل کریں۔ صرف رپورٹ میں severity یا code ہونے کی وجہ سے merge نہ کریں۔
6. **Disclosure اور remediation میں رابطہ رکھیں۔**اپنی security policy اور متعلقہ ecosystem کے disclosure عمل پر عمل کریں۔ Anthropic کہتا ہے کہ غیر تصدیق شدہ OSS Scanner findings پر 90 دن کا coordinated-disclosure دور لاگو نہیں ہوتا اور Anthropic انہیں عوامی نہیں کرے گا۔ اگر بعد میں Anthropic اپنے CVD پروگرام کے ذریعے رپورٹ کو دستی طور پر validate کرے، تو FAQ کے مطابق انسانی تصدیق کی اطلاع سے 90 دن شروع ہو سکتے ہیں۔ اس سے آپ کی اپنی قانونی، معاہداتی یا ecosystem ذمہ داریاں ختم نہیں ہوتیں۔
7. **محدود اور واضح feedback بھیجیں۔**Anthropic مینٹینرز کو رپورٹ کے ای میل کا جواب دے کر feedback بھیجنے کی دعوت دیتا ہے۔ اگر finding غلط، duplicate، غلط ترجیح والی، یا threat model کو غلط سمجھنے والی ہو تو مخصوص نکتہ اور شواہد بتائیں تاکہ رپورٹ درست کی جا سکے۔

اگر آپ کی صلاحیت بدلے تو FAQ دو controls بتاتا ہے: رپورٹس روکنے کے لیے pull request میں `disabled: true` مقرر کریں، یا واپس جانے کے لیے پروجیکٹ directory ہٹا دیں۔ scanning بند سمجھنے سے پہلے repository میں تبدیلی کی تصدیق کریں۔

## Anthropic کے validation اعداد کیا دکھاتے ہیں اور کیا نہیں

Anthropic رپورٹ کرتا ہے کہ ماہر penetration testers نے 48 پروجیکٹس میں scanner کے ابتدائی ورژن کی 97 critical اور high-severity findings دیکھی۔ اس کے مطابق 85 اس کے CVD معیار پر پوری اتریں؛ باقی 12 میں سے 11 حقیقی تھیں مگر duplicate یا ایک دوسرے سے ملتی تھیں، اور ایک غلط تھی۔ Anthropic مینٹینر feedback کا بھی حوالہ دیتا اور 90% سے زیادہ true-positive شرح کی توقع بیان کرتا ہے۔

یہ Anthropic کے بتائے ہوئے validation نتائج اور توقعات ہیں، آزادانہ نقل یا نئی رپورٹ کی ضمانت نہیں۔ آزمودہ مجموعہ ابتدائی scanner outputs سے منتخب کیا گیا تھا اور اس میں 48 پروجیکٹس تھے؛ اس سے ثابت نہیں ہوتا کہ ہر آئندہ نتیجہ، severity rating یا patch درست ہوگا۔ کارآمد عملی نتیجہ محدود ہے: نظام رپورٹس جلد سامنے لا سکتا ہے، مگر validation، ترجیح اور fixes کی ذمہ داری مینٹینرز کی ہے۔

## بڑی تبدیلی

OSS Scanner اہل اوپن سورس مینٹینرز کو انسانی جائزے سے پہلے باقاعدہ، مفت، ماڈل سے تیار کردہ سکیورٹی رپورٹس حاصل کرنے کا اختیاری راستہ دیتا ہے۔ فیصلہ صرف یہ نہیں کہ مفت scan قبول کیا جائے؛ سوال یہ ہے کہ کیا پروجیکٹ غیر تصدیق شدہ findings کے تیز بہاؤ کو محفوظ طور پر سنبھال اور validate کر سکتا ہے۔

## ذرائع اور مزید مطالعہ

- [Anthropic OSS Scanner FAQ اور اندراج کی ہدایات](https://red.anthropic.com/oss-scanner/) — اہلیت، مینٹینر کی تصدیق، configuration fields، build کی ضروریات، رپورٹوں کی ترتیب، disclosure policy، اور opt-out controls۔
- [Anthropic کا `oss-scanner` repository](https://github.com/anthropics/oss-scanner) — اندراج pull request کا طریقہ، validation اور مقامی build-check tools، اور security considerations۔
- [پروجیکٹ configuration template](https://github.com/anthropics/oss-scanner/blob/main/templates/project.yaml) — repository، رابطہ، Dockerfile، threat model، encryption اور رپورٹس روکنے کے لیے موجودہ field مثالیں۔
- [Anthropic: “اوپن سورس سافٹ ویئر کے لیے اختیاری vulnerability-finding سروس کا آغاز”](https://www.anthropic.com/research/launching-opt-in-vuln-finding-service-for-open-source) — آغاز کی تفصیل، ماڈل سے تیار کردہ رپورٹوں کا مواد اور Anthropic سے منسوب ابتدائی validation اعداد۔
- [Anthropic: “Anthropic Cyber Mission کا تعارف”](https://www.anthropic.com/news/anthropic-cyber-mission) — وسیع پروگرام کا پس منظر اور OSS Scanner رپورٹوں اور انسانی جائزے والے disclosure کا فرق۔

*9 اکتوبر 2026 کو دیکھی گئی دستاویزات پر مبنی رہنما۔ BIG CHANGE نے اندراج نہیں کیا، scan نہیں چلایا، اور vulnerability دوبارہ پیدا نہیں کی۔*

## Sources

- [Anthropic OSS Scanner FAQ اور اندراج کی ہدایات](https://red.anthropic.com/oss-scanner/) — اہلیت، مینٹینر کی تصدیق، اندراج fields، رپورٹوں کے مواد اور ترتیب، disclosure، توقف اور واپسی پر آفیشل FAQ۔
- [Anthropic OSS Scanner repository](https://github.com/anthropics/oss-scanner) — اندراج کا آفیشل README، جس میں configuration، build/offline audit کی حد، مقامی validation tools، prerequisites اور Docker security considerations بیان ہیں۔
- [Anthropic OSS Scanner project.yaml template](https://github.com/anthropics/oss-scanner/blob/main/templates/project.yaml) — درکار اور اختیاری configuration fields کی آفیشل مثال۔
- [اوپن سورس سافٹ ویئر کے لیے اختیاری vulnerability-finding سروس کا آغاز](https://www.anthropic.com/research/launching-opt-in-vuln-finding-service-for-open-source) — ماڈل سے تیار کردہ رپورٹوں اور ان کے مواد، case-by-case اندراج اور vendor کی بتائی ہوئی ابتدائی validation statistics پر Anthropic کا launch account۔
- [Anthropic Cyber Mission کا تعارف](https://www.anthropic.com/news/anthropic-cyber-mission) — وسیع Cyber Mission میں OSS Scanner اور انسانی جائزے والے CVD reporting سے اس کے فرق پر Anthropic کا اعلان۔