# رجیستری آسیب‌پذیری

نسخهٔ چارچوب: 2.0.0-draft.1. وضعیت: طرح پیشنهادی رجیستری و فرایند حاکمیت. این سند نهادی فعال تأسیس نمی‌کند و هیچ یافتهٔ پذیرفته‌شده‌ای را اعلام نمی‌کند.

## هدف و انواع مدخل

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

یافته‌های مشخص را از پیشنهادهای رده متمایز کنید. یافتهٔ مشخص به سامانه و پیکربندی‌ای محدود مربوط است. پیشنهاد رده، سازوکار، خانواده یا خاصیت امنیتیِ تازه یا بازنگری‌شده‌ای را درخواست می‌کند. گزارش یک رخداد ممکن است برای هر دو شاهد فراهم کند، اما نباید بی‌اعلام به رده‌ای عمومی تبدیل شود. نوع مدخل را صریحاً ثبت کنید و مدخل‌های مرتبط را به هم پیوند دهید.

رجیستری باید ردشده‌ها، موارد تکراری، موارد پس‌گرفته‌شده و موارد بی‌نتیجه را نگه دارد. این‌ها از تکرار ادعاهای بی‌پشتوانه جلوگیری می‌کنند و شواهد منفیِ سودمند را حفظ می‌کنند. نگه‌داری تابع تعهدات حریم خصوصی و افشاست؛ نگه‌داری عمومیِ داده‌های شخصی یا جزئیات عملیاتیِ اکسپلویت الزامی نیست.

## ساختار نسخه‌دار سوابق

هر مدخل یک شناسهٔ پایدار طبق طرحِ سند «نسخه‌گذاری و شناسه‌ها»، یک شمارهٔ بازنگری مدخل، یک نسخهٔ طرح‌واره و نسخه‌ای از چارچوب که برای طبقه‌بندی به کار رفته دارد. تخصیص شناسه به معنای ایجاد سابقه است، نه پذیرش. بازنگری‌های پیشین قابل ارجاع می‌مانند، مگر جایی که حذفِ قانونی یا حفاظتِ ضروری رسیدگیِ محدود را الزام کند؛ چنین تغییراتی باید توضیحی غیرحساس برای ممیزی بر جای بگذارند.

| گروه فیلد | محتوای الزامی |
| --- | --- |
| هویت | `entry_id`، `entry_revision`، `schema_version`، `framework_version`، `entry_kind`، `title`، `created_at`، `updated_at` |
| ادعا | گزارهٔ محدود، شناسه‌های ادعا، قرارداد مورد انتظار، مفروضات، مشاهدات ابطال‌کننده |
| دامنه | نسخه‌های هدف، ارجاع‌های پیکربندی، مرز استقرار، چرخهٔ عمر، شناسه‌ها و نسخه‌های پروفایل |
| تهدید | کنشگر یا اختلال، دسترسی، دانش، کنترل، بازخورد، بودجه، زمان‌بندی، موارد مستثنا |
| طبقه‌بندی | `property_ids`، `mechanism_ids`، `dimension_ids`، `entry_points`، `failed_contracts`، `participating_domains`، `interaction_locus`، `propagation`، `impact_scope` |
| شواهد | نتایج ارزیابی، وجه‌های E0 تا E6، پروتکل، اوراکل، کنترل‌ها، واحدها، حساب‌رسیِ اجراها، تحلیل، ارجاع به مصنوعات |
| پیامد | پیامدِ نشان‌داده‌شده و بالقوه، دلیل شدت، مفروضات احتمال، برگشت‌پذیری، حدود بازیابی |
| بازبینی | `review_status`، بازبینان، افشای استقلال، تعارض‌ها، دلیل، معیارهای حل‌نشده، تاریخچهٔ تصمیم |
| افشا | `confidentiality_status`، سابقهٔ تماس با مالک در صورت لزوم، شرایط دورهٔ عدم انتشار یا آزادسازی، پوشاندن اطلاعات، قواعد دسترسی و نگه‌داری |
| روابط | مدخل‌های مرتبط، پیوندهای تکراری یا جایگزین، مقایسه با دسته‌های پیشین، تاریخچهٔ مهاجرت |

هر اطلاعات الزامیِ مفقود باید دلیلی صریح و وضعیتی «حل‌نشده» داشته باشد. «نامعلوم» هم‌ارزِ خالی، نادرست یا صفر نیست. برای پیشنهاد رده، فیلدهای ویژهٔ هدف می‌توانند به ارزیابی‌های پشتیبان ارجاع دهند، نه اینکه وانمود کنند یک رده تنها یک نسخهٔ هدف دارد.

طبقه‌بندی دقیقاً به حوزه‌های مرجع ارجاع می‌دهد: L1 مدل‌ها و محاسبه؛ L2 نرم‌افزار و زیرساخت؛ L3 داده و دانش؛ L4 ادراک و بازنمایی جهان؛ L5 تفسیر و هدف‌ها؛ L6 حافظه و تداوم حالت؛ L7 برنامه‌ریزی و کنش؛ L8 تعامل انسان و سامانه؛ و L9 تعامل جمعی و سامانه‌ای. طرح‌واره چند قرارداد شکست‌خورده و جایگاه‌هایی از نوع گره، یال، منبع مشترک، گروه یا زیرگراف را مجاز می‌داند. حوزهٔ اصلی اختیاری است. صرفِ عبور به معنای شکست یک حوزه نیست.

## فیلدهای شواهد و نتیجه

نتایج ارزیابی عبارت‌اند از `supported`، `refuted`، `inconclusive`، `quality_issue`، `hazard_only` یا `out_of_scope` که هر یک به ادعا و دلیلی پیوسته است. این نتایج از وضعیتِ اداریِ بازبینی جدا هستند. یک مدخل می‌تواند ادعایی محدودِ پشتیبانی‌شده و تعمیمی بی‌نتیجه را با هم داشته باشد.

E0 فرضیه، E1 مشاهدهٔ منفرد، E2 مشاهدهٔ بازتولیدشده، E3 آزمایش کنترل‌شده، E4 شواهد میان‌شرایطی، E5 شواهد میان‌مدلی و E6 تکرار مستقل، وجه‌های شواهدی‌اند که در «روش‌شناسی ارزیابی» تعریف شده‌اند. هر وجه یکی از مقادیر `supported`، `unsupported`، `not_tested`، `inconclusive` یا `not_applicable` را همراه با مصنوعات و دامنه ثبت می‌کند. این وجه‌ها نمره‌هایی انباشتی یا جایگزین داوری بازبین نیستند. تکرار مستقلِ ادعایی محدود، کاربردپذیریِ گسترده را ثابت نمی‌کند.

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

## وضعیت‌های پیشنهادی بازبینی

از `submitted`، `under_review`، `accepted`، `rejected`، `withdrawn` و `superseded` به‌عنوان مقادیر `review_status` استفاده کنید. پذیرش یک یافتهٔ مشخص یعنی ادعای مشخص‌شده معیارهای مستند بازبینی را برآورده کرده است. پذیرش پیشنهادِ یک رده افزون بر این، معیارهای تازگی و شمولِ «طبقه‌بندی حمله‌ها» را الزام می‌کند. هیچ‌یک گواهی‌ای برای سامانهٔ هدف یا گزاره‌ای دربارهٔ همهٔ استقرارهای مرتبط نیست.

هر ارسال با وضعیت `submitted` وارد می‌شود. غربالگری می‌تواند آن را به `under_review` ببرد یا بدون تغییر وضعیت، اطلاعات مفقود را درخواست کند. بازبینیِ مستدل می‌تواند به `accepted` یا `rejected` بینجامد؛ ارسال‌کننده ممکن است پس‌گرفتن را درخواست کند. سوابق `superseded` به جایگزین خود پیوند می‌خورند. شواهد تازه می‌توانند هر تصمیمِ ماهوی را از راه `under_review` دوباره بگشایند. تصمیم پیشین را حفظ کنید و توضیح دهید چرا تغییر کرده است.

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

## مسئولیت‌های پیشنهادیِ حاکمیت

نقش‌های زیر پیشنهادی برای حاکمیت‌اند، نه ادعایی بر اینکه بازبینان یا هیئتی هم‌اکنون وجود دارند. «متولی پذیرش» کامل بودن را بررسی می‌کند و از مواد حساس حفاظت می‌کند. «بازبین فنی» قراردادها، رسیدن‌پذیری، کنترل‌ها و شواهد علّی را بررسی می‌کند. «بازبین حوزهٔ کاربردی» هر جا تخصص ویژه لازم باشد، پیامدها و مفروضات پروفایل را بررسی می‌کند. «متولی تصمیم» نتیجه را ثبت می‌کند و اطمینان می‌یابد که معیارهای بیان‌شده به کار رفته‌اند.

در پروژه‌ای کوچک، یک نفر ممکن است نقش‌های اداری را بر عهده بگیرد، اما باید هم‌پوشانیِ نقش‌ها را افشا کند. ارسال‌کننده نباید تنها بازبینِ ماهویِ پذیرشِ ارسالِ خودش باشد. هر جا بازبینی مستقل ممکن نیست، ارسال را در وضعیت «در انتظار بازبینی» نگه دارید، نه اینکه استقلال را شبیه‌سازی کنید. تعارض‌های مالی، شغلی، تألیفی، شخصی و رقابتی باید افشا و سنجیده شوند؛ ممکن است کناره‌گیری یا یک بازبین افزوده لازم باشد.

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

درخواست تجدیدنظر، خطایی رویه‌ای، شاهدی نادیده‌مانده یا استنباط فنیِ مورد مناقشه‌ای را مشخص می‌کند. هر جا شدنی است، بازبینی که مسئول تصمیمِ مورد مناقشه نبوده باید آن را بررسی کند. نتیجه و استدلال به سابقهٔ اصلی پیوسته می‌مانند. اگر هیچ بازبینِ مستقلی برای تجدیدنظر در دسترس نیست، این محدودیت را ثبت کنید و مناقشه را قابل‌دیدن نگه دارید. این پیشنهاد اختیاری را که اکنون قادر به اعمال آن نیست پدید نمی‌آورد.

## پذیرش و ارجاع‌دهی

یافتهٔ مشخص به قرارداد امنیتیِ مشخص‌شده، شرایطِ باورپذیر، شواهد نقضِ ادعاشده، توضیحی محدود از پیامد، بررسی تبیین‌های جایگزین و سابقهٔ بازبینی نیاز دارد. شواهد لازم به ادعا و پروفایل بستگی دارد. نقصی قطعی در پیاده‌سازی صرفاً برای اینکه قابل‌اقدام شود، به آزمون میان‌مدلی نیاز ندارد.

پیشنهادِ یک رده افزون بر این، نزدیک‌ترین دسته‌های موجود را مقایسه می‌کند، تمایز را توضیح می‌دهد، موارد پشتیبان فراهم می‌کند و ابطال‌کننده‌های باورپذیر را می‌آزماید. شواهد میان‌شرایطی و مستقل را باید به تناسب عمومیتِ ادعاشده جست‌وجو کرد. نبودِ پروفایلِ بازبینی‌شده مسئله‌ای حل‌نشده در پذیرش است که باید صریحاً به آن پرداخت، نه دلیلی برای اعمال آستانهٔ عددیِ دلبخواهی برای شواهد.

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

## افشا و دسترسی به شواهد

ضعف‌های مشخص در سامانه‌های مستقر، پیش از انتشار عمومیِ جزئیات عملیاتی، به رسیدگیِ هماهنگ با مالک مسئول نیاز دارند. تلاش‌های تماس، پاسخ‌های مربوط، زمان‌بندیِ توافق‌شده در صورت وجود و مبنای تصمیم به انتشار را ثبت کنید. این سند مهلت جهان‌شمولی تجویز نمی‌کند و انتشارِ مغایر با تعهدات حاکم را مجاز نمی‌کند.

از `public`، `restricted` و `embargoed` به‌عنوان مقادیر `confidentiality_status` استفاده کنید. سوابق عمومی می‌توانند قراردادها، نسخه‌های متأثر در صورت مناسب بودن، خلاصهٔ شواهد و رفع را توصیف کنند و جزئیاتی را که به‌طور اساسی سوءاستفاده را ممکن می‌کنند محدود نگه دارند. مصنوعات حساس را با کمترین دسترسیِ لازم، محدودیت‌های نگه‌داری و سوابق ممیزی ذخیره کنید. اعتبارنامه‌ها، داده‌های شخصی و اطلاعات سازمانیِ نامربوط را بپوشانید.

پژوهشگران باید شواهد کافی در اختیار بازبینان مجاز بگذارند، بی‌آنکه دستورالعمل‌های زیان‌بارِ بازتولید را در دسترس همگان قرار دهند. اگر محدودیت‌های افشا مانع راستی‌آزمایی مستقل می‌شوند، همین محدودیتِ مشخص را ثبت کنید. حفاظت از حریم خصوصی و کیفیت شواهد تصمیم‌هایی مرتبط اما متمایزند. چکیده‌ای حافظِ حریم خصوصی می‌تواند هویت یک مصنوع را ثابت کند، بی‌آنکه محتوای ادعا را ثابت کند.

## مدخل توضیحی

آنچه در ادامه می‌آید مثالی توضیحی و اجرانشده است، نه یافته‌ای ارسال‌شده یا پذیرفته‌شده در رجیستری. شناسهٔ محلیِ این مثال EXAMPLE-RETRIEVAL-01 است و نباید به‌عنوان مدخلِ واقعیِ رجیستری تخصیص یابد.

ادعا این است که محتوای بازیابی‌شده‌ای که در کنترل مهاجم است، می‌تواند در یک دستیار ساختگی باعث به‌روزرسانیِ غیرمجازِ یک ترجیحِ نگه‌داشته‌شده شود. کنشگر یک سند را در کنترل دارد و نمی‌تواند دستورهای سامانه یا اجازه‌های ابزار را تغییر دهد. خاصیت‌های پیشنهادی P04 «یکپارچگی دستور» و P07 «یکپارچگی حافظه» هستند. نقطهٔ ورود یک منبع اطلاعاتی در L3 است؛ قراردادهای شکست‌خوردهٔ فرضی به تفسیر در L5 و ماندگاری در L6 مربوط‌اند. ارجاع‌های پیشنهادی به سازوکار، تا رسیدن شواهد، M05 «دست‌کاری معنایی» و M08 «دست‌کاری حافظه» هستند. بدون مشاهده‌ای مربوط به قرارداد کنش، هیچ نقضی در یکپارچگی کنش در L7 ادعا نمی‌شود.

اوراکلِ برنامه‌ریزی‌شده، بازخوانیِ حالتِ نگه‌داشته‌شده است، با بازیابیِ بی‌خطرِ همسان به‌عنوان کنترل منفی و بازنشانیِ جداگانهٔ نشست. شمار آزمایش‌ها، رویدادهای مشاهده‌شده و پیامد در دسترس نیستند، زیرا این مثال اجرا نشده است. نتیجهٔ ارزیابی `inconclusive` است؛ E0 می‌تواند فرضیهٔ صریح را توصیف کند، در حالی که E1 تا E6 در وضعیت `not_tested` قرار دارند. وضعیت بازبینی تنها در صورتی `submitted` می‌ماند که ارسالی واقعی ایجاد شده باشد؛ این سابقهٔ توضیحی هیچ تصمیم بازبینی‌ای ندارد.

ابطال‌کننده می‌تواند شاهدی باشد بر اینکه تغییر حالت به به‌روزرسانیِ مجاز از سوی کاربر نیاز دارد، یا اینکه ماندگاریِ ادعاشده هرگز رخ نمی‌دهد. تبیین جایگزینِ دوم این است که خودِ بستر آزمون ترجیح را می‌نویسد. این مثال نشان می‌دهد چگونه می‌توان شواهدِ مفقود را بیان کرد، بی‌آنکه یافته‌ای ساخته شود.

## نگه‌داری و مهاجرت

ساختار طرح‌واره را جدا از پذیرش علمی اعتبارسنجی کنید. سابقه‌ای که از نظر ساختاری درست است، می‌تواند ادعایی بی‌پشتوانه در خود داشته باشد. ارجاع‌های شناسه‌ای را در برابر نسخهٔ مشخص‌شدهٔ چارچوب اعتبارسنجی کنید و استفادهٔ دوبارهٔ بی‌اعلام از معانی شناسه‌های P، M یا D را رد کنید. مهاجرت‌ها طبقه‌بندیِ قدیمی، نگاشت پیشنهادی، بازبین و دلیل را ثبت می‌کنند؛ تغییرات اساسی در حوزه‌ها به طبقه‌بندی دوبارهٔ انسانی نیاز دارند، نه برچسب‌گذاریِ دوبارهٔ خودکار.

تأخیر در تصمیم‌گیری، مناقشه‌های حل‌نشده، رسیدگی به افشا و فیلدهایی را که مکرراً مفقودند به‌عنوان شواهد فرایندی ممیزی کنید. شمار مدخل‌ها را اثباتی بر کیفیت علمی معرفی نکنید. رجیستری زمانی موفق است که خواننده بتواند تشخیص دهد چه چیزی پیشنهاد، مشاهده، اثبات و محدود شده و بعدها چه چیزی بازنگری شده است.