اسکنر متن‌باز Anthropic؛ بررسی امنیتی رایگان با هوش مصنوعی، اصلاح آسیب‌پذیری‌ها و بار کاری نگه‌دارندگان
اخبار هوش مصنوعی
۱۹ اکتبر ۲۰۲۶
نویسنده: کرتیس پایک
شرکت Anthropic اسکن‌های امنیتی رایگان مبتنی بر هوش مصنوعی را برای پروژه‌های مهم متن‌باز ارائه می‌کند. اصلاح یک آسیب‌پذیری جدی در curl نشان داده است که این سرویس چه ظرفیت‌هایی دارد؛ بااین‌حال، نگه‌دارندگان پروژه‌ها همچنان باید تصمیم بگیرند چه میزان کار بررسی‌نشده را می‌توانند مدیریت کنند.
یکی از قوی‌ترین دلایل برای جدی گرفتن اسکنر OSS Scanner شرکت Anthropic، تجربه پروژه curl است. دنیل استنبرگ، نگه‌دارنده این پروژه، در ۱۴ اکتبر ۲۰۲۶ اعلام کرد که این سرویس آسیب‌پذیری‌ای از نوع استفاده پس از آزادسازی حافظه (use-after-free) را شناسایی کرده است؛ مشکلی که در نسخه ۸.۲۳.۰ curl برطرف شد. به گفته او، این نقص در شرایط خاص و دشوار می‌توانست به اجرای کد از راه دور منجر شود. پروژه شدت آن را بالا ارزیابی کرد. شرح استنبرگ چیزی فراتر از وعده‌های زمان راه‌اندازی در اختیار می‌گذارد: نام یک نگه‌دارنده مشخص، یک اطلاعیه امنیتی عمومی و اصلاحی که در قالب نسخه جدید منتشر شده است.
این تجربه پرسشی عملی را مطرح می‌کند: اگر هوش مصنوعی بتواند گزارش‌های مفید آسیب‌پذیری را سریع‌تر از توان متخصصان امنیتی برای بررسی آن‌ها تولید کند، گزارش‌های بررسی‌نشده باید به دست چه کسانی برسند و چه کسانی فرصت دارند آن‌ها را به انتشار نسخه‌های امن تبدیل کنند؟
OSS Scanner به نگه‌دارندگان واجد شرایط امکان انتخاب می‌دهد. ارزیابی ما این است که پروژه‌هایی با فرایند تثبیت‌شده پاسخ‌گویی امنیتی باید این سرویس را جدی بررسی کنند. در مقابل، تیمی که همین حالا نیز در پردازش آسیب‌پذیری‌های تأییدشده با مشکل روبه‌روست، بهتر است پیش از پذیرفتن یک مسیر ورودی جدید محتاطانه تصمیم بگیرد.
بررسی منابع در ۱۹ اکتبر ۲۰۲۶ انجام شده است. این مطلب تحلیلی مبتنی بر منابع است و حاصل آزمایش عملی اسکنر توسط Kingy.ai نیست. ما پروژه‌ای را در سرویس ثبت‌نام نکردیم، گزارش‌های خصوصی را ندیدیم و آسیب‌پذیری‌های مطرح‌شده در ادامه را بازتولید نکردیم. نتایج ارائه‌شده از سوی عرضه‌کننده، شواهد نگه‌دارندگان، محاسبات و توصیه‌های تحریریه در متن از یکدیگر تفکیک شده‌اند.
اسکنر متن‌باز Anthropic چه کاری انجام می‌دهد؟
Anthropic در ۸ اکتبر، اسکنر OSS Scanner را در قالب برنامه گسترده‌تر خود با عنوان مأموریت سایبری (Cyber Mission) راه‌اندازی کرد. این شرکت هزینه اسکن‌های دوره‌ای آسیب‌پذیری را برای پروژه‌های متن‌باز پذیرفته‌شده می‌پردازد. هدف اعلام‌شده این است که یافته‌های امنیتی سریع‌تر به دست نگه‌دارندگان برسند و درعین‌حال، برای پروژه‌هایی که به این فرایند نیاز دارند، افشای هماهنگ‌شده با تأیید انسانی ادامه یابد.
گزارش‌ها بدون بازبینی انسانی ارسال می‌شوند و فاصله زمانی میان اسکن‌های تکراری ثابت نیست. بخش پرسش‌های متداول رسمی هیچ تعهدی برای انجام اسکن هفتگی نمی‌دهد. بنابراین، برنامه بررسی و انتشار نسخه‌ها را بر اساس زمان‌بندی‌ای تنظیم کنید که خود پروژه بر آن کنترل دارد.
در توضیحات راه‌اندازی آمده است که گزارش‌ها ممکن است شامل نمونه‌ای برای بازتولید مشکل، توضیح فنی، تحلیل دودویی‌سازی (bisection) در صورت امکان و وصله پیشنهادی در صورت دسترس‌بودن باشند. Anthropic می‌گوید این سرویس از قدرتمندترین مدل‌های خود، از جمله Claude Mythos، استفاده می‌کند. این توضیحی درباره قابلیت‌های سرویس است، نه تضمینی مبنی بر اینکه هر گزارش حتماً اصلاحی قابل‌استفاده ارائه خواهد کرد. منبع: گزارش راه‌اندازی Anthropic.
از دید نگه‌دارنده، این موارد خروجی‌هایی متفاوت‌اند. توضیحی قانع‌کننده به یافتن محل مشکل کمک می‌کند؛ نمونه بازتولید نشان می‌دهد که مشکل واقعاً وجود دارد؛ و وصله پیشنهادی راهکاری برای تغییر نرم‌افزار ارائه می‌دهد. پذیرفتن یکی از این موارد نباید به معنای پذیرش خودکار دو مورد دیگر باشد.
یک فرایند امنیتی مناسب این تفاوت‌ها را حفظ می‌کند. باید ثبت شود که آیا خطا بازتولید شده، آیا از یک مرز امنیتی پشتیبانی‌شده عبور می‌کند و آیا اصلاح پیشنهادی آزمون‌های رگرسیون را با موفقیت پشت سر می‌گذارد. یک گزینه ساده با عنوان «گزارش هوش مصنوعی پذیرفته شد» اطلاعاتی را از بین می‌برد که پروژه بعداً به آن‌ها نیاز خواهد داشت.
نتایج اولیه چه چیزی را ثابت می‌کنند؟
Anthropic از بررسی اولیه کارشناسان روی ۹۷ یافته با شدت بالا یا بحرانی در ۴۸ پروژه خبر داده است. بر اساس گزارش این شرکت، ۸۵ مورد معیارهای افشای هماهنگ‌شده آن را برآورده کردند، ۱۱ مورد مشکلات واقعی بودند که با مسائل شناخته‌شده یا یافته‌های دیگر هم‌پوشانی داشتند و یک مورد نامعتبر بود. این آمار را خود عرضه‌کننده و بر اساس نمونه‌ای منتخب از نتایج اولیه گزارش کرده است. ارقام یادشده همه سطوح شدت، تمام اسکن‌های آینده یا سهم آسیب‌پذیری‌های موجودی را که اسکنر از شناسایی آن‌ها بازمانده است، اندازه‌گیری نمی‌کنند. منبع: ارزیابی زمان راه‌اندازی.
بر اساس محاسبه از این ارقام، حدود ۸۷.۶ درصد یافته‌ها معیار اعلام‌شده برای افشای هماهنگ‌شده را برآورده کرده‌اند و اگر موارد تکراری نیز در شمار مشکلات واقعی لحاظ شوند، این نسبت به حدود ۹۹ درصد می‌رسد. هر دو درصد ممکن است در تیترها چشمگیر به نظر برسند؛ اما هیچ‌کدام مشخص نمی‌کنند که یک نگه‌دارنده مشخص در ازای یک بعدازظهر بررسی و دسته‌بندی گزارش‌ها، چند اصلاح جدید و مرتبط دریافت خواهد کرد.
موارد تکراری تفاوت میان این معیارها را روشن می‌کنند. چنین مواردی نشان می‌دهند اسکنر نقصی واقعی را تشخیص داده است، اما ممکن است بدون بهبود نسخه فعلی، وقت تیم را بگیرند. یافته‌ای که خارج از مدل تهدید پشتیبانی‌شده پروژه قرار دارد نیز می‌تواند وضعیت مشابهی ایجاد کند: رفتار معیوب کد ممکن است واقعی باشد، درحالی‌که درباره پیامد امنیتی ادعاشده اختلاف نظر وجود دارد.
داشبورد گسترده‌تر افشای هماهنگ‌شده آسیب‌پذیری (CVD) شرکت Anthropic که تاریخ ۲ اکتبر را دارد، بر ضرورت بررسی مخرج محاسبات تأکید می‌کند. این داشبورد ۲۹٬۴۳۹ مورد نامزد، ۶٬۱۲۳ بررسی خارجی و نرخ مثبت واقعی ۹۲.۷ درصد را در میان موارد بررسی‌شده ثبت کرده است. تعریف این شاخص، موارد تکراری و یافته‌هایی را نیز شامل می‌شود که نگه‌دارندگان ممکن است آن‌ها را اصلاح نکنند. این داشبورد پیش از راه‌اندازی عمومی OSS Scanner منتشر شده و برنامه‌ای گسترده‌تر را پوشش می‌دهد؛ بنابراین، نمی‌توان از آن به‌عنوان امتیاز دقت عملیاتی سرویس جدید استفاده کرد.
این داشبورد میان گزارش آسیب‌پذیری، تأیید دریافت آن، انتشار وصله و اختصاص شناسه اطلاعیه امنیتی نیز تمایز قائل می‌شود. این مراحل اهمیت دارند، زیرا کشف یک مشکل فقط زمانی میزان آسیب‌پذیری را کاهش می‌دهد که راهکار مؤثر به سامانه‌هایی برسد که به آن نیاز دارند. شمار وصله‌های منتشرشده در پروژه اصلی مشخص نمی‌کند که چه تعداد از نصب‌های مبتنی بر آن در پروژه‌های پایین‌دستی واقعاً محافظت شده‌اند.
Anthropic در اعلام مأموریت سایبری خود گفته است انتظار دارد نرخ مثبت واقعی از ۹۰ درصد بیشتر باشد. این رقم را باید یک انتظار دانست، نه نتیجه‌ای تضمین‌شده. پروژه‌ای که این سرویس را ارزیابی می‌کند باید تجربه خود را بسنجد؛ از جمله اختلاف بر سر شدت آسیب‌پذیری، موارد تکراری، شکست در بازتولید و کیفیت وصله‌ها.
wolfSSL داده‌ای از دید نگه‌دارندگان ارائه می‌کند
پروژه wolfSSL در مطلبی که ۱۶ اکتبر در وب‌سایت خود منتشر کرد، گزارش داده است که ۷۲ مورد از ۷۴ یافته معتبر بوده‌اند و پنج مورد به شناسه‌های CVE منتهی شده‌اند. محاسبه بر اساس ارقام نگه‌دارندگان نشان می‌دهد حدود ۹۷.۳ درصد یافته‌ها معتبر بوده‌اند. wolfSSL همچنین از برخورداری تیم مهندسی خود از توان پردازش حجم قابل‌توجهی از گزارش‌ها و مجموعه‌ای از آزمون‌های امنیتی موجود خبر داده است.
این اطلاعات برای ارزیابی تناسب سرویس با تیم wolfSSL مفید است، اما مبنای مناسبی برای وعده دادن تجربه‌ای مشابه به پروژه کوچکی که بازبین امنیتی اختصاصی ندارد، نیست. ظرفیت نگه‌دارندگان بخشی از نتیجه نهایی است.
نباید پنج شناسه CVE را به این معنا تفسیر کرد که پنج مشکل تأیید شده و ۶۹ مورد شکست خورده‌اند. اختصاص شناسه CVE، وجود یک نقص معتبر، وجود یک آسیب‌پذیری امنیتی منحصربه‌فرد و ادغام یک اصلاح در کد، چهار معیار جداگانه‌اند. گزارش عمومی جزئیات کافی برای طبقه‌بندی تک‌تک گزارش‌ها بر اساس هر چهار معیار ارائه نمی‌کند.
مورد curl نشان می‌دهد چرا شدت آسیب‌پذیری به زمینه بستگی دارد
اطلاعیه رسمی CVE-2026-92392 آسیب‌پذیری استفاده پس از آزادسازی حافظه در بارگذاری داده از طریق HTTP/2 را شرح می‌دهد. این مشکل در شاخه اصلی curl نسخه‌های ۸.۱۲.۰ تا ۸.۲۲.۰ را تحت تأثیر قرار می‌دهد و در نسخه ۸.۲۳.۰ اصلاح شده است. اطلاعیه همچنین نسخه‌های اصلاح‌شده شاخه‌های نگه‌داری را فهرست می‌کند. هنگام بررسی یک بسته نرم‌افزاری نصب‌شده، باید این استثناها و اطلاعات وصله‌های توزیع‌کننده آن را نیز بررسی کرد؛ مقایسه شماره نسخه‌ها به‌تنهایی کافی نیست.
شرح فنی استنبرگ محدودیتی را توضیح می‌دهد که پشت ارزیابی شدت بالا قرار دارد: اجرای موفق کد به ترکیب مشخصی از شرایط نیاز دارد و از نظر او، در حمله‌ای از این نوع احتمال بروز فروپاشی برنامه بیشتر از اجرای کد است. او همچنین می‌گوید این گزارش باعث شد تیم چرخه انتشار را دو هفته کوتاه‌تر کند.
این نتیجه بدون اغراق نیز اهمیت دارد. نمونه curl نشان می‌دهد گزارشی از یک مشکل به دست نگه‌دارنده رسیده، ارزیابی شده و در نهایت به اصلاحی در نسخه منتشرشده انجامیده است. اما این تجربه ثابت نمی‌کند که تمام نصب‌های curl از راه دور قابل بهره‌برداری بوده‌اند یا اسکنر به‌تنهایی فرایند اصلاح را به پایان رسانده است.
درس دیگری نیز در این تجربه وجود دارد. گزارش نگه‌دارنده می‌تواند پیامدهایی را توضیح دهد که یک امتیاز عددی از بیان آن‌ها ناتوان است؛ از جمله پیکربندی‌های پشتیبانی‌شده، میزان کنترل واقعی مهاجم، زمان‌بندی انتشار و روش مهندسی برای جلوگیری از تکرار مشکل. اسکنر باید شواهد لازم برای این ارزیابی را فراهم کند، اما مسئولیت تصمیم نهایی همچنان بر عهده پروژه است.
این مسئولیت از کاربران در برابر اصلاحات شتاب‌زده نیز محافظت می‌کند. اگر گزارشی همراه با وصله‌ای ظاهراً معقول دریافت شود، بازبینان باید بررسی کنند که آیا اصلاح پیشنهادی خطای اصلی در طول عمر حافظه را برطرف می‌کند، مسیر خطای تازه‌ای به وجود می‌آورد، سازگاری را تغییر می‌دهد یا صرفاً مانع اجرای نمونه بازتولید ارائه‌شده می‌شود. آزمون رگرسیون باید تا حد امکان روشن و دقیق، ویژگی ایمنی مورد انتظار را بیان کند.
اسکن رایگان هم از نگه‌دارندگان وقت می‌گیرد
مسئله مدیریت گزارش‌های ورودی سابقه دارد. استنبرگ در ژوئیه ۲۰۲۵ درباره فشار ناشی از گزارش‌های امنیتی کم‌کیفیت نوشت و توضیح داد که رسیدگی به برخی گزارش‌ها برای چندین عضو تیم curl زمان قابل‌توجهی می‌گرفت. آن نوشته قدیمی‌تر به تجربه کلی پروژه در دریافت گزارش‌ها مربوط است و ارزیابی OSS Scanner محسوب نمی‌شود.
اگر این تجربه را در کنار نتیجه بعدی curl قرار دهیم، به موضعی واقع‌بینانه‌تر از خوش‌بینی یا رد کامل این ابزارها می‌رسیم. گزارش‌های کمک‌گرفته از هوش مصنوعی می‌توانند ارزشمند باشند، اما ارزش آن‌ها به کیفیت شواهد، محدوده مسئله و میزان کاری بستگی دارد که برای رسیدن به تصمیم لازم است.
دو مجموعه گزارش فرضی را در نظر بگیرید. مجموعه اول شامل ۱۰ نقص منحصربه‌فرد و قابل‌بازتولید است که برای هرکدام وصله‌ای محدود ارائه شده است. مجموعه دوم شامل ۱۰ نقص واقعی است که پروژه ماه گذشته آن‌ها را برطرف کرده است. هر دو مجموعه ممکن است درصد بالایی از «اشکالات واقعی» داشته باشند، اما ارزش آن‌ها برای نسخه فعلی نرم‌افزار یکسان نیست.
از نظر ما، مهم‌ترین شاخص عملیاتی عبارت است از ساعت کاری نگه‌دارندگان به‌ازای هر مشکل منحصربه‌فرد و مرتبط که برطرف می‌شود. زمان صرف‌شده برای رد گزارش‌ها را نیز در کنار زمان اصلاح آن‌ها ثبت کنید و رگرسیون‌هایی را که هنگام بازبینی وصله‌ها کشف می‌شوند، بشمارید. در غیر این صورت، ممکن است تیم دقت گزارش‌های ورودی را جشن بگیرد، درحالی‌که بی‌سروصدا زمان توسعه را از دست می‌دهد.
ظرفیت تیم باید بر زمان ثبت‌نام در سرویس اثر بگذارد. توقف انتشار، غیبت یکی از نگه‌دارندگان یا انباشت حل‌نشده مسائل امنیتی ممکن است جذب حتی یک سرویس از نظر فنی عالی را دشوار کند. تیم می‌تواند ابتدا فرایند ساخت و مدل تهدید خود را آماده کند و زمانی ثبت‌نام کند که فردی بتواند به‌طور قابل‌اتکا گزارش‌ها را رسیدگی کند.
اسکنر OSS Scanner، ابزار OSS-Fuzz و سرویس Claude Security وظایف متفاوتی دارند
مستندات OSS-Fuzz گوگل از فازینگ پیوسته با اجرای توزیع‌شده، موتورهای فازینگ و ابزارهای تشخیص خطا سخن می‌گوید. این روش با اجرای مکرر نرم‌افزار، به شناسایی خطاها کمک می‌کند. ممیزی مبتنی بر هوش مصنوعی می‌تواند روابط میان بخش‌های کد را بررسی کند و فرضیه‌هایی برای آزمودن پیشنهاد دهد. این رویکردها می‌توانند مکمل یکدیگر باشند؛ اما در شواهد عمومی موجود، چیزی نشان نمی‌دهد که جایگزین کردن سامانه فازینگ تثبیت‌شده با OSS Scanner پوشش آزمون را بهبود می‌دهد.
| سرویس | کاربرد اصلی | مواردی که پیش از اتکا به آن باید بررسی شوند |
|---|---|---|
| OSS Scanner | ممیزی دوره‌ای با هوش مصنوعی برای پروژه‌های مهم متن‌باز که پذیرفته شده‌اند | واجد شرایط بودن پروژه، حجم کار ناشی از گزارش‌ها، کیفیت بازتولید و فاصله واقعی میان اسکن‌ها |
| OSS-Fuzz | آزمون فازینگ پیوسته برای نرم‌افزارهای متن‌باز پشتیبانی‌شده | اهداف آزمون، کیفیت مجموعه ورودی‌ها، سلامت فرایند ساخت و میزان پوشش |
| Claude Security | اسکن تجاری کد و بازبینی وصله‌ها در فرایند کاری سازمانی | دسترسی به حساب کاربری، نیازهای یکپارچه‌سازی و شرایط تجاری فعلی |
صفحه فعلی محصول Claude Security از نسخه بتای عمومی سازمانی با استفاده از Claude Mythos 5.1، مراحل راستی‌آزمایی، وصله‌های پیشنهادی و یکپارچه‌سازی با گردش کار خبر می‌دهد. نباید فرض کرد که این ویژگی‌های اختصاصی محصول در OSS Scanner نیز وجود دارند. ترکیب مدل‌ها و فرایند عملیاتی برنامه متن‌باز جداگانه شرح داده شده است.
هنگام ارزیابی این مسیر جدید، آزمون‌های موجود، فازرها، بررسی وابستگی‌ها و بازبینی انسانی امنیت را حفظ کنید. هرگاه اسکنر نقصی پیدا کرد، در صورت امکان از آن یافته برای بهبود آزمون رگرسیون یا هدف فازینگ مربوط استفاده کنید. به این ترتیب، کشفی یک‌باره به آزمونی مستمر تبدیل می‌شود که پروژه خودش آن را کنترل می‌کند.
چه پروژه‌هایی واجد شرایط‌اند و فرایند ثبت‌نام چگونه است؟
بخش پرسش‌های متداول درباره شرایط پذیرش پروژه‌های تثبیت‌شده و حیاتی از نظر امنیتی را هدف قرار می‌دهد و صلاحیت هر پروژه به‌صورت موردی ارزیابی می‌شود. پروژه‌های تازه و انشعاب‌های معمولی عموماً واجد شرایط نیستند. تیم‌ها باید از پیش توانایی رسیدگی به گزارش‌های تأییدشده با شدت بالا و بحرانی را داشته باشند.
ثبت‌نام از طریق ارسال یک درخواست ادغام (pull request) به مخزن رسمی anthropics/oss-scanner انجام می‌شود. کد عمومی این مخزن، پیکربندی ثبت‌نام و ابزارهای پشتیبان را فراهم می‌کند؛ اما وجود این مخزن به معنای انتشار کد کامل خط لوله اسکن میزبانی‌شده نیست.
نگه‌دارنده باید پوشه‌ای در مسیر projects/<name>/، یک فایل پیکربندی و یک Dockerfile برای آماده‌سازی پروژه اضافه کند. Anthropic فرایند ساخت را با دسترسی به شبکه انجام می‌دهد و سپس ممیزی را بدون دسترسی به اینترنت اجرا می‌کند. بنابراین، آزمون‌هایی که هنگام نخستین اجرا وابستگی‌ها را دریافت می‌کنند، ممکن است شکست بخورند؛ مگر اینکه وابستگی‌های لازم در مرحله آماده‌سازی نصب شده باشند. مخزن توصیه می‌کند پیش از ارسال درخواست، پیکربندی اعتبارسنجی و محیط حاصل آزمایش شود.
قالب فعلی پیکربندی پروژه از نام فایل با حروف کوچک dockerfile استفاده می‌کند. هنگام آماده‌سازی درخواست، همین قالب و اعتبارسنج آن را دنبال کنید. نمونه زیر صرفاً نمایشی است و نشانی‌ها و مخزن آن واقعی نیستند:
repo: https://github.com/example/project#main
primary_contact: [email protected]
homepage: https://example.org
dockerfile: .oss-scanner/Dockerfile
threat_model: .oss-scanner/threat_model.md
disabled: falseقالب از افزودن گیرندگان دیگر گزارش یا یک کلید عمومی PGP با قالب متنی زره‌پوش‌شده (armored) نیز پشتیبانی می‌کند. ارسال از طریق PGP را نمی‌توان با فهرست گیرندگان اضافی ترکیب کرد. همچنین، Dockerfile می‌تواند در کنار فایل پیکربندی ثبت‌نام قرار گیرد؛ در این صورت، فیلد مسیر متناظر حذف می‌شود. پیش از ارسال، قالب به‌روز را بررسی کنید؛ این نمونه روی یک پروژه واقعی اجرا نشده است.
فایل README مخزن هشدار می‌دهد که نشانی‌های ایمیل ثبت‌شده برای پروژه عمومی هستند. از یک نشانی اختصاصی امنیتی استفاده کنید که انتشار عمومی آن مناسب باشد. ابزار بررسی محیط محلی نیز فرایند ساخت را با دسترسی به شبکه اجرا می‌کند؛ بنابراین، فقط Dockerfileهایی را اجرا کنید که به آن‌ها اعتماد دارید. آفلاین بودن مرحله ممیزی به این معنا نیست که مرحله ساخت پیش از آن نیز بدون اینترنت انجام می‌شود.
مدل تهدید مناسب می‌تواند ساعت‌ها اختلاف‌نظر را کاهش دهد
قالب مدل تهدید Anthropic از پروژه‌ها می‌خواهد ورودی‌های غیرقابل‌اعتماد، اجزای مهم، روش‌های اجرای نرم‌افزار، معیارهای شدت و موارد مستثنا را مشخص کنند. این پرسش‌ها حتی پیش از ثبت‌نام نیز برای نگه‌دارندگان مفیدند.
این فایل را برای کسی بنویسید که برنامه‌نویسی می‌داند، اما هرگز نگه‌دارنده پروژه شما نبوده است. مشخص کنید کدام عامل‌ها از پیش مورد اعتمادند، کدام عملیات به مجوز نیاز دارند و کدام مرزها برای مقاومت در برابر ورودی مخرب طراحی شده‌اند. دستور کلی «اشکالات امنیتی مهم را پیدا کن» فضای زیادی برای برداشت‌های ناسازگار باقی می‌گذارد.
برای مثال، یک تجزیه‌گر فرضی اسناد ممکن است تمام فایل‌های بارگذاری‌شده را بالقوه مخرب در نظر بگیرد، اما ابزار تولید مجموعه داده‌ای را که فقط توسعه‌دهندگان استفاده می‌کنند، از این محدوده خارج کند. یک ابزار مدیریتی ممکن است عمداً به کاربران دارای امتیاز اجازه اجرای فرمان بدهد. گزارشی که در چنین ابزاری از اجرای فرمان سخن می‌گوید، باید توضیح دهد یک عامل فاقد امتیاز چگونه می‌تواند به اختیاری دست پیدا کند که نباید داشته باشد.
این مثال‌ها توصیه‌های ما هستند، نه گزارش‌هایی درباره پروژه‌های ثبت‌نام‌شده. هدف آن است که فرض‌های بازبینان به‌اندازه کافی روشن باشند تا اسکنر بتواند آن‌ها را به چالش بکشد و نگه‌دارنده نیز امکان ارزیابی این چالش را داشته باشد.
پیکربندی‌های پشتیبانی‌شده را دقیق توصیف کنید. اگر قابلیتی اختیاری است، توضیح دهید چگونه فعال می‌شود و چه کسی معمولاً کنترل آن را در اختیار دارد. اگر موردی به دلیل فرضی درباره محیط واقعی اجرا مستثنا شده است، علت را بیان کنید. از استثناهای کلی‌ای که دسته‌های کامل ورودی را بدون مستندسازی مرز اعتماد حذف می‌کنند، بپرهیزید.
همچنین شواهدی را مشخص کنید که به تیم شما برای تصمیم‌گیری سریع کمک می‌کنند: نسخه ثبت‌شده در مخزن که آزموده شده، نمونه‌ای حداقلی برای بازتولید، گزینه‌های لازم هنگام ساخت، رفتار مورد انتظار در برابر رفتار مشاهده‌شده و آزمون رگرسیون پیشنهادی. از گزارش‌دهنده بخواهید تا حد امکان وصله‌ای محدود ارائه کند که علت اصلی را برطرف سازد. این کار چیزی ملموس در اختیار بازبینان می‌گذارد تا آن را بپذیرند، اصلاح کنند یا رد کنند.
افشا، محرمانگی و دریافت‌کنندگان گزارش‌ها
برای گزارش‌های اعتبارسنجی‌نشده، مهلت ۹۰روزه افشا آغاز نمی‌شود. اگر Anthropic بعداً گزارشی را به‌صورت دستی تأیید کند، طبق پرسش‌های متداول سرویس این مهلت از زمان اطلاع‌رسانی درباره تأیید انسانی آغاز خواهد شد. این شرکت می‌تواند با اعلام قبلی سیاست خود را تغییر دهد.
سیاست عمومی افشای هماهنگ‌شده آسیب‌پذیری (CVD) زمان‌بندی‌های جداگانه‌ای دارد؛ از جمله هدف پیش‌فرض افشا و قواعد متفاوت برای نقص‌های بحرانی که به‌طور فعال مورد سوءاستفاده قرار گرفته‌اند. نگه‌دارندگان باید میان دریافت یک مورد پیشنهادی خودکار و دریافت اطلاعیه بعدی مبنی بر تأیید انسانی تفاوت قائل شوند و زمان دریافت اطلاعیه دوم را در سامانه پیگیری امنیتی ثبت کنند.
توافق‌نامه OSS Scanner مستلزم داشتن اختیار ثبت‌نام است، استفاده از گزارش‌ها را به فعالیت‌های دفاعی مرتبط با پروژه محدود می‌کند و بررسی یافته‌ها و وصله‌ها را بر عهده شرکت‌کننده می‌گذارد. همچنین، تا زمان رفع آسیب‌پذیری یا افشای عمومی آن، حفاظت معقول از گزارش‌های حساس الزامی است. این سرویس بدون تضمین ارائه می‌شود و وصله‌های پیشنهادی ممکن است ناقص باشند یا عملکرد نرم‌افزار را مختل کنند.
پیش از به‌اشتراک‌گذاشتن گزارش خارج از گروه مجاز نگه‌دارندگان، این شرایط را بخوانید. به‌ویژه، مخزن عمومی ثبت مشکلات مقصد پیش‌فرض مناسبی برای پیامی نیست که ممکن است جزئیات یک آسیب‌پذیری اصلاح‌نشده را فاش کند. پیش از دریافت نخستین بسته گزارش، مشخص کنید چه کسانی گزارش‌ها را دریافت می‌کنند، چه افرادی به پیوست‌های آن‌ها دسترسی دارند و پروژه چگونه انتشار اطلاعیه امنیتی را هماهنگ خواهد کرد.
Anthropic اطلاعات تماس و محدوده پروژه را بررسی می‌کند و تغییرات Dockerfile را نیز بازبینی می‌کند. این بررسی جدا از تأیید تک‌تک یافته‌هاست.
توقف سرویس یا خروج از آن از طریق درخواست‌های ادغام در پیکربندی انجام می‌شود. برای یافته‌های باز مسئول مشخصی تعیین کنید و وضعیت رسیدگی به هرکدام را جداگانه ثبت کنید؛ توقف دریافت گزارش‌های جدید، گزارش‌های قبلی را حل‌وفصل نمی‌کند.
برنامه عملی برای ارزیابی نخستین چرخه اسکن
توصیه ما این است که نخستین اسکن را به‌عنوان یک فعالیت مهندسی با محدوده مشخص ارزیابی کنید. برنامه زیر توصیه تحریریه است، نه تضمینی از سوی Anthropic درباره عملکرد سرویس. پیش از ثبت‌نام، بودجه زمانی بازبینی را تعیین کنید و یک بازبین اصلی و یک جانشین مشخص کنید. همچنین پیشاپیش تصمیم بگیرید که چه نتایجی ادامه استفاده را توجیه خواهند کرد.
۱. وضعیت پایه را ثبت کنید
عقب‌ماندگی فعلی در رسیدگی به مسائل امنیتی، شاخه‌های انتشار پشتیبانی‌شده، پوشش اسکنرهای موجود و ساعات در دسترس برای بازبینی را ثبت کنید. نسخه ثبت‌شده مخزن و ساخت کانتینر استفاده‌شده برای اسکن را نیز نگه دارید. بدون این اطلاعات، تشخیص اینکه شکست در بازتولید ناشی از اشکال گزارش است یا تغییری که بین زمان اسکن و بازبینی اصلاح شده، ممکن است دشوار باشد.
۲. هر گزارش را در چند محور مستقل دسته‌بندی کنید
قابلیت بازتولید، منحصربه‌فرد بودن، قرار گرفتن در محدوده پشتیبانی‌شده، پیامد امنیتی و وضعیت وصله را جداگانه ثبت کنید. نتیجه «شواهد ناکافی» را نیز به‌عنوان یک گزینه بپذیرید. ممکن است گزارشی یک فروپاشی واقعی را توصیف کند، اما دامنه دسترسی مهاجم را بیش از حد نشان دهد؛ همچنین ممکن است یک گزارش تکراری از نظر فنی درست باشد، اما کار تازه و ارزشمندی به پروژه اضافه نکند.
۳. مشکل را در محیط آزمایشی ایزوله بازتولید کنید
ابتدا از نسخه گزارش‌شده و شرایط ساخت مشخص‌شده استفاده کنید. خروجی خطا و جزئیات کافی از محیط را حفظ کنید تا بازبین دیگری بتواند آزمون را تکرار کند. سپس بررسی کنید که آیا مشکل نسخه‌های پشتیبانی‌شده و پیکربندی‌های واقع‌بینانه را تحت تأثیر قرار می‌دهد. هرگونه داده حساس را در چارچوب فرایند امنیتی تثبیت‌شده پروژه نگه دارید.
۴. وصله را مستقلاً بررسی کنید
علت اصلی، شاخه‌های تحت تأثیر، سازگاری، مدیریت خطا و پوشش آزمون‌های رگرسیون را بررسی کنید. اندازه‌گیری کنید چه مقدار از وصله پیشنهادی پس از بازبینی باقی می‌ماند. وصله‌ای که به بازنویسی نیاز دارد نیز ممکن است زمان بررسی اولیه را کاهش دهد، اما این مزیت را صادقانه ثبت کنید و آن را آماده ادغام معرفی نکنید.
۵. هزینه و نتیجه را هم‌زمان بسنجید
برای هر مجموعه گزارش، تعداد یافته‌های منحصربه‌فرد و مرتبط با محدوده پروژه، اصلاحات منتشرشده، گزارش‌های تکراری، گزارش‌های نامعتبر، موارد حل‌نشده و ساعات صرف‌شده برای بازبینی را ثبت کنید. تغییرات شدت و رگرسیون‌های کشف‌شده هنگام بررسی را نیز یادداشت کنید. سپس این نتایج را با وضعیت پایه‌ای که پیش از ثبت‌نام ثبت کرده‌اید، مقایسه کنید.
برای نمونه، اگر ۲۰ یافته قابل‌اقدام به ۴۰ ساعت کار بازبینان نیاز داشته باشند، پیش از محاسبه زمان اضافی انتشار، برای هر یافته دو ساعت صرف شده است. در مقابل، ۱۰ یافته قابل‌اقدام که ۸۰ ساعت زمان می‌برند، به هشت ساعت برای هر یافته نیاز دارند. این اعداد فرضی‌اند و نتایج اندازه‌گیری‌شده OSS Scanner نیستند. هدف آن‌ها نشان دادن این نکته است که اعتبار گزارش‌ها به‌تنهایی مشخص نمی‌کند یک سرویس تا چه اندازه برای تیم مناسب است.
۶. تصمیم بگیرید آیا پروژه توان ادامه استفاده از این مسیر را دارد
اگر گزارش‌ها نقص‌های مرتبطی را آشکار می‌کنند و هزینه بازبینی آن‌ها در توان پروژه است، استفاده را ادامه دهید. اگر اختلاف‌نظرها تکرار می‌شوند، مدل تهدید را دقیق‌تر کنید. اگر دریافت گزارش‌ها باعث می‌شود رسیدگی به مشکلات فوری و تأییدشده بیشتر به تأخیر بیفتد، سرویس را موقتاً متوقف کنید. ارزیابی موفق ممکن است در نهایت به این تصمیم منجر شود که تا زمان افزایش ظرفیت پروژه باید منتظر ماند.
ارزیابی ما
OSS Scanner شواهد اولیه قابل‌اعتنایی در پشتیبانی از کارایی خود دارد. اصلاح عمومی curl و گزارش wolfSSL بررسی جدی این سرویس را برای نگه‌دارندگانی که توان رسیدگی به خروجی آن را دارند، توجیه می‌کنند. نمونه منتخب اعتبارسنجی Anthropic نیز دلایلی برای خوش‌بینی درباره کیفیت یافته‌ها ارائه می‌دهد، اما میزان پوشش، تفاوت نتایج میان پروژه‌ها و هزینه‌های اصلاح در بلندمدت همچنان مشخص نیستند.
توصیه ما این است که زمانی ثبت‌نام کنید که پروژه ساختی قابل‌بازتولید، مدل تهدیدی مکتوب، فرایندی خصوصی برای دریافت گزارش‌ها و بازبینانی مشخص با وقت کافی داشته باشد. آزمون‌های امنیتی موجود را حفظ کنید و چرخه نخست را بر اساس تعداد مشکلات منحصربه‌فرد و مرتبطی که برطرف می‌شوند و ساعات کاری نگه‌دارندگان ارزیابی کنید.
برای تیم‌هایی که به کمک در اصلاح مشکلات نیاز دارند، برنامه جداگانه Claude for Open Source نیز شش ماه دسترسی به Claude Max 20x را برای مشارکت‌کنندگان واجد شرایط تبلیغ می‌کند. این برنامه معیارهای درخواست مخصوص خود را دارد و نباید فرض کرد که ثبت‌نام در اسکنر به‌طور خودکار به معنای پذیرش در آن است.
کار را با مطالعه پرسش‌های متداول رسمی آغاز کنید، توافق‌نامه سرویس را بخوانید و ساخت پروژه خود را با ابزارهای فعلی ثبت‌نام آزمایش کنید. پیش از ارسال درخواست ادغام، زمان نخستین جلسه بازبینی را در تقویم یکی از اعضای تیم ثبت کنید.