خانه محصولات اشتراک ها مقاله ها راهکارها درباره ما ورود به حساب درخواست مشاوره
MODIRAM / JOURNAL

هوش مصنوعی باگ پیدا می‌کند؛ چه زمانی نرم‌افزار ما واقعاً امن‌تر می‌شود؟

Anthropic اسکن امنیتی رایگان برای پروژه‌های متن‌باز معرفی کرده است. بررسی می‌کنیم گزارش هوش مصنوعی چگونه به اصلاح واقعی می‌رسد و چه چیزی هنوز باید تأیید شود.

تاریخ انتشار1405/07/17 07:42 زمان مطالعه6 دقیقه
هوش مصنوعی باگ پیدا می‌کند؛ چه زمانی نرم‌افزار ما واقعاً امن‌تر می‌شود؟
MODIRAM EDITORIALهوش مصنوعی

اعلان «به‌روزرسانی امنیتی آماده است» روی گوشی ظاهر می‌شود. برای ما، داستان معمولاً از همین‌جا شروع می‌شود؛ اما پشت آن ممکن است کسی خطایی را پیدا کرده، برنامه‌نویسی علتش را بررسی کرده و گروه دیگری نسخه اصلاح‌شده را آزموده باشد. حالا هوش مصنوعی می‌خواهد بخش بیشتری از این کار را انجام دهد. پرسش اصلی این است: سریع‌تر پیدا کردن خطا، چه زمانی به امنیت بیشتر برای کسی تبدیل می‌شود که فقط می‌خواهد از برنامه‌اش استفاده کند؟

Anthropic در ۸ اکتبر ۲۰۲۶، هم‌زمان با انتشار خبر رسمی خود، سرویس رایگان و اختیاری OSS Scanner را برای بررسی امنیتی پروژه‌های مهم متن‌باز معرفی کرد. گزارش‌های این سرویس با هوش مصنوعی تولید می‌شوند و پیش از ارسال، بازبینی انسانی ندارند. همین نکته، مرز میان یک خبر امیدوارکننده و برداشت اغراق‌آمیز از آن است. اعلام رسمی عرضه سرویس

خطایی در جایی که کاربر هرگز آن را نمی‌بیند

همه بخش‌های یک برنامه را لزوماً سازنده همان برنامه از ابتدا نمی‌نویسد. Anthropic در توضیح برنامه امنیتی خود بر نقش اجزای متن‌باز مشترک و فشار کاری نگهدارندگان آن‌ها تأکید می‌کند. متن‌باز بودن یعنی کد پروژه در دسترس بررسی و استفاده طبق مجوز آن قرار دارد؛ نه اینکه هر کسی بتواند بی‌اجازه نسخه نصب‌شده روی دستگاه شما را تغییر دهد. توضیح زمینه و هدف برنامه امنیتی Anthropic

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

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

گزارش قابل‌بررسی، هنوز اصلاح نصب‌شده نیست

طبق مستندات رسمی OSS Scanner، آماده‌سازی اولیه پروژه در محیط مجازی با دسترسی شبکه انجام می‌شود و مرحله اسکن پس از آن، بدون دسترسی شبکه ادامه می‌یابد. یافته‌ها برای نگهدارندگان پروژه ارسال می‌شوند و می‌توانند نمونه‌ای برای بازتولید خطا و، در صورت فراهم بودن، اصلاح پیشنهادی داشته باشند. این فرایند را نباید با آزمایش مستقیم امنیت گوشی کاربران اشتباه گرفت. مستندات رسمی OSS Scanner

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

بازتولید یعنی بتوان شرایط گزارش‌شده را دوباره ایجاد کرد و نتیجه را دید. این کار، ادعا را بررسی‌پذیرتر می‌کند؛ ولی هنوز باید پرسید نتیجه واقعاً پیامد امنیتی دارد یا فقط خطایی کم‌اهمیت است. اصلاح پیشنهادی هم نیاز به آزمون دارد: برطرف شدن همان خطا کافی نیست اگر تغییر جدید، رفتار درست دیگری از برنامه را خراب کند. این‌ها پرسش‌های ارزیابی‌اند، نه نتیجه آزمایش ما روی سرویس تازه.

جدا بودن این مراحل، مختص ابزار جدید Anthropic نیست. در معماری مستند OSS-Fuzz گوگل نیز گزارش مشکل، اصلاح آن در پروژه اصلی و تأیید اصلاح، گام‌های جداگانه‌اند. این مستند قدیمی‌تر را برای توضیح فرایند می‌خوانیم؛ نه به‌عنوان خبر امروز یا شاهدی برای تأیید عملکرد OSS Scanner. دو سرویس یکسان نیستند و از این شباهت نمی‌توان برتری یکی را نتیجه گرفت. معماری OSS-Fuzz

عدد ۸۸ درصد دقیقاً درباره چیست؟

Anthropic می‌گوید کارشناسان، ۹۷ گزارش با شدت بالا یا بحرانی از ۴۸ پروژه را در ارزیابی نسخه اولیه بررسی کردند. از این نمونه، ۸۵ گزارش، یعنی حدود ۸۸ درصد، معیار برنامه افشای هماهنگ آسیب‌پذیری شرکت را داشتند؛ ۱۱ مورد واقعی اما تکراری یا از قبل شناخته‌شده بود و یک مورد نامعتبر تشخیص داده شد. این ارزیابی گزارش‌شده از سوی شرکت است، نه ممیزی مستقل. روش و نتیجه ارزیابی اعلام‌شده

این عدد سهم خطاهای کشف‌شده از تمام خطاهای موجود نیست؛ تعداد خطاهای پنهان را نمی‌دانیم. نتیجه فقط درباره همان نمونه و معیار اعلام‌شده معنا دارد. گزارش‌های شدید نیز لزوماً نماینده همه گزارش‌ها نیستند. بنابراین پذیرش هر خروجی آینده بدون بررسی، از این ارزیابی نتیجه نمی‌شود.

بار کار از کشف خطا به بررسی آن منتقل می‌شود؟

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

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

ارزیابی منصفانه در ماه‌های بعد می‌تواند روی نتیجه متمرکز شود: چه تعداد گزارش به اصلاح پذیرفته‌شده رسیده، رسیدگی چقدر زمان برده و نگهدارندگان چقدر وقت صرف بررسی کرده‌اند و چقدر زمان برایشان صرفه‌جویی شده است؟ این‌ها معیارهای پیشنهادی برای پیگیری خبر هستند. نبود چنین داده‌هایی در این مقاله به معنی شکست ابزار نیست؛ یعنی هنوز نباید موفقیت آن در کل مسیر را قطعی بنامیم.

آخر این مسیر باید به دستگاه ما برسد

برای کاربر عادی، توصیه عملی به نصب ابزار تخصصی اسکن کد وابسته نیست. کمیسیون تجارت فدرال آمریکا در راهنمای امنیت مصرف‌کننده بر به‌روز نگه داشتن سیستم‌عامل، مرورگر و برنامه‌ها و فعال کردن به‌روزرسانی خودکار تأکید دارد. این توصیه عمومی، پیش از خبر تازه هم وجود داشته است. راهنمای FTC درباره به‌روزرسانی نرم‌افزار

خبر امروز دلیل خوبی برای دنبال کردن نقش دفاعی هوش مصنوعی است، اما نباید فقط بر اساس تعداد گزارش‌های پیدا‌شده درباره امنیت دستگاه خودمان نتیجه‌گیری کنیم. وقتی خبر آسیب‌پذیری مشخصی منتشر می‌شود، سؤال مفیدتر این است: کدام نسخه درگیر است و اصلاح در کدام نسخه به دست کاربر می‌رسد؟ ارزش نهایی کشف، در بسته شدن همین فاصله دیده می‌شود؛ فاصله‌ای که از گزارش شروع می‌شود و باید به نرم‌افزاری برسد که واقعاً استفاده می‌کنیم.

هر دو تصویر این مقاله با هوش مصنوعی ساخته شده‌اند و تصویرسازی مفهومی هستند؛ عکس واقعی یک رخداد یا نمای رابط کاربری OSS Scanner نیستند.

منابع

M
درباره نویسنده

تیم تحریریه مدیرم

تجربه‌های واقعی تیم مدیرم از طراحی محصول، معماری سیستم و ساخت نرم‌افزارهای قابل اتکا برای کسب‌وکارها.

همه مقاله‌ها ↗
گفتگو درباره این مطلب

نظر شما چیست؟

نظر شما برای ما ارزشمند استدیدگاه شما پس از بررسی نمایش داده می‌شود.
امتیاز شما
NEXT STEP / YOUR PROJECT

این مسئله در کسب‌وکار
شما هم واقعی است؟

برای تبدیل آن به یک سیستم روشن، سریع و قابل توسعه با ما گفتگو کنید.

شروع گفتگو ↗