دانیل استنبرگ، نویسنده ابزاری برای دریافت و ارسال داده از طریق حلقه شبکه، از استفاده از ابزارهای هوش مصنوعی هنگام ایجاد گزارش‌های آسیب‌پذیری انتقاد کرد. چنین گزارش‌هایی شامل اطلاعات دقیق هستند، به زبان عادی نوشته شده‌اند و باکیفیت به نظر می‌رسند، اما بدون تجزیه و تحلیل متفکرانه در واقعیت، تنها می‌توانند گمراه‌کننده باشند و محتوای زباله با کیفیت بالا را جایگزین مشکلات واقعی کنند.
پروژه Curl برای شناسایی آسیب‌پذیری‌های جدید پاداش پرداخت می‌کند و تاکنون 415 گزارش از مشکلات احتمالی دریافت کرده است که از این تعداد تنها 64 مورد به عنوان آسیب‌پذیری و 77 مورد به عنوان باگ غیرامنیتی تأیید شده است. بنابراین، 66 درصد از همه گزارش‌ها حاوی هیچ اطلاعات مفیدی نبودند و تنها زمانی را از توسعه‌دهندگان می‌گرفتند که می‌توانستند برای چیز مفیدی صرف شوند.
توسعه دهندگان مجبورند زمان زیادی را برای تجزیه گزارش های بی فایده و چندین بار بررسی مجدد اطلاعات موجود در آنجا هدر دهند، زیرا کیفیت خارجی طراحی اعتماد بیشتری به اطلاعات ایجاد می کند و این احساس وجود دارد که توسعه دهنده چیزی را اشتباه متوجه شده است. از سوی دیگر، تولید چنین گزارشی نیازمند تلاش حداقلی از سوی متقاضی است، که به خود زحمت نمی دهد مشکل واقعی را بررسی کند، بلکه به سادگی کورکورانه داده های دریافت شده از دستیاران هوش مصنوعی را کپی می کند، به امید شانس در مبارزه برای دریافت پاداش.
دو نمونه از این گونه گزارش های زباله آورده شده است. یک روز قبل از افشای برنامه ریزی شده اطلاعات مربوط به آسیب پذیری خطرناک اکتبر (CVE-2023-38545)، گزارشی از طریق Hackerone ارسال شد مبنی بر اینکه وصله با اصلاح در دسترس عموم قرار گرفته است. در واقع، این گزارش حاوی ترکیبی از حقایق در مورد مشکلات مشابه و تکه‌هایی از اطلاعات دقیق در مورد آسیب‌پذیری‌های گذشته بود که توسط دستیار هوش مصنوعی گوگل، Bard گردآوری شده بود. در نتیجه، اطلاعات جدید و مرتبط به نظر می رسید و هیچ ارتباطی با واقعیت نداشت.
مثال دوم مربوط به پیامی است که در 28 دسامبر در مورد سرریز بافر در کنترلر WebSocket دریافت شده است که توسط کاربری ارسال شده است که قبلاً از طریق Hackerone به پروژه های مختلف در مورد آسیب پذیری ها اطلاع داده بود. به عنوان روشی برای بازتولید مشکل، گزارش شامل کلمات کلی در مورد ارسال درخواست اصلاح شده با مقداری بزرگتر از اندازه بافر مورد استفاده هنگام کپی کردن با strcpy بود. این گزارش همچنین نمونه ای از تصحیح (نمونه ای از جایگزینی strcpy با strncpy) را ارائه می دهد و پیوندی به خط کد "strcpy(keyval, randstr)" را نشان می دهد که به گفته متقاضی حاوی خطا است.
توسعه دهنده همه چیز را سه بار دوبار بررسی کرد و مشکلی پیدا نکرد، اما از آنجایی که گزارش با اطمینان نوشته شده بود و حتی حاوی یک اصلاح بود، این احساس وجود داشت که چیزی در جایی گم شده است. تلاش برای روشن کردن اینکه چگونه محقق موفق به دور زدن بررسی اندازه صریح موجود قبل از فراخوانی strcpy شده و اینکه چگونه اندازه بافر کلیدی کمتر از اندازه داده‌های خوانده شده است، منجر به توضیحات دقیق، اما بدون ارائه اطلاعات اضافی شد. که فقط دلایل رایج آشکار سرریز بافر را که به کد Curl خاص مربوط نمی شود، جوید. پاسخ ها یادآور برقراری ارتباط با یک دستیار هوش مصنوعی بود و پس از صرف نیم روز در تلاش های بیهوده برای یافتن دقیق چگونگی بروز مشکل، توسعه دهنده در نهایت متقاعد شد که در واقع هیچ آسیب پذیری وجود ندارد.
منبع: opennet.ru