রেসপনসিবল ডিসক্লোজার ও বাগ বাউন্টি বেসিকস

Responsible disclosure & bug bounty basics

৮ মিনিট পড়া শুরু · Beginner Python কোডসহ সম্পূর্ণ বাংলায়

এক নজরে · TL;DR

রেসপনসিবল (কো-অর্ডিনেটেড) ডিসক্লোজার মানে vendor-কে প্রাইভেটে জানানো এবং একটি নির্দিষ্ট সময়সীমা (সাধারণত ৯০ দিন) দেওয়া, প্যাচ করার জন্য, পাবলিকলি জানানোর আগে।
ফুল/ইনস্ট্যান্ট ডিসক্লোজার ব্যবহারকারীদের ঝুঁকিতে ফেলে (প্যাচের আগেই দুর্বলতা প্রকাশ্যে চলে আসে); নন-ডিসক্লোজার মানে দুর্বলতা কখনোই ঠিক হয় না।
বাগ বাউন্টি প্রোগ্রাম — HackerOne, Bugcrowd-এর মতো প্ল্যাটফর্মে কোম্পানিগুলো নির্ধারিত স্কোপের মধ্যে দায়িত্বশীলভাবে রিপোর্ট করা বাগের জন্য গবেষকদের অর্থ প্রদান করে।

এই পাঠে যা শিখবেন

রেসপনসিবল/কো-অর্ডিনেটেড ডিসক্লোজার প্রক্রিয়া এবং কেন এটি শিল্পের মান
ফুল ডিসক্লোজার ও নন-ডিসক্লোজারের ঝুঁকি — তিনটি পদ্ধতির তুলনা
বাগ বাউন্টি প্রোগ্রাম কীভাবে কাজ করে এবং কেন কোম্পানিগুলো এতে বিনিয়োগ করে
রিপোর্টের তারিখ থেকে ডিসক্লোজারের সময়সীমা কীভাবে গণনা করা হয়

১ · রেসপনসিবল ডিসক্লোজার — একজন সৎ গবেষক যা করেন

L02-এ আমরা দেখেছি White Hat হ্যাকাররা লিখিত অনুমতি নিয়ে কাজ করেন। কিন্তু একজন স্বাধীন গবেষক যিনি একটি সাইটের সর্বজনীন অংশ ঘুরে (কোনো আক্রমণাত্মক টেস্টিং ছাড়াই) একটি দুর্বলতা আবিষ্কার করেন — তার জন্য নির্ধারিত পথ হলো রেসপনসিবল ডিসক্লোজারResponsible / Coordinated Disclosureএকটি দুর্বলতা প্রথমে vendor-কে প্রাইভেটভাবে জানানো এবং তাদের প্যাচ করার জন্য যুক্তিসঙ্গত সময় দেওয়া, তারপরই — এবং শুধু তারপরই — জনসাধারণকে জানানো। —

প্রাইভেট রিপোর্ট — vendor-এর নিরাপত্তা দলকে সরাসরি জানানো, পাবলিক ফোরামে নয়।
যুক্তিসঙ্গত সময় দেওয়া — সাধারণত ৯০ দিন (Google Project Zero-র সুপরিচিত নীতি) প্যাচ তৈরি ও রোলআউটের জন্য।
সমন্বিত পাবলিক ডিসক্লোজার — প্যাচ প্রকাশিত হওয়ার পর (অথবা সময়সীমা শেষ হলে) প্রযুক্তিগত বিস্তারিত প্রকাশ করা, যাতে সম্প্রদায় শিখতে পারে।

Responsible Disclosure
প্রাইভেট রিপোর্ট + সময়সীমা + সমন্বিত প্রকাশ। ব্যবহারকারী ও vendor উভয়ের স্বার্থ রক্ষা করে — শিল্পের মান।

Full/Instant Disclosure
কোনো সময় না দিয়েই সাথে সাথে সব বিস্তারিত পাবলিক করে দেওয়া — প্যাচ তৈরির আগেই আক্রমণকারীদের হাতিয়ার তুলে দেয়, ব্যবহারকারীদের ঝুঁকিতে ফেলে।

Non-disclosure
দুর্বলতা কাউকে না জানানো — vendor কখনো জানতে পারে না, তাই দুর্বলতা কখনো ঠিক হয় না এবং অন্য কেউ (সম্ভবত একজন Black Hat) এটি স্বাধীনভাবে খুঁজে পেলে কোনো সতর্কতা ছাড়াই কাজে লাগাতে পারে।

কেন ৯০ দিন একটি ব্যালেন্স পয়েন্ট

সময়সীমা খুব কম হলে vendor জটিল প্যাচ তৈরির যথেষ্ট সময় পায় না; খুব বেশি হলে ব্যবহারকারীরা অনেক দিন ধরে একটি অরক্ষিত দুর্বলতা নিয়ে ঝুঁকিতে থাকে (এবং vendor-এর প্যাচ করার তাড়া কমে যায়)। ৯০ দিন এই দুই চাপের মধ্যে একটি ব্যবহারিক ভারসাম্য হিসেবে শিল্পে ব্যাপকভাবে গৃহীত।

২ · বাগ বাউন্টি প্রোগ্রাম

রেসপনসিবল ডিসক্লোজারকে প্রাতিষ্ঠানিক রূপ দিয়ে, অনেক কোম্পানি এখন বাগ বাউন্টি প্রোগ্রামBug Bounty Programএকটি আনুষ্ঠানিক প্রোগ্রাম যেখানে কোম্পানি স্বাধীন গবেষকদের নির্ধারিত স্কোপের মধ্যে দুর্বলতা খুঁজে দায়িত্বশীলভাবে রিপোর্ট করার জন্য অর্থ প্রদান করে। চালায় — HackerOne ও Bugcrowd এই ধরনের প্রোগ্রামের সবচেয়ে পরিচিত প্ল্যাটফর্ম। প্রতিটি প্রোগ্রামের একটি স্পষ্ট স্কোপ থাকে (কোন সিস্টেম টেস্ট করা যাবে, কোনটি নয় — L01-এর RoE ধারণারই একটি বাণিজ্যিক রূপ), এবং পুরস্কারের পরিমাণ প্রায়ই দুর্বলতার CVSS স্কোরের (L14-এ বিস্তারিত) উপর ভিত্তি করে নির্ধারিত হয় — একটি Critical-severity বাগের পুরস্কার একটি Low-severity বাগের চেয়ে অনেক বেশি হয়।

বাগ বাউন্টি প্রোগ্রামের স্কোপের বাইরে কিছু টেস্ট করা — এমনকি একই কোম্পানির অন্য কোনো সিস্টেমে — অনুমতির বাইরে চলে যায় এবং L01-এর নীতি অনুযায়ী আইনি ঝুঁকি তৈরি করতে পারে। "প্রোগ্রামে অংশ নিচ্ছি" মানেই "সবকিছু পরীক্ষা করার অনুমতি আছে" নয়।

৩ · কোড সেল — ডিসক্লোজার সময়সীমা গণনা

একটি রিপোর্ট জমা দেওয়ার দিন থেকে কত দিন পর পাবলিক ডিসক্লোজার করা যুক্তিসঙ্গত, তা গণনা করার জন্য আমরা সাধারণ পূর্ণসংখ্যা দিন-গণনা ব্যবহার করব (বাস্তব ক্যালেন্ডার তারিখের প্রয়োজন নেই) — যেখানে দিন ০ হলো রিপোর্ট জমা দেওয়ার দিন।

Python

def days_until_public(report_day, disclosure_policy_days=90):
    """report_day: রিপোর্ট জমা দেওয়ার দিন-সংখ্যা (যেমন দিন ৫০)
       disclosure_policy_days: নীতি অনুযায়ী কতদিন অপেক্ষা করা হবে (ডিফল্ট ৯০)
       রিটার্ন করে: যেই দিন পাবলিক ডিসক্লোজার করা যুক্তিসঙ্গত"""
    return report_day + disclosure_policy_days

# তিনটি ভিন্ন কেস
report_a = days_until_public(report_day=50)                       # স্ট্যান্ডার্ড ৯০ দিন
report_b = days_until_public(report_day=50, disclosure_policy_days=45)  # দ্রুততর নীতি
report_c = days_until_public(report_day=50, disclosure_policy_days=90)  # পুনরায় স্ট্যান্ডার্ড, তুলনার জন্য

print("রিপোর্ট জমার দিন: ৫০")
print("স্ট্যান্ডার্ড ৯০-দিন নীতি -> পাবলিক ডিসক্লোজারের দিন:", report_a)
print("কিছু প্রোগ্রামের ৪৫-দিন নীতি -> পাবলিক ডিসক্লোজারের দিন:", report_b)
print()
print("এখন ধরুন আজ দিন ১০০ — সময়সীমা কি পার হয়ে গেছে?")
today = 100
print("৯০-দিন নীতি অনুযায়ী সময়সীমা পার হয়েছে?", today > report_a)

মূল কথা · Key takeaway

রেসপনসিবল ডিসক্লোজার একটি নৈতিক দায়িত্বের প্রক্রিয়াগত রূপ — প্রাইভেট রিপোর্ট, যুক্তিসঙ্গত সময়সীমা, সমন্বিত প্রকাশ। বাগ বাউন্টি প্রোগ্রাম এই একই নীতিকে একটি আর্থিক প্রণোদনার কাঠামোর মধ্যে রূপ দেয় — কিন্তু উভয় ক্ষেত্রেই মূল নিয়ম অপরিবর্তিত থাকে: স্কোপের মধ্যে থেকে, দায়িত্বের সাথে, এবং ক্ষতি না করে কাজ করা।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ একজন গবেষক ধৈর্য হারিয়ে vendor-কে না জানিয়ে সরাসরি একটি দুর্বলতার সম্পূর্ণ প্রযুক্তিগত বিবরণ টুইট করে দিলেন — এটি কোন ধরনের ডিসক্লোজার এবং এতে কারা সবচেয়ে বেশি ঝুঁকিতে পড়েন?

এটি Full/Instant Disclosure। সবচেয়ে বেশি ঝুঁকিতে পড়েন সাধারণ ব্যবহারকারীরা — কারণ vendor-এর প্যাচ তৈরির কোনো সুযোগ পাওয়ার আগেই প্রতিটি Black Hat হ্যাকার এখন জানে ঠিক কীভাবে দুর্বলতাটি কাজে লাগাতে হয়। একজন গবেষকের হতাশা যতই ন্যায্য হোক, এই পদ্ধতি ক্ষতির ঝুঁকিকে সবচেয়ে বেশি বাড়িয়ে দেয়।

প্র ০২ একটি কোম্পানি যদি জানার পরেও বছরের পর বছর একটি রিপোর্ট করা দুর্বলতা প্যাচ না করে, তাহলে গবেষকের কী করা উচিত বলে আপনার মনে হয় — এবং কেন এটি একটি নৈতিক দ্বিধা?

এখানেই রেসপনসিবল ডিসক্লোজার নীতির আসল উদ্দেশ্য প্রকাশ পায় — সময়সীমা শুধু vendor-কে চাপ দেওয়ার জন্য নয়, বরং ব্যবহারকারীদের অনির্দিষ্টকালের জন্য ঝুঁকিতে রাখা থেকে রক্ষা করার জন্যও। একটি যুক্তিসঙ্গত সময়সীমা পার হওয়ার পর পাবলিক ডিসক্লোজার সাধারণত গ্রহণযোগ্য বিবেচিত হয় — এটি নৈতিক দ্বিধা কারণ এতে vendor-এর সুনাম ক্ষতিগ্রস্ত হয়, কিন্তু এটি না করলে ব্যবহারকারীরা অনির্দিষ্টকালের জন্য অন্ধকারে ঝুঁকিতে থেকে যান।

প্র ০৩ একই ধরনের দুইটি দুর্বলতা — একটি Critical CVSS স্কোরের, একটি Low CVSS স্কোরের — একটি বাগ বাউন্টি প্রোগ্রামে কেন ভিন্ন পুরস্কার পায়?

বাগ বাউন্টি পুরস্কার সাধারণত ঝুঁকির (risk-based) ভিত্তিতে নির্ধারিত হয়, শুধু "কতটা কঠিন খুঁজে পাওয়া গেছে" তার ভিত্তিতে নয়। একটি Critical দুর্বলতা (যেমন সম্পূর্ণ সিস্টেম টেকওভার সম্ভব) একটি Low দুর্বলতার (যেমন সামান্য তথ্য ফাঁস) চেয়ে অনেক বেশি সম্ভাব্য ক্ষতি করতে পারে — তাই কোম্পানি বেশি অর্থ দিয়ে দ্রুত প্যাচ করার প্রণোদনা তৈরি করে। এটি L04-এ শেখা risk-based prioritization-এরই একটি বাস্তব প্রয়োগ।

অনুশীলন

চিন্তা করুন: কল্পনা করুন আপনি একটি জনপ্রিয় ওয়েবসাইটে একটি দুর্বলতা খুঁজে পেয়েছেন। রেসপনসিবল ডিসক্লোজারের তিনটি ধাপ (প্রাইভেট রিপোর্ট, সময়সীমা, সমন্বিত প্রকাশ) অনুসরণ করে আপনি ঠিক কী কী পদক্ষেপ নেবেন তা ক্রমানুসারে লিখুন।

সাধারণ ক্রম: (১) কোম্পানির নিরাপত্তা টিমের অফিসিয়াল যোগাযোগ চ্যানেল (security.txt, বাগ বাউন্টি প্রোগ্রাম, বা security@ ইমেইল) খুঁজে বের করে প্রাইভেটভাবে বিস্তারিত রিপোর্ট পাঠানো; (২) একটি যুক্তিসঙ্গত সময়সীমা (সাধারণত ৯০ দিন) প্রস্তাব করা এবং vendor-এর প্রতিক্রিয়ার জন্য অপেক্ষা করা; (৩) প্যাচ প্রকাশিত হওয়ার পর (বা সময়সীমা পার হলে) সমন্বিতভাবে প্রযুক্তিগত বিবরণ প্রকাশ করা।
পরীক্ষা করুন: উপরের কোড সেলে report_day=50-এর বদলে report_day=200 ব্যবহার করে এবং today = 250 সেট করে Run চাপুন — সময়সীমা পার হয়েছে কি না দেখুন।

report_day=200 ও ৯০-দিন নীতিতে পাবলিক ডিসক্লোজারের দিন হবে ২৯০। যেহেতু today = 250 এখনো ২৯০-এর কম, তাই today > report_a ফলাফল হবে False — অর্থাৎ সময়সীমা এখনো পার হয়নি, vendor-কে আরও সময় দেওয়া উচিত।