هوش مصنوعی یافتن باگ را ارزان کرد. اکنون رفع آن‌ها گلوگاه است
هزینه کشف فروپاشید
پیدا کردن یک آسیب‌پذیری معتبر پیش‌تر به مهارت، زمان و درک کاملی از کدبیس نیاز داشت. مدل‌های زبانی بزرگ بیشتر این هزینه را برداشته‌اند. پژوهشگران و ابزارهای خودکار اکنون می‌توانند در چند ساعت حجم زیادی گزارش احتمالی برای پروژه‌های محبوب متن‌باز تولید کنند. مشکل این است که کار با کشف تمام نمی‌شود. هنوز باید مشکل بازتولید شود، شدت آن سنجیده شود، وصله نوشته و بازبینی شود و به کاربران برسد. هیچ‌کدام از این مراحل ارزان‌تر نشده است.
این عدم تقارن برنامه‌های باگ‌بانتی را وادار به تغییر قوانین کرده است. curl در ژانویه ۲۰۲۶ برنامه باگ‌بانتی خود را معلق کرد. گوگل در مارس ۲۰۲۶ برنامه پاداش متن‌باز خود را سخت‌تر کرد و برای برخی سطوح پرداخت، شواهد با کیفیت بالاتر مانند بازتولید با OSS-Fuzz یا یک وصله ادغام‌شده را خواست. گوگل گفته است که بسیاری از گزارش‌های تولیدشده با هوش مصنوعی شرایط ماشه‌خوردن ساختگی دارند یا باگ‌هایی با تأثیر امنیتی کم گزارش می‌کنند. در آوریل، HackerOne پرداخت‌های Internet Bug Bounty را متوقف کرد. این برنامه از سال ۲۰۱۲ بیش از ۱.۵ میلیون دلار پرداخت کرده بود و تاریخاً حدود ۸۰ درصد پاداش‌ها را به کشف جدید و ۲۰ درصد را به پشتیبانی از رفع اختصاص می‌داد.
توضیح HackerOne روشن‌ترین بیانی است که تاکنون از این مسئله شده است. این شرکت گفته که پژوهش مبتنی بر هوش مصنوعی پوشش و سرعت کشف آسیب‌پذیری را در کل اکوسیستم افزایش داده و تعادل میان یافته‌ها و ظرفیت رفع در متن‌باز اساساً تغییر کرده است. Node.js، یکی از اولین پروژه‌های تحت تأثیر، همچنان گزارش‌ها را از طریق HackerOne می‌پذیرد، اما دیگر برای آن‌ها پاداش نمی‌پردازد.
چرا گزارش‌های بد گران تمام می‌شوند
یک گزارش اشتباه برای کسی که آن را دریافت می‌کند رایگان نیست. نگهدارنده باید آن را بخواند، بازتولید کند و توضیح دهد که چرا کار نمی‌کند، و اغلب این کار در رشته‌ای پر از گفت‌وگوی مؤدبانه اما بی‌فایده انجام می‌شود. اگر گزارش مسیر ماشه‌ای را توصیف کند که وجود ندارد، نگهدارنده ممکن است ساعت‌ها کدی را بررسی کند که هرگز اجرا نمی‌شود. با ضرب کردن این در ده‌ها ارسال، یک تیم داوطلب می‌تواند کل هفته‌اش را صرف غربال کردن کند. گزارش‌هایی که معتبر به نظر می‌رسند اما اشتباه‌اند از گزارش‌های آشکارا بد گران‌ترند، چون نمی‌شود با یک نگاه کنارشان گذاشت.
پاسخ برنامه‌ها این بوده که بار اثبات را دوباره روی دوش گزارش‌دهنده بگذارند. خواستن بازتولید با فازر، یک اثبات مفهوم که روی نسخه فعلی اجرا شود، یا یک وصله، بخشی از کاری را به گزارش‌دهنده می‌سپارد که در غیر این صورت نگهدارنده باید انجام دهد. همچنین ارسال‌هایی را فیلتر می‌کند که نویسنده‌شان کد را واقعاً اجرا نکرده است.
چرا این موضوع فراتر از متن‌باز اهمیت دارد
پیامدها نظری نیستند. گزارش داده‌های نقض امنیتی ورایزن در سال ۲۰۲۶ نشان داد که حدود ۳۱ درصد نقض‌ها اکنون از بهره‌برداری از آسیب‌پذیری‌های نرم‌افزاری آغاز می‌شوند، در مقابل حدود ۲۰ درصد در سال قبل. بهره‌برداری از آسیب‌پذیری در آن مجموعه داده از سرقت اعتبارنامه‌ها پیشی گرفته و مسیر اصلی ورود مهاجمان شده است. بیشتر نرم‌افزارهای سازمانی روی اجزای متن‌باز ساخته شده‌اند، بنابراین انباشت رفع‌های بالادستی به انباشت در همه محصولات پایین‌دستی تبدیل می‌شود.
پوشش شکاف مالی نیز مقیاس مسئله را نشان داده است. بنا به گزارش‌ها، بنیاد لینوکس از شرکت‌های هوش مصنوعی کمک مالی خواست و گوگل، Anthropic، AWS، مایکروسافت و OpenAI روی هم ۱۲.۵ میلیون دلار برای کار امنیتی متن‌باز متعهد شدند. این مبلغ قابل توجه است، اما در مقایسه با کار مداوم نگهداری کتابخانه‌های پرکاربرد، یک‌باره است.
چه چیزی باید تغییر کند
کار درست این است که برای بخش پرهزینه کار پول پرداخت شود. کشف اکنون ارزان است؛ یک رفع تأییدشده که منتشر شود ارزان نیست. چند تغییر از این نتیجه می‌آیند.
- نگهدارندگان باید معیار شواهد را صریحاً در سیاست امنیتی خود بنویسند. گزارش‌های بدون بازتولید، تست شکست‌خورده یا اثبات مفهوم می‌توانند خودکار بسته شوند، با یک الگوی کوتاه که توضیح می‌دهد چه چیزی لازم است. راه‌اندازی این کار چند دقیقه طول می‌کشد و ساعت‌ها صرفه‌جویی می‌کند.
- نگهدارندگان باید بازبینی وصله را فعالیتی با بودجه مشخص بدانند. اگر پروژه‌ای به داوطلبان وابسته است، بودجه باید زمان بازبینی را هم پوشش دهد، نه فقط پرداخت پاداش گزارش‌ها.
- شرکت‌هایی که به نرم‌افزار متن‌باز وابسته‌اند باید زمان رفع را اندازه بگیرند، نه زمان گزارش‌دهی. تیم امنیتی که تعداد مواردی را که غربال کرده دنبال کند، به سمت حجم بهینه می‌شود. تیمی که مدت ماندن آسیب‌پذیری بدون وصله در وابستگی‌هایش را پیگیری کند، کاری را تأمین می‌کند که اهمیت دارد.
- پلتفرم‌های باگ‌بانتی باید برای وصله‌های ادغام‌شده بیشتر از گزارش‌ها پرداخت کنند و پیش از غربال، برای مدارک بازتولید هم پاداش در نظر بگیرند.
- پژوهشگرانی که باگ‌های واقعی پیدا می‌کنند باید وصله را کنار گزارش بفرستند. وصله‌ای که مجموعه تست را پشت سر بگذارد، مفیدترین چیزی است که یک گزارش‌دهنده می‌تواند به نگهدارنده بدهد.
این برای تیم خودتان چه معنایی دارد
اگر محصولی می‌سازید که به اجزای متن‌باز وابسته است، از فهرست کردن پروژه‌های بالادستی‌ای شروع کنید که به آن‌ها وابسته‌اید و بررسی کنید آیا فرایند پاسخ امنیتی فعال دارند. از فروشندگان خود سطح خدمات وصله را بخواهید، نه فقط نتایج اسکن را. وقتی آسیب‌پذیری‌ای در بالادست گزارش می‌شود، زمان تا انتشار نسخه رفع‌شده عددی است که تعرض شما را تعیین می‌کند، و آن عدد به ظرفیت نگهدارنده‌ها بستگی دارد که می‌توانید در تأمین مالی‌اش کمک کنید.
مسئله کشف از بین نمی‌رود و احتمالاً نباید برود. پیدا شدن باگ‌های بیشتر به‌خودی‌خود شکست نیست. شکست این است که همچنان مرحله ارزان را پاداش دهیم، در حالی که مرحله گران بر دوش چند داوطلب خسته بیفتد. برنامه‌هایی که اکنون قوانینشان را تغییر می‌دهند تلاش می‌کنند این را اصلاح کنند، و تیم‌هایی که به این نرم‌افزار وابسته‌اند هم باید توجه کنند.