مرداد
اخبار
اپل جلوی سیل گزارشهای باگ ساختهشده با هوش مصنوعی را گرفت
شرکت اپل یکی از بیسروصداترین اما پرمعناترین تصمیمهای امنیتی سال را گرفت: سقفگذاری روی تعداد گزارشهای باز هر پژوهشگر و یک دورهی انتظار سیروزه. دلیلش نه کمبود منابع بود و نه بیاعتمادی به جامعهی امنیت، بلکه سیلی از گزارشهای باگ که مدلهای زبانی تولید کرده بودند و هیچ باگ واقعی پشتشان نبود. ماجرا وقتی تلخ شد که یک آسیبپذیری واقعی و پرارزش مکاواس، دقیقاً بهخاطر همین سقف، دیر به دست اپل رسید. این پرونده نشان میدهد ارزانشدن تولید متن قانعکننده چطور میتواند کل اقتصاد یک برنامهی امنیتی را بههم بریزد.
لیست مطالب
۱) ماجرا از کجا شروع شد؟
برنامههای باگبانتی سالهاست ستون پنهان امنیت نرمافزارهای بزرگاند. منطقشان ساده است: بهجای آنکه یک تیم داخلی محدود دنبال همهی حفرهها بگردد، هزاران پژوهشگر مستقل در سراسر جهان انگیزهی مالی پیدا میکنند تا آسیبپذیریها را پیش از مهاجمان کشف و گزارش کنند. این مدل تا زمانی جواب میدهد که هزینهی نوشتن یک گزارش قابلقبول، بالاتر از صفر باشد؛ یعنی نوشتن گزارش خودش نیازمند دانش، زمان و اعتبار باشد.
اتفاقی که در دو سال گذشته افتاد دقیقاً همین توازن را بههم زد. مدلهای زبانی به جایی رسیدند که میتوانند در چند ثانیه متنی بنویسند که از نظر ساختار، اصطلاحات فنی و لحن، عیناً شبیه یک گزارش امنیتی حرفهای است: توضیح مسیر حمله، شمارهی تابع، حتی مراحل بازتولید. تنها مشکل این است که در بسیاری از موارد، آن باگ اصلاً وجود خارجی ندارد. جامعهی امنیت برای این پدیده اصطلاح «اِیآی اِسلاپ» را ساخته است؛ محتوایی که همهی نشانههای ظاهری کیفیت را دارد اما تهی از ارزش واقعی است.
طبق گزارش فایننشالتایمز، حجم این گزارشها در برنامهی اپل به جایی رسید که تیم امنیت شرکت ناچار شد سازوکار پذیرش را تغییر دهد. اپل در بیانیهای اعلام کرد: «با رشد حجم گزارشهای امنیتی تولیدشده با هوش مصنوعی در سراسر صنعت، اخیراً تعداد گزارشهای تازهای که هر پژوهشگر میتواند همزمان باز داشته باشد را تنظیم کردیم.» این تغییر، بر پایهی گزارشهای منتشرشده، از ژوئن ۲۰۲۶ اعمال شده است.
۲) سازوکار تازه دقیقاً چیست؟
دو تغییر کلیدی در فرایند ثبت گزارش اعمال شده است. نخست، هر حساب کاربری سقف مشخصی برای تعداد گزارشهای «باز» دارد؛ یعنی گزارشهایی که هنوز بررسی و بسته نشدهاند. تا وقتی این گزارشها تعیین تکلیف نشوند، پژوهشگر نمیتواند مورد تازهای اضافه کند. دوم، میان دستههای ارسال یک دورهی انتظار سیروزه قرار گرفته است؛ به این معنا که پس از پر شدن سهمیه، پژوهشگر باید تا نوبت بعدی صبر کند.
نکتهی مهم این است که این سقف مطلق و غیرقابلتغییر نیست. اپل مسیری برای درخواست افزایش سهمیه از طریق درگاه امنیتی خود در نظر گرفته و پژوهشگرانی که سابقهی گزارشهای معتبر دارند میتوانند ظرفیت بیشتری بگیرند. به بیان دیگر، طراحی سیستم تلاش میکند اعتبار انباشتهی پژوهشگر را جایگزین هزینهای کند که پیشتر خودِ سختیِ نوشتن گزارش ایجاد میکرد.
این تصمیم در ظاهر یک تنظیم اداری کوچک است، اما در عمل قاعدهی بازی را عوض میکند. پیش از این، گلوگاه در سمت پژوهشگر بود: چند باگ میتوانی پیدا کنی؟ حالا گلوگاه به سمت شرکت منتقل شده است: چند گزارش میتوانی بررسی کنی؟ اگر بخواهید تصویر بزرگتر این جابهجایی را دنبال کنید، بایگانی بخش اخبار هوش مصنوعی نشان میدهد که همین الگو در حوزههای دیگر هم تکرار شده است.
۳) پروندهی بایناریو؛ باگی که دیر رسید
ملموسترین بخش این ماجرا داستان یک استارتاپ کوچک ایتالیایی به نام بایناریو است. این تیم هفتنفره، طبق گزارشهای منتشرشده، آسیبپذیری جدیای در مکاواس کشف کرد که امکان بهدستگرفتن کامل کنترل دستگاه را فراهم میکرد. جالب اینکه خود تیم برای رسیدن به این کشف از ابزارهای هوش مصنوعی کمک گرفته بود.
مشکل زمانی پیش آمد که تیم خواست یافته را ثبت کند و با سقف تازهی گزارشها روبهرو شد. آلفردو پسولی، مدیرعامل بایناریو، به این تناقض اشاره کرده است: پژوهشگرانی که با کمک هوش مصنوعی حفرههای واقعی پیدا میکنند، قربانی نویزی میشوند که همان فناوری تولید کرده است. ارزش این آسیبپذیری در بازارهای خاکستری، طبق برآوردهای منتشرشده، بین ۱۰۰ تا ۲۰۰ هزار دلار تخمین زده شده است؛ رقمی که نشان میدهد اگر بهجای گزارش رسمی به مسیر دیگری میرفت، چه هزینهای برای کاربران داشت. اپل بعداً مستقیماً با این تیم تماس گرفت.
این پرونده اهمیت نمادین دارد چون دقیقاً همان حالتی است که هر سیستم فیلترینگ از آن میترسد: خطای نوع دوم. سیستمی که برای حذف نویز طراحی شده، سیگنال واقعی را هم حذف میکند. تفاوت اینجاست که در امنیت نرمافزار، هزینهی یک خطای نوع دوم میتواند میلیونها کاربر را درگیر کند.
۴) چرا مدلهای زبانی گزارش باگ ساختگی میسازند؟
برای فهم ریشهی مسئله باید به سازوکار خود مدلها برگردیم. یک مدل زبانی برای پیشبینی محتملترین ادامهی متن آموزش دیده است، نه برای تأیید صحت گزارهها. وقتی از آن میخواهید «یک گزارش آسیبپذیری» بنویسد، خروجیاش متنی است که شبیه گزارشهای واقعی است؛ و چون نمونههای واقعی فراوانی در دادههای آموزشی دیده، این شباهت میتواند بسیار قانعکننده باشد.
مسئله وقتی جدیتر میشود که کاربر خودش هم دانش کافی برای ارزیابی خروجی ندارد. کسی که فقط دنبال جایزهی نقدی است، متن تولیدشده را میخواند، منطقی بهنظرش میرسد و ارسالش میکند. اینجا مدل چیزی را «جعل» نکرده؛ بلکه کاری را انجام داده که برایش طراحی شده و انسان پشت آن، مرحلهی راستیآزمایی را حذف کرده است. توضیح سادهتر این محدودیتها را در مقالهی توان و محدودیتهای واقعی هوش مصنوعی دنبال کنید.
بخش دیگری از ماجرا به کیفیت درخواست برمیگردد. پرامپت مبهم و بدون محدودیت، مدل را به سمت تولید متن عمومی و پرطمطراق میبرد؛ در حالی که پرامپت دقیق با شرطهای تأییدپذیر، خروجی محتاطانهتری میسازد. اگر میخواهید تفاوت این دو را در عمل ببینید، راهنمای پرامپتنویسی برای مبتدیها نقطهی شروع خوبی است.
۵) هزینهی پنهان بررسی گزارشهای بیکیفیت
در نگاه اول شاید بهنظر برسد که یک گزارش اشتباه هزینهی چندانی ندارد؛ کافی است کارشناس نگاهی بیندازد و ردش کند. اما واقعیت عملیاتی چیز دیگری است. رد کردن یک گزارش امنیتی بهسرعت ممکن نیست، چون رد اشتباهِ یک باگ واقعی فاجعه است. بنابراین هر گزارش، حتی مشکوک، باید بازتولید شود، مسیر حمله بررسی شود و در برخی موارد کد مربوطه دوباره خوانده شود.
وقتی حجم ورودی چند برابر میشود، این هزینه به شکل خطی رشد نمیکند؛ صف طولانی میشود، زمان پاسخ بالا میرود و پژوهشگران واقعی که ماهها منتظر میمانند انگیزهشان را از دست میدهند. اثر مرکب این وضعیت، کاهش کیفیت متوسط ورودیهاست: کسانی که بیشترین ارزش را میآفرینند زودتر از سیستم خارج میشوند و کسانی که کمترین هزینه را میپردازند باقی میمانند.
این پدیده منحصر به اپل نیست. پروژههای متنباز و پلتفرمهای واسط باگبانتی هم در ماههای گذشته از فشار مشابهی گفتهاند. تفاوت اپل در مقیاس و در این است که پاسخش شفاف و رسمی بوده؛ چیزی که آن را به مطالعهی موردی مفیدی برای بقیهی صنعت تبدیل میکند.
۶) تناقض بزرگ؛ اپل هم از هوش مصنوعی استفاده میکند
نکتهی ظریف ماجرا اینجاست که خودِ اپل از مدلهای هوش مصنوعی برای کشف آسیبپذیری استفاده میکند. طبق گزارشها، شرکت از مدلهای آنتروپیک و اوپنایآی در فرایندهای امنیتی داخلی بهره میگیرد و همین موضوع باعث شده تعداد رفعهای امنیتی در برخی بهروزرسانیهای اخیر چند برابر حالت معمول باشد.
پس مسئله «هوش مصنوعی در امنیت» نیست؛ مسئله «هوش مصنوعی بدون راستیآزمایی» است. وقتی خروجی مدل درون یک خط لولهی مهندسی قرار میگیرد که تست خودکار، بازتولید و بازبینی انسانی دارد، نتیجه جهش بهرهوری است. وقتی همان خروجی مستقیم و بدون فیلتر به صف بررسی دیگران فرستاده میشود، نتیجه انتقال هزینه است. تفاوت این دو حالت را میتوان در بحث توهم توسعهدهندهی تنها در برابر مهندس واقعی با جزئیات بیشتر دید.
۷) آیندهی باگبانتی؛ از کشف به اعتبارسنجی
کارشناسان امنیتی معتقدند نقش برنامههای باگبانتی در حال جابهجایی است. رِیف پیلینگ از شرکت سوفوس این تغییر را چنین توصیف کرده که تمرکز این برنامهها از «کشف» آسیبپذیری به «اعتبارسنجی» آن در سرعت ماشینی منتقل شده است. یعنی وقتی پیدا کردن سرنخ ارزان میشود، ارزش واقعی به توانایی تشخیص سرنخ درست از غلط منتقل میشود.
پیامد عملی این جابهجایی چند چیز است: اهمیت یافتن اثباتهای اجرایی بهجای توضیح متنی، وزن بیشتر سابقه و اعتبار پژوهشگر، و احتمالاً ورود لایهی خودکار غربالگری در ابتدای مسیر. برخی سازمانها هم به سمت مدل دعوتنامهای میروند؛ یعنی برنامهی باز عمومی جای خود را به حلقهی محدودتری از پژوهشگران تأییدشده میدهد.
این تغییرات لزوماً بد نیستند، اما یک ریسک روشن دارند: بستن در به روی تازهواردها. بسیاری از بهترین پژوهشگران امنیت امروز، روزی با یک گزارش ساده و بدون سابقه شروع کردند. اگر سیستم بهگونهای طراحی شود که فقط نامهای شناختهشده امکان ورود داشته باشند، تنوع نگاهها کاهش مییابد و همین میتواند در بلندمدت به ضرر امنیت تمام شود.
۸) این ماجرا برای کاربران و کسبوکارها چه پیامی دارد؟
درس اول برای هر تیمی که با خروجی مدلها کار میکند روشن است: تولید متن ارزان شده، اما اعتبارسنجی همچنان گران است. هر جریان کاری که خروجی مدل را بدون مرحلهی بررسی به دست دیگری میرساند، در واقع هزینهاش را به گردن او میاندازد. این الگو در کارراهههای سازمانی هم دیده میشود؛ موضوعی که در اهمیت هوش مصنوعی در کسبوکار از زاویهی مدیریتی بررسی شده است.
درس دوم به شکل استفاده برمیگردد. مدلها در نقش دستیارِ پژوهشگر عالی عمل میکنند: خواندن سریع کد، پیشنهاد فرضیه، ساخت اسکریپت تست. اما جایگزین قضاوت انسانی نیستند. برای مقایسهی رفتار مدلهای مختلف در وظایف استدلالی، بررسی نبرد چتجیپیتی و دیپسیک نشان میدهد اختلاف کیفیت خروجی چقدر میتواند زیاد باشد.
درس سوم برای کسانی است که تازه وارد این حوزه شدهاند: ارزش شما در آینده به این نیست که چقدر سریع متن تولید میکنید، بلکه به این است که چقدر دقیق میتوانید ادعاها را راستیآزمایی کنید. مجموعهی آموزشهای کاربردی چتجیپیتی برای ساختن همین عادت طراحی شده است.
پرسشهای پرتکرار دربارهی محدودیت تازهی اپل
آیا اپل برنامهی باگبانتی را تعطیل کرده است؟
خیر. برنامه فعال است و تنها تعداد گزارشهای بازِ همزمان هر حساب محدود شده و میان دستههای ارسال فاصلهی سیروزه قرار گرفته است.
پژوهشگران حرفهای چطور میتوانند سهمیهی بیشتری بگیرند؟
طبق گزارشها، اپل امکان درخواست افزایش سهمیه را از طریق درگاه امنیتی خود فراهم کرده و سابقهی گزارشهای معتبر در این تصمیم نقش دارد.
منظور از «اِیآی اِسلاپ» در امنیت چیست؟
گزارشهایی که با کمک مدلهای زبانی نوشته شدهاند، ظاهر فنی و قانعکننده دارند اما آسیبپذیری واقعی پشتشان نیست و تنها زمان تیم بررسی را میگیرند.
آیا استفاده از هوش مصنوعی برای یافتن باگ ممنوع شده است؟
خیر. حتی خود اپل هم از مدلهای هوش مصنوعی در فرایندهای امنیتی داخلی استفاده میکند. مشکل، ارسال خروجی بدون راستیآزمایی است، نه استفاده از ابزار.
این تصمیم چه تأثیری بر امنیت کاربران عادی دارد؟
در کوتاهمدت باعث میشود گزارشهای واقعی سریعتر بررسی شوند، اما همانطور که پروندهی بایناریو نشان داد، ریسک از دست رفتن یافتههای مهم هم وجود دارد.
