اتحاد امنیتی هوش مصنوعی گزارش اجباری حوادث را برای اعضا الزامی کرد

عصر سکوت در برابر شکست‌های امنیتی هوش مصنوعی باید به پایان برسد. اگر یک مدیر ارشد فناوری هستید و امنیت سیستم‌های خود را به «اعتماد» سپرده‌اید، قوانین جدید بنیاد لینوکس دیدگاه شما را تغییر خواهد داد.

به نقل از مستندات بنیاد لینوکس، در ۴ اوت ۲۰۲۶، درخواست نظرات (RFC) برای ایجاد «تبادل یافته‌های مشترک هوش مصنوعی» یا SAFE منتشر شد. هدف محوری این اقدام پایان دادن به پنهان‌کاری در مورد نقص‌های امنیتی است. این چارچوب اعضای «اتحاد باز امنیتی هوش مصنوعی» را موظف می‌کند تا حوادث امنیتی را طبق یک جدول زمانی سخت‌گیرانه و عمومی گزارش کنند. این پیشنهاد که توسط متخصصان و مشارکت‌کنندگان شرکت‌های Cisco، CrowdStrike، Hugging Face، NVIDIA و Red Hat تدوین شده، دقیقاً هم‌زمان با آغاز کنفرانس Black Hat در لاس‌وگاس ارائه شد تا توجه حداکثری جامعه امنیتی را جلب کند.

این ابتکار در حالی می‌آید که صنعت با ماهیت «جعبه سیاه» امنیت هوش مصنوعی دست‌وپنجه نرم می‌کند. سال‌هاست شرکت‌ها نشت داده‌ها و رخ‌نفوذها را به عنوان یک بدهی خصوصی و شرم‌آور می‌بینند و آن‌ها را پنهان می‌کنند. اما چارچوب SAFE با این حوادث مانند فرصت‌های یادگیری جمعی برخورد می‌کند؛ این رویکرد دقیقاً شبیه به صنعت هوانوردی است که در آن هر سقوط هواپیما کالبدشکافی می‌شود تا ایمنی کل پروازها در جهان بالا برود و خطاهای تکراری حذف شوند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، شفافیت تنها راه خروج از بن‌بست توهمات امنیتی است. طبق اعلام Nvidia، این اتحاد که در ۲۷ ژوئیه ۲۰۲۶ تأسیس شد، از همان ابتدا شامل ائتلافی از حدود سه دوجین شرکت و بنیادهای متن‌باز بود و اکنون بیش از ۱۲۰ سازمان از جمله Amazon و Visa را در بر می‌گیرد.

ساعت شمارش معکوس گزارش‌دهی

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

• فوری: اطلاع‌رسانی به سازمان مستقیماً آسیب‌دیده در سریع‌ترین زمان ممکن.
• ۷۲ ساعت: هشدار به مشتریانی که با شواهد معتبر در معرض خطر قرار گرفته‌اند.
• ۴ روز کاری: ارسال اولین گزارش محرمانه و اولیه در قالب SAFE.
• ۱۴ روز: صدور یک توصیه جامع‌تر برای مشتریان، در صورتی که توجیه فنی داشته باشد.
• ۳۰ روز: انتشار یک گزارش واقعی اولیه و تحلیل مقدماتی از شکستِ حفاظ‌ها (Control-Failure Analysis).
• ۹۰ روز: انتشار وضعیت نهایی رفع نقص و اقدامات اصلاحی.
• هفتگی: ارائه به‌روزرسانی‌های ماشین‌خوان (Machine-readable) تا زمانی که ریسک‌های Material همچنان حل‌نشده باقی مانده‌اند.

چه اتفاقی باعث گزارش می‌شود؟

گزارش‌دهی در SAFE بر اساس «قصد» یا نیت کاربر نیست، بلکه بر اساس «نتیجه» و خروجی است. یک عضو باید حادثه را گزارش کند اگر سیستم هوش مصنوعی او:
۱. بدون مجوز به یک سیستم شخص ثالث دسترسی پیدا کند.
۲. از یک سندباکس (Sandbox)، شبکه، هویت، سیاست یا مرز ابزاری به گونه‌ای عبور کند که بر شخص ثالث تأثیر بگذارد.
۳. به اطلاعات محرمانه شخص ثالث دسترسی پیدا کند.

علاوه بر این، اگر سیستمی به بررسی و probing یک هدف در محیط عملیاتی (Production) ادامه دهد، در حالی که اپراتور مشکوک شده که این فعالیت خارج از محدوده (Out of scope) است، گزارش الزامی است. حتی اگر اپراتور به اشتباه تصور کرده باشد که در یک محیط شبیه‌سازی شده کار می‌کند، وظیفه گزارش‌دهی همچنان بر عهده اوست. اعضا همچنین باید «حوادث نزدیک به شکست» (Near Misses) را گزارش دهند؛ یعنی مواردی که هرچند آسیبی رخ نداده، اما پتانسیل تبدیل شدن به یک فاجعه امنیتی را داشته‌اند.

هر حادثه پس از گزارش، تحت یک بررسی دقیق در ۸ لایه از پشته عملیاتی قرار می‌گیرد. این لایه‌ها عبارتند از:

• مدل و دستورات (Prompts) آن
• حفاظ‌ها (Safeguards)
• ابزارها (Tools)
• محیط (Environment)
• نظارت (Monitoring)
• عملیات انسانی (Human operations)
• زنجیره تأمین (Supply chain)

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

کاتالیزور: نشت داده در Hugging Face

عجله برای ایجاد این چارچوب از یک شکست واقعی و تکان‌دهنده در ۱۶ ژوئیه ۲۰۲۶ نشأت می‌گیرد. شرکت Hugging Face افشا کرد که یک چارچوب عامل‌محور (Autonomous Agent Framework) توانسته بود به طور کامل و از ابتدا تا انتها (End-to-End) به زیرساخت‌های عملیاتی این شرکت نفوذ کند. در طول پاک‌سازی فارنزیک، تیم امنیتی تلاش کرد بیش از ۱۷ هزار اقدام ثبت‌شده‌ی مهاجم را تحلیل کند.

آن‌ها با یک مانع غیرمنتظره روبرو شدند: مدل‌های تجاری از طریق API، تحلیل آن‌ها را مسدود کردند؛ زیرا حفاظ‌های (Guardrails) این مدل‌ها نمی‌توانستند تفاوت بین یک پاسخ‌دهنده امنیتی (Security Responder) و یک مهاجم واقعی را تشخیص دهند. در واقع، ابزارهای حفاظتی مدل‌های تجاری جلوی تحلیلِ خودِ حمله را گرفتند. تیم تنها با استفاده از مدل GLM-5.2 با وزن‌های باز (Open Weights) — یعنی مدلی که روی زیرساخت شخصی خودشان اجرا می‌شد و محدودیت‌های API نداشت — توانست تحقیقات فارنزیک را کامل کند. این تجربه تلخ باعث شد تنها ۸ روز بعد، در ۲۷ ژوئیه، این ائتلاف شکل بگیرد تا دیگر هیچ شرکتی در برابر ابزارهای محدودکننده APIهای تجاری در زمان بحران فلج نشود.

تحلیل: اعتماد به مثابه یک معیار فنی

برای رهبران کسب‌وکار، این رویکرد ارزش «اعتماد» را از یک شعار بازاریابی به یک معیار فنی قابل اندازه‌گیری تبدیل می‌کند. در متن پیش‌نویس صراحتاً و با صراحت آمده است: «اعتماد یک کنترل امنیتی نیست. شواهد مشترک و بهبودهای قابل راستی‌آزمایی، تنها راه به‌دست آوردن اعتماد هستند». با الزام گزارش‌دهی به عنوان شرط عضویت، این اتحاد پذیرفته است که سکوت شرکت‌ها در مورد شکست‌ها، یک ریسک سیستماتیک برای کل صنعت است. اگر حادثه Hugging Face تحت قوانین SAFE رخ داده بود، شکست‌های فارنزیک APIهای تجاری ظرف ۳۰ روز علنی می‌شد و این فشار عمومی احتمالاً ارائه‌دهندگان API را مجبور می‌کرد حفاظ‌های خود را سریع‌تر و هوشمندتر اصلاح کنند.

با این حال، باید توجه داشت که این سیستم فعلاً یک پیمان داوطلبانه یا یک Compact است. این یک قانون الزام‌آور دولتی نیست و جایگزین وظایف قانونی موجود در برابر رگولاتورها، نیروهای انتظامی، یا تعهدات قراردادی و رویه‌های افشای هماهنگ آسیب‌پذیری‌ها (CVD) نمی‌شود. پیش‌نویس تأکید می‌کند که نهادهای دولتی و badanهای استاندارد تنها به عنوان ناظر غیرکنترلی (Non-controlling observers) حضور دارند تا هیچ فروشنده یا بخش خاصی از صنعت نتواند یافته‌ها را کنترل یا سانسور کند. همچنین، رفتارهای عمدی یا جنایی صراحتاً از حمایت‌های کانال محرمانه این اتحاد مستثنی شده‌اند.

این RFC اکنون برای مشارکت جامعه در مخزن مربوطه تحت مجوز Creative Commons Attribution 4.0 باز است. بنیاد لینوکس این سند را به عنوان یک «بحث باز» توصیف می‌کند، نه یک مشخصات فنی نهایی شده. توسعه‌دهندگان و پژوهشگران تشویق شده‌اند تا قبل از نهایی شدن چارچوب، در شکل دادن به این وظایف و ضرب‌الاجل‌های پیشنهادی نقش داشته باشند.

گام بعدی شما

• اگر از مدل‌های تجاری برای تحلیل امنیتی استفاده می‌کنید، محدودیت‌های حفاظ‌های آن‌ها را با تست‌های نفوذ شبیه‌سازی شده بسنجید تا در زمان بحران غافلگیر نشوید.
• مخزن RFC بنیاد لینوکس را دنبال کنید تا متوجه شوید استانداردهای گزارش‌دهی در صنعت چگونه تغییر می‌کنند و چگونه می‌توانید در آن مشارکت کنید.
• مدل‌های با وزن‌های باز را به عنوان جایگزین برای تحلیل‌های حساس امنیتی در زیرساخت شخصی خود تست کنید تا کنترل کاملی بر داده‌ها و تحلیل‌ها داشته باشید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.