افشای آسیب‌پذیری؛ Authorization تا Coordination

پاسخ کوتاه: افشای هماهنگ آسیب‌پذیری یا Coordinated Vulnerability Disclosure (CVD) یک شعار اخلاقی و یک مهلت ثابت برای انتشار نیست؛ پرونده‌ای کنترل‌شده است که از مجوز و محدوده آغاز می‌شود، گزارش را از مسیر امن می‌گیرد، شواهد را حداقلی نگه می‌دارد، ذی‌نفعان را هماهنگ می‌کند و با توجه به خطر بهره‌برداری، آمادگی اصلاح و آسیب کاربران دربارهٔ اطلاع‌رسانی تصمیم می‌گیرد. قصد خوب، یافتن security.txt، ارسال خصوصی یک PoC یا صبرکردن ۹۰ روز به‌تنهایی مجوز، مصونیت حقوقی یا تکمیل CVD را ثابت نمی‌کند.

این راهنما برای تیم QA، AppSec، مالک محصول و مسئول دریافت گزارش نوشته شده است. هدف آن، ساختن Vulnerability Disclosure Case Record از Authorization تا Coordination است؛ نه آموزش کشف یا بهره‌برداری، نه توصیهٔ حقوقی و نه نسخه‌ای برای افشای عمومی. تمام مثال‌ها ساختگی، آفلاین و بدون هدف واقعی‌اند.

مالکیت این مقاله: پروندهٔ افشای هماهنگ، نه تست امنیت

اگر پرسش شما طراحی آزمون و Rules of Engagement است، راهنمای تست امنیت نرم‌افزار مرجع مناسب‌تری است. اگر باید یک Security Claim را تا تصمیم Release دنبال کنید، به همکاری QA و AppSec بروید. مقالهٔ حاضر از لحظه‌ای آغاز می‌شود که یک مشاهدهٔ بالقوه مهم باید بدون افزودن آسیب دریافت، ثبت، ارزیابی، هماهنگ و در نهایت بسته یا اطلاع‌رسانی شود.

مرزهای دیگر نیز مهم‌اند: مدیریت Ticketهای عادی در مدیریت نقص نرم‌افزار پوشش داده شده؛ تحلیل پس از سوءاستفاده واقعی در تحلیل رخنه امنیتی است؛ و گزارش تخلف یا خطر سازمانی به مسیر افشاگری در توسعه نرم‌افزار تعلق دارد. CVD ممکن است با هرکدام تماس داشته باشد، اما جای آنها را نمی‌گیرد.

واژهٔ «مسئولانه» کافی نیست؛ هماهنگی قابل مشاهده لازم است

برچسب Responsible Disclosure می‌تواند داوری اخلاقی مبهمی ایجاد کند: چه کسی «مسئول» بوده و بر اساس کدام قاعده؟ اصطلاح CVD تمرکز را به کار قابل‌مشاهده می‌برد: اطلاعات از Finder/Reporter گرفته می‌شود، میان Vendor/Deployer/Coordinator به اندازهٔ نیاز گردش می‌کند، Mitigation و Fix پیش می‌روند و محتوای مناسب در زمان مناسب به مخاطب مناسب می‌رسد. راهنمای رسمی CERT/CC برای CVD نیز آن را فرایند گردآوری، هماهنگی و افشای اطلاعات آسیب‌پذیری و راهکارهای کاهش خطر معرفی می‌کند.

پنج مرز که نباید با هم مخلوط شوند

مفهوم	پرسش اصلی	چیزی که ثابت نمی‌کند
Authorization	چه کسی، روی کدام دارایی و با چه فعالیتی اجازه دارد؟	خوب‌بودن قصد یا مفیدبودن نتیجه
VDP	سازمان چه سیاست و کانال عمومی برای دریافت دارد؟	وجود جایزه یا مجوز خارج از متن سیاست
CVD Case	این گزارش مشخص چگونه هماهنگ و تصمیم‌گیری می‌شود؟	اینکه یافته حتماً معتبر یا قابل CVE است
Bug Bounty	شرایط پذیرش و پاداش چیست؟	پرداخت قطعی یا پوشش همهٔ دارایی‌ها
Incident Response	آیا بهره‌برداری یا آسیب جاری باید مهار شود؟	اینکه پرونده فقط یک Vulnerability Report عادی است

Intent مجوز نیست

تقسیم افراد به White Hat و Black Hat بر اساس ادعای نیت، کنترل عملیاتی قابل اتکایی نیست. مجوز به Actor، Asset، Activity، Time و Terms وابسته است. یک فعالیت ممکن است برای دامنه‌ای مجاز و برای Subdomain، Tenant، شریک تجاری یا دادهٔ شخص ثالث ممنوع باشد. حتی اگر نتیجه امنیت را بهتر کند، عبور از مرز احراز هویت، تغییر داده، ایجاد حساب برای دیگران، ماندگاری، حرکت جانبی، دسترسی به دادهٔ واقعی یا اختلال در Availability می‌تواند خارج از مجوز باشد.

برای خوانندهٔ ایرانی نیز قاعدهٔ امن همین است: از روی عرف اینترنت، نیت خیر، ملیت مالک یا دسترس‌پذیری عمومی، اجازهٔ فنی یا نتیجهٔ حقوقی استنتاج نکنید. متن سیاست، قرارداد، مالکیت دارایی، قانون قابل اعمال و نظر متخصص واجد صلاحیت باید جدا بررسی شود. این مقاله مجوز انجام هیچ تستی روی سامانهٔ واقعی نمی‌دهد.

Safe Harbor مصونیت عمومی نیست

عبارت Safe Harbor در یک VDP معمولاً تعهد یا موضع همان سازمان را دربارهٔ فعالیت‌های منطبق با همان سیاست بیان می‌کند. دامنهٔ دقیق آن به متن، مرجع صادرکننده، شرایط، حوزهٔ قضایی و اشخاص ثالث بستگی دارد؛ بنابراین مترادف «مصونیت قانونی جهانی» نیست. برای نمونه، VDP وزارت دادگستری آمریکا فعالیت منطبق با سیاست خود را مجاز تلقی می‌کند و هم‌زمان فعالیت ناسازگار با سیاست یا قانون را مجاز نمی‌داند. این نمونه قابل کپی‌کردن به هر سازمان یا کشور نیست.

security.txt مسیر تماس است، نه چراغ سبز تست

RFC 9116 قالب ماشین‌خوان security.txt را برای اعلام Contact، Policy، Encryption، Acknowledgments و اطلاعات مرتبط تعریف می‌کند. فایل اصلی برای وب در مسیر /.well-known/security.txt قرار می‌گیرد و Scope آن به میزبان دریافت‌شده محدود است، مگر Policy جزئیات دیگری بدهد. خود RFC صریحاً هشدار می‌دهد که وجود این فایل اجازهٔ ضمنی تست ایجاد نمی‌کند.

پس کنترل درست این نیست که «فایل پیدا شد؟»؛ بلکه این است: فایل چه زمانی و از کدام میزبان خوانده شد، Expiry و Signature چه بود، Policy به کجا اشاره می‌کرد، Redirect معتبر بود، کدام Contact ترجیحی بود، Encryption چگونه انجام می‌شد و کدام Asset/Activity واقعاً در محدوده قرار داشت. نسخهٔ Snapshot‌شده را کنار Case نگه دارید، چون سیاست ممکن است بعداً تغییر کند.

VDP با Bug Bounty یکی نیست

VDP راه گزارش و قواعد تعامل را مشخص می‌کند؛ Bug Bounty لایه‌ای قراردادی برای Eligibility، Duplicate، Severity، پاداش، پرداخت، مالیات، کشورها و محدودیت‌های برنامه می‌افزاید. یک VDP می‌تواند هیچ جایزه‌ای نداشته باشد و یک برنامهٔ Bounty نیز ممکن است فقط چند Asset را پوشش دهد. دریافت گزارش، تأیید آسیب‌پذیری، تخصیص CVE و پرداخت چهار تصمیم مستقل‌اند.

CVE هم گواهی شدت یا پاداش نیست

CVE یک شناسه برای رکورد عمومی آسیب‌پذیری واجد شرایط است، نه مهر اثبات فنی، رتبهٔ کیفیت محصول، تعیین مالکیت کشف یا تعهد پرداخت. در Case Record، وضعیت درخواست/رزرو/انتشار CVE، CNA مسئول و مرجع رکورد را جدا نگه دارید. تصمیم Mitigation نباید تا گرفتن شناسه معطل بماند و نبود CVE نیز به‌تنهایی Finding را باطل نمی‌کند.

چرخهٔ عملیاتی از Policy تا Correction

Policy، Authorization و Scope را Snapshot کنید.
با Stop Condition و حداقل تماس، از افزودن آسیب جلوگیری کنید.
گزارش و Evidence حداقلی را از کانال امن تحویل بگیرید.
Ack، مرجع Case و زمان به‌روزرسانی بعدی بدهید.
Validity، Exposure، Harm و فوریت را با عدم‌قطعیت Triage کنید.
Vendor، Supplier، Deployer و Coordinator لازم را Need-to-know هماهنگ کنید.
Mitigation، Fix، Verification و Deployment را جدا دنبال کنید.
دربارهٔ مخاطب، زمان و سطح جزئیات Disclosure تصمیم ثبت‌شده بگیرید.
Case را با Retention، Correction و تاریخچهٔ تغییر ببندید.

Artifact اصلی: Vulnerability Disclosure Case Record

CaseID / Version / Status / Classification
PolicyID / PolicyVersion / PolicySnapshot / AuthorizationEvidence
Actor / Asset / Activity / Time / Terms / Scope / StopConditions
FindingClaim / ObservedImpact / PotentialImpact / Confidence / NotClaimed
EvidenceRefs / Redaction / Access / Retention / DeleteEvidence
ReceivedAt / AcknowledgedAt / NextUpdateAt / Owners / DecisionRights
Triage / Exposure / Harm / ExploitationSignal / Uncertainty
Participants / NeedToKnow / Milestones / Dependencies / MessageLog
Mitigation / Fix / Verification / Deployment / ResidualRisk
DisclosureOptions / Criteria / Authority / Rationale / Audience / DetailLimit
StateHistory / Reassessment / Closure / Correction / Supersession

این Schema استاندارد CERT، CISA، NIST یا RFC نیست؛ یک ترکیب عملی برای QA است. فیلدها باید به رکوردهای واقعی سازمان، طبقه‌بندی اطلاعات و الزامات حقوقی آن تطبیق داده شوند. وجود همهٔ فیلدها نیز فقط آمادگی ساختاری را نشان می‌دهد، نه صحت Finding یا درستی تصمیم.

Case را با هویت و نسخهٔ پایدار آغاز کنید

CaseID تغییرناپذیر، نسخهٔ رکورد، وضعیت، Owner، Classification، Created/Updated و Review date را ثبت کنید. Subject ایمیل یا نام عمومی آسیب‌پذیری شناسهٔ کافی نیست؛ ممکن است عنوان تغییر کند، چند گزارش Duplicate شوند یا چند محصول متاثر باشند. اصلاح بعدی باید Revision جدید و رابطهٔ Supersedes بسازد، نه اینکه تاریخچه را بی‌صدا بازنویسی کند.

Authorization Snapshot پیش از Evidence

Policy ID/Version/URL، متن دقیق Authorization، بازهٔ زمانی، Actor واجد شرایط، Activities مجاز و ممنوع، Terms قابل اعمال و مدرک Snapshot را ثبت کنید. اگر Policy مبهم، منقضی، متعارض یا بدون مالک است، وضعیت را SCOPE_UNKNOWN نگه دارید و فعالیت بیشتری انجام ندهید. QA نباید ابهام حقوقی را با فرض فنی پر کند.

Scope باید دارایی قابل شناسایی باشد

نام برند یا دامنهٔ اصلی به‌تنهایی Scope نیست. Asset owner، hostname/app/package، نسخه، environment، Tenant، API، Mobile build، Cloud account، Third-party boundary، dependency و Out-of-scope را بنویسید. Redirect، CDN، SaaS، فروشندهٔ پرداخت، کتابخانهٔ مستقل و دامنهٔ خواهر ممکن است مالک دیگری داشته باشند. Scope Snapshot را به زمان مشاهده گره بزنید.

Stop Condition قبل از هر تماس فعال

احتمال دسترسی به دادهٔ شخص دیگر یا Secret؛
نیاز به Persistence، Pivot، تغییر داده یا دورزدن کنترل بیشتر؛
اثر بر Availability، هزینه، پیام یا عملیات واقعی؛
دارایی، Tenant یا طرف ثالث خارج از Scope؛
مشاهدهٔ بهره‌برداری جاری یا قربانی واقعی؛
ابهام در Authorization یا تضاد Policyها.

در این نقاط، اقدام امن توقف، حفظ حداقل Fact، محدودکردن دسترسی و استفاده از مسیر Escalation است. «برای اثبات کامل‌تر ادامه دادم» توجیه مناسبی برای افزودن آسیب نیست. Reproduction باید فقط توسط نقش مجاز، در محیط مناسب و با Plan ازپیش‌تأییدشده انجام شود.

Finding Claim را از Fact جدا کنید

لایه	نمونهٔ امن و محدود
Observation	در Fixture آفلاین، پاسخ با انتظار قرارداد متفاوت بود.
Interpretation	ممکن است کنترل دسترسی در این مسیر اعمال نشده باشد.
Hypothesis	نسخه‌های هم‌خانواده شاید همان الگو را داشته باشند؛ بررسی نشده‌اند.
Confirmed scope	فقط Build و Fixture ثبت‌شده، نه Production یا نسخه‌های دیگر.
Not claimed	بهره‌برداری واقعی، گسترهٔ کاربران، علت ریشه‌ای و شدت نهایی اثبات نشده است.

Observed impact با Potential impact یکی نیست. Confidence، prerequisites، affected component/version، duplicate key و Not-claimed boundaries را ثبت کنید. عباراتی مانند «بحرانی»، «همهٔ کاربران»، «RCE» یا «داده‌ها لو رفت» بدون Evidence متناسب، هم Triage را منحرف می‌کند و هم خطر انتشار غیرضروری را بالا می‌برد.

Evidence حداقلی، قابل ردیابی و امن

EvidenceID، زمان و محیط جمع‌آوری، مرجع Authorization، مراحل حداقلی، Hash، Redaction، Sample limit، روش انتقال امن، Access list، Retention و Delete evidence را نگه دارید. Token، Cookie، دادهٔ شخصی، Secret، Log حجیم و Screenshot حاوی اطلاعات دیگران را در Ticket عمومی نریزید. اصل «هرچه بیشتر بهتر» برای Evidence امنیتی غلط است.

برای کیفیت گزارش عادی می‌توانید از ساختار گزارش باگ حرفه‌ای الهام بگیرید، اما Vulnerability Report کانال، طبقه‌بندی، دسترسی و Redaction سخت‌گیرانه‌تری می‌خواهد. اگر Evidence حساس ناخواسته دریافت شد، دسترسی را محدود، مشاهده را ثبت و مسیر Incident/Privacy را فعال کنید؛ از Reporter نخواهید دوباره دادهٔ واقعی بیشتری بفرستد.

گزارش حداقلی چه فیلدهایی دارد؟

راه تماس امن و ترجیح Credit/ناشناسی Reporter؛
خلاصهٔ بدون اغراق و Asset/Version متاثر؛
Observation، prerequisites و Impact boundary؛
مراحل حداقلی در محدودهٔ مجاز و محیط ثبت‌شده؛
Evidence reference امن، نه Secret در متن؛
زمان کشف و ارسال، Policy/Scope دیده‌شده؛
اقدام متوقف‌شده و هر دسترسی ناخواسته؛
مواردی که بررسی یا اثبات نشده‌اند.

کانال دریافت باید قابل اعتماد باشد

Contact ترجیحی، گزینهٔ Encryption، Fallback، اصالت دامنه/کلید و Delivery receipt را ثبت کنید. Inbox بی‌مالک، فرم بدون شماره پیگیری و پیام‌رسان شخصی، Case را شکننده می‌کند. سازمان باید مسیر عمومی را مرتب آزمایش کند: پیام تست بی‌خطر دریافت می‌شود؟ On-call می‌بیند؟ Attachment قرنطینه می‌شود؟ Ack صادر می‌شود؟ مسیر غیبت Owner چیست؟

Acknowledgment پذیرش ادعا نیست

Ack باید ReceivedAt، Case reference، کانال ادامه، Owner ارتباط و زمان تقریبی Update بعدی را بدهد؛ اما نباید پیش از Triage، Validity، Severity، پاداش یا Credit را تضمین کند. پاسخ کوتاه و روشن جلوی ارسال تکراری به کانال‌های ناامن را می‌گیرد. اگر گزارش ناقص است، حداقل اطلاعات لازم را مشخص کنید و درخواست Evidence اضافی را با Safety/Authorization بسنجید.

Triage امنیتی چهار سؤال مستقل دارد

Validity: Observation با محیط و نسخهٔ ثبت‌شده سازگار است؟
Exploitability: prerequisites و کنترل‌های جبرانی چیست؟
Exposure: کدام دارایی، نسخه، جمعیت و مدت در معرض است؟
Harm: پیامد محتمل برای کاربر، سازمان یا اکوسیستم چیست؟

این چهار محور را به یک برچسب Severity خام تقلیل ندهید. Confidence و Uncertainty را همراه هر نتیجه بنویسید. یک Finding با Impact بالقوه بالا اما Exposure نامعلوم، نیازمند بررسی سریع است؛ این به معنی انتشار فوری جزئیات یا اثبات Incident نیست.

Reproduction مجدد، حق خودکار تیم نیست

دریافت یک گزارش، مجوز Reproduction روی Production یا حساب Reporter را ایجاد نمی‌کند. محیط، داده، Actor، Plan، Stop condition و Evidence collection باید مجاز باشند. ترجیح با محیط جداشده، Fixture ساختگی و کمترین تعامل است. ابزارها و Pipelineهای امنیتی نیز باید همان Rule of Engagement را رعایت کنند؛ راهنمای ابزارهای تست امنیت مرز Scanner finding و حکم قطعی را توضیح می‌دهد.

نقش‌ها و Decision Right را زود تعیین کنید

Finder ممکن است Reporter نباشد؛ Vendor ممکن است Product owner نهایی نباشد؛ Deployer و Supplier ممکن است Mitigation متفاوتی بخواهند. حداقل نقش‌ها شامل Intake owner، Triage owner، Product/Fix owner، Security owner، Legal/Privacy route، Communications owner، Coordinator، Disclosure decision authority و Independent reviewer است. Shared responsibility یعنی همکاری، نه اینکه همه حق انتشار یا بستن Case داشته باشند.

Need-to-know با پنهان‌کاری دائمی فرق دارد

پیش از Mitigation، جزئیات می‌تواند Adversarial advantage ایجاد کند؛ پس Participants، Access و Message log را کنترل کنید. با این حال، محدودسازی نباید Supplier متاثر، Deployer در معرض یا Decision authority را از اطلاعات ضروری محروم کند. برای هر مخاطب بپرسید چه تصمیمی باید بگیرد، کدام Fact لازم است و کدام جزئیات فنی هنوز ضرورتی ندارد.

چه زمانی Coordinator لازم است؟

مالک پیدا نمی‌شود، چند Vendor/Dependency متاثرند، ارتباط متوقف شده، اختلاف بر سر Validity یا Timeline مانده، Reporter ایمنی یا بی‌طرفی می‌خواهد، یا اثر اکوسیستمی است؟ یک هماهنگ‌کننده مانند CERT/CSIRT مناسب می‌تواند Discovery، تماس، وابستگی و انتشار را تسهیل کند. Coordinator جای Vendor برای Fix یا جای مرجع حقوقی را نمی‌گیرد و پذیرش Case نیز تضمین‌شده نیست.

Timeline یک فرضیهٔ قابل بازنگری است، نه عدد مقدس

سیاست‌های مختلف ممکن است ۴۵، ۶۰، ۹۰ یا روزهای دیگری را هدف بگذارند؛ اینها قواعد همان برنامه‌اند، نه قانون طبیعی CVD. Timeline باید با Exploitation signal، Harm، availability of mitigation، پیچیدگی Fix، زنجیرهٔ تامین، Deployment coverage، هماهنگی کاربران و توان اطلاع‌رسانی بازبینی شود. «۹۰ روز گذشت، پس همهٔ جزئیات منتشر می‌شود» تصمیم ناقص و بالقوه آسیب‌زا است.

TimelineEvent = {
  occurredAt, observedAt, recordedAt,
  actor, eventType, evidenceRef,
  nextMilestone, dependency,
  riskChange, decisionRef
}

OccurredAt را از ObservedAt و RecordedAt جدا کنید. تأخیر در ثبت نباید به‌صورت تأخیر Vendor یا Reporter نمایش داده شود. Extension باید Owner، دلیل، خطر جدید، Milestone و Review date داشته باشد؛ سکوت نامحدود نیز Timeline نیست.

No Response مجوز انتشار خودکار نیست

اگر Contact پاسخ نمی‌دهد، اصالت مسیر، Receipt، Fallback، مالکیت Asset و تغییر Vendor را بررسی کنید؛ سپس Coordinator یا مسیر تخصصی مناسب را درگیر کنید. احتمال آسیب کاربران، بهره‌برداری فعال، دسترس‌بودن Mitigation و خطر جزئیات فنی را دوباره بسنجید. تصمیم انتشار باید Authority و Rationale داشته باشد؛ سکوت طرف مقابل به‌تنهایی آن را صادر نمی‌کند.

Mitigation، Fix و Deployment سه وضعیت متفاوت‌اند

خاموش‌کردن یک Feature یا افزودن Rule موقت Mitigation است؛ تغییر پایدار کد/پیکربندی می‌تواند Fix باشد؛ و موجودبودن Patch به معنی نصب آن نزد کاربران نیست. Remediation record باید Owner، Branch/Version متاثر، Workaround، Fix reference، Verification plan، Regression plan، Deployment evidence و Residual risk را جدا کند.

Patch موجود با «کاربران امن‌اند» برابر نیست

ممکن است Patch ناقص، ناسازگار، فقط برای شاخه‌ای خاص یا هنوز Deploy نشده باشد. Dependencyها، Applianceها، Mobile storeها، مشتریان On-prem و نسخه‌های End-of-life چرخه‌های متفاوت دارند. Verification فنی، امضا و اصالت بسته، دسترس‌پذیری، راهنمای Upgrade، Telemetry مجاز و Residual exposure باید در تصمیم لحاظ شوند.

Retest باید Claim را بیازماید، نه فقط Payload را

تکرار همان ورودی و دیدن پاسخ متفاوت فقط یک مشاهده است. Security Claim، نسخهٔ Fix، محیط، کنترل‌های مرتبط، Negative/Boundary cases و Regression scope را بنویسید. اگر Fix به Pipeline متکی است، Evidence تولید و نگهداری آن را نیز بررسی کنید؛ DevSecOps از Control تا Evidence این زنجیره را پوشش می‌دهد.

Active Exploitation مسیر را عوض می‌کند

نشانهٔ معتبر بهره‌برداری جاری، قربانی، دسترسی ناخواسته یا تغییر Production دیگر فقط یک CVD عادی نیست. Incident owner، حفظ Evidence، Containment، Privacy/Breach route، اطلاع‌رسانی ذی‌نفعان و در صورت لزوم مسیر قانونی فعال می‌شود. جزئیات باید میان Incident و CVD با شناسه و Access روشن پیوند بخورد، نه اینکه همه‌چیز در یک Ticket عمومی ادغام شود.

Disclosure Decision یک Gate چندمعیاره است

DisclosureDecision = {
  options: [continuePrivate, targetedNotice, mitigationFirstAdvisory, publicAdvisory, close],
  exploitationSignal, userHarm, mitigationAvailability,
  fixConfidence, deploymentCoverage, dependencyReadiness,
  reporterPosition, vendorPosition, uncertainty,
  authority, rationale, decidedAt, reviewAt
}

گزینه‌ها فقط «مخفی» یا «افشای کامل» نیستند. اطلاع محدود به Deployerهای متاثر، Advisory با Mitigation و جزئیات فنی کم، هماهنگی با Supplierها، تأخیر بازبینی‌شونده یا بستن ادعای پشتیبانی‌نشده هم ممکن است. تصمیم باید متناسب، قابل بازبینی و متصل به Evidence باشد.

مخاطب و زمان و جزئیات را جدا تصمیم بگیرید

ممکن است Deployerها پیش از عموم نیاز به اطلاع داشته باشند؛ ممکن است عموم فقط نسخه‌های متاثر و Mitigation را لازم داشته باشد؛ و جزئیات Reproduction تا افزایش Deployment coverage محدود بماند. یک Date واحد پاسخ سه پرسش نیست. برای Audience، Release time، Content level، Distribution channel و Owner رکورد مستقل بسازید.

Advisory دفاع‌محور بنویسید

محصول و نسخه‌های متاثر/غیرمتاثر با Confidence؛
Impact محدود و prerequisites بدون اغراق؛
Fix یا Mitigation قابل اجرا و روش بررسی وضعیت؛
تاریخ‌ها، شناسه‌ها و منابع رسمی؛
Credit فقط با رضایت Reporter؛
Unknownها و برنامهٔ Correction؛
حداقل جزئیات فنی لازم برای دفاع.

هدف Advisory کمک به تصمیم دفاعی است، نه نمایش مهارت، بازاریابی ترس یا انتشار دستور سوءاستفاده. اگر جزئیات خاص هنوز نسبت Attack/Defense نامطلوبی دارد، علت محدودسازی و زمان Review را ثبت کنید. «پس از Patch هر جزئیاتی امن است» نیز فرض معتبری نیست، چون Deployment و شاخه‌های متاثر ممکن است عقب باشند.

Credit و هویت Reporter نیازمند رضایت است

نام، Handle، سازمان، کانال تماس و ترجیح ناشناس‌ماندن را دادهٔ قابل حفاظت بدانید. Credit را پیش‌فرض نگیرید و تغییر ترجیح را تا Cutoff مشخص بپذیرید. Reporter ممکن است از Retaliation، محدودیت شغلی، خطر منطقه‌ای یا افشای ارتباطات نگران باشد. مسیر حمایت و بازبینی حقوقی را معرفی کنید، ولی وعدهٔ حفاظت یا نتیجه‌ای خارج از اختیار سازمان ندهید.

رسانه و شبکهٔ اجتماعی کانال Triage نیستند

بحث عمومی زودهنگام می‌تواند Scope، Reporter، کاربران و Fix را در معرض خطر قرار دهد. تیم Communications باید Factهای تاییدشده، مخاطب، زمان، سخنگو و Correction route داشته باشد. سکوت مطلق و تهدید Reporter نیز فرایند سالم نمی‌سازد؛ Ack، Update قابل پیش‌بینی و توضیح محدودیت‌ها اعتماد عملی ایجاد می‌کند.

Automation چه کاری می‌تواند انجام دهد؟

Automation برای تخصیص CaseID، کنترل Schema، Deadline reminder، Access expiry، Link integrity، Hash verification، Duplicate candidate و تولید Timeline مفید است. اما نباید از چند Keyword، CVSS خام یا شهرت Reporter به‌تنهایی Validity، Intent، Authorization، Severity نهایی، پاداش یا زمان Disclosure را صادر کند. Gateهای پراثر نیازمند Context و Authority انسانی‌اند.

AI فقط دستیار با Provenance و Redaction

سپردن Report، Secret یا دادهٔ شخصی به مدل بیرونی بدون مجوز می‌تواند یک افشای تازه بسازد. Model/provider/version، Data route، Retention، Access، Prompt، Redaction و Human review را ثبت کنید. AI می‌تواند خلاصه یا Missing-field پیشنهاد دهد، اما نباید Evidence اختراع کند، Exploitability را قطعی بداند یا متن Advisory را بدون بازبینی منتشر کند.

State Model جلوی «بسته شد» مبهم را می‌گیرد

RECEIVED → ACKNOWLEDGED → TRIAGE
TRIAGE → NEEDS_INFO | COORDINATING | NOT_SUPPORTED
COORDINATING → MITIGATION_READY → FIX_READY → DEPLOYMENT_TRACKING
any active state → INCIDENT_ESCALATED | ON_HOLD | DECISION_REVIEW
DECISION_REVIEW → DISCLOSED | CLOSED_PRIVATE | CLOSED_UNSUPPORTED
any closed state → CORRECTED

این State machine نیز پیشنهاد عملی این مقاله است. Transition باید Actor، زمان، Evidence و Reason داشته باشد. NOT_SUPPORTED یعنی شواهد فعلی Claim را پشتیبانی نکرده، نه اینکه Reporter بدخواه است. CLOSED_PRIVATE نیز به معنی پاک‌کردن تاریخچه یا منع Correction نیست.

Change Trigger و Reassessment

مشاهدهٔ Exploitation یا افزایش Harm؛
کشف نسخه، Vendor یا Dependency تازه؛
شکست Fix، Workaround یا Deployment؛
تغییر Policy، Scope یا Authorization؛
انتشار ناخواسته یا گزارش رسانه‌ای؛
از دست‌رفتن تماس یکی از طرف‌ها؛
Evidence تازه یا Correction Reporter/Vendor.

هر Trigger می‌تواند Priority، Participants، Timeline و Disclosure option را عوض کند. Reassessment date را از Calendar reminder منفعل به Gate متصل کنید: چه کسی چه داده‌ای را مرور می‌کند و اگر داده نرسید چه می‌شود؟

Closure بدون Retention و Correction کامل نیست

Closure criteria باید شامل تصمیم ثبت‌شده، وضعیت Mitigation/Fix، اطلاع مخاطبان لازم، Residual risk owner، Retention end و دسترسی آرشیو باشد. اگر Advisory یا ارزیابی قبلی اشتباه شد، CorrectionID، Supersedes، مخاطبان متاثر، Reissue plan و Evidence توزیع را ثبت کنید. پاک‌کردن متن قدیمی بدون اشاره به اصلاح، زنجیرهٔ اعتماد را می‌شکند.

آزمایش قطعی: هفت چراغ سبز جعلی

یک Validator مستقل و بدون وابستگی با Node.js ۲۴.۱۸.۰ روی پرونده‌ای ساختگی اجرا شد. Checker سطحی فقط دید برچسب Responsible Disclosure وجود دارد، گزارش خصوصی است، security.txt پیدا شده، PoC پیوست شده، ۹۰ روز گذشته، Patch منتشر شده و برنامه Bug Bounty وجود دارد؛ بنابراین به‌اشتباه نتیجه داد:

SUPERFICIAL=RESPONSIBLE_DISCLOSURE_COMPLETE

ممیز قراردادی ۲۱۲ کنترل یکتا را در ۲۲ گروه بررسی کرد: Identity، Authority، Scope، Safety، Finding، Evidence، Report، Channel، Intake، Triage، Roles، Coordination، Timeline، Remediation، Disclosure، Publication، Researcher، Bounty، Incident، Lifecycle، Correction و Limits. تمام کنترل‌ها در Fixture سطحی غایب بودند:

AUDIT=HOLD-212
INDEPENDENT_SAFETY=no-unauthorized-testing:PASS

قاعدهٔ ۲۱۳ام مستقل بود: noUnauthorizedTesting=true. آن را عمداً خارج از شمارش Missingها نگه داشتیم تا Safety با کامل‌بودن فرم مخلوط نشود. پس از پرکردن تمام فیلدهای ساختاری با مقادیر ساختگی و ممنوع‌کردن Network، Scanning، Exploitation و Persistence، خروجی چنین شد:

CORRECTED=READY_FOR_CVD_CASE_REVIEW-0
BOUNDARY=structure-only; no authorization, legality, vulnerability,
exploitability, remediation, safety, disclosure timing, CVE, bounty,
compliance, or real-world correctness proven

چرا صفر Finding هنوز Green نیست؟

Validator فقط حضور ساختار را می‌سنجد. ممکن است Policy جعلی، Scope اشتباه، Evidence ناکافی، Assessor نامناسب یا Decision غیرمنطقی باشد. نتیجهٔ درست READY_FOR_CVD_CASE_REVIEW است، نه LEGALLY_SAFE یا VULNERABILITY_CONFIRMED. بازبینی انسانی باید Provenance، محتوا و Authority را ارزیابی کند.

آزمایشگاه آفلاین فارسی و ایرانی

برای تمرین، یک Checkout کاملاً ساختگی بسازید: Order، PaymentAttempt، PSP Stub، Callback، Ledger، Reconciliation و Notification فقط در حافظه/فایل محلی. سناریوها شامل Timeout پیش و پس از Commit ساختگی، Retry، Duplicate، Callback دیرهنگام و Reordering هستند. هیچ Network، Production، دامنه، شرکت، شخص، سفارش، پرداخت، PSP یا بانک واقعی وجود ندارد.

شناسه‌های Tenant/Order/Attempt/Event/Build/Run/Case/Decision پایدار و ساختگی‌اند. مبلغ فقط IRR تخیلی است؛ نمایش تومان صرفاً Presentation و با برچسب روشن است. ارقام فارسی/عربی/لاتین، ی/ی، ک/ک، ZWNJ، RTL/LTR/Bidi، زمان UTC و نمای Asia/Tehran و تاریخ جلالی صرفاً نمایشی آزموده می‌شوند. هیچ PII، نام، کدملی، موبایل، ایمیل، IP، PAN، CVV2، OTP، حساب، Cookie، Token، Credential، Log یا Screenshot واقعی وارد Lab نمی‌شود.

LabBoundary = {
  network: false,
  production: false,
  realTarget: false,
  unauthorizedTesting: false,
  realPersonOrPaymentData: false,
  purpose: "validate CVD record structure only"
}

سناریوی تمرین بدون آموزش سوءاستفاده

یک Contract ساختگی می‌گوید هر Attempt فقط به Order همان Tenant متصل است.
Fixture ازپیش‌ساخته یک Observation ناسازگار تولید می‌کند؛ هیچ Payload یا Target واقعی وجود ندارد.
دانشجو Observation را از Potential impact و Not-claimed جدا می‌کند.
گزارش با EvidenceID محلی، Redaction و Stop condition ثبت می‌شود.
تیم Ack، Triage، نقش‌ها و Timeline را پر می‌کند.
سه گزینهٔ ادامهٔ هماهنگی خصوصی، Advisory دفاع‌محور و بستن ادعای پشتیبانی‌نشده مقایسه می‌شوند.
Correction ساختگی نشان می‌دهد چگونه Fact جدید تصمیم قبلی را Supersede می‌کند.

Anti-patternهایی که باید رد شوند

«قصد من خوب بود، پس مجاز بود»؛
«security.txt هست، پس همهٔ Subdomainها Scope هستند»؛
«Safe Harbor یعنی مصونیت کامل»؛
«PoC خصوصی است، پس هر داده‌ای مجاز است»؛
«۹۰ روز تمام شد، پس انتشار کامل خودکار است»؛
«Patch آمده، پس همه Deploy کرده‌اند»؛
«CVSS بالا است، پس Incident تایید شده»؛
«CVE داریم، پس Finding و Credit و پاداش قطعی است»؛
«Bug Bounty هست، پس پول تضمین است»؛
«No response یعنی اجازهٔ انتشار»؛
«Reporter ناشناس است، پس بدخواه است»؛
«Responsible label یعنی فرایند کامل است»؛
«اسکنر دوباره اجرا شد، پس Fix تایید است»؛
«اطلاعات بیشتر همیشه Evidence بهتر است»؛
«بستن Ticket یعنی حذف تاریخچه»؛
«AI می‌تواند بدون Redaction گزارش را خلاصه کند»؛
«QA باید حکم قانونی یا اخلاقی بدهد»؛
«یک سیاست خارجی عیناً برای ایران قابل اعمال است».

چک‌لیست Owner پیش از Decision Review

CaseID، نسخه، Owner و Classification روشن است.
Policy/Authorization/Scope Snapshot و زمان آن ثبت شده است.
Actor/Asset/Activity/Time/Terms و Out-of-scope مشخص‌اند.
Stop conditions و واکنش به دسترسی ناخواسته تایید شده‌اند.
Observation/Potential impact/Confidence/Not-claimed جدا هستند.
Evidence حداقلی، Redacted، Hash‌شده و دارای Retention است.
کانال معتبر، Receipt، Ack و Next update وجود دارد.
Validity/Exploitability/Exposure/Harm با Uncertainty ثبت شده‌اند.
Roleها و Disclosure authority نام‌گذاری شده‌اند.
Participants و Need-to-know و Message log کامل‌اند.
Milestoneها بر اساس Risk و Dependency بازبینی می‌شوند.
Mitigation/Fix/Verification/Deployment/Residual risk جدا هستند.
Exploitation signal مسیر Incident را فعال می‌کند.
گزینه‌ها، معیارها، مواضع طرفین و Rationale تصمیم ثبت شده‌اند.
Audience/Time/Detail level مستقل انتخاب شده‌اند.
Credit رضایتی و دادهٔ Reporter محافظت شده است.
Bounty/CVE/VDP/CVD وضعیت‌های جدا دارند.
Closure/Retention/Correction/Supersession تعریف شده است.
هیچ ادعای مجوز، مصونیت، Zero risk یا Deadline جهانی نشده است.
هیچ دستور بهره‌برداری یا Target واقعی در Lab وجود ندارد.

Pilot سی‌روزهٔ فرایند، بدون دعوت به تست واقعی

هفتهٔ اول: روی پرونده‌های تاریخی Sanitized، Policy/Scope/Role map و Case schema را تکمیل کنید. هفتهٔ دوم: کانال، Encryption، Receipt، Ack و Escalation را با پیام‌های بی‌خطر و ازپیش‌هماهنگ‌شده آزمایش کنید. هفتهٔ سوم: Tabletop آفلاین برای No response، Supplier چندگانه، Exploitation signal و Fix failure اجرا کنید. هفتهٔ چهارم: Decision Review، Advisory دفاع‌محور، Correction و Retention را تمرین و Findings ساختاری را ببندید.

شاخص Pilot «تعداد آسیب‌پذیری پیدا‌شده» نیست. زمان Ack، درصد Caseهای دارای Scope snapshot، Evidence overcollection، Access exception، Milestoneهای بدون Owner، Decisionهای بدون Rationale و Correction drill را بسنجید. این معیارها نیز برای رتبه‌بندی افراد نیستند و بدون Baseline و Context به هدف تنبیهی تبدیل نمی‌شوند.

این راهنما بر چه منابعی تکیه دارد؟

RFC ۹۱۱۶ برای قالب و مرز security.txt؛ راهنمای CERT/CC برای مفهوم، نقش‌ها و چرخهٔ CVD؛ و توضیح رسمی CISA دربارهٔ VDP برای اهمیت Scope، فعالیت‌های مجاز و انتظار ارتباط استفاده شده‌اند. همچنین NIST SP 800-216 یک منبع رسمی برای طراحی راهنمای پردازش و ارتباط Vulnerability Report در سازمان‌های فدرال آمریکاست. این مقاله اصول عمومی را برای QA تطبیق داده و ادعای انطباق با هیچ استاندارد یا حوزهٔ قضایی ندارد.

جمع‌بندی

افشای هماهنگ سالم از اخلاق‌نمایی و ساعت‌شماری فاصله می‌گیرد و به رکورد قابل ممیزی تبدیل می‌شود: Authorization و Scope پیش از اقدام، Safety و Stop پیش از Evidence، Ack و Triage پیش از حکم، Coordination پیش از انتشار، Mitigation/Fix/Deployment به‌صورت جدا، و Decision/Correction با Authority و تاریخچه. نتیجهٔ خوب لزوماً افشای عمومی یا پنهان‌ماندن نیست؛ نتیجه‌ای است که با کمترین آسیب، بیشترین توان دفاعی و تصمیمی قابل توضیح به دست آمده باشد.

سوالات متداول

آیا پیدا کردن security.txt یعنی اجازهٔ تست داریم؟

خیر. RFC ۹۱۱۶ می‌گوید این فایل اجازهٔ ضمنی تست نمی‌دهد. Policy مرتبط را بخوانید و Actor، Asset، Activity، زمان، شرایط و موارد ممنوع را دقیق ثبت کنید. اگر Scope مبهم است، توقف و پرسش از مسیر رسمی امن‌تر از استنتاج مجوز است.

اگر شرکت پاسخ نداد، بعد از ۹۰ روز می‌توانیم منتشر کنیم؟

یک قاعدهٔ جهانی ۹۰روزه وجود ندارد. Policy برنامه، خطر بهره‌برداری، آسیب کاربر، Mitigation، Deployment، Dependency و قانون قابل اعمال مهم‌اند. مسیرهای تماس و مالکیت را دوباره بررسی کنید، از Coordinator یا مشاور واجد صلاحیت کمک بگیرید و Disclosure decision را با Authority و Rationale ثبت کنید.

آیا Safe Harbor ما را از هر مسئولیت حقوقی مصون می‌کند؟

خیر. دامنهٔ آن به متن دقیق سیاست، رعایت شرایط، اختیار سازمان، اشخاص ثالث و حوزهٔ قضایی بستگی دارد. آن را «مصونیت عمومی» ترجمه نکنید. برای وضعیت واقعی از متخصص حقوقی واجد صلاحیت در حوزهٔ مربوط کمک بگیرید.

VDP و Bug Bounty چه تفاوتی دارند؟

VDP راه گزارش، Scope و قواعد ارتباط را تعریف می‌کند؛ Bug Bounty شرایط جداگانهٔ Eligibility، Duplicate، Severity، پاداش و پرداخت دارد. هر VDP جایزه ندارد و عضویت در Bounty نیز پذیرش گزارش یا پرداخت را تضمین نمی‌کند.

QA در CVD چه نقشی دارد؟

QA می‌تواند Fact و Claim را جدا کند، نسخه و محیط را تثبیت کند، Evidence حداقلی و قابل ردیابی بسازد، Verification/Regression را طراحی و Case completeness را ممیزی کند. QA به‌تنهایی مجوز تست، نظر حقوقی، Severity نهایی، زمان انتشار یا ادعای ایمنی صادر نمی‌کند.

مدیریت آسیب‌پذیری

افشای آسیب‌پذیری؛ از Authorization تا Coordination