Defending Code Reference Harness

क्लॉड माइथोस प्रीव्यू लॉन्च करने के बाद से कई संगठनों में सुरक्षा टीमों के साथ साझेदारी से हमारी सीख के आधार पर, क्लॉड के साथ स्वायत्त भेद्यता खोज और निवारण के लिए एक संदर्भ कार्यान्वयन। इन सीखों और सर्वोत्तम प्रथाओं का विवरण के लिए, संबंधित ब्लॉग पोस्ट देखें (blog-post.md में भी उपलब्ध)। उसी रीकॉन → फाइंड → ट्राइएज → रिपोर्ट → पैच लूप के हल्के SDK-केवल वॉकथ्रू के लिए, संगत कुकबुक देखें।

यह रिपॉजिटरी अनुरक्षित नहीं है और योगदान स्वीकार नहीं करती है।

🔒 एक प्रबंधित विकल्प चाहते हैं? Anthropic क्लॉड सिक्योरिटी प्रदान करता है, जो एक होस्टेड उत्पाद है जो आपके सोर्स कोड में कई प्रोजेक्ट्स में भेद्यताओं को ढूंढता और ठीक करता है। क्लॉड सिक्योरिटी आपके रिपॉजिटरी को भेद्यताओं के लिए स्कैन करता है, गलत सकारात्मकता कम करने के लिए एक बहु-चरणीय सत्यापन पाइपलाइन लागू करता है, और आपको उनके जीवनचक्र के माध्यम से निष्कर्षों को प्रबंधित करने देता है: ट्राइएज, फिक्स सत्यापन, और तेजी से फिक्स निर्माण।

यह रिपॉजिटरी क्लॉड का उपयोग करके भेद्यताएं खोजने के लिए सामान्य सर्वोत्तम प्रथाओं पर आधारित एक ओपन-सोर्स संदर्भ कार्यान्वयन है। आप इसका उपयोग अपनी स्वयं की भेद्यता खोज पाइपलाइन बनाने, तर्क को अनुकूलित करने के लिए कर सकते हैं, और यह क्लॉड एपीआई तक आपकी जो भी पहुंच है (बेडरॉक, वर्टेक्स या एज़्योर सहित) के साथ इस्तेमाल किया जा सकता है।

विषय-सूची

• क्लॉड कोड स्किल्स: /quickstart, /threat-model, /vuln-scan, /triage, /patch, /customize: इंटरैक्टिव स्कोपिंग, स्कैनिंग, ट्राइएज, और पैचिंग। क्लॉड कोड में इस रिपॉजिटरी को खोलें और अभिविन्यास के लिए /quickstart चलाएं।
• harness/: स्वायत्त संदर्भ पाइपलाइन (रीकॉन → फाइंड → वेरिफाई → रिपोर्ट → पैच), जो डॉकर और ASAN का उपयोग करके C/C++ मेमोरी भेद्यताओं को खोजने के लिए कॉन्फ़िगर की गई है। यह हार्नेस एक संदर्भ है, उत्पाद नहीं। सामान्य आकार, प्रॉम्प्ट्स और सैंडबॉक्सिंग पुनः प्रयोग योग्य हैं, लेकिन हार्नेस हर कोडबेस पर तुरंत काम नहीं करेगा। इसे अपनी भाषा, डिटेक्टर या भेद्यता वर्ग में स्थानांतरित करने के लिए /customize चलाएं।

⚠️ सुरक्षा: /quickstart, /threat-model, /vuln-scan, और /triage केवल फ़ाइलें पढ़ते और लिखते हैं। स्थैतिक निष्कर्षों (TRIAGE.json या VULN-FINDINGS.json) पर /patch चलाना भी केवल पढ़ने-लिखने वाला है। /customize हार्नेस कोड को संपादित करता है और सत्यापन कमांड चलाता है। ये सभी स्किल्स बिना सैंडबॉक्स के चलाना सुरक्षित हैं, जब तक आप क्लॉड कोड में प्रत्येक टूल उपयोग की समीक्षा और अनुमोदन करते हैं। स्वायत्त संदर्भ पाइपलाइन (पाइपलाइन परिणामों पर /patch सहित) लक्ष्य कोड निष्पादित करती है, इसलिए यह स्पष्ट रूप से ओवरराइड किए जाने तक gVisor सैंडबॉक्स के बाहर चलने से इनकार करती है। सेटअप करने के लिए, scripts/setup_sandbox.sh एक बार चलाएं, फिर पाइपलाइन को bin/vp-sandboxed के माध्यम से शुरू करें। अधिक विवरण के लिए docs/security.md और docs/agent-sandbox.md देखें।

शुरुआत करना

git clone https://github.com/anthropics/defending-code-reference-harness
cd defending-code-reference-harness
claude

# 30-sec intro + guided first run on the canary target
> /quickstart

> /quickstart how do I port the pipeline to Java?
> /quickstart how do I triage all these bugs?

आगे की पढ़ाई

• ब्लॉग पोस्ट · सीख + सर्वोत्तम प्रथाओं वाली संबंधित ब्लॉग पोस्ट
• पाइपलाइन · यह कैसे काम करती है: आरेख, चरण, CLI फ़्लैग
• सुरक्षा · सैंडबॉक्सिंग, क्या माउंट न करें
• एजेंट सैंडबॉक्स · प्रत्येक एजेंट के लिए gVisor अलगाव + ईग्रेस अनुमति-सूची
• कस्टमाइज़ · मेरे स्टैक में पोर्ट करें; कौन सी फ़ाइलें बदलती हैं और क्यों
• पैचिंग · सत्यापित क्रैश के लिए फिक्स उत्पन्न करें और सत्यापित करें
• समस्या निवारण · डुप्लिकेट, दर सीमाएं, सबएजेंट मॉडल पिनिंग
• सुरक्षा उपाय · खतरनाक साइबर कार्य के लिए अवरोध

रैंप-अप

जिन सुरक्षा टीमों के साथ हमने साझेदारी की है, उनमें सबसे सफल वे हैं जिन्होंने सबसे तेज़ी से व्यावहारिक कार्य शुरू किया। हालाँकि सही पाइपलाइन डिजाइन करने में महीनों बिताना आकर्षक है, हम दिन 1 पर छोटी शुरुआत करने और सीख आने पर वहाँ से आगे बढ़ने की सलाह देते हैं। नीचे दिए गए चरण उसी पैटर्न का अनुसरण करते हैं और जो हमने देखा है उसके आधार पर एक महत्वाकांक्षी (लेकिन उचित) गति निर्धारित करते हैं।

चरण 1 (दिन 1): एक थ्रेट मॉडल बनाएं और अपना पहला स्टैटिक स्कैन + ट्राइएज चलाएं

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

प्रासंगिक स्किल्स आपके रिपॉजिटरी में केवल फ़ाइलें पढ़ते और लिखते हैं। जब तक आप क्लॉड कोड को इंटरैक्टिव रूप से चलाते हैं और प्रत्येक टूल उपयोग को अनुमोदित करते हैं, किसी सैंडबॉक्स की आवश्यकता नहीं है।

# Pin every subagent to the model you want
export CLAUDE_CODE_SUBAGENT_MODEL=<model-id>
claude

# 0. intro + guided first run
> /quickstart

# 1. Build a threat model (aim before you shoot)
> /threat-model bootstrap targets/canary

# 2. Run a static scan, scoped by that threat model
> /vuln-scan targets/canary

# 3. Verify, dedupe, and rank what came back
> /triage targets/canary/VULN-FINDINGS.json

# 4. Generate candidate fixes for the verified findings
> /patch ./TRIAGE.json --repo targets/canary

यह प्रवाह THREAT_MODEL.md, VULN-FINDINGS.{json,md}, TRIAGE.{json,md} और PATCHES/ उत्पन्न करता है।

चरण 1 में उत्पन्न भेद्यता उम्मीदवार स्रोत की क्लॉड की स्टैटिक समीक्षा से आते हैं (कुछ भी बनाया या चलाया नहीं जाता), इसलिए किसी भी गैर-कैनरी लक्ष्य पर अधिक गलत सकारात्मकता की उम्मीद करें। चरण 2 में, आप निष्पादन-सत्यापित निष्कर्ष तैयार करेंगे।

नोट: कैनरी लक्ष्य पर, /triage स्कैन के निष्कर्षों को गलत सकारात्मक के रूप में खारिज कर सकता है। entry.c स्वयं को जानबूझकर कमजोर डेमो कोड घोषित करता है, और /triage परीक्षण / फिक्स्चर कोड में बग्स को सही ढंग से बाहर करता है। पूर्ण पुष्टि / डीडुप / गलत सकारात्मक प्रवाह देखने के लिए, इसे क्यूरेटेड फिक्स्चर पर चलाएं (/triage .claude/skills/triage/fixtures/canary-findings.json --repo targets/canary) या चरण 1 स्किल्स को अपने स्वयं के कोड पर इंगित करें।

चरण 2 (दिन 2): किसी C/C++ लाइब्रेरी पर संदर्भ पाइपलाइन चलाएं

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

पाइपलाइन चलाना सरल है:

# One-time setup
python3 -m venv .venv && .venv/bin/pip install -e .
./scripts/setup_sandbox.sh   # installs gVisor, builds the agent images, and verifies isolation; note: requires Docker
export ANTHROPIC_API_KEY=sk-ant-...   # or CLAUDE_CODE_OAUTH_TOKEN, or Bedrock — see docs/agent-sandbox.md

# Run the recon → find → verify → report loop
bin/vp-sandboxed run drlibs --model <model-id> --runs 3 --parallel --stream --auto-focus
# Generate a candidate patch for each finding
bin/vp-sandboxed patch results/drlibs/<timestamp>/ --model <model-id>

# Or, ask Claude Code to launch the pipeline and watch the run for you
claude
> run the pipeline on drlibs and explain findings as they come

लूप के परिणाम results/drlibs/<timestamp>/ निर्देशिका में आते हैं। --stream फ़्लैग के साथ, पहली रिपोर्ट मिनटों में reports/bug_NN/ के अंतर्गत दिखाई देगी।

⚠️ run स्वायत्त एजेंटों को जन्म देता है। पाइपलाइन प्रत्येक एजेंट को gVisor कंटेनर के अंदर चलाती है, जिसमें क्लॉड एपीआई तक ईग्रेस प्रतिबंधित है। एजेंट-जन्म देने वाले सबकमांड स्पष्ट रूप से ओवरराइड किए जाने तक इसके बाहर शुरू होने से इनकार करते हैं। अधिक जानकारी के लिए, docs/security.md और docs/agent-sandbox.md देखें।

अंतर्निहित रूप से, पाइपलाइन सात चरणों से गुजरती है:

1. बिल्ड: लक्ष्य को ASAN (C और C++ के लिए मेमोरी त्रुटि डिटेक्टर) के साथ एक डॉकर इमेज में संकलित करता है। पाइपलाइन पहली बार चलाने पर लक्ष्य के Dockerfile का उपयोग करके इस इमेज को स्वचालित रूप से बनाती है।
2. रीकॉन: एक हल्का एजेंट नेटवर्क-पृथक कंटेनर के अंदर स्रोत पढ़ता है और एक विभाजन प्रस्तावित करता है, जैसे "यहाँ N अलग-अलग इनपुट-पार्सिंग सबसिस्टम हैं जिन पर अलग से हमला करना उचित है", ताकि समानांतर फाइंड एजेंट एक ही बग पर केंद्रित होने के बजाय विभिन्न क्षेत्रों का पता लगाएं। --auto-focus फ़्लैग के बिना, पाइपलाइन लक्ष्य के config.yaml से focus_areas सूची का उपयोग करती है।
3. फाइंड: N एजेंट समानांतर में चलते हैं, प्रत्येक अपने स्वयं के पृथक कंटेनर में। प्रत्येक एजेंट स्रोत पढ़ता है, विकृत इनपुट तैयार करता है, और ASAN बाइनरी तब तक चलाता है जब तक कोई दिया गया इनपुट 3 में से 3 बार क्रैश न उत्पन्न करे।
4. वेरिफाई: एक अलग ग्रेडर एजेंट प्रत्येक क्रैश को एक नए कंटेनर में पुन: उत्पन्न करता है जिसे फाइंड एजेंट ने छुआ नहीं है। फाइंड एजेंट से ग्रेडर तक जाने वाली एकमात्र चीज़ उसके द्वारा उत्पादित प्रूफ ऑफ कॉन्सेप्ट है।
5. डीडुप: एक जज एजेंट सत्यापित क्रैश की तुलना पहले से रिपोर्ट किए गए बग्स से करता है और तय करता है कि प्रत्येक एक नया बग है, किसी ज्ञात बग का बेहतर उदाहरण है, या छोड़ने योग्य डुप्लिकेट है।
6. रिपोर्ट: एक रिपोर्ट एजेंट प्रत्येक अद्वितीय बग के लिए एक संरचित शोषण-क्षमता विश्लेषण लिखता है, जिसमें प्रिमिटिव वर्ग, पहुंच-क्षमता, एस्केलेशन पथ और गंभीरता के विवरण शामिल हैं।
7. पैच (ऊपर अलग पैच कमांड): एक पैच एजेंट एक प्रस्तावित फिक्स लिखता है, और एक ग्रेडर एजेंट पुष्टि करता है कि नया कोड बिल्ड होता है, मूल प्रूफ ऑफ कॉन्सेप्ट इनपुट अब क्रैश नहीं करता, लक्ष्य का परीक्षण सूट अभी भी पास होता है, और एक नया फाइंड एजेंट फिक्स के आसपास का रास्ता नहीं खोज सकता।

अधिक विवरण के लिए, docs/pipeline.md देखें।

चरण 3 (दिन 3-5): अपने लक्ष्य के लिए पाइपलाइन कस्टमाइज़ करें

दिन 3-5 में, आप अपने स्वयं के लक्ष्य के लिए हार्नेस कस्टमाइज़ करेंगे। पहले, आप चरण 1 स्किल्स को अपने कोड पर इंगित करेंगे, फिर आप पाइपलाइन को अपने स्टैक में पोर्ट करने के लिए /customize का उपयोग करेंगे। सप्ताह के अंत तक, आपके पास एक targets/<your-service>/ निर्देशिका होगी जिस पर पाइपलाइन चल सकती है, पाइपलाइन के एक स्मोक रन के साथ मान्य, और चरण 4 में स्केल करने के लिए तैयार।

जबकि संदर्भ पाइपलाइन C और C++ कोड में मेमोरी भेद्यताएं खोजने के लिए डिज़ाइन की गई है, इसका आकार सामान्य है। इसे एक नए भेद्यता वर्ग या भाषा में पोर्ट करने का मतलब केवल अपने लक्ष्य स्टैक के लिए निम्नलिखित प्रश्नों के उत्तर देना है:

कस्टमाइज़ करने से पहले, चरण 1 स्किल्स को अपने स्वयं के कोड पर इंगित करें। याद दिलाने के लिए, वे केवल पढ़ने-लिखने वाली हैं, इसलिए वे बिना सैंडबॉक्स के चल सकती हैं।

claude

> /quickstart how do I customize this for ~/code/my-service?

> /threat-model bootstrap-then-interview ~/code/my-service
> /vuln-scan ~/code/my-service
> /triage ~/code/my-service/VULN-FINDINGS.json --repo ~/code/my-service

फिर, उन स्किल्स द्वारा उत्पादित आर्टिफैक्ट्स को /customize स्किल में उपयोग करें, जो आपके कोडबेस के लिए हार्नेस को संशोधित करता है।

> /customize use ~/code/my-service/{THREAT_MODEL.md,VULN-FINDINGS.json} and ./TRIAGE.md

जब /customize पूरा हो जाएगा, तो आपके पास एक targets/my-service/ निर्देशिका सेटअप होगी। स्केल करने से पहले पाइपलाइन के स्मोक रन के साथ इसे मान्य करें।

bin/vp-sandboxed run my-service --model <model-id> --runs 1

अधिक विवरण के लिए, docs/customizing.md देखें।

चरण 4 (सप्ताह 2): स्वायत्त स्कैनिंग, ट्राइएज और पैचिंग शुरू करें

सप्ताह 2 में, आप चरण 3 में कस्टमाइज़ की गई पाइपलाइन का उपयोग अपने स्वयं के लक्ष्यों पर करेंगे, आंतरिक पाइपलाइन लूप में एक बाहरी लूप जोड़ते हुए - कई पाइपलाइन स्कैन चलाएं, उन दौड़ों के निष्कर्षों का ट्राइएज करें, प्राथमिकता के आधार पर पैच करें, और दोहराएं।

# Scan - run a wave of parallel runs against your target
bin/vp-sandboxed run my-service --model <model-id> --runs 5 --parallel --stream --auto-focus

# Triage - dedupe and rank every finding across all waves using your threat model
> /triage results/my-service/ --repo ~/code/my-service --auto --votes 5

# Patch - generate and validate fixes, starting with what triage ranked the highest
> /patch results/my-service/<timestamp>/ --model <model-id>

⚠️ चरण 2 के समान सैंडबॉक्सिंग दिशानिर्देशों का पालन करें

एक दी गई पाइपलाइन दौड़ पहले से ही अपने स्वयं के निष्कर्षों को सत्यापित और डीडुप्लिकेट करती है। /triage कई पाइपलाइन दौड़ों में काम करता है। जब इसे results/ निर्देशिका पर इंगित किया जाता है, तो यह सभी दौड़ों में डुप्लिकेट्स को समाप्त करता है (और /vuln-scan से कोई भी स्टैटिक निष्कर्ष यदि मौजूद हों), आपके थ्रेट मॉडल के विरुद्ध गंभीरता रेटिंग्स को पुन: कैलिब्रेट करता है, और प्रत्येक निष्कर्ष को घटक स्वामी तक पहुंचाने का प्रयास करता है।

जब संभव हो, निष्कर्षों को तुरंत पैच करने से बाहरी लूप को यथासंभव उत्पादक बनाए रखने में मदद मिलती है। जब निष्कर्ष ठीक हो जाते हैं, तो मॉडल उन्हें दोबारा नहीं खोज सकता, और इसके बजाय नए, आमतौर पर गहरे मुद्दों को सतह पर लाएगा। जैसे-जैसे आप अधिक पाइपलाइन लहरें चलाते हैं, निष्कर्षों की संख्या संभवतः घटेगी, लेकिन जटिलता भी संभवतः बढ़ेगी। यदि त्वरित पैचिंग संभव नहीं है, तो लक्ष्य के known_bugs में पिछले निष्कर्षों को दर्ज करना भी भविष्य की दौड़ों को नए बग्स की ओर ले जाने में मदद कर सकता है।

स्वायत्त ट्राइएज और पैचिंग अभी भी खुले मुद्दे हैं, और यह संदर्भ हार्नेस उन्हें पूरी तरह से हल नहीं करता है। /patch में सत्यापन रणनीतियाँ मानक को ऊपर उठाने में मदद करती हैं, लेकिन गंभीरता और प्राथमिकता अंततः आपके वातावरण के बारे में निर्णय हैं, और सत्यापित पैच हमेशा अपस्ट्रीम करने योग्य नहीं होते हैं। कई भागीदारों ने इन चरणों को अपनी वर्तमान बाधाओं के रूप में बताया है, और आपको उनके लिए वास्तविक इंजीनियरिंग समय आवंटित करना चाहिए।

अधिक विवरण के लिए, docs/triage.md और docs/patching.md देखें।

आगे की ओर देखते हुए

प्रारंभिक रैंप-अप के बाद, जिन टीमों के साथ हमने काम किया है, उन्होंने कुछ दिशाओं में निवेश करने की प्रवृत्ति दिखाई है:

1. अपने सभी आंतरिक रिपॉजिटरी और प्रमुख ओपन-सोर्स निर्भरताओं की समीक्षा करना, यह रैंक करना कि स्कैन करने के लिए सबसे महत्वपूर्ण कौन सी हैं (जैसे, उनके जोखिम, CVE के इतिहास, व्यावसायिक-महत्व के आधार पर), फिर सूची को प्राथमिकता क्रम में स्कैन करना।
2. स्कैनिंग को लैपटॉप या एक-बार VMs से स्थानांतरित करने के लिए विशेष स्कैनिंग इंफ्रास्ट्रक्चर स्थापित करना। सबसे सफल टीमें स्केल करने से पहले सही स्कैनिंग प्लेटफॉर्म बनाने के आग्रह का विरोध करती हैं।
3. स्कैन को अपने SDLC में शामिल करना। कुछ टीमों ने आवर्ती स्कैन (जैसे, दैनिक, साप्ताहिक) स्थापित किए हैं या अपने CI पाइपलाइनों में स्कैनिंग जोड़ी है।
4. यह जानने के लिए मॉडलों का परीक्षण और प्रयोग करना कि उनके लिए सबसे अच्छा क्या काम करता है।