خانه » چرا برخی پچ‌های امنیتی هرگز در داشبوردهای مدیریت آسیب‌پذیری ثبت نمی‌شوند؟

چرا برخی پچ‌های امنیتی هرگز در داشبوردهای مدیریت آسیب‌پذیری ثبت نمی‌شوند؟

توسط Vulnerbyte_News
19 بازدید

در سال 2026، مفهوم مدیریت آسیب‌پذیری دیگر شباهت زیادی به مدل سنتی شناسایی ضعف‌های امنیتی و اعمال پچ ندارد. سیستم CVE که در ابتدا برای ردیابی ضعف‌های کدنویسی همراه با پچ امنیتی طراحی شده بود، اکنون برای پوشش حملات زنجیره تأمین (Supply Chain)، بدافزارها و تهدیدات مبتنی بر عامل‌های هوش مصنوعی استفاده می‌شود. این موضوع باعث شده فرآیند مدیریت آسیب‌پذیری به‌جای تمرکز بر ضعف‌های فنی، به سمت ردیابی رخدادها و فعالیت‌های مشکوک حرکت کند.

حملات مدرنی مانند s1ngularity و Shai-Hulud نشان دادند که بسیاری از تهدیدات جدید اساساً با مدل سنتی CVE سازگار نیستند. کرم رایانه‌ای npm که از سپتامبر 2025 در اکوسیستم npm گسترش یافت، صدها پکیج را آلوده کرد؛ اما بخش بزرگی از این آلودگی‌ها هرگز شناسه CVE دریافت نکردند. حتی Red Hat نیز اعلام کرد که به دلیل تعداد بالای سازمان‌ها و پکیج‌های آلوده، اختصاص CVE به همه موارد عملاً امکان‌پذیر نیست.

شکاف در سیستم CVE و بحران مدیریت آسیب‌پذیری

حمله Shai-Hulud نمونه واضحی از محدودیت‌های فعلی CVE بود. برخی نسخه‌های آلوده موفق به دریافت شناسه شدند، اما صدها پکیج دیگر بدون هیچ ردپایی در ابزارهای امنیتی باقی ماندند. این یعنی بسیاری از داشبوردهای مدیریت آسیب‌پذیری اساساً دید کاملی نسبت به تهدیدات واقعی ندارند.

در نمونه Bitwarden نیز همین مسئله تکرار شد. در آوریل 2026 نسخه‌ای مخرب از Bitwarden CLI روی npm منتشر شد که حاوی یک کد مخرب(payload)  سرقت اعتبارنامه بود. این کد مخرب پس از اجرای دستور npm install، توکن‌های AWS، Azure، GCP، GitHub و npm را از سیستم توسعه‌دهندگان استخراج می‌کرد.

مهاجمان از طریق یک GitHub Action آلوده که به رخداد زنجیره تأمین Checkmarx مرتبط بود، به مسیر انتشار Bitwarden دسترسی پیدا کردند. حدود 9 روز بعد، شناسه CVE-2026-42994 برای نسخه تروجانیزه‌شده منتشر شد و ابزارهای تحلیل ترکیب نرم‌افزار (Software Composition Analysis-SCA) آن را روی داشبوردهای امنیتی نمایش دادند.

اما نکته مهم اینجاست که CVE در این سناریو عملاً نقش یک هشدار مرتبط با پچ امنیتی را ایفا نمی‌کرد. مشکل اصلی یک بازه حدود 90 دقیقه‌ای بود که طی آن زنجیره انتشار نرم‌افزار در معرض نفوذ قرار گرفت؛ بازه‌ای که با انتشار پکیج مخرب به پایان رسیده بود. در عمل، CVE صرفاً به سازمان‌ها هشدار می‌داد که اگر در همان بازه دستور npm install را اجرا کرده‌اند، باید اعتبارنامه‌های توسعه‌دهندگان خود را افشاشده در نظر بگیرند. این وضعیت بیشتر به «پاسخ به رخداد» (Incident Response) شباهت دارد تا مدل سنتی مدیریت آسیب‌پذیری.

وقتی پچ‌های امنیتی بی‌سروصدا منتشر می‌شوند

بسیاری از شرکت‌ها و توسعه‌دهندگان، ضعف‌های امنیتی را بدون انتشار هشدار امنیتی رسمی (Security Advisory) برطرف می‌کنند. در چنین شرایطی، گزارش یک محقق امنیتی ممکن است به‌جای ثبت به‌عنوان آسیب‌پذیری، صرفاً با عنوان‌هایی مانند بهبود ایمن‌سازی (Hardening Improvement) یا ارتقای امنیت (Security Enhancement) طبقه‌بندی شود؛ بدون اینکه به آن شناسه CVE اختصاص داده شود.

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

چگونه عامل‌های هوش مصنوعی سیستم‌های سنتی را ناکارآمد می‌کنند؟

ظهور عامل‌ها، Skillها و سرورهای MCP، مدل سنتی مدیریت آسیب‌پذیری را با چالش جدی روبه‌رو کرده است. سیستم CVE برای نرم‌افزارهایی طراحی شده بود که هویت ثابت، نسخه مشخص و ضعف‌های فنی قابل پچ‌شدن داشتند؛ اما زیرساخت‌های عامل‌محور دائماً تغییر می‌کنند.

این دارایی‌ها:

  • در زمان اجرا (Runtime) تغییر عملکرد می‌دهند.
  • هویت پایداری ندارند.
  • از ریجستری‌ها و مخازن مختلف منتشر می‌شوند.
  • گاهی تنها با یک فایل متنی کنترل می‌شوند.

در چنین شرایطی، تهدیدات دیگر الزاماً به شکل اکسپلویت حافظه،  دور زدن احراز هویت (Authentication Bypass) یا اجرای کد از راه دور (RCE) ظاهر نمی‌شوند. گاهی یک فایل SKILL.md برای هدایت عامل به فعالیت مخرب کافی است.

نمونه derp در ریجستری skills.sh دقیقاً همین الگو را نشان می‌داد و فاقد هرگونه نشانه کلاسیک بدافزار بود. در این نمونه:

  • هیچ فراخوانی شبکه‌ای مشکوکی دیده نمی‌شد.
  • هیچ کد مخرب رمزگذاری‌شده‌ای وجود نداشت.
  • هیچ مکانیزم مستقیمی برای سرقت اعتبارنامه‌ مشاهده نمی‌شد.

با این حال، فایل SKILL.md به Claude دستور می‌داد عمداً کد مخرب تولید کند، راهکارهای اشتباه ارائه دهد و این عملکرد را از کاربر پنهان نگه دارد.

در چنین سناریویی، شناسه CVE عملاً کاربردی ندارد، چون مشکل به یک ضعف فنی سنتی محدود نیست. اما پیامدها واقعی‌ هستند:

  • اتلاف منابع پردازشی (Compute Resources)
  • افزایش هزینه توکن‌ها
  • کاهش اعتماد به عامل‌ها

این مسئله نشان می‌دهد بخش قابل توجهی از تهدیدات جدید، خارج از محدوده دید ابزارهای سنتی مدیریت آسیب‌پذیری قرار دارند.

کمپین ClawSwarm و اتصال پنهانی عامل‌ها در شبکه‌های خارجی

شرکت Manifold Security در آوریل 2026 کمپینی با نام ClawSwarm را شناسایی کرد؛ کمپینی که شامل 30 مورد Skill منتشرشده توسط یک توسعه‌دهنده در پلتفرم ClawHub بود. برخی از این Skillها ابزارهایی مانند Cron Helper و Agent Security را ارائه می‌کردند، اما در پشت‌صحنه، عامل‌ها کاربر را بدون اطلاع اپراتور به شبکه‌های شخص ثالث متصل می‌کردند.

با نصب این Skillها، عامل کاربر به‌صورت خودکار:

  • روی یک سرور خارجی ثبت می‌شد.
  • قابلیت‌ها و سطح دسترسی خود را گزارش می‌کرد.
  • یک کیف‌پول رمزارزی بر شبکه Hedera ایجاد می‌کرد.
  • اعتبارنامه‌ها را روی دیسک ذخیره می‌کرد.
  • هر چهار ساعت برای دریافت وظایف جدید با سرور ارتباط برقرار می‌کرد.

نکته مهم اینجاست که این فعالیت‌ها در ظاهر کاملاً عادی و قانونی به نظر می‌رسیدند:

  • ارتباطات از طریق پروتکل امن HTTPS انجام می‌شد.
  • کیف‌پول‌ها با استفاده از کیت توسعه نرم‌افزار رسمی (SDK) ساخته می‌شدند.
  • هیچ Shellcode یا زیرساخت فرماندهی و کنترل (C2) شناخته‌شده‌ای در این زنجیره دیده نمی‌شد.

این مسئله باعث می‌شد بسیاری از ابزارهای امنیتی، این فعالیت‌ها را به‌عنوان تهدید شناسایی نکنند.

آینده مدیریت آسیب‌پذیری

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

سه تغییر کلیدی برای این تحول ضروری است:

  • استفاده از شناسه‌های عملکردی (Behavioral Identifiers) به‌جای تمرکز صرف بر هش فایل یا SHA
  • شفافیت بیشتر ریجستری‌ها در حذف Skillها و توسعه‌دهنده‌های مخرب
  • افشای مسئولانه تغییرات امنیتی توسط شرکت‌ها و توسعه‌دهندگان مدل‌های هوش مصنوعی

در حال حاضر بسیاری از اصلاحات مربوط به Prompt Injection یا محدودسازی عامل‌ها بدون هشدار امنیتی رسمی و حتی بدون تغییر نسخه انجام می‌شوند؛ موضوعی که دید امنیتی سازمان‌ها را محدود می‌کند.

داشبوردهای امنیتی دیگر تصویر کاملی ارائه نمی‌دهند

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

در اکوسیستم هوش مصنوعی عامل‌محور، بسیاری از حملات:

  • شناسه CVE مشخصی ندارند.
  • فاقد شاخص‌های نفوذ (IOC) سنتی هستند.
  • حتی ممکن است هیچ فعالیت مخرب کلاسیکی از خود نشان ندهند.

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

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

منابع

همچنین ممکن است دوست داشته باشید

پیام بگذارید