اگر امروز از هوش مصنوعی برای بازبینی کد استفاده می‌کنید، احتمالاً با کوهی از گزارش‌های «مثبت کاذب» دست‌وپنجه نرم می‌کنید که بیشتر وقت شما را تلف می‌کند تا امنیت را بالا ببرد. اما یک رویکرد منضبط در ۲ سپتامبر ۲۰۲۶ توانست ۴ حفره امنیتی واقعی در حوزه احراز هویت را در مخازن معروف متن‌باز شناسایی کند. در حالی که پرامپت‌های عمومی مدل‌های زبانی اغلب حجم زیادی از آسیب‌پذیری‌های «خیالی» یا فانتوم تولید می‌کنند، این متد از یک قرارداد سخت‌گیرانه برای جداسازی یافته‌های واقعی از نویزهای هوش مصنوعی استفاده می‌کند.
بسیاری از توسعه‌دهندگان با مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — مانند یک اسکنر جادویی رفتار می‌کنند و از آن می‌خواهند «کد من را بازبینی کن». نتیجه این کار معمولاً دریافت لیست‌های طولانی از موارد مشکوک به XSS، CORS، CSP یا فایل‌های SVG مشکوک است. طبق گزارش این پژوهش، این رویکرد معمولاً منجر به حجم بالای گزارشات اما دقت بسیار پایین می‌شود و در نهایت منجر به گزارش‌هایی می‌گردد که مدیران پروژه (Maintainers) آن‌ها را نادیده می‌گیرند. مشکل اصلی این است که مدل‌ها روی چارچوب OWASP آموزش دیده‌اند و برای اینکه «سکوت» نکنند و پاسخ خالی برنگردانند، تمایل دارند یافته‌های ساختگی ابداع کنند.
برای حل این مشکل، پژوهشگر سیستمی به نام «قرارداد» (Contract) را پیاده کرد که دقیقاً تعیین می‌کند مدل پیش از باز کردن هر مخزن، چه ادعاهایی می‌تواند بکند و چه ادعاهایی ممنوع است. این کار لزوماً مدل را هوشمندتر نمی‌کند، بلکه با تحمیل جهت و انضباط، رفتار آن را کنترل می‌کند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، کنترل رفتار مدل از طریق محدودیت‌های ساختاری، بسیار مؤثرتر از تلاش برای «هوشمندتر کردن» آن است. در واقع در دنیای امنیت، این همان چیزی است که یک بازبینی حرفه‌ای را از یک لیست ساده از حدس‌ها جدا می‌کند. این رویکرد در واقع بخشی از روند گسترده‌تر گذار مدل‌های زبانی به سوی اتوماسیون پیچیده است که در آن مدل‌ها از تولید متن ساده به سمت اجرای وظایف تخصصی حرکت می‌کنند.
کالبدشکافی یک قرارداد امنیتی
این چارچوب برای حذف توهم (Hallucination) — وقتی مدل با اطمینان چیزی می‌گوید که اصلاً وجود ندارد، شبیه دوستی که خاطره‌ای را اشتباه تعریف می‌کند — و حذف «نمایش‌های توخالی» (Theatre) بر سه ستون اصلی استوار است:
- استانداردهای خارجی: مدل باید هر یافته را به یک شناسه (ID) مشخص در OWASP ASVS 5.0 متصل کند. استفاده از عبارات کلی مثل «بهترین تجربیات» (Best Practices) صراحتاً ممنوع است.
- ناورداهای قابل ابطال: به‌جای درخواست «یافتن باگ»، کاربر یک قانون دقیق تعریف می‌کند. برای مثال، جمله «هر هندلر وب‌هوک ورودی باید پیش از تغییر وضعیت (Mutating State)، اصالت فرستنده را تأیید کند» یک ناوردا قابل شکار است؛ اما جمله «وب‌هوک‌ها باید احراز هویت شوند» صرفاً یک نظر است.
- قالب‌بندی سخت‌گیرانه: یافته‌ها، مشاهدات و فرضیات باید کاملاً مجزا باشند. اگر مدل نتواند یک فایل مشخص و شماره خط دقیق را ارائه دهد، آن مورد «یافته» محسوب نمی‌شود.
انضباط و محدودیت‌ها
برای جلوگیری از بداههپردازی مدل، مجموعه‌ای از قوانین سخت‌گیرانه پیش از دسترسی مدل به هرگونه فایلی اعمال می‌شود. بر اساس مستندات این روش، اگر مدل یک کد CWE ساختگی ابداع کند یا یافته‌ای بدون ارجاع به «فایل:خط» ارائه دهد، جلسه (Session) فوراً خاتمه می‌یابد.
علاوه بر این، قرارداد حکم می‌کند که مسائل «نیازمند زمان اجرا» (Needs-runtime) به عنوان کارت یا یافته ثبت نشوند. همچنین، فرآیند «یافتن» از «اصلاح» کاملاً جدا شده است. پژوهشگر اشاره می‌کند که مدل‌ها اغلب هیجان‌زده شده و سعی می‌کنند کد را (مثلاً در یک عبارت where در Prisma) بدون تست کردن بازنویسی کنند؛ قرارداد این کار را ممنوع می‌کند تا تضمین شود جلسه‌ای که شکاف را می‌یابد، همان جلسه‌ای نباشد که آن را اصلاح می‌کند. این تفکیک دقیق بین شناسایی و اصلاح، مشابه رویکردی است که در آن عامل‌های هوش مصنوعی هزینه‌های نگهداری تست‌های نرم‌افزاری را کاهش داده‌اند تا از تداخل در چرخه توسعه جلوگیری شود.
این سیستم توسط یک پایگاه دانش (Knowledge Base) خصوصی و مهارت‌های ابزاری (Harness Skills) پشتیبانی می‌شود که تعریف می‌کنند چه زمانی باید «شکار» (Hunt) انجام شود و چه زمانی «اسکن» (Scan). بدون این پایگاه دانش، مدل شروع به تخیل می‌کند و بدون این مهارت‌ها، مدل صرفاً بلوک کد را می‌خواند و از آن عبور می‌کند. این سطح از سخت‌گیری تنها در مدل‌های استدلالی (Reasoning Model) — مدلی که قبل از جواب، یک قدم درنگ می‌کند و فکر می‌کند، مثل شطرنج‌بازی که چند حرکت جلوتر را می‌بیند — نتیجه می‌دهد؛ در مدل‌های ضعیف‌تر، پرامپت خوب فقط باعث می‌شود خطاها مرتب‌تر سازماندهی شوند.
شکار در برابر اسکن
پژوهشگر تأکید می‌کند که مدل‌های زبانی جایگزین ابزارهای تحلیل ایستای (Static Analysis) مانند Semgrep، CodeQL یا Bandit نیستند. اسکنرهای ایستا قطعی، سریع و ارزان هستند و برای خط لوله‌های CI/CD ایده‌آل‌اند تا الگوهای شناخته‌شده مثل کوئری‌های متصل‌شده (Concatenated Queries)، فراخوانی‌های خطرناک یا نبود هدرها را پیدا کنند.
اما اسکنرها نسبت به «کنترل‌های مفقود» کور هستند؛ یعنی ویژگی‌های معنایی که در آن یک مسیر (Route) باید مالکیت منبع را چک کند اما این کار را نمی‌کند. این مورد به عنوان BOLA (احراز هویت شکسته در سطح شیء - OWASP API #1) شناخته می‌شود. چون الگوهای درست و غلط اغلب از یک فراخوانی findUnique مشابه استفاده می‌کنند، هیچ قانون نحوی (Syntactic Rule) پایداری برای اسکنر وجود ندارد تا آن را دنبال کند.
در یک تست روی ۱۷۴ مسیر، پژوهشگر از یک خط پایه Semgrep با هفت مجموعه قانون (شامل p/default ،p/typescript ،p/react ،p/nextjs ،p/owasp-top-ten ،p/javascript و p/secrets) استفاده کرد. در ۲۵ ثانیه، این ابزار ۲۳ مورد را یافت، اما ۱۷ مورد از آن‌ها صرفاً unsafe-formatstring در تمپلیت‌ها بود. این اسکنر صفر شکاف احراز هویت پیدا کرد.
در مقابل، «شکار» هدایت‌شده توسط هوش مصنوعی شناسایی کرد که ۱۷۳ مسیر از ۱۷۴ مسیر امن هستند و تنها یکی آسیب‌پذیر است. این دقت اجازه می‌دهد عدد دقیق (۱ از ۱۷۴) اعلام شود و یک «حس کلی» به یک بازبینی قابل تأیید تبدیل شود. این شکار با نوشتن ابتدا ناوردا، سپس شمارش مسیرها و طبقه‌بندی آن‌ها به دسته‌های enforced-explicitly (اجرای صریح)، inherited (به‌ارث‌برده)، gap (شکاف) یا out-of-scope (خارج از محدوده) آغاز می‌شود.
نتایج قابل تأیید و ارزش سکوت
اثربخشی این انضباط در ۸ هدف مختلف به اثبات رسید. در بسیاری از موارد، ارزشمندترین نتیجه «سکوت» مدل بود. برای مثال در یک اپلیکیشن Next.js، جست‌وجوی ساده و ابتدایی برای dangerouslySetInnerHTML هشت مورد بحرانی XSS را پیشنهاد داد، اما بازبینی منضبط نشان داد همه آن‌ها توسط DOMPurify مدیریت شده‌اند یا در SSR توسط React Escape شده‌اند.
تأثیرات تأییدشده واقعی عبارت بودند از:
- Formbricks: یک پیکربندی متناقض CORS (استفاده از Wildcard
*به همراه Credentials) که توسط مرورگرها رد می‌شود (Issue #9081). این مورد به عنوانsecurityوagent-readyعلامت‌گذاری شد. - Dub: یک آسیب‌پذیری حمله زمان‌بندی (Timing Attack) در مقایسه‌های HMAC با استفاده از
!==در مخزنی که در جاهای دیگر ازtimingSafeEqualاستفاده کرده بود (Issue #4415). این مورد با کدENG-1732وارد ردیاب Linear آن‌ها شد. - Plane: سه شکاف احراز هویت که از طریق کانال‌های خصوصی گزارش شد.
- Medusa و Documenso: بررسی کامل مخرج کسر برای هندلرهای پرداخت و فایل با نتیجه صفر آسیب‌پذیری، که منجر به سکوت مدل شد.
- Axios، Gin و Guzzle: حفظ کامل ناورداها (به ترتیب ۳/۳، ۴/۴ و ۱۱/۱۱) که منجر به سکوت مدل شد.
خط لوله افشای آسیب‌پذیری
یافتن باگ تنها نیمی از راه است. پژوهشگر از رویکرد «حداقل دسترسی» برای افشا استفاده می‌کند تا اثر متنی (Blast Radius) را به حداقل برساند. این یک فرآیند انسان-در-حلقه (HITL) است که در آن انسان تصمیم می‌گیرد خبر از کدام در خارج شود، نه مدل.
- Issues عمومی: فقط برای موارد سخت‌سازی (Hardening) رزرو شده‌اند.
- کانال‌های خصوصی: دور زدن‌ها (Bypasses)، تزریق‌ها، افشای اسرار (Secrets) یا احراز هویت‌های شکسته ابتدا به‌صورت خصوصی ارسال می‌شوند. اگر فایل
SECURITY.mdوجود نداشته باشد، پژوهشگر به‌جای ایجاد ترد‌های عمومی، از طریق ایمیل با مدیر پروژه تماس می‌گیرد.
این فرآیند تضمین می‌کند که ردپای بازبینی در سیستم ردیابی یا ایمیل بماند، نه در متن گفتگو با هوش مصنوعی. پژوهشگر هشدار می‌دهد که کپی کردن گزارش خام هوش مصنوعی در یک Tracker، نشانه «درِ باز» یا همان عدم انضباط حرفه‌ای است که باعث ایجاد نویز برای مدیران پروژه می‌شود.
گام بعدی شما
برای کسانی که می‌خواهند این روش را از فردا اجرا کنند، توصیه ساده است: یک مخزن که مدیریت می‌کنید را انتخاب کنید و یک ناوردا قابل ابطال بنویسید (مثلاً: «هر وب‌هوک ورودی باید پیش از تغییر وضعیت، امضا را تأیید کند»). ابتدا اسکنر ایستای خود را اجرا کنید، سپس از مدل بخواهید فقط همان ناوردا را تست کند. مدل را مجبور کنید مخرج کسر (تعداد کل مسیرها) و ارجاع دقیق به فایل و خط را ارائه دهد، بدون اینکه در همان جلسه راه حل یا PoC بخواهید. اگر مدل «۲۳ یافته» را بدون مخرج کسر یا ارجاع دقیق برگرداند، شما یک «لیست» دارید، نه یک «بازبینی».
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو