تصور کنید ابزاری دارید که هر ثانیه صدها درِ باز در قلعه‌ی شما را پیدا می‌کند، اما شما تنها یک کلیدساز دارید که هفته‌ای یک در را می‌بندد. این دقیقاً وضعیتی است که اکنون در اکوسیستم نرم‌افزارهای متن‌باز رخ داده است.
طبق اعلام آنتروپیک (Anthropic) در داشبورد تیم قرمز (Red Team) خود، از میان ۶,۱۵۷ آسیب‌پذیری افشا شده، تنها ۵۱۶ مورد در منبع اصلی اصلاح شده‌اند. این نرخ ترمیم ۸.۴ درصدی، یک نقطه اصطکاک بحرانی را برملا می‌کند: هوش مصنوعی سریع‌تر از آن است که انسان‌ها بتوانند باگ‌ها را رفع کنند.
این داده‌ها در حالی منتشر می‌شود که آزمایشگاه‌های AI به‌طور گسترده از مدل‌های خود برای بازرسی اکوسیستم متن‌باز استفاده می‌کنند. در حالی که ما پیش‌تر به نحوه مدیریت حریم خصوصی کاربران و گزارش‌های پلیس توسط آنتروپیک پرداخته بودیم، این دفتر ثبت، تمرکز را به ریسک سیستمیک «کشف خودکار آسیب‌پذیری‌ها» تغییر می‌دهد. برای یک مدیر کسب‌وکار، این یک هشدار جدی است؛ بازرسی‌های امنیتی مبتنی بر AI می‌توانند «صف انتظار ترمیمی» ایجاد کنند که سریع‌تر از توان تخلیه یک تیم فنی رشد می‌کند.
قیف کشف آسیب‌پذیری
به نقل از مستندات این برنامه، بین ۱ نوامبر ۲۰۲۵ تا ۲ اکتبر ۲۰۲۶، تعداد خیره‌کننده ۲۹,۴۳۹ یافته ثبت شده است. برای تضمین کیفیت، این فرآیند از یک خط لوله پالایش سخت عبور می‌کند:
- ۶,۱۲۳ مورد کاندید به مرحله پالایش انسانی ارجاع شدند.
- شرکت‌های امنیتی خارجی ۵,۶۷۴ مورد از این کاندیداها را بررسی کردند.
- این شرکت‌ها ۹۲.۷٪ از ۶,۱۲۳ مورد را به‌عنوان «مثبت واقعی» تأیید کردند.
- ۴,۸۲۴ مورد مستقیماً و بنا به درخواست توسعه‌دهندگان، بدون بررسی مستقل گزارش شدند.
زمینه و محدوده عملیاتی
این برنامه به‌طور صریح درباره مرزهای عملیاتی خود توضیح داده است. فعالیت‌ها از فوریه ۲۰۲۶ آغاز شد و در آن از یک نسخه پیش‌نمایش اولیه از Claude Mythos استفاده شد. برای حفظ یکپارچگی و اعتبار، آنتروپیک شش شرکت تحقیقاتی امنیتی خارجی را به خدمت گرفته است تا پیش از گزارش نهایی، یافته‌ها را بازتولید و ارزیابی کنند.
هوش مصنوعی زاینده (Generative AI) — شبیه به یک بازرس خستگی‌ناپذیر که هر خط کد را با سرعت نور می‌خواند — در اینجا نقش شکارچی را دارد. آنتروپیک به‌طور غیرمعمولی درباره محدودیت‌های آماری خود صادق است. این شرکت هشدار می‌دهد که نرخ «مثبت واقعی» معیار ضعیفی است؛ زیرا شامل باگ‌های واقعی می‌شود که قبلاً در جای دیگری گزارش شده بودند یا باگ‌های واقعی که توسعه‌دهنده صرفاً تصمیم گرفته آن‌ها را اصلاح نکند. علاوه بر این، ممکن است فروشندگان یافته‌ها را در هر دو جهت (بیشتر یا کمتر از حد واقعی) دسته‌بندی کنند.
به دلیل همین موارد، آنتروپیک بیان می‌کند که تعداد پچ‌های (Patch) ایجاد شده «معیار قابل‌اعتمادتری» است، هرچند می‌پذیرد که ساخت این اصلاحات زمان‌بر است. داشبورد این برنامه همچنین اعتراف می‌کند که برخی از یافته‌های تأیید شده به دلیل محدودیت‌های ظرفیت داخلی در خودِ برنامه، هنوز گزارش نشده‌اند.
شناسایی و افشا
آنتروپیک از یک پنجره افشای شفاف اما محتاطانه استفاده می‌کند. این برنامه جزئیات فنی کامل را تنها پس از بسته شدن پنجره افشا منتشر می‌کند. تا آن زمان، یافته‌ها فقط به‌صورت هش‌های تعهدی (Commit Hashes) ثبت می‌شوند. این روش تضمین می‌کند که وجود باگ و تاریخ کشف آن قابل اثبات باشد، در حالی که محتوای فنی آن مخفی می‌ماند.
تا ۲ اکتبر ۲۰۲۶، این دفتر ثبت ۶,۱۵۷ آسیب‌پذیری در ۵۹۱ پروژه متن‌باز را نشان می‌دهد. این موارد از طریق ۵۸۴ رکورد شناسایی ردیابی می‌شوند که به ۲۱۹ کد CVE و ۳۶۵ هشدار امنیتی گیت‌هاب (GitHub Security Advisories) تقسیم شده‌اند. با این حال، شرکت اشاره می‌کند که یک یافته واحد می‌تواند هر دو شناسه را داشته باشد و برخی توسعه‌دهندگان بدون انتشار هشدار رسمی، اصلاحات را اعمال می‌کنند.
گلوگاه ترمیم
شکاف میان پذیرش گزارش و اقدام عملی تکان‌دهنده است. در حالی که ۵,۱۰۳ گزارش توسط توسعه‌دهندگان پذیرفته شد، تنها ۵۱۶ مورد به پچ منجر شد. این تفاوت لزوماً به دلیل اهمال نیست؛ اکثر نگهدارندگان پروژه‌های متن‌باز داوطلب یا تیم‌های کوچک هستند. یک گزارش پالایش‌شده باید ابتدا درک شود، بازتولید شود، اصلاح شود، تست شود و در نهایت منتشر شود.
برای مدیریت این فشار، سیاست‌های آنتروپیک شامل چندین حفاظ است:
- گزارش‌های استاندارد: مهلت ۹۰ روزه برای افشا، با امکان تمدید ۱۴ روزه در صورتی که توسعه‌دهنده درگیر باشد و پیشرفتی نشان دهد.
- آسیب‌پذیری‌های بحرانی: باگ‌هایی که فعالانه مورد بهره‌برداری قرار گرفته‌اند، هدف ۷ روزه برای اصلاح یا کاهش اثر دارند که در صورت درخواست، ۷ روز دیگر قابل تمدید است.
- پنجره پس از پچ: یک دوره انتظار ۴۵ روزه پس از انتشار پچ تا انتشار جزئیات فنی، تا کاربران پایین‌دستی فرصت استقرار اصلاحیه را داشته باشند.
- تنظیم سرعت ارسال: تعهد به تنظیم سرعت ارسال گزارش‌ها بر اساس توان جذب واقعی توسعه‌دهندگان، تا از ارسال حجم بالای یافته‌ها برای یک پروژه بدون توافق پایدار جلوگیری شود.
حاکمیت و ارجاع
در فرآیند افشا، قدرت توزیع شده است. وقتی آنتروپیک و توسعه‌دهنده بر سر شدت یک باگ اختلاف نظر دارند، فروشنده عموماً ارزیابی توسعه‌دهنده را می‌پذیرد، مگر اینکه بهره‌برداری فعال از باگ در جریان باشد.
همچنین مسیر سخت‌گیرانه‌ای برای پروژه‌های غیرپاسخگو وجود دارد. اگر پس از ۳۰ روز سکوتی برقرار باشد، مورد به یک هماهنگ‌کننده خارجی ارجاع شده و سپس طبق زمان‌بندی افشا می‌شود. بنابراین سرعت برنامه توسط سه مرحله متمایز تعیین می‌شود: کشف باگ توسط مدل، پالایش توسط شرکت‌های خارجی و ترمیم توسط انسان.
واقعیت عملیاتی
وقتی یک تیم کوچک با چرخه بازرسی AI مواجه می‌شود، مسئله تبدیل به یک چالش استخدامی می‌شود. فرض کنید شرکتی با ۲۵ نفر، بازرسی AI را روی مخزن کد خود فعال کند و در ماه اول ۴۰ یافته دریافت کند (۱۲ مورد سطح بالا، بقیه متوسط و پایین).
حتی اگر هیچ‌کس با یافته‌ها مخالف نباشد، با نرخ یک اصلاح در هر دو روز، ۱۱ هفته زمان می‌برد تا صف خالی شود. این در صورتی است که دو مهندس متخصص که قادر به رفع باگ‌ها هستند، همزمان روی نقشه راه محصول اصلی شرکت کار نکنند.
در این سناریو، حالت شکست، یک باگ بحرانی گم‌شده نیست؛ بلکه صفی است که سریع‌تر از تخلیه، پر می‌شود و اولویت‌ها به‌جای ریسک واقعی، بر اساس صدای بلندترین منتقد تعیین می‌شود.
سنجش توان عملیاتی
برای مدیریت این وضعیت، گزارش پیشنهاد می‌کند دو معیار اصلی ردیابی شوند:
- تعداد موارد بسته شده در هفته: نشان می‌دهد صف در حال رشد است یا کاهش.
- عمر قدیمی‌ترین مورد باز: فاش می‌کند که انباشتگی مدیریت می‌شود یا صرفاً در حال جابه‌جایی است.
معیار سوم و منضبط‌تر، سهم مواردی است که به‌عنوان «ریسک پذیرفته‌شده» بسته می‌شوند؛ جایی که اکثر تیم‌ها تفاوت میان پالایش و ترمیم واقعی را پنهان می‌کنند.
این دفتر ثبت، نمونه‌ای نادر از شفافیت است که هر دو سر خط لوله را نشان می‌دهد. با نمایش نرخ کشف (۲۹,۴۳۹ مورد) در برابر نرخ ترمیم (۵۱۶ مورد)، آنتروپیک به صنعت اجازه می‌دهد فاصله واقعی میان «پیدا کردن سوراخ» و «پر کردن آن» را اندازه بگیرد.
اگر امروز یک کدبیس را مدیریت می‌کنید، گام بعدی حسابرسی توان عملیاتی پچ‌های خودتان است. نرخ کشف هفتگی را با نرخ بستن موارد مقایسه کنید تا ببینید آیا بدهی امنیتی شما در حال انباشت است یا خیر.
گام بعدی شما
- توان عملیاتی پچ‌های خود را حساب کنید: نرخ کشف هفتگی را با نرخ بستن موارد مقایسه کنید تا ببینید بدهی امنیتی شما در حال انباشت است یا خیر.
- برای پروژه‌های حساس، به‌جای تکیه بر ابزارهای خودکار، یک فرآیند تایید انسانی (Human-in-the-loop) برای اولویت‌بندی ریسک‌ها تعریف کنید.
- اگر از ابزارهای AI برای بازرسی کد استفاده می‌کنید، سقف ارسال گزارش‌ها را متناسب با ظرفیت تیم فنی تنظیم کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو