Defending Code Reference Harness - AI-आधारित vulnerability खोज और fix के लिए Anthropic का open source framework

• Defending Code Reference Harness Claude के साथ स्वायत्त vulnerability खोज और fix करने के लिए एक reference implementation है, और यह कई संगठनों की security teams के साथ सहयोग से मिली सीख पर आधारित प्रोजेक्ट है
• यह repository कोई product नहीं बल्कि एक reference implementation है, और फिलहाल इसका maintenance नहीं हो रहा है तथा contributions भी स्वीकार नहीं किए जा रहे हैं
• Anthropic एक managed alternative के रूप में Claude Security प्रदान करता है, जो कई projects के source code में vulnerabilities ढूंढ और fix कर सकता है, तथा triage, fix validation, rapid fix generation lifecycle को manage कर सकता है
• Claude Code के लिए skills /quickstart, /threat-model, /vuln-scan, /triage, /patch, /customize उपलब्ध हैं, जो interactive scope setting, scan, triage और patch workflows को support करते हैं
• harness/ एक स्वायत्त reference pipeline है जो recon → find → verify → report → patch flow का पालन करती है, और Docker तथा ASAN का उपयोग करके C/C++ memory vulnerabilities खोजने के लिए optimize की गई है
• Reference pipeline की सामान्य संरचना, prompts और sandboxing तरीका दोबारा इस्तेमाल किया जा सकता है, लेकिन यह हर codebase पर सीधे काम नहीं करेगा; इसे /customize के जरिए language, detector और vulnerability type के अनुसार port करना होगा
• /quickstart, /threat-model, /vuln-scan, /triage और static results के लिए /patch केवल file read/write करते हैं, इसलिए Claude Code में हर tool use की समीक्षा और approval के बाद इन्हें sandbox के बिना चलाया जा सकता है
• Autonomous reference pipeline और pipeline results के लिए /patch target code को execute करते हैं, इसलिए जब तक स्पष्ट रूप से bypass न किया जाए, ये gVisor sandbox के बाहर चलने से इनकार करते हैं
• Pipeline चलाने के लिए scripts/setup_sandbox.sh से gVisor और agent images तैयार करने होते हैं, और Docker के साथ ANTHROPIC_API_KEY या CLAUDE_CODE_OAUTH_TOKEN environment variable की आवश्यकता होती है
• Execution stages build, recon, find, verify, dedupe, report और patch में बंटी हैं; find agent isolated container में malformed input बनाता है और तब तक खोज जारी रखता है जब तक ASAN binary 3 में से 3 बार crash न हो जाए
• verify चरण में एक अलग grader agent नए container में केवल proof of concept प्राप्त करके crash को reproduce करता है, और dedupe चरण यह तय करता है कि मामला नया bug है, किसी मौजूदा bug का बेहतर example है, या duplicate है
• report चरण primitive class, reachability, escalation path और severity सहित structured exploitability analysis लिखता है, और patch चरण fix बनाकर build, मूल proof of concept पर non-crash, tests pass होना, और bypass possibility की दोबारा खोज की जांच करता है
• शुरुआती उपयोग flow में Day 1 पर threat model और static scan, triage, candidate patch बनाए जाते हैं; Day 2 पर C/C++ libraries में execution-validated findings तैयार किए जाते हैं; और Days 3-5 में अपने target के लिए targets/<your-service>/ बनाया जाता है
• अपने stack पर port करते समय finding signal, proof of concept format, और build/execute method को define करना होता है; C/C++ reference में ASAN crash signature, crashing input file, और clang+ASAN आधारित Dockerfile को baseline माना गया है
• Autonomous triage और patching अभी भी open problem हैं; /patch की validation strategy standard को ऊंचा करती है, लेकिन severity और priority environment-specific निर्णय हैं, और validated patch हमेशा upstream नहीं किया जा सकता — यह इसकी सीमा है

[GN⁺]

Hacker News की राय

• यह चीज़ workshop jig के ज़्यादा क़रीब है। चाहें तो आप crosscut sled खरीद सकते हैं, लेकिन ज़्यादातर woodworkers उसे खुद बनाते हैं
  2 साल पहले अपना harness बनाना महंगा पड़ता था, इसलिए तब स्थिति अलग थी, लेकिन अब इसे आइडिया के रेफ़रेंस की तरह देखकर अपने workflow, interface, targets and effort की definition, और notification style के हिसाब से खुद बनाना ही सबसे बेहतर लगता है

  • workshop jig वाली उपमा बिल्कुल सटीक है। बहुत-सा software सामान्य उपयोग के लिए बने रूप से बदलकर बेहद व्यक्तिगत उपयोग की तरफ जा रहा है
    AI से पहले अपने problem को solve करने वाला software बनाने में काफ़ी मानवीय मेहनत लगती थी, इसलिए लोग उसमें थोड़ा और effort लगाकर उसे इतना generalize कर देते थे कि दूसरे भी reuse कर सकें। अब इसमें लगभग कोई effort नहीं लगता, इसलिए software अक्सर generalized हुए बिना ही रह जाता है
    आजकल मैं अपनी बनाई चीज़ें लगभग कभी share नहीं करता[0], क्योंकि उनके दूसरों के काम आने की संभावना कम होती है, और अगर किसी को वैसी ही चीज़ चाहिए भी तो वह मेरी चीज़ को extend या modify करने से बेहतर अपने लिए बिल्कुल फिट बैठने वाली चीज़ बना सकता है। बिल्कुल jig की तरह
    0: https://redfloatplane.lol/blog/17-why-share/ और उससे जुड़े लेख
  • बिल्कुल यही। मैं कई बार कह चुका हूँ कि “कंप्यूटर का इस्तेमाल करना” एक ऐसी चीज़ बनने जा रहा है जिसमें कंप्यूटर का आपकी जगह code लिखना और चलाना पारदर्शी रूप से शामिल होगा, और अगर आप technical नहीं हैं तो शायद आपको इसका पता भी नहीं चलेगा। अभी जो दिशा बताई गई है, वह भी उसी तरफ जा रही है
    हमारी ज़िंदगी में ऐसे बहुत मौके होते हैं जहाँ purpose-built tools बनाना बेहतर होता है, और हर नए model के आने के साथ ऐसे tools की complexity भी बढ़ती जाती है
    यह सचमुच personal tools हैं। ये ऐसी problems हल करते हैं जो औरों की भी हो सकती हैं, लेकिन ये आपके अपने workflow से इतनी मज़बूती से बंधे होते हैं कि इन्हें दूसरों को समझाना या उनके हिसाब से ढालना मुश्किल होता है। इसलिए ये workshop jig हैं
    मेरे पास भी ऐसे custom scripts और programs लगभग 10 हैं, और university के बाद पहली बार फिर ऐसा महसूस हो रहा है। तब मेरे पास settings को जी भरकर customize करने का समय था, और अब हमारे पास agents हैं
    मैं इन्हें दोस्तों को दिखाना चाहता हूँ, लेकिन जब दिमाग़ में चलाकर देखता हूँ कि इन्हें कैसे समझाऊँ, तो लगता है कि वे कई अजीब हिस्सों को समझ नहीं पाएँगे। क्योंकि वह मेरी अपनी अजीबियत है। ये काफ़ी complex technical pieces हैं जो मेरी problems को बहुत अच्छे से solve करते हैं, और वे problems किसी बड़े problem का personal variation हैं, और कम से कम अभी तो मेरा उन्हें support करने का कोई इरादा नहीं है
    हम इस दिशा में जा रहे हैं, यह इतना साफ़ है, फिर भी बहुत लोग अब भी मानते हैं कि code elitist चीज़ है। product code शायद वैसा हो, लेकिन बाकी दुनिया में जल्द ही शायद हमारे parents के computers भी अपने लिए लिखा हुआ code चलाएँगे। security के लिहाज़ से यह डरावना है, लेकिन सोचने पर दिलचस्प भी
  • अगर इरादा हो तो कोई भी harness बना सकता है, लेकिन ज़्यादातर लोगों में वह इच्छा ही नहीं होती
    ऊपर से, खुद करने पर भी, जिन AI workflows को मैंने कई महीनों में polish किया था, वे ultracode की वजह से तुरंत पुराने लगने लगे
  • मैं इस बदलाव को कैसे बयान करूँ, यह ढूँढ रहा था, और यह उपमा बिल्कुल सही बैठती है। software engineering में libraries और infrastructure components की value तेज़ी से घट रही है
    मुझे लगता है कि बहुत-सी organizations में इस तरह का काम संभालने वाली teams के पास आने वाले users अब कम होते जा रहे होंगे
  • open source का भविष्य भी मुझे मोटे तौर पर ऐसा ही दिखता है। open source libraries लाकर इस्तेमाल करने के बजाय, हम उन्हें अपने बनाए custom tools के design inspiration के रूप में reuse करेंगे
    अपनी चीज़ बनाना बहुत सस्ता हो गया है, और किसी दूसरे के building blocks में फँस जाना बहुत महंगा पड़ता है
    लेकिन AI coding को existing tools से grounded रखना बेहद शक्तिशाली है

• इसे चलाने में कितनी लागत आती होगी, यह जानने की जिज्ञासा है
  https://github.com/anthropics/defending-code-reference-harne... के मुताबिक:

  मोटे तौर पर, प्रति agent प्रति मिनट लगभग 10K uncached input tokens और लगभग 2K output tokens मानकर चलें। आप अपने account की ITPM limit तक parallelism बढ़ा सकते हैं (लगभग हर 100K ITPM पर 10 agents)
  मेरा अंदाज़ा है कि Opus पर यह सैकड़ों डॉलर और Mythos पर हज़ारों डॉलर पड़ सकता है

  • यह बात और साफ़ होती जा रही है कि code लिखने से ज़्यादा tokens code को सुरक्षित बनाने में लगते हैं
    शायद फर्क एक digit order तक भी जा सकता है
  • मुझे तो Opus की लागत भी पहले से काफ़ी मुश्किल से वहन करने लायक लगती है, इसलिए Mythos से तुलना कैसी होगी, यह पता नहीं
    इस calculator को देखें तो 100 developers वाली कंपनी के लिए सालाना token cost लगभग 25 लाख डॉलर तक जा सकती है, जो काफ़ी चौंकाने वाला है
    https://ai-cost-calculator.arnica.io
  • Claude का ultra code mode workflow भी बहुत मिलते-जुलते तरीके से काम करता है, और task की complexity के हिसाब से session usage limits को ठीक-ठाक consume करता है
    बस API के ज़रिए चलाने पर लागत बहुत तेज़ी से बढ़ेगी, ऐसा लगता है
  • मैंने तो scan cost estimate करने के लिए एक calculator भी बनाया है। इसमें यह भी शामिल है कि आप इसे लगातार चलाते हैं या नहीं: https://ai-cost-calculator.arnica.io
    यह estimate है, इसलिए ग़लत हो सकता है, लेकिन हमारे अनुभव के आधार पर एक मोटा range दिखाता है। feedback अच्छा लगेगा
  • उनकी managed service से तुलना करें तो यह estimate, codebase के हिसाब से, अपेक्षित लागत का शायद दसवाँ हिस्सा हो सकता है
    लेकिन बड़े नंबर मानकर भी देखें, तो इस तरह के tools जिस तरह की खोजें करने की कोशिश कर रहे हैं, उनके लिए होने वाले formal security engagement की लागत का यह शायद लगभग दसवाँ हिस्सा होगा। यह वे नतीजे हैं जो सिर्फ PR review या /security-review से नहीं मिलते, बल्कि तब मिलते हैं जब कोई expert open source framework के prep work को lead करता है। ऐसे engagement को कैसे चलाना है, यह समझने में लगने वाला समय और delay तो मैंने गिना भी नहीं है
    सीधे कहूँ तो, अगर यह महत्वपूर्ण है, तो एक single scan पर एक महीने के vibe coding budget जितना खर्च भी “dollars के बदले cents” जैसा बहुत सस्ता सौदा है
    साथ ही, उस output के लिए अब भी expert की ज़रूरत होती है। suggestion मददगार भी हो सकते हैं और सक्रिय रूप से नुकसानदेह भी, और सब कुछ prep work की quality पर निर्भर करता है
    मैं किसी IT director को सलाह दूँगा कि कुछ हज़ार डॉलर खर्च करके इसे चलाएँ, डरावने results page के सहारे budget हासिल करें, और फिर ऐसी red team से संबंध बनाएँ जो vulnerabilities ढूँढने, classify करने, ज़रूरत पड़े तो fix करने में मदद करे, और आपकी internal team को security-oriented बनने की training भी दे सके

• “यह repository maintain नहीं की जा रही है और contributions स्वीकार नहीं किए जा रहे हैं।”
  हूँ :)

  • Claude इसे maintain क्यों नहीं कर रहा?
  • यह maintain की जा रही है, और इसे सभी frozen models के अनुसार जितनी जल्दी हो सके ढालना चाहिए
    https://github.com/space-bacon/SRT
    रातों-रात सभी frozen models में बड़ा सुधार किया जा सकता है। चलो करें

• हमारे अनुभव में, अगर अच्छा harness न हो तो codex/claude से बहुत खास फायदा नहीं मिलता। और यह समझने में समय और ऊर्जा लगानी पड़ती है कि coding agents वे bugs क्यों नहीं ढूंढ़ पाते जो इंसान ढूंढ़ लेते हैं
  auditor के रूप में हम हर हफ्ते ऐसे bugs देखते हैं जिन्हें हमारा harness(https://zkao.io/) नहीं पकड़ पाता, और tool से वे bugs पकड़वाने के लिए हमें काफी दिलचस्प techniques खोजनी पड़ती हैं। यहां बात मुख्य रूप से cryptographic vulnerabilities की है, साधारण webapp bugs की नहीं
  इसलिए लगता है कि कंपनियों के लिए अपना harness रखना और अनुभव के आधार पर अच्छा harness बनाने पर केंद्रित services के लिए पैसे देना उचित हो जाएगा। audit firms जो बहुत सारे bugs देखती हैं और उन bugs को harness को “सिखाने” में समय लगा सकती हैं, वे शायद यह काम सबसे अच्छा करेंगी
  दूसरी ओर, classification के लिए भी उतनी ही अच्छी techniques चाहिए। नहीं तो मेरे शब्दों में एक vibe audit मशीन बन जाएगी, जो सिर्फ इतने false positives उगलेगी कि bug bounty की पहले से ही घटिया AI submissions और हर PR review करने वाले AI tools से थके developers और ज्यादा परेशान हो जाएंगे
  आखिर में, अगर harness कोई bug वापस नहीं देता तो आप सोचने लगते हैं, “तो क्या इसका मतलब bug है ही नहीं?” अंत में मामला फिर उसी reputation game पर लौट आता है, जहां आपको सबसे अच्छा tool या सबसे अच्छी team चुननी होती है, यानी वह team जो जानती है कि सबसे अच्छा tool कौन सा है, और फिर पता लगाना पड़ता है कि वह कौन है

• security निश्चित रूप से एक शानदार AI/LLM use case है। क्योंकि काम का बड़ा हिस्सा known security issue patterns को उस चीज़ से match करना है जिसका विश्लेषण हो रहा है, और वह बहुत सटीक programming-language text होता है
  जो बात ध्यान खींचती है, वह यह है कि सबसे शक्तिशाली use cases में AI कंपनियां raw output बेचने के बजाय उस technique को service के रूप में बेचना चाहती हैं। जहां output की value कम होती है, वहां वे tokens बेचती हैं
  अगर AI tokens सामान्य software application development में नई value बनाने के लिए सचमुच जादुई होते, तो वे सीधे tokens नहीं बेचते। वे tokens अपने पास जमा रखते और जिन भी industries में चाहें, वहां के SaaS software पर कब्जा करने में उनका इस्तेमाल करते
  यह कुछ वैसा है जैसे stock market में महंगे courses बेचने वाला कोई व्यक्ति यह संकेत दे रहा हो कि उसके लिए course बेचना, अपनी जानकारी से सीधे stock market में पैसा कमाने से ज्यादा फायदेमंद है

  • या फिर वे diversification चाहते हों
    AI tokens से product बनाना हो तो उन्हें पूरा product बनाना और बेचना पड़ता है, जिसमें उनका अनुभव कम है, और उन्हें अपने ही customers से compete भी करना पड़ता है। अभी अपनी जगह बना रहे AI vendor के लिए यह अच्छी position नहीं है। मौजूदा business से ही निपटने के लिए बहुत कुछ है, इसलिए यह बड़ा distraction है, और strategic value भी बहुत ज्यादा नहीं है
  • “tokens अपने पास जमा रखकर जिन industries में चाहें वहां के SaaS software पर कब्जा करना चाहिए” वाला तर्क समझ नहीं आता
    मैंने एक ठीक-ठाक सफल SaaS चलाया है और उसे बेच भी चुका हूं, और जो हिस्से थकाने वाले और frustrate करने वाले होते हैं, उनमें LLM मदद नहीं कर सकता। product को code करना न तो bottleneck है और न ही success की guarantee
  • वह निष्कर्ष बिल्कुल नहीं निकलता। Anthropic token sales से revenue में साल-दर-साल 10x growth देख रहा है
    भले ही उनके tokens सचमुच जादुई हों, और वे मौजूदा industries में घुसकर incumbents को हटाते हुए उन industries में सालाना 100% growth हासिल कर सकते हों, फिर भी token sales को प्राथमिकता देना बेहतर रहेगा। क्योंकि वह अपने आप में ही शानदार business है
    यह logic बस इतना दिखाता है कि limits हैं। tokens software के हर क्षेत्र में तुरंत असीमित पैसा बनाने जितने शक्तिशाली नहीं हैं। यह बात सही लगती है
  • एक और व्याख्या यह हो सकती है कि ecosystem बनाना लंबे समय में ज्यादा मूल्यवान है
    शुरुआत में कई कंपनियां security concerns की वजह से अपने employees को remote LLM में source code डालने से रोकती थीं। अब कई कंपनियां यह मानने लगी हैं कि security concerns की वजह से सारे source code का remote LLM से analysis होना चाहिए
    अगर Anthropic पर भरोसा करना सामान्य बात बन जाता है, तो वे source code access की जरूरत वाली और भी services बेच पाएंगे
  • हैरानी होती है कि integrated MetaSploit AI update अभी तक नहीं आया, जिसमें आप कंपनी के भीतर बहुत से लोगों को call और message करके किसी vulnerable दिखने वाले व्यक्ति को ढूंढ़ना शुरू करें, फिर कोई human red-teamer takeover करे या और सीधे तरीके से lead करे

• थोड़ा अलग विषय है, लेकिन लगता है कोई इस पोस्ट के अच्छे GitHub links को dead/flag करके सब खत्म कर रहा है, समझ नहीं आता क्यों

• एक छेद ढूंढ़ना हमेशा सभी छेद बंद करने से आसान होता है। hackers के पास भी वही tools हैं, इसलिए यह एक ऐसी arms race है जिसे जीता नहीं जा सकता

  • यह साफ है कि LLM threat model की गणना को काफी बदल देते हैं, लेकिन सिर्फ यह observation यह नहीं बताती कि यह कैसे या क्यों बदलता है
    जिस asymmetry की बात हुई, वह LLM से पहले के software में भी मौजूद थी
  • defenders के पास context होता है जो attackers को नहीं पता होता

• काफी दिलचस्प है। मैं कुछ समय से ऐसा ही एक tool बना और इस्तेमाल कर रहा हूं:
  https://github.com/bobinson/vulture
  false positives ने बहुत परेशान किया, और मैं Claude + MCP को गरीब आदमी के audit tool की तरह इस्तेमाल करता रहा हूं। पिछले कुछ दिनों में Nvidia-hosted models पर बेहतर नतीजे मिले हैं

• जब तक यह पता न हो कि Claude इस harness के साथ tokens का कुशलतापूर्वक उपयोग करता है या नहीं, यह सुनने में जितना उपयोगी लगता है उतना शायद न हो

• यह साफ है कि Anthropic अब खास use cases के लिए harness बना रहा है और उन्हें product के रूप में पेश कर रहा है
  इसे security के लिए Claude Design का समकक्ष कहा जा सकता है
  harness अलग है, packaging अलग है, और target persona अलग है, इसलिए distribution method भी स्वाभाविक रूप से अलग है
  दिलचस्प बात यह है कि Mythos पर रिपोर्ट लिखने वाली कंपनियों के posts देखें तो हर कोई अपना harness बना रहा है। Cisco ने तो उनमें से एक का spec भी प्रकाशित किया है
  लेकिन इसे package और distribute कैसे करना है, यह Anthropic ने समझ लिया है। यह शानदार go-to-market strategy है

  • यह post और GitHub organization भी भ्रम पैदा करते हैं। Anthropics और Anthropic अलग हैं