اگر امروز برای بازرسی امنیتی کدهای خود به نظارت دستی متخصصان تکیه می‌کنید، باید بدانید که دوران «حدس‌زدن‌های چت‌محور» به پایان رسیده است. کلاودفلر (Cloudflare) با معرفی یک خط لوله خودکار شش‌مرحله‌ای، بازرسی‌های امنیتی در سطح حرفه‌ای را به عامل‌های هوش مصنوعی (AI Agents) سپرد.
این سیستم که به عنوان یک «مهارت» (Skill) عرضه شده، مجموعه‌ای از عامل‌های ایزوله را برای نقشه‌برداری از معماری، شکار باگ‌ها و تأیید مستقل یافته‌ها سازماندهی می‌کند. طبق اعلام کلاودفلر، آنچه ابتدا به عنوان یک نقطه شروع برای تک‌مخازن کد بود، اکنون به ابزاری برای کشف آسیب‌پذیری در مقیاس کل ناوگان تبدیل شده است. این رویکرد یادآور پیشرفت‌های مشابه در حوزه‌ی بلاک‌چین است که در آن ترکیب تحلیل ایستا و مدل‌های زبانی توانست بازرسی قراردادهای هوشمند را خودکار کند.
بسیاری از ابزارهای امنیتی مبتنی بر هوش مصنوعی از توهم (Hallucination) — شبیه دوستی که خاطره‌ای را اشتباه تعریف می‌کند — یا نبود پوشش سیستماتیک رنج می‌برند. برای حل این مشکل، کلاودفلر بازرسی امنیتی را نه به عنوان یک پرامپت ساده، بلکه به شکل یک فرآیند مهندسی ساختاریافته طراحی کرد. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، رویکرد سیستماتیک تنها راه رهایی از خطاهای تصادفی مدل‌هاست. این متدولوژی دقیقاً مشابه عملکرد متخصصان تست نفوذ انسانی است که از شناسایی کلی شروع کرده و به اعتبارسنجی جراحی‌گونه می‌رسند.
گردش کار و مراحل عملیاتی
security-audit-skill از یک توالی سخت‌گیرانه در شش مرحله عمل می‌کند:
- شناسایی (Reconnaissance): نقشه‌برداری از معماری، مرزهای اعتماد، سطوح ورودی و شواهد قبلی. این مرحله پوشش قطعی را در فایل‌های
architecture.mdوcoverage-ledger.jsonثبت می‌کند. - شکار مبتنی بر پوشش: تخصیص شکارچی‌های ایزوله از واحدهای دفتر کل (ledger units) برای ثبت بررسی‌ها. در اینجا از «منتقدان پوشش» برای شناسایی شکاف‌های باقی‌مانده استفاده می‌شود.
- اعتبارسنجی کاندیداها: هر کاندیدای منحصربه‌فرد به یک تأییدکننده تازه داده می‌شود که هدفش صرفاً تلاش برای رد کردن و ابطال آن یافته است.
- خروجی ساختاریافته: سوابق تأییدشده (Confirmed)، نیازمند اعتبارسنجی (needs_validation) و ردشده (rejected) در فایل
findings.jsonثبت و باreport-schema.jsonتطبیق داده می‌شوند. برای تضمین شفافیت این سوابق، استانداردهای جدیدی مانند پیش‌نویس IETF برای ثبت وقایع غیرقابل‌دستکاری در عامل‌های هوش مصنوعی در حال توسعه است تا اعتماد به خروجی‌های خودکار افزایش یابد. - تأیید مستقل: عامل‌های جدید ادعاهای نهایی منبع را بررسی می‌کنند. هر جایگزینی material، دوباره توسط یک تأییدکننده مستقل بررسی می‌شود.
- گزارش‌دهی خنثی: تولید گزارش‌های نهایی مانند
REPORT.md،FINDINGS-DETAIL.mdوNEEDS-VALIDATION.mdبر اساس سوابق تأییدشده و دفتر کل پوشش.
جزئیات فنی و استانداردهای اجرا
برای حفظ یکپارچگی، فرآیند اصلی اسکریپت validate-coverage-ledger.cjs را بلافاصله پس از ایجاد دفتر کل اولیه و پس از هر به‌روزرسانی بعدی اجرا می‌کند. همچنین اسکریپت validate-findings.cjs در طول مرحله چهارم و پس از هر جایگزینی در مرحله پنجم اجرا می‌شود.
- تعاریف حکم (Verdict Definitions):
- تأییدشده (Confirmed): نیازمند یک ردپای کامل از منبع کد و یک نتیجه مشاهده‌شده محدود است.
- نیازمند اعتبارسنجی (Needs_validation): حاوی یک حقیقت دقیق حل‌نشده است اما هیچ شدت (Severity) تخصیص داده نشده است.
- ردشده (Rejected): سوابق کاندیدایی که با موفقیت ابطال شده است را ثبت می‌کند.
- کلاس‌های حمله: این مهارت از کلاس‌های تخصصی شکار استفاده می‌کند؛ از جمله
MEMORY-SAFETY-AND-BINARY.mdبرای اهداف نیتیو،AI-AND-LLM.mdبرای تزریق پرامپت و مدیریت ابزارها،WEB-PROTOCOL-AND-AUTH.mdبرای مسائل HTTP و کش، وSUPPLY-CHAIN-AND-RELEASE.mdبرای آسیب‌پذیری‌های CI و امضا. کلاس‌های دیگر مواردی چون Cloud/IAM، RPC/Messaging، اتمام منابع (Resource Exhaustion) و ایزولاسیون داده‌ها را پوشش می‌دهند. - منطق افزایشی: اجراهای مکرر روی یک مخزن، تجمعی هستند. سیستم از سوابق قبلی برای هدف قرار دادن شکاف‌ها و اعتبارسنجی مجدد منابع تغییریافته استفاده می‌کند، بدون اینکه کارهای قدیمی و منسوخ را به عنوان موارد پوشش‌داده‌شده تلقی کند.
به نقل از مستندات کلاودفلر، برای تضمین دقت از «اعتبارسنجی خصمانه» استفاده شده است؛ یعنی عاملی که یافته را تأیید می‌کند، هرگز همان عاملی نیست که آن را کشف کرده است. همچنین، شدت آسیب‌پذیری بر اساس اثر واقعی (احتمال × تأثیر) سنجیده می‌شود، نه صرفاً انحراف از یک چک‌لیست. شکاف‌های مربوط به «دفاع در عمق» (Defense-in-depth) نیز اگر یک لایه اصلی مانع حمله شود، به عنوان یادداشت‌های سخت‌کنندگی (Hardening notes) تلقی می‌شوند و نه به عنوان آسیب‌پذیری.
الزامات فنی شامل مدلی است که از استفاده از ابزار (Tool Use) و عامل‌های موازی پشتیبانی کند. همچنین استفاده از Node.js برای اسکریپت‌های اعتبارسنجی و یک سندباکس (Sandbox) اجباری در سطح سیستم‌عامل الزامی است. این سندباکس باید شبکه خارجی را غیرفعال کند، از یک محیط پاک‌سازی‌شده و مجاز (Allowlisted) استفاده کند و محدودیت‌های منابع را اعمال نماید. بدون این کنترل‌ها، گردش کار وضعیت یافته را به جای اجرای کد هدف، در حالت needs_validation نگه می‌دارد.
این تغییر، امنیت هوش مصنوعی را از «حدس‌های چت‌محور» به «بازرسی مبتنی بر شواهد» منتقل می‌کند. کلاودفلر اشاره کرده است که در تست‌ها، یک بار اجرای کامل توانسته تقریباً نیمی از آسیب‌پذیری‌هایی را که در مجموع اجراهای مکرر یافت شد، شناسایی کند. با الزام به ارائه یک ردپای مستند از منبع برای هر آسیب‌پذیری تأییدشده، کلاودفلر نویزهای معمول اسکن‌های امنیتی LLM را کاهش داده است.
برای توسعه‌دهندگان، این یعنی بازرسی‌های امنیتی را می‌توان به عنوان یک گام ماشین‌خوان در خط لوله CI/CD ادغام کرد. خروجی به جای یک PDF مبهم، یک دفتر کل ساختاریافته است که در طول زمان قابل ردیابی است.
کاربران می‌توانند این مهارت را از طریق CLI با دستور npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit نصب کنند. این مهارت با درخواست‌هایی مثل «این کد را بازرسی امنیتی کن» یا «آسیب‌پذیری‌های امنیتی را پیدا کن» فعال می‌شود. یک درخواست مستقیم برای بازرسی، «حالت بازرسی کامل» (Full Audit Mode) را فعال می‌کند، در حالی که سوالات متمرکز از «حالت راهنما» (Guidance Mode) استفاده می‌کنند.
گام بعدی شما
- اگر از مخازن کد بزرگ استفاده می‌کنید، این مهارت را در محیط سندباکس نصب کنید تا شکاف‌های امنیتی را شناسایی کنید.
- ساختار
coverage-ledger.jsonرا بررسی کنید تا متوجه شوید هوش مصنوعی چگونه فضای حمله را نقشه‌برداری می‌کند. - خروجی‌های
needs_validationرا به عنوان تمرینی برای تیم قرمز خود به کار بگیرید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو