nealbridges/vulnhunterएजेंटिक AI सुरक्षा स्कैनर जो स्रोत कोड पर हमलावर की तरह तर्क करता है, निष्पादन योग्य PoC के साथ शोषण योग्य खामियों की पुष्टि करता है, और hunt, fix, तथा verify कौशलों के माध्यम से परीक्षण-प्रथम समाधान को आगे बढ़ाता है।
[!NOTE] Capital One के VulnHunter (Apache-2.0) का एक अनुरक्षित फ़ोर्क — जिसे किसी भी एजेंट हार्नेस पर चलाने के लिए बनाया गया है, न कि केवल Claude Code पर। इस फ़ोर्क का फ़ोकस: हार्नेस पोर्टेबिलिटी, सैंडबॉक्स्ड (कंटेनरीकृत) एक्सप्लॉइट वैलिडेशन, और मापित-प्रभाव PoCs। देखें परिवर्तन क्यों · यह फ़ोर्क क्या बदलता है · आँकड़े।
पैटर्न-मिलान से प्रमाणनीयता तक।
VulnHunter एक ओपन-सोर्स, एजेंटिक AI सुरक्षा उपकरण है जो स्रोत कोड पर सीधे सक्रिय, आक्रामक-प्रथम विश्लेषण लागू करता है।
पारंपरिक, निष्क्रिय SAST स्कैनरों के विपरीत जो संदिग्ध पैटर्न को चिह्नित करते हैं और अक्सर गलत सकारात्मक परिणाम उत्पन्न करते हैं, VulnHunter एक विरोधी की तरह तर्क करता है। यह पहचानता है कि कौन से दोष वास्तव में शोषणीय हैं, संभावित आक्रमण पथों का मानचित्रण करता है, और लक्षित, साक्ष्य-समर्थित सुधार प्रस्तावित करता है।
आधुनिक सॉफ़्टवेयर आपूर्ति श्रृंखलाएँ गहराई से परस्पर जुड़ी हुई हैं। व्यापक रूप से उपयोग किए जाने वाले ओपन-सोर्स घटक में एक भी भेद्यता एक साथ हज़ारों उद्यमों में फैल सकती है।
VulnHunter को Capital One में आंतरिक रूप से विकसित किया गया था और समुदाय के लिए ओपन-सोर्स किया गया था। यह फ़ोर्क उस कार्य को आगे बढ़ाता है — वही कार्यप्रणाली, किसी भी एजेंट हार्नेस पर चलाने के लिए पुनर्गठित, जिसमें सैंडबॉक्स्ड (कंटेनरीकृत) एक्सप्लॉइट वैलिडेशन और मापित-प्रभाव PoCs रोडमैप के रूप में हैं। देखें यह फ़ोर्क क्या बदलता है।
दोहरे-उपयोग की चेतावनी VulnHunter दोहरे-उपयोग वाला साइबर सुरक्षा कार्य करता है (भेद्यता खोज और शोषण)। गार्डरेल की अपेक्षा करें: अधिकांश व्यावसायिक रूप से उपलब्ध मॉडल दोहरे-उपयोग वाले साइबर सुरक्षा उपाय लागू करते हैं, और आक्रामक शोषण व्यवहार दर सीमाओं या उपयोग फ़्लैग को सक्रिय कर सकता है। VulnHunter का विकास और परीक्षण ओपन-वेट, समुदाय-प्रदत्त मॉडलों पर चलाया गया — डी-रिस्क्ड, एब्लिटरेटेड, और अनसेंसर्ड — जो आगे चलकर संगठनात्मक उपयोग के लिए मायने रखने वाले मॉडल हैं। केवल उसी कोड का ऑडिट करें जिसका आप स्वामी हैं या अन्यथा ऑडिट करने के लिए अधिकृत हैं।
[!IMPORTANT] पूर्वापेक्षाएँ और मॉडल आवश्यकताएँ VulnHunter की कार्यप्रणाली ओपन-वेट, समुदाय-प्रदत्त मॉडलों पर चलाने के लिए बनाई गई है — वे डी-रिस्क्ड, एब्लिटरेटेड, अनसेंसर्ड मॉडल जिन्हें संगठन वास्तव में तैनात कर सकते हैं। एक सक्षम रीज़निंग मॉडल आवश्यक है; आपका हार्नेस जो सबसे मज़बूत मॉडल प्रदान करता है वह सर्वोत्तम परिणाम देता है, लेकिन कार्यप्रणाली किसी विशिष्ट विक्रेता के फ्रंटियर मॉडल पर निर्भर नहीं करती। आप अपनी स्वयं की मॉडल पहुँच प्रदान करते हैं।
| क्षमता | अपस्ट्रीम (Capital One) | यह फ़ोर्क | स्थिति |
|---|---|---|---|
| हार्नेस पोर्टेबिलिटी | स्किल्स विशेष रूप से Claude Code को आमंत्रित करती हैं; इंस्टॉलर ~/.claude/skills को लक्षित करता है; मॉडल गेट्स Opus को हार्डकोड करते हैं; हार्नेस claude-opus-4-8 को पिन करता है | स्किल्स हार्नेस-पोर्टेबल प्रॉम्प्ट फ़ाइलें हैं (कोई भी हार्नेस जिसमें स्किल्स डायरेक्टरी + सबएजेंट हों); VULNHUNT_SKILLS_DIR / VULNHUNT_AGENTS_DIR / VULNHUNT_BIN_DIR / VULNHUNT_HOST_CMD / VULNHUNT_MODEL पर्यावरण अनुबंध; मॉडल गेट्स को "आपके हार्नेस का सबसे सक्षम रीज़निंग मॉडल" के रूप में पुनःव्यक्त किया गया | शिप किया गया |
| नो-गेस इंस्टॉलर | install.sh ~/.claude/skills मान लेता है | स्पष्ट डायरेक्टरियाँ, GROK_HOME सेमांटिक्स का पालन करता है, vh लॉन्चर को VULNHUNT_BIN_DIR/~/.local/bin में लिखता है, vulnhunter-run स्किल + एजेंट परिभाषा इंस्टॉल करता है; Windows .cmd समकक्ष अपडेट किए गए | शिप किया गया |
vulnhunter-run ऑपरेटर स्किल | — (अनुपस्थित) | अनअटेंडेड ऑपरेटर: क्लोन → हंट → फाइंड-रिज़ल्ट्स → स्कैन मैनिफ़ेस्ट लिखना/सत्यापित करना, स्पष्ट स्टॉप नियमों के साथ और बिना किसी अनौपचारिकता के | शिप किया गया |
| बेंचमार्क/जज हार्डनिंग | निश्चित मॉडल + बुनियादी रीट्राई | पर्यावरण के माध्यम से मॉडल, रीट्राई/बैकऑफ़ कॉन्फ़िगरेशन, analyze_misses पाइपलाइन लॉस-पॉइंट ट्रेसिंग, प्रति-फाइंडिंग इतिहास ट्रैकिंग | शिप किया गया |
| हार्नेस-न्यूट्रल रिपोर्ट भाषा | स्किल्स में Claude-विशिष्ट गद्य | हार्नेस-न्यूट्रल टूल भाषा (Agent → सबएजेंट, Claude CLI → हार्नेस सत्र) | शिप किया गया |
| सैंडबॉक्स-फ़र्स्ट एक्सप्लॉइट सत्यापन | एक्सप्लॉइट परीक्षण स्थिर ट्रेस हो सकते हैं; रनटाइम चयन तदर्थ | Docker-फ़र्स्ट रनटाइम प्रोविज़निंग; प्रति फाइंडिंग रिकॉर्ड किया गया रनटाइम; Medium+ गंभीरता को निष्पादित करना अनिवार्य | प्रगति पर |
| मापित-प्रभाव PoCs | PoCs दस्तावेज़ हैं; प्रभाव का दावा किया जाता है | निष्पादन योग्य PoC + फाइंडिंग में प्रभाव संख्या (उजागर पंक्तियाँ, प्रवर्धित अनुरोध, अटकी कुंजी-घंटे) | प्रगति पर |
VulnHunter की कार्यप्रणाली स्वभाव से होस्ट-अज्ञेयवादी है: यह प्रॉम्प्ट प्रक्रिया है, टूल बाइंडिंग नहीं। अपस्ट्रीम प्रोजेक्ट Claude Code के भीतर विकसित हुआ — एक सुसंगत विकल्प, और सही पहला घर। लेकिन एजेंट-हार्नेस परिदृश्य व्यापक हो गया है, और एक सुरक्षा कार्यप्रणाली जो केवल उनमें से एक में इंस्टॉल होती है, ऑडिट क्षमता होना बंद करके विक्रेता सुविधा बन जाती है। यह फ़ोर्क चार परिवर्तन करता है, प्रत्येक का एक कारण है।
यहाँ प्रत्येक स्किल एक पोर्टेबल प्रॉम्प्ट फ़ाइल है जिसमें एक स्पष्ट पर्यावरण अनुबंध (VULNHUNT_SKILLS_DIR, VULNHUNT_AGENTS_DIR, VULNHUNT_MODEL, VULNHUNT_HOST_CMD) है, और मॉडल गेट्स अब किसी विशिष्ट उत्पाद के बजाय आपके हार्नेस का सबसे सक्षम रीज़निंग मॉडल माँगते हैं। बेहतर का अर्थ है: वही कार्यप्रणाली आपकी टीम जो भी हार्नेस पहले से चलाती है उसमें इंस्टॉल हो जाती है — और बेंचमार्क रन में हार्नेस के पार तुलनीय हो जाती है, जो इस फ़ोर्क के विकास का तरीका है।
अपस्ट्रीम इंस्टॉलर स्किल्स को बिना शर्त ~/.claude/skills में कॉपी करता था। दो हार्नेस चलाने वाली मशीन पर — या स्थानांतरित होम वाले हार्नेस पर — वह अनुमान चुपचाप गलत जगह पर इंस्टॉल कर देता है। फ़ोर्क का इंस्टॉलर पूछता है, या पर्यावरण चर लेता है, और उत्तर अनुपस्थित होने पर सटीक निर्देश के साथ ज़ोर से विफल होता है। बेहतर का अर्थ है: मल्टी-हार्नेस मशीनों पर सुरक्षित, स्थानांतरित होम के अंतर्गत सही, गलत कॉन्फ़िगर होने पर चुप्पी के बजाय ज़ोर से।
मूल डिज़ाइन पहले से ही मिथ्याकरण और शोषण परीक्षणों की मांग करता है। जो बात इसमें खुली रह गई थी वह यह थी कि उन्हें वास्तव में निष्पादित करने के लिए कितनी कड़ी मेहनत करनी है: स्थिर ट्रेस, मॉक किया गया परीक्षण, या एक वास्तविक कंटेनरीकृत सर्वर। एक ही कमिट के विरुद्ध छह-रन वाले एक बेंचमार्क में, उस विवेक ने कहीं भी 3 से 42 निष्कर्ष उत्पन्न किए — और एक ही सिंक पर विपरीत निर्णय, एक मॉक के विरुद्ध सिद्ध, एक वास्तविक सर्वर के विरुद्ध परीक्षण द्वारा बंद। यह फ़ोर्क एक रनटाइम-प्रोविज़निंग प्रक्रिया (Docker-प्रथम, प्रति निष्कर्ष रिकॉर्ड की गई) और एक PoC अनुशासन जोड़ता है जिसमें प्रभाव मापा जाता है — लीक हुई पंक्तियाँ, ×-प्रवर्धन, अटकी हुई key-hours — न कि वर्णित। बेहतर का अर्थ है: किसी निष्कर्ष की वैधता अब इस पर निर्भर नहीं करती कि किस मॉडल में कंटेनर खड़ा करने की प्रवृत्ति थी। (प्रगति पर — बिल्ड योजना सार्वजनिक रोडमैप पर है; issues में पूछें या रेपो के Discussions को देखें।)
इस फ़ोर्क में नया: vulnhunter-run, एक बिना निगरानी वाला ऑपरेटर जो क्लोन करता है, शिकार करता है, परिणामों का पता लगाता है, और स्पष्ट स्टॉप नियमों के साथ स्कैन मैनिफ़ेस्ट लिखता और सत्यापित करता है। बेंचमार्क टूलिंग को पर्यावरण के माध्यम से मॉडल कॉन्फ़िगरेशन, रिट्राई/बैकऑफ़ नॉब्स, और छूटे हुए निष्कर्षों के लिए लॉस-पॉइंट विश्लेषण प्राप्त होता है। बेहतर का अर्थ है: उस टूल के बीच का अंतर जिसे आप डेमो करते हैं और उस टूल के बीच जिसे आप शेड्यूल करते हैं।
हम VulnHunter का बेंचमार्क स्वयं के विरुद्ध करते हैं: एक वास्तविक प्रोडक्शन Go सेवा के छह पूर्ण स्कैन — एक ही कमिट, पाँच हार्नेस/मॉडल स्टैक। नीचे दिए गए आँकड़े उन रनों से हैं, और यही कारण है कि यह फ़ोर्क मौजूद है।
