آنتروپیک سرویس اسکن امنیتی داوطلبانه برای پروژه‌های مهم متن‌باز راه‌اندازی کرد
۲۳ اکتبر ۲۰۲۶ | نویسنده: مت ساندرز
شرکت هوش مصنوعی آنتروپیک سرویس OSS Scanner را راه‌اندازی کرده استنگه‌دارانی که در این طرح ثبت‌نام می‌کنند، گزارش‌های امنیتی دوره‌ای دریافت خواهند کرد که با استفاده از قدرتمندترین مدل‌های این شرکت، از جمله Claude Mythos، تولید می‌شوند. این گزارش‌ها بدون بررسی انسانی ارسال می‌شوند و نگه‌داران پروژه‌ها می‌توانند یافته‌های آن‌ها را اعتبارسنجی کنند و تصمیم بگیرند کدام اصلاحات پیشنهادی را بپذیرند.
تیم امنیتی Frontier Red Team آنتروپیک در اطلاعیه هشتم اکتبر خود توضیح داده است که اعتبارسنجی انسانی به یکی از عوامل محدودکننده این فرایند تبدیل شده است. مدل‌های این شرکت طی شش ماه بیش از ۲۹ هزار آسیب‌پذیری احتمالی شناسایی کردند، اما پژوهشگران توانستند تنها حدود ۶ هزار مورد را به‌صورت دستی بررسی و اولویت‌بندی کنند. پیش از این نیز نگه‌دارانی که درخواست دسترسی زودهنگام داده بودند، نزدیک به ۵ هزار گزارش اعتبارسنجی‌نشده را همراه با وصله‌های اصلاحی پیشنهادی دریافت کرده بودند.
هر گزارش این اسکنر شامل ابزاری مستقل برای بازتولید خطا و توضیحی درباره آسیب‌پذیری احتمالی است. این سرویس در صورت امکان، با استفاده از روش جست‌وجوی دودویی در تغییرات کد (Bisection)، تغییری را که باعث ایجاد خطا شده است شناسایی می‌کند و یک وصله اصلاحی پیشنهادی نیز ارائه می‌دهد. این قابلیت ادامه فعالیت‌هایی است که در قالب پروژه Glasswing انجام شده بود؛ پروژه‌ای که InfoQ در ماه آوریل به آن پرداخت
«چندین گزارش همراه با اصلاحاتی ارائه شدند که می‌توانیم تقریباً بدون تغییر از آن‌ها استفاده کنیم.»
آنتروپیک نسخه اولیه اسکنر را با کمک متخصصان آزمون نفوذ ارزیابی کرد. از این متخصصان خواسته شد ۹۷ مورد از یافته‌های دارای شدت بحرانی و بالا را در ۴۸ پروژه بررسی کنند. از میان این موارد، ۸۵ یافته با معیارهای این شرکت برای افشای هماهنگ آسیب‌پذیری‌ها مطابقت داشتند. ۱۱ مورد دیگر نیز آسیب‌پذیری‌های واقعی بودند، اما با مشکلات شناخته‌شده یا یافته‌های دیگر اسکن تکرار داشتند و تنها یک مورد نامعتبر تشخیص داده شد. البته این نتایج صرفاً به نمونه انتخاب‌شده مربوط است و نمی‌توان آن را معیاری برای تعیین نرخ دقت تمام گزارش‌هایی دانست که این سرویس در آینده تولید خواهد کرد.
با این حال، آنتروپیک پذیرفته است که برخی نگه‌داران با گزارش‌هایی مواجه شده‌اند که شدت آسیب‌پذیری‌ها را بیش از اندازه برآورد کرده یا مدل تهدید پروژه‌های آن‌ها را به‌درستی درک نکرده‌اند. با وجود این محدودیت‌ها، آنتون آراپوف (Anton Arapov) از شرکت OpenSSL Corporation کیفیت گزارش‌های اولیه را «هم‌سطح و گاهی بهتر از گزارش‌هایی که از افراد دریافت می‌کنیم» توصیف کرده است؛ به‌ویژه در مواردی که وجود یک کد بهره‌برداری عملی، تأیید آسیب‌پذیری را آسان می‌کرد.
تاد اوسکا (Todd Ouska) از پروژه wolfSSL نیز اعلام کرده است که وصله‌های اصلاحی پیشنهادی با فرایند فعلی این پروژه برای اعتبارسنجی و رفع آسیب‌پذیری‌ها سازگار بوده‌اند:
«از میان ۷۴ گزارشی که دریافت کردیم، همه به‌جز دو مورد معتبر بودند و پنج مورد نیز به ثبت شناسه CVE منجر شدند.»
علاوه بر نمونه‌های مطرح‌شده در اطلاعیه آنتروپیک، نمونه دیگری نیز وجود دارد که نگه‌دار پروژه آن را تأیید کرده است. دنیل استنبرگ (Daniel Stenberg) از پروژه curl، شناسایی یک آسیب‌پذیری استفاده پس از آزادسازی حافظه (Use-After-Free) در فرایند بارگذاری داده از طریق HTTP/2 را به لونا تانگ (Luna Tong) از آنتروپیک نسبت داده است که با استفاده از OSS Scanner این مشکل را کشف کرده بود. این آسیب‌پذیری با شناسه CVE-2026-92392 در نسخه 8.23.0 نرم‌افزار curl برطرف شد و در شرایط خاص می‌توانست امکان اجرای کد از راه دور را فراهم کند. با این حال، استنبرگ شدت آن را «بالا» و نه «بحرانی» ارزیابی کرد، زیرا بهره‌برداری موفق از آن دشوار بود و احتمال از کار افتادن برنامه بیشتر از اجرای کد دلخواه به نظر می‌رسید.
آنتروپیک سرویس OSS-Fuzz گوگل را یکی از منابع الهام خود معرفی کرده است، هرچند OSS Scanner برای بررسی کد از مدل‌های زبانی استفاده می‌کند. نمونه قابل مقایسه دیگر، CodeMender متعلق به گوگل دیپ‌مایند است که InfoQ در اکتبر ۲۰۲۵ درباره آن گزارش داده بود. در اطلاعیه معرفی این ابزار، پژوهشگرانی به نام رالوکا آدا پوپا (Raluca Ada Popa) و فور فلین (Four Flynn) فرایند اعتبارسنجی خودکار وصله‌های اصلاحی را با استفاده از تحلیل برنامه و آزمون نرم‌افزار تشریح کردند. با این تفاوت که در CodeMender بررسی انسانی پیش از ارسال اصلاحات به پروژه اصلی حفظ شده بود، در حالی که OSS Scanner یافته‌های بررسی‌نشده توسط انسان را مستقیماً در اختیار نگه‌داران قرار می‌دهد.
اهمیت اقداماتی که پس از کشف آسیب‌پذیری باید انجام شوند، در بحث‌های جامعه متخصصان امنیت نیز مطرح شده است. وارون بادوار (Varun Badhwar) در لینکدین نوشته است: «اگر سه نسخه اصلی از نسخه فعلی عقب باشید، ارائه یک وصله در پروژه بالادستی کمک چندانی به شما نمی‌کند.» بادوار که مدیرعامل و هم‌بنیان‌گذار شرکت ارائه‌دهنده راهکارهای امنیت نرم‌افزار Endor Labs است، معتقد است سازمان‌ها باید مشخص کنند که آیا کد آسیب‌پذیر واقعاً از مسیرهای اجرایی برنامه قابل دسترسی است و آیا می‌توانند بدون ایجاد اختلال در برنامه‌های خود، اصلاحیه مربوط را اعمال کنند.
دیمیتریوس توماس (Dimitrios Thomas) نیز در مطلبی در لینکدین که آن را از دیدگاه شخصی خود نوشته، تأکید کرده است که ارزیابی چنین ابزارهایی باید «دقت اعتبارسنجی، حجم کاری نگه‌داران و مدت‌زمان میان کشف آسیب‌پذیری تا استقرار اصلاحیه» را در نظر بگیرد. معیارهای پیشنهادی او فراتر از شمار آسیب‌پذیری‌های گزارش‌شده هستند.
در بخش پرسش‌های متداول OSS Scanner توضیح داده شده است که عامل‌های هوش مصنوعی پیش از ارسال گزارش‌ها از طریق ایمیل، خطاها را دوباره بررسی می‌کنند، وصله‌های اصلاحی پیشنهاد می‌دهند و علت‌های ریشه‌ای مشکلات را تحلیل می‌کنند. این بررسی خودکار با بازبینی انسانی تفاوت دارد. اسکن‌های بعدی نیز با هدف یافتن مشکلات تازه‌ای که به کد اضافه شده‌اند و همچنین آسیب‌پذیری‌هایی که در بررسی‌های قبلی شناسایی نشده‌اند انجام می‌شوند. تناوب این اسکن‌ها به عواملی از جمله میزان استفاده از پروژه و حجم کاری سرویس بستگی دارد.
نگه‌داران اصلی پروژه‌ها برای ثبت‌نام باید یک درخواست تغییر (Pull Request) در گیت‌هاب ثبت کنند که شامل پیکربندی پروژه و یک فایل Dockerfile برای آماده‌سازی فرایند ساخت نرم‌افزار و وابستگی‌های آن باشد. پس از انجام تنظیمات اولیه، اسکن بدون دسترسی به اینترنت اجرا می‌شود. همچنین نگه‌داران می‌توانند به‌صورت اختیاری فایلی برای مدل تهدید ارائه کنند که محدوده بررسی و انتظارات مربوط به تعیین شدت آسیب‌پذیری‌ها را مشخص می‌کند. صلاحیت پروژه‌ها برای استفاده از این سرویس به‌صورت موردی ارزیابی می‌شود و اولویت با پروژه‌های باسابقه‌ای است که برای زیرساخت‌ها و امنیت کاربران اهمیت دارند و از پیش توانایی رسیدگی به گزارش‌های تأییدشده با شدت بالا را دارند.
نگه‌داران می‌توانند از سند مدل تهدید برای مشخص کردن ورودی‌های غیرقابل اعتماد، مستثنا کردن برخی اجزای پروژه از بررسی و توضیح معیارهای خود برای ارزیابی شدت آسیب‌پذیری‌ها استفاده کنند. این سند همچنین می‌تواند قالب ترجیحی گزارش‌ها و انتظارات مربوط به وصله‌های اصلاحی را تعیین کند. آنتروپیک درخواست‌های ثبت‌نام را به‌صورت دستی بررسی می‌کند تا مطمئن شود متقاضی از نگه‌داران اصلی پروژه است و یافته‌ها به مسئول امنیتی مجاز آن پروژه ارسال خواهند شد.
پروژه‌ها می‌توانند دریافت گزارش‌ها را موقتاً متوقف کنند یا به‌طور کامل از این طرح خارج شوند. یافته‌هایی که هنوز اعتبارسنجی نشده‌اند، به‌طور خودکار مشمول مهلت ۹۰روزه افشای آسیب‌پذیری نمی‌شوند. با این حال، اگر گزارشی بعداً به‌صورت دستی تأیید شود، ممکن است وارد فرایند جداگانه افشای هماهنگ آسیب‌پذیری‌ها شود. در این صورت، مهلت ۹۰روزه از زمانی آغاز خواهد شد که نگه‌داران از تأیید آن گزارش مطلع شوند. آنتروپیک همچنان گزارش‌های آسیب‌پذیری بررسی‌شده توسط انسان را نیز ارائه می‌کند، به‌ویژه برای پروژه‌هایی که منابع کافی برای بررسی و اولویت‌بندی یافته‌های اولیه و اعتبارسنجی‌نشده را در اختیار ندارند.