Google گزارش‌های آسیب‌پذیری متن‌باز را بست؛ سیل گزارش‌های خودکار مقصر است

Google بر پایهٔ قواعد رسمی OSS VRP از اول اکتبر ۲۰۲۶ پذیرش گزارش تازهٔ آسیب‌پذیری محصول را در برنامهٔ پاداش امنیتی نرم‌افزار متن‌باز خود متوقف کرده است. به گزارش SecurityWeek، گزارش‌های مربوط به زنجیرهٔ تأمین و پرونده‌های ثبت‌شده پیش از توقف همچنان از این تغییر مستثنا هستند.

در گزارش ITPro از توضیح Google، علت توقف چنین نقل شده است: «This pause is due to a significant rise in automated submissions, the vast majority of which are not valid»؛ به‌روزرسانی بعدی برنامه نیز برای سه‌ماههٔ نخست ۲۰۲۷ وعده داده شده است. این زمان، موعد اعلام خبر تازه است و تاریخ بازگشایی پذیرش گزارش محصول تعیین نشده است. در نتیجه پژوهشگری که امروز نقصی پیدا می‌کند باید نخست روشن کند اثر آن متوجه خود محصول متن‌باز است یا تمامیت کد و فرایند انتشار آن.

مرز توقف در OSS VRP کجاست؟

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

در گزارش زنجیرهٔ تأمین، موضوع عوض می‌شود: پرسش این است که مهاجم چگونه می‌تواند کد منبع، تنظیمات ساخت، خروجی منتشرشده یا بسته‌ای را که به دست کاربران می‌رسد تغییر دهد. دسترسی عملی به شاخهٔ اصلی مخزن، سوءاستفاده از پیکربندی GitHub Actions، افشای اعتبارنامهٔ انتشار بسته و تصرف کلید امضای خروجی، نمونه‌های مشخص این مسیرند. نام بردن از چنین اجزایی به‌تنهایی گزارش معتبر نمی‌سازد؛ باید نشان داده شود پیش‌شرط‌های لازم واقعاً قابل عبورند و تغییر مخرب می‌تواند به دارایی مورد ادعا برسد.

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

کدام یافته را کجا باید فرستاد؟

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

• نقص تازهٔ خود محصول متن‌باز: مسیر محصول در OSS VRP بسته است. اگر همان نقص بر محصولی در برنامهٔ پاداش دیگر Google اثر دارد، باید دامنهٔ همان برنامه و پیوند فنی با محصول متأثر روشن شود. مسیر Patch Rewards Program نیز برای مشارکت در اصلاح امنیتی پروژه‌ها مطرح است؛ ارائهٔ وصله با ثبت گزارش تازهٔ محصول در OSS VRP یکی نیست. مدرک اصلی در مسیر جایگزین، نسخهٔ آسیب‌دیده، روش بازتولید و اثر واقعی بر محصول مشمول آن برنامه است.
• خطر زنجیرهٔ تأمین: مسیر OSS VRP باز مانده است و در فرم گزارش Bug Hunters باید OSS VRP و نشانی مخزن انتخاب یا ثبت شود. گزارش باید جزء آسیب‌دیده، نقطهٔ ورود مهاجم، پیش‌شرط دسترسی، راه عبور از کنترل‌های مشارکت و اثر بر کد یا بستهٔ منتشرشده را نشان دهد. اگر ادعا دربارهٔ اعتبارنامهٔ انتشار یا تنظیمات ساخت است، رابطهٔ آن با خروجی قابل‌دریافت کاربران باید دقیق باشد.
• گزارش محصولیِ ارسال‌شده پیش از توقف: پروندهٔ موجود همچنان مشمول رسیدگی است. شواهد تازه، مانند نسخهٔ دقیق آسیب‌دیده، نتیجهٔ بازتولید یا اصلاح نمونهٔ اثبات مفهوم، به همان پرونده مربوط‌اند. بازفرستادن همان نقص به‌صورت گزارش تازه نه دامنهٔ توقف را تغییر می‌دهد و نه جای توضیح روشن دربارهٔ یافتهٔ قبلی را می‌گیرد.
• نقص مرتبط با Google Cloud: Cloud VRP ممکن است برای بعضی مخزن‌های مرتبط با محصولات Google Cloud گزارش آسیب‌پذیری محصول را بپذیرد. برای این مسیر باید محصول Cloud متأثر، راه رسیدن کد آسیب‌پذیر به آن محصول و پیامد امنیتی قابل‌بازتولید مشخص باشد. تعلق مخزن به Google یا استفاده از واژهٔ Cloud در نام پروژه، به‌تنهایی پذیرش گزارش را تضمین نمی‌کند.

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

گزارش قابل‌بررسی چه شواهدی می‌خواهد؟

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

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

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

مرحلهٔ بعدی این پرونده، به‌روزرسانی وعده‌داده‌شده برای سه‌ماههٔ نخست ۲۰۲۷ است. آن زمان مشخص خواهد شد Google چه تصمیمی دربارهٔ پذیرش دوبارهٔ گزارش‌های محصول در OSS VRP گرفته است.

بیشتر بخوانید:

• جلسه یا کار ناهم‌زمان؛ تصمیم زنده است، گزارش نه
• Passkey یا اپ احراز هویت؛ فقط یکی در برابر فیشینگ طراحی شده است
• Google ویدئوی چنددقیقه‌ای را یک مسئلهٔ حافظه کرد، نه فقط پرامپت