سیاست جدید پروژه صفر گوگل، شفافیت برای کاهش فاصله وصله‌های امنیتی

چالش اصلی: فاصله‌ای که یک اپدیت تا رسیدن به شما طی میکنه

در سال ۲۰۲۱، این تیم سیاست گزارش دهی اسیب پذیری خودش رو به مدل فعلی یعنی «۹۰+۳۰» تغییر داد. هدف از این کار این بود که روند ساخت وصله‌های امنیتی سریع‌تر و در عین حال کامل‌تر بشه و شرکت‌ها هم سریع‌تر این اپدیت‌ها رو برای کاربرها منتشر کنن. با اینکه پیشرفت‌هایی دیده شده، اما هنوز یک چالش بزرگ وجود داره: مدت زمانی که طول میکشه تا یک اپدیت امنیتی واقعا به دست کاربر نهایی برسه.

این تاخیر که بهش «فاصله وصله» یا «patch gap» هم میگن، یک مشکل پیچیده‌اس. خیلی‌ها این فاصله رو از زمان انتشار یک اپدیت تا وقتی که کاربر اون رو نصب میکنه در نظر میگیرن. اما تحقیقات پروژه صفر یک تاخیر مهم‌تر و البته زودتر رو مشخص کرده: «فاصله وصله بالادستی» یا «upstream patch gap». این فاصله به زمانی گفته میشه که یک شرکت اصلی یا بالادستی (مثلا سازنده چیپست) اپدیت رو اماده کرده، اما شرکت‌های پایین دستی (مثلا سازنده گوشی) که مسئول رسوندن اپدیت به کاربر هستن، هنوز اون رو توی محصول نهایی خودشون قرار ندادن.

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

از نگاه یک کاربر عادی، یک اسیب پذیری وقتی حل شده که اپدیت رو دانلود و روی دستگاهش نصب کنه، نه وقتی که شرکت A اون رو برای شرکت B میفرسته. برای کوتاه کردن کل این زنجیره، باید فکری به حال تاخیر بالادستی کرد.

معرفی یک سیاست ازمایشی: شفافیت در گزارش دهی

برای حل این مشکل، پروژه صفر یک سیاست ازمایشی جدید رو معرفی کرده: «شفافیت در گزارش دهی» یا «Reporting Transparency».

قانون اصلی اونها یعنی مهلت ۹۰ روزه برای حل مشکل، سر جای خودش باقی میمونه. اما یک مرحله جدید به اول این فرایند اضافه شده. از الان به بعد، طی یک هفته بعد از گزارش یک اسیب پذیری به یک شرکت، پروژه صفر این موارد رو به صورت عمومی اعلام میکنه:

• اسم شرکت یا پروژه متن بازی که گزارش رو دریافت کرده.
• محصولی که تحت تاثیر این اسیب پذیری هست.
• تاریخی که گزارش ثبت شده و تاریخی که مهلت ۹۰ روزه تموم میشه.

این سیاست ازمایشی، همون مدل «۹۰+۳۰» قبلی رو حفظ میکنه. یعنی شرکت‌ها هنوز ۹۰ روز وقت دارن تا یک باگ رو قبل از افشای عمومی برطرف کنن و اگه زودتر این کار رو انجام بدن، یک دوره ۳۰ روزه برای انتشار وصله توسط شرکت‌های دیگه در نظر گرفته میشه.

پروژه «گوگل بیگ اسلیپ» (Google Big Sleep) که حاصل همکاری بین «گوگل دیپ مایند» و «پروژه صفر گوگل» هست هم قراره این سیاست رو برای گزارش‌های اسیب پذیری خودش امتحان کنه. ردیاب مشکلات این پروژه در ادرس goo.gle/bigsleep در دسترسه.

چرا این تغییر ایجاد شد؟

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

تیم پروژه صفر امیدوار هست که این طرح ازمایشی، کانال‌های ارتباطی قوی‌تری بین شرکت‌های بالادستی و پایین دستی در مورد مسائل امنیتی ایجاد کنه و در نهایت به انتشار سریع‌تر اپدیت‌ها برای کاربران نهایی منجر بشه. این اطلاعات همچنین به محقق‌ها و عموم مردم کمک میکنه تا راحت‌تر پیگیری کنن که چقدر طول میکشه تا یک اپدیت از لحظه گزارش اولیه به دست کاربر برسه (که این موضوع به خصوص وقتی مهمه که اپدیت هیچوقت به دست کاربر نمیرسه!).

ایا این کار به هکرها کمک میکنه؟

جواب پروژه صفر به این سوال «نه» هست. اونها پیش بینی میکنن که در مرحله اولیه این طرح، ممکنه توجه عمومی به باگ‌های حل نشده بیشتر بشه. اما اونها این موضوع رو شفاف کردن که هیچ جزییات فنی، کد اثبات مفهومی (PoC) یا اطلاعاتی که به نظرشون میتونه به کشف اسیب پذیری کمک کنه، تا قبل از پایان مهلت ۹۰ روزه منتشر نمیشه. سیاست «شفافیت در گزارش دهی» فقط یک هشداره، نه یک نقشه راه برای هکرها.

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

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

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