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

کانال را پیدا کنید و بررسی کنید که وجود دارد

با مسیر مستند شروع کنید: صفحهٔ سیاست امنیتی، نشانی اختصاصی، یا پروندهٔ /.well-known/security.txt که فیلد Contact آن با RFC 9116 تعریف شده است.

سپس پاراگراف دامنه را بخوانید نه مقدمهٔ دوستانه را. کدام محصولات پوشش داده می‌شوند، کدام نسخه‌ها، و پروژه چه برخوردی می‌خواهد؟

کانالی که به پروژهٔ دیگری تعلق دارد، یا به میزبان‌دهنده به‌جای نگهدارنده، برای نرم‌افزاری که ارزیابی می‌کنید فرایند افشا نیست.

ردیاب عمومی یا کانال خصوصی

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

پروژه‌ای که تنها ردیاب عمومی عرضه می‌کند کانال افشا فراهم نکرده است، هر چه مستنداتش بگوید.

هیچ‌یک از این‌ها اجازهٔ آزمودن سامانه‌هایی را که مالکشان نیستید نمی‌دهد. نشانی گزارش دعوت به فرستادن اطلاعات است، نه اجازهٔ کاوش سرورهای عمومی نامرتبط.

یک اصلاح را از آغاز تا پایان دنبال کنید

اعلانی پیشین را برگزینید و دنبالش کنید: آیا نسخه‌های آسیب‌دیده و نسخه‌ای که آن‌ها را اصلاح می‌کند نام می‌برد، و آیا کاربر واقعاً می‌تواند آن نسخه را نصب کند؟

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

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

نگهدارندهٔ کلاینت یا گردانندهٔ سرویس

برای یک VPN، کسانی که کلاینت را می‌نویسند و کسانی که دروازه را می‌گردانند غالباً سازمان‌های متفاوتی‌اند. مشکلی در کد کلاینت و خطایی در استقرار سرور گیرندگان متفاوتی می‌خواهند.

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

غیاب چه را اثبات می‌کند و چه را نه

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

به‌همین‌ترتیب، نبودن صفحهٔ سیاست شاهد بدخواهی نیست. شاهد آن است که نمی‌توانید فرایند را بررسی کنید، و این همان نتیجهٔ صادقانه‌ای است که باید ثبت شود.

چه چیزی را بنویسید

چهار واقعیت را ثبت کنید: تماسی که می‌توانید بررسی کنید، دامنه‌ای که نسخهٔ شما را می‌پوشاند، اعلان‌هایی که نسخه‌های اصلاح‌شده را نام می‌برند، و تاریخچهٔ انتشاری که نشان می‌دهد اصلاح‌ها بیرون می‌آیند.

سپس بنویسید چه چیزی ناشناخته می‌ماند. بازبینی‌ای که این را می‌گوید سودمندتر است از بازبینی‌ای که سیاستی غایب را به ادعای امنیت بدل می‌کند.

مقالات مرتبط