تصور کنید یک مهندس امنیت است که باید بفهمد آیا یک آسیب‌پذیری خاص در میان هزاران وابستگی پروژه واقعاً خطرناک است یا خیر. در دنیای واقعی، تکیه بر حدس و گمان مدل‌های زبانی برای بررسی CVEها می‌تواند منجر به ساعت‌ها اتلاف وقت یا بدتر از آن، نادیده گرفتن یک تهدید واقعی شود. مدل‌های زبانی بزرگ (LLM) اغلب برای ارزیابی ریسک‌های امنیتی به شهود تکیه می‌کنند، اما «دستیار مشاور امنیتی هوش مصنوعی» با اولویت دادن به شواهد در پژوهش‌های آسیب‌پذیری npm، این حدس و گمان‌ها را حذف می‌کند. این ابزار که به عنوان بخشی از چالش Sanity (مسیر اول: عرضه عاملی که محتوای واقعی را استعلام می‌کند) عرضه شده است، نحوه تایید توسعه‌دهندگان در مورد اینکه آیا یک CVE خاص واقعاً بر استقرار آن‌ها تأثیر می‌گذارد یا خیر را متحول می‌کند.
ممیزی‌های امنیتی اغلب از «توهمات» در بازه‌های نسخه‌ها یا دستورالعمل‌های اصلاحی مبهم رنج می‌برند. اکثر ابزارهای هوش مصنوعی صرفاً یک آسیب‌پذیری را خلاصه می‌کنند، اما این عامل (Agent) نیازمند یک مسیر مستند از منبع تا پاسخ است. این سیستم با مدل زبانی نه به عنوان یک «غیب‌گو»، بلکه به عنوان یک «ناوبری» برخورد می‌کند و تضمین می‌کند که هر ادعایی توسط یک رکورد استناد شده پشتیبانی شود.
زمینه سیستم
دستیار مشاور امنیتی هوش مصنوعی یک ابزار جست‌وجوی مشورتی است. این ابزار یک اسکن از کد اپلیکیشن نیست و تضمین نمی‌کند که یک استقرار لزوماً امن است. این سیستم به‌طور خاص برای پژوهش درباره آسیب‌پذیری‌های شناخته‌شده در بسته‌های npm طراحی شده است.
طبق جزئیات پروژه، این سیستم برای تضمین دقت، چندین منبع داده با وفاداری بالا (High-fidelity) را ادغام می‌کند. این عامل برای دریافت هشدارهای زنده npm به OSV.dev متصل می‌شود و هم‌زمان از یک پایگاه دانش Sanity شامل ۱۲۲ سند مشورتی منتشر شده استفاده می‌کند. برای پردازش این داده‌ها، مدل DeepSeek V4.1 Flash از طریق Token Harbor به کار گرفته شده است. این مدل به سیستم کمک می‌کند تا بدون نیاز به خواندن تک‌تک اسناد، مسیرهای دانش مرتبط را انتخاب کند.
گردش کار تایید
کاربران می‌توانند یک جلسه پژوهشی را با وارد کردن نام بسته و نسخه آن آغاز کنند. برای مثال، استعلام نسخه ۱۴.۲.۲۴ بسته Next.js در رابطه با CVE-2025-29927، یک فرآیند تایید چندمرحله‌ای را فعال می‌کند:
- مرور پژوهش: اپلیکیشن بازه‌های نسخه‌های آسیب‌پذیر، اصلاحات مستند و شرایط خاص استقرار که نیاز به بررسی دارند را بازمی‌گرداند.
- بررسی پوشش: یک تب اختصاصی، بسته npm تحلیل شده، تعداد هشدارهای زنده بازیابی و تطبیق داده شده و زمان‌بندی هر منبع را ثبت می‌کند. شکست در یکی از منابع به معنای پوشش ناقص داده‌ها است.
- بازرسی شواهد: تب Sources ورودی بازیابی شده از پایگاه دانش و لینک‌های مستقیم به رکوردهای اصلی هشدار را برای تایید دستی فراهم می‌کند.
- ردپای فعالیت: یک لاگ تمام عملیات‌ها، از جمله تحلیل بسته، جست‌وجوی زنده، خواندن پایگاه دانش و تایید رکوردها را ثبت می‌کند.
تحلیل وابستگی‌ها
علاوه بر استعلام‌های دستی، این ابزار بررسی‌های خودکار وابستگی‌ها را نیز مدیریت می‌کند. با آپلود یک فایل package-lock.json — که مانند لیست دقیق تمام قطعات به کار رفته در پروژه است — اپلیکیشن داده‌های JSON را تجزیه می‌کند تا نسخه‌های نصب‌شده از وابستگی‌های مستقیم و انتقالی (Transitive) را با هشدارهای شناخته‌شده تطبیق دهد.
این فرآیند کاملاً داده‌محور است؛ اپلیکیشن در حین آپلود، هیچ بسته‌ای را نصب نمی‌کند و هیچ اسکریپتی را اجرا نمی‌نماید. نتیجه نهایی، رکوردهای منبع تطبیق داده شده را بر اساس بسته و نسخه نصب‌شده گروه‌بندی کرده و برای هر هشدار، لینکی جهت بررسی اصلاحات لیست شده و شرایط مربوطه ارائه می‌دهد.
پیاده‌سازی فنی
معماری این سیستم نقش هوش مصنوعی را از یک «تولیدکننده» به یک «تاییدکننده» تغییر می‌دهد. سیستم از یک نقطه اتصال پروتکل زمینه مدل (MCP) در Sanity به نام «Security Advisor» استفاده می‌کند. عامل به جای تکیه بر داده‌های آموزشی داخلی خود، در مسیرهای استناد شده پیمایش می‌کند.
جزئیات ادغام با Sanity
توسعه‌دهنده از یک پیکربندی خاص Sanity برای تغذیه پایگاه دانش استفاده کرده است:
- پیکربندی پروژه: اپلیکیشن از شناسه پروژه
o7qa6o3yبا مجموعه دادهproductionاستفاده می‌کند. - جذب داده‌ها: هشدارهای امنیتی اصلی گیت‌هاب در فایل
data/advisory-sources.jsonلیست شده‌اند. توسعه‌دهنده از دستورnpm run ingestبرای اجراهای آزمایشی وnpm run ingest -- --applyبرای نوشتن رکوردهای بررسی شده با استفاده از توکن Editor استفاده کرده است. در این راستا، مدیریت امن دسترسی‌ها حیاتی است، مشابه آنچه در رویکرد استفاده از توکن‌های کوتاه‌مدت برای کاهش ریسک نشت اعتبارنامه‌ها در عوامل هوش مصنوعی بررسی شده است. - ساختار پایگاه دانش: سیستم شامل ۱۲۲ سند منبع و ۲۸ ورودی تولید شده است. این ورودی‌ها اطلاعات مرتبط را در مسیرهای کوتاه‌تر و استناد شده سازماندهی می‌کنند تا عامل بتواند در آن‌ها پیمایش کند.
- مکانیزم بازیابی: سرور Next.js توابع
initial_contextوknowledge_base_readرا از طریق نقطه اتصال MCP فراخوانی می‌کند و از یک توکن Viewer مجزا برای خواندن رکوردهای منتشر شده استفاده می‌کند.
کد اپلیکیشن در نهایت یک بررسی نهایی انجام می‌دهد تا مطمئن شود مسیرها، نقل‌قول‌ها، لینک‌های منبع و نتایج مربوط به نسخه‌ها پیش از نمایش به کاربر، با رکوردهای اصلی هم‌خوانی دارند.
برای یک توسعه‌دهنده، این یعنی تفاوت بین یک آسیب‌پذیری «محتمل» و یک آسیب‌پذیری «مستند». در یک محیط عملیاتی، اقدام بر اساس یک CVE توهمی می‌تواند منجر به اتلاف ساعت‌های مهندسی شود یا بدتر از آن، باعث نادیده گرفتن یک تهدید واقعی شود چون هوش مصنوعی نتوانست بازه نسخه صحیح را پیدا کند.
این رویکرد نشان‌دهنده حرکتی به سمت جریان‌های کاری عاملی «اول-شواهد» (Evidence-first) است. با جداسازی بازیابی حقیقت (از طریق OSV.dev و Sanity) از سنتز پاسخ (از طریق DeepSeek)، سیستم یک ردپای ممیزی شفاف ایجاد می‌کند که یک مهندس امنیت انسانی می‌تواند به آن اعتماد کند.
برای مشاهده این سیستم در عمل، توسعه‌دهندگان می‌توانند مخزن گیت‌هاب پروژه را بررسی کنند که شامل اپلیکیشن، اسکیمای Sanity، واردکننده هشدارها، نمونه lockfile و فایل VERIFICATION.md برای تست‌های دقیق انجام شده است. این پشته تکنولوژی با Next.js، React، TypeScript، Node.js، Vercel AI SDK، Vitest و Playwright ساخته شده است.
گام بعدی شما
- مخزن گیت‌هاب پروژه را برای بررسی ساختار Sanity و فایل
VERIFICATION.mdمطالعه کنید. - اگر از Next.js یا TypeScript استفاده می‌کنید، مدل پیاده‌سازی MCP را برای ابزارهای داخلی خود بررسی کنید.
- فایل lockfile پروژه‌های فعلی خود را با متدولوژی‌های مبتنی بر شواهد (Evidence-first) تطبیق دهید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو