Mythos के बाद: bug bounty प्रोग्रामों को अब मजबूत सबूतों की जरूरत क्यों है

कुछ सप्ताह पहले मैंने Anthropic Mythos और Project Glasswing के बारे में लिखा था। तब बात मुख्य रूप से बड़ी दिशा की थी: अगर models सच में पुरानी vulnerabilities खोजने, exploit paths जोड़ने, और पूरी codebase समझने में बेहतर हो जाते हैं, तो vulnerability research बदल जाएगा।

Sophos का नया लेख, जो Mythos युग में bug bounty पर है, अब इसका operational पक्ष दिखाता है।

अब सवाल सिर्फ यह नहीं है कि AI बेहतर vulnerabilities खोजता है या नहीं। सवाल यह है कि bug bounty programs, security teams, और engineering organizations कचरा, plausible claims, और वास्तविक security problems में पर्याप्त तेजी से फर्क कर पाते हैं या नहीं।

असली समस्या सिर्फ AI slop नहीं है

AI और bug bounty की बात आते ही लोग अक्सर slop सोचते हैं: automatically generated reports, आधे समझे गए error messages, गढ़ी हुई exploit chains, ऐसे claims जिन्हें reproduce नहीं किया जा सकता, और बहुत text जिसमें substance कम हो।

यह वास्तविक है। और maintainers, product security teams, और triage करने वालों के लिए बहुत परेशान करने वाला है।

लेकिन यह सिर्फ एक पक्ष है।

दूसरा पक्ष ज्यादा खतरनाक है: अच्छे researchers उन्हीं models का इस्तेमाल करके वास्तविक vulnerabilities तेजी से खोज सकते हैं, बड़े codebases पर hypotheses test कर सकते हैं, और किसी pattern की variants को systematically देख सकते हैं। जो काम पहले दिनों या हफ्तों की manual मेहनत मांगता था, वह भविष्य में कुछ घंटों में queue में आ सकता है।

इससे समस्या बदलती है। पहले सवाल अक्सर था: क्या हमें पर्याप्त अच्छे external findings मिल रहे हैं? आज सवाल ज्यादा यह है: क्या हम noise बढ़ने के साथ वास्तविक findings को काफी तेजी से पहचान, validate, prioritize, और fixes में बदल सकते हैं?

Sophos यहां दिलचस्प स्रोत क्यों है

Sophos का लेख AI पर generic टिप्पणी नहीं है। Sophos अपने bug bounty program को देखता है और concrete numbers देता है।

Sophos के अनुसार, public program दिसंबर 2017 से Bugcrowd पर चल रहा है। Sophos लिखता है कि लेख के समय तक 1,343 vulnerabilities को reward दिया गया था, कुल 7,091 submissions में से, और total payout 599,695 US dollars था।

2025 के लिए Sophos इनमें से कुछ बातें बताता है:

• 52 से अधिक reports के लिए 59,400 US dollars payout
• लगभग 420 researchers शामिल
• कुछ conditions में Intercept X Endpoint के लिए 80,000 US dollars तक
• Sophos Central के लिए 50,000 US dollars तक
• Sophos Firewall के लिए 50,000 US dollars तक
• 2025 में Sophos Firewall के 13 valid bugs, कुल payout 21,500 US dollars
• 2025 में Sophos Central के 13 valid bugs, कुल payout 11,650 US dollars

ये astronomical numbers नहीं हैं, और इसलिए ही दिलचस्प हैं। ये दिखाते हैं कि एक काफी mature program के पीछे कितना sorting work होता है। हजारों submissions अपने आप हजारों relevant security problems नहीं बनते। और AI शायद इस ratio को आसान नहीं करेगा।

यह इसे कठिन बनाएगा।

Reproducibility प्रवेश टिकट बन जाती है

मेरी नजर में सबसे महत्वपूर्ण परिणाम सरल है, पर असुविधाजनक: साफ reproducibility के बिना security report की value घटेगी।

इसलिए नहीं कि triage teams आलसी हैं। बल्कि इसलिए कि उनका समय कम होता जा रहा है।

अगर कोई report remote code execution, auth bypass, या critical data exposure दिखाने का दावा करती है, तो उसे साफ साबित करना होगा:

• कौन सा version प्रभावित है
• कौन सी configuration जरूरी है
• attacker को कौन से rights चाहिए
• कौन से steps reproducibly result तक ले जाते हैं
• कौन से logs, requests, traces, या screenshots claim को support करते हैं
• कौन सा impact वास्तव में proven है
• assumption और proof की सीमा कहां है

यह सख्त लगता है। है भी। लेकिन यही जरूरी होगा अगर security teams plausible sounding texts में डूबना नहीं चाहतीं।

AI-generated report भाषा में बहुत convincing लग सकती है। वह code quote कर सकती है, CVE जैसा लिख सकती है, और साफ structure का दिखावा कर सकती है। इससे वह सच नहीं हो जाती। इसके उलट, एक छोटी और dry report अच्छे proof of concept के साथ बेहद valuable हो सकती है।

नई currency wording नहीं है। नई currency evidence है।

AI authorization bugs को खास तौर पर मुश्किल बनाता है

Sophos के लेख का एक point मुझे खास तौर पर practical लगता है: AI किसी मिले हुए authorization bypass को बड़े scope surfaces पर scale करने में मदद कर सकता है।

यह वास्तविक SaaS environments में दिखने वाली चीजों से मेल खाता है। Authorization शायद ही कभी एक single switch होता है। यह roles, tenants, object IDs, subdomains, API versions, admin surfaces, mobile endpoints, legacy routes, और half-migrated features में रहता है।

जब researcher कोई pattern पाता है, AI उसकी variations को systematically check करने में मदद कर सकता है:

• क्या bypass सिर्फ एक endpoint के लिए है या पूरी endpoint family के लिए?
• क्या यह सिर्फ एक tenant में काम करता है या cross-tenant भी?
• क्या वही logic old और new APIs में मौजूद है?
• क्या admin और user roles सच में हर जगह cleanly separated हैं?
• क्या object direct ID से load हो सकता है, भले UI उसे न दिखाए?

यहीं AI खतरनाक रूप से उपयोगी होता है। magic hacker के रूप में नहीं, बल्कि boring, broad, systematic testing के accelerator के रूप में।

और यह उन organizations के लिए बुरा है जिनकी security काफी हद तक इस बात पर निर्भर करती है कि किसी के पास boring variants को test करने का समय नहीं है।

Bug bounty PR mailbox नहीं है

कई companies अभी भी bug bounty को आधा image topic मानती हैं: हमारे पास program है, इसलिए हम open, modern, और security-minded हैं।

अब यह काफी नहीं है।

Bug bounty program एक production system है। इसे clear rules, good triage, technical reproduction, product closeness, engineering responsibility, और incident response connection चाहिए। वरना यह सिर्फ public mailbox बन जाता है जहां external researchers, AI slop, और real attackers एक ही entrance share करते हैं।

Sophos लेख में दो uncomfortable points साथ लाता है:

पहला: अच्छे researchers मदद करते हैं। external view, अलग thinking patterns, और continuous pressure valuable हैं।

दूसरा: money और trust वाला system abuse भी हो सकता है। Sophos Pacific Rim, Asnarök, और Personal Panda से जुड़े experiences का उल्लेख करता है, जहां active exploitation और बाद के bug bounty reports के बीच temporal proximity ने कम से कम सवाल उठाए। Sophos साफ नहीं कहता कि हर ऐसा report malicious था। लेकिन operational point बना रहता है: bug bounty program naive तरीके से नहीं बनाया जा सकता।

व्यावहारिक रूप से इसका मतलब है:

• Reports को telemetry के साथ correlate करना चाहिए।
• नया finding retroactive threat hunts भी trigger कर सके।
• triage को पता होना चाहिए कि similar exploit attempts पहले से visible थे या नहीं।
• researcher reputation मदद करती है, लेकिन technical verification का substitute नहीं है।
• Safe harbor महत्वपूर्ण है, लेकिन abuse detection का substitute नहीं है।

यही sober reality है: bug bounty Secure by Design का हिस्सा है, उसका replacement नहीं।

मजबूत सबूत मजबूत जिम्मेदारी भी लाते हैं

यहां एक tension है जिसे छिपाना नहीं चाहिए।

Historically researchers से अक्सर कहा जाता है: पर्याप्त जल्दी रुकें। bug दिखाएं, लेकिन बहुत गहराई में न जाएं। customer data न छुएं। lateral movement न करें। destructive actions न करें।

यह सही है।

साथ ही burden of proof बढ़ेगा। अगर AI बड़े पैमाने पर plausible लेकिन false reports बनाता है, तो programs ज्यादा evidence मांगेंगे। तब मुश्किल सवाल उठेगा: researcher impact को ज्यादा मजबूती से कैसे prove करे, बिना dangerous behavior में फिसले?

जवाब यह नहीं हो सकता: “बस और ज्यादा करो।” जवाब ज्यादा controlled होना चाहिए:

• clearer Rules of Engagement
• dedicated test environments
• safe reproduction paths
• impact proof की agreed boundaries
• बेहतर sandbox और lab systems
• proof of concept के automated replays

बड़े vendors के लिए यह लगभग अनिवार्य होगा। जो high bounties गंभीरता से pay करते हैं, उनके पास reports को cleanly और quickly validate करने की infrastructure भी होनी चाहिए।

छोटे projects के लिए यह ज्यादा कड़वा है। उन्हें वही slop wave मिलती है, लेकिन वही resources नहीं। इसलिए कुछ projects financial bug bounties कम करेंगे या पूरी तरह बंद करेंगे। इसलिए नहीं कि वे security को गंभीरता से नहीं लेते, बल्कि इसलिए कि program चलाना खुद burden बन जाता है।

Admins और MSPs क्या सीख सकते हैं

कोई कह सकता है: यह सिर्फ vendors और Bugcrowd programs की बात है।

मुझे ऐसा नहीं लगता।

यही mechanism MSPs, internal IT teams, और security owners को भी प्रभावित करता है। जहां भी external या internal findings को evaluate करना होता है, pressure बढ़ता है:

• scanners ज्यादा findings देते हैं।
• AI assistants findings को ज्यादा convincing तरीके से explain करते हैं।
• developers AI-generated security notes लेकर आते हैं।
• customers context समझने से पहले CVEs पूछते हैं।
• management जानना चाहता है कि risk real है या सिर्फ loud।

Practical answer सब ignore करना नहीं है। जवाब है ज्यादा कठोर validation process।

मेरे लिए कम से कम ये questions जरूरी हैं:

1. क्या problem reproducible है?
2. क्या affected scope clear है?
3. क्या realistic attacker path है?
4. क्या impact technically proven है या सिर्फ claimed?
5. क्या logs या telemetry exploitation दिखा सकते हैं?
6. क्या fix patch, configuration, workaround, या सिर्फ bandage है?
7. क्या retroactively search करना जरूरी है कि यह पहले exploit हुआ था?

यह ज्यादा काम जैसा लगता है। है भी। लेकिन हर अच्छी तरह लिखी report पर panic reaction से यह बेहतर काम है।

यह Mythos से अच्छी तरह क्यों जुड़ता है

मेरे लिए Mythos का निर्णायक point कभी सिर्फ यह नहीं था: “वाह, model bugs खोजता है।”

Point यह था: अगर ऐसी capabilities ज्यादा real होती हैं, तो finding, understanding, reproduction, और exploitation के बीच का समय घटता है। यहीं bug bounty programs प्रभावित होते हैं। वे research, attack potential, engineering, और responsibility के intersection पर बैठते हैं।

Sophos अपने लेख में इसे मिलते-जुलते तरीके से कहता है: सवाल यह नहीं कि AI submissions को कैसे रोका जाए। सवाल यह है कि जब good research और noise दोनों machine speed पर पैदा हो सकते हैं, तो trust और signal कैसे बचाए जाएं।

मेरे लिए यही समस्या का सबसे साफ सार है।

हर organization को अपना बड़ा bug bounty program नहीं चाहिए। लेकिन हर organization को technical claims जांचने के बेहतर mechanisms चाहिए। क्योंकि security information की बाढ़ कम नहीं होगी। वह तेज, loud, और बेहतर लिखी हुई होगी।

मेरी राय

मैं Sophos के लेख को Mythos का उपयोगी follow-up मानता हूं, क्योंकि यह debate को model room से operations room में लाता है।

Mythos शानदार signal है। Bug bounty triage वह workbench है जहां दिखता है कि security processes साथ चल सकते हैं या नहीं।

मेरा thesis सरल है:

• जो सिर्फ ज्यादा reports इकट्ठे करेगा, वह हारेगा।
• जो reproducible evidence मांगेगा, वह बेहतर prioritize करेगा।
• जो bug bounty, telemetry, engineering, और incident response को जोड़ेगा, वह तेजी से react करेगा।
• जो AI को सिर्फ text generator समझता है, वह systematic security work के लिए उसकी value को underestimate करता है।
• जो AI slop filter नहीं करता, वह उन लोगों का समय जलाता है जिन्हें वास्तविक समस्याएं हल करनी चाहिए।

यह frontier model द्वारा zero-days खोजने जितना glamorous नहीं लगता। लेकिन यहीं तय होता है कि security gain defenders तक पहुंचेगा या सब और ज्यादा noise में डूबेंगे।

अगली बार तक,
Joe