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 যথেষ্ট দ্রুত garbage, plausible claims, আর বাস্তব security problems আলাদা করতে পারে কি না।

আসল সমস্যা শুধু AI slop নয়

AI এবং bug bounty নিয়ে কথা উঠলেই এখন অনেকে slop-এর কথা ভাবে: automatically generated reports, অর্ধেক বোঝা error messages, বানানো exploit chains, reproduce করা যায় না এমন claims, এবং অনেক text যার substance কম।

এটা বাস্তব। আর maintainers, product security teams, এবং triage করা মানুষের জন্য এটা খুব বিরক্তিকর।

কিন্তু এটা শুধু এক দিক।

অন্য দিকটা বেশি বিপজ্জনক: ভালো researchers একই models ব্যবহার করে বাস্তব vulnerabilities দ্রুত খুঁজে পেতে পারে, বড় codebases জুড়ে hypotheses test করতে পারে, এবং কোনো pattern-এর variants পদ্ধতিগতভাবে দেখতে পারে। আগে যে manual কাজের জন্য দিন বা সপ্তাহ লাগত, ভবিষ্যতে তা কয়েক ঘণ্টার মধ্যে queue-তে ঢুকতে পারে।

তাই সমস্যাটা বদলে যায়। আগে প্রশ্ন ছিল প্রায়ই: আমরা কি যথেষ্ট ভালো external findings পাচ্ছি? আজ প্রশ্নটা বেশি এমন: noise বাড়ার মধ্যেও আমরা কি বাস্তব findings যথেষ্ট দ্রুত চিনতে, validate করতে, prioritize করতে, এবং fixes-এ বদলাতে পারছি?

Sophos এখানে আকর্ষণীয় source কেন

Sophos-এর লেখা AI নিয়ে generic মন্তব্য নয়। Sophos নিজের bug bounty program দেখেছে এবং concrete numbers দিয়েছে।

Sophos-এর মতে, public program ডিসেম্বর 2017 থেকে Bugcrowd-এ চলছে। Sophos লিখেছে, লেখাটির সময় পর্যন্ত 1,343 vulnerabilities rewarded হয়েছে, মোট 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, total payout 21,500 US dollars
• 2025 সালে Sophos Central-এ 13টি valid bugs, total 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 affected
• কোন configuration দরকার
• attacker-এর কোন rights দরকার
• কোন steps reproducibly result-এ পৌঁছায়
• কোন logs, requests, traces, বা screenshots claim support করে
• কোন impact সত্যিই proven
• assumption আর proof-এর boundary কোথায়

এটা কঠোর শোনায়। সত্যিই কঠোর। কিন্তু security teams যদি plausible sounding texts-এ ডুবে যেতে না চায়, তাহলে এটাই দরকার হবে।

AI-generated report ভাষার দিক থেকে খুব convincing হতে পারে। এটা code quote করতে পারে, CVE-এর মতো লিখতে পারে, এবং clean 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?
• UI দেখাবে না, তবু direct ID দিয়ে object load করা যায় কি?

এখানেই AI বিপজ্জনকভাবে useful হয়। 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 ব্যবহার করে।

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 যদি mass scale-এ 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
• better 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।

আমার কাছে অন্তত এই প্রশ্নগুলো দরকার:

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 নিয়ে আমার কাছে decisive 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 কীভাবে রাখা যায়।

আমার কাছে এটাই সমস্যার সবচেয়ে পরিষ্কার summary।

প্রতিটি organization-এর নিজস্ব বড় bug bounty program দরকার নেই। কিন্তু প্রতিটি organization-এর technical claims যাচাই করার ভালো mechanisms দরকার। কারণ security information-এর flood কমবে না। এটা দ্রুত, loud, এবং ভালোভাবে লেখা হবে।

আমার অবস্থান

আমি Sophos-এর লেখাকে Mythos-এর একটি useful follow-up মনে করি, কারণ এটি debate-কে model room থেকে operations room-এ নিয়ে আসে।

Mythos হলো spectacular 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 করে না, সে সেই মানুষের সময় নষ্ট করে যাদের বাস্তব problems solve করা উচিত।

এটা frontier model zero-days খুঁজে পাওয়ার মতো glamorous শোনায় না। কিন্তু ঠিক সেখানেই ঠিক হয় security gain defenders-এর কাছে পৌঁছাবে, নাকি সবাই আরও noise-এ ডুবে যাবে।

আবার দেখা হবে,
Joe