در حملات زنجیره تأمین نرم‌افزار، مهاجم به‌جای هدف قرار دادن مستقیم سازمان، به نرم‌افزار، کتابخانه یا ابزار توسعه‌ای که سازمان به آن اعتماد دارد نفوذ می‌کند و از همان کانال مجاز وارد می‌شود. این مقاله تعریف و سازوکار این حملات، نقش مخازن کد و وابستگی‌های متن‌باز، پنج رخداد مستند از 2020 تا 2026 و نقش SBOM، امضای دیجیتال و پایش رفتار را مرور می‌کند و در پایان فهرستی عملی برای کاهش ریسک ارائه می‌دهد.
حمله زنجیره تأمین نرم‌افزار چیست؟
حملات زنجیره تأمین نرم‌افزار (Software Supply Chain Attack) نفوذهایی هستند که مهاجم در آن‌ها سازمان هدف را مستقیم نمی‌زند. او حلقه‌ای را آلوده می‌کند که سازمان از پیش به آن اعتماد دارد: یک کتابخانه، یک بسته در مخزن عمومی، یک ابزار ساخت و استقرار یا خود فرایند انتشار به‌روزرسانی. نتیجه این است که کد مخرب با مجوز و امضای نرم‌افزار قانونی وارد شبکه می‌شود و بسیاری از کنترل‌های سنتی آن را مشکوک نمی‌بینند.
تیم امنیت معمولاً برای آنچه نصب و اجرا می‌کند «اعتماد پیش‌فرض» قائل است. مهاجم دقیقاً از همین پیش‌فرض استفاده می‌کند. به همین دلیل، راهکارهای امنیت سایبری آتنا و بیشتر چارچوب‌های امنیتی امروز، اعتبارسنجی اجزای نرم‌افزار را هم‌ردیف محافظت از شبکه و نقطه پایانی قرار می‌دهند.
تفاوت با حمله به زنجیره تأمین فیزیکی
در زنجیره تأمین فیزیکی، مثل قطعات سخت‌افزاری، دست‌کاری نیازمند دسترسی به کالا، کارخانه یا مسیر حمل است و هر واحد آلوده جداگانه ساخته و جابه‌جا می‌شود. در نرم‌افزار، یک بار آلوده کردن مخزن یا سرور ساخت کافی است و سازوکار توزیع خودکار همان نسخه را برای همه مشتریان می‌فرستد.
- تکثیر: یک تغییر در کد منبع یا بسته منتشرشده در چند ساعت به هزاران سامانه می‌رسد.
- اعتماد رمزنگاری‌شده: نسخه مخرب می‌تواند با گواهی معتبر خود شرکت تولیدکننده امضا شود.
- ردیابی دشوار: وابستگی‌ها لایه‌لایه‌اند و سازمان اغلب نمی‌داند کدام کتابخانه در عمق درخت وابستگی‌ها حضور دارد.
- قابلیت اصلاح: یک قطعه فیزیکی معیوب را می‌توان بازگرداند؛ در نرم‌افزار، پس از اجرا، اطلاعات و کلیدهای سرقت‌شده برگشت‌پذیر نیستند.
تفاوت حمله مستقیم با حمله از طریق تأمین‌کننده
در حمله مستقیم، مهاجم باید از دفاع پیرامونی، احراز هویت و پایش سازمان عبور کند. در حمله زنجیره تأمین، همین دفاع‌ها بخشی از مسیر را خودشان باز می‌کنند، چون ورودی از کانالی می‌آید که سازمان آن را تأیید کرده است.
- نقطه ورود: در حمله مستقیم، سامانه یا کاربر سازمان؛ در حمله از طریق تأمین‌کننده، نرم‌افزار، پکیج یا به‌روزرسانی معتبر.
- هدف مهاجم: در حمله مستقیم، یک سازمان مشخص؛ در حمله زنجیره تأمین، بسیاری از مشتریان یک تأمین‌کننده و سپس انتخاب قربانیان ارزشمندتر.
- دید سازمان به ریسک: در حمله مستقیم از طریق دارایی‌های شناخته‌شده؛ در حمله زنجیره تأمین وابسته به شفافیت تأمین‌کننده و فهرست اجزا.
- کنترل دفاعی اصلی: در حمله مستقیم پیرامون، هویت و پایش؛ در حمله زنجیره تأمین اعتبارسنجی منبع، کنترل انتشار و پایش رفتار پس از نصب.
نکته مهم این است که سازمان قربانی ممکن است هدف نهایی هم نباشد. در رخداد 3CX، همان‌طور که در ادامه می‌بینید، شرکت سازنده خودش از طریق نرم‌افزار آلوده یک شرکت دیگر وارد ماجرا شده بود.
مهاجم چگونه کتابخانه، پکیج و به‌روزرسانی را آلوده می‌کند؟
آلودگی کتابخانه‌ها و پکیج‌ها
مسیرهای رایج شامل ربودن حساب نگهدارنده پکیج با فیشینگ یا سرقت توکن، انتشار پکیجی با نامی شبیه پکیج معروف (Typosquatting)، اضافه کردن وابستگی مخرب به یک پروژه معتبر و بدتر از همه، تبدیل شدن به نگهدارنده قانونی پروژه با گذر زمان است. در این حالت بدافزار در بسته‌های نرم‌افزاری، مثل اسکریپت‌های نصب خودکار، همان لحظه‌ای اجرا می‌شود که توسعه‌دهنده یا سامانه ساخت وابستگی را نصب می‌کند.
به‌روزرسانی‌ها و زیرساخت ساخت
اگر مهاجم به سرور ساخت (Build) یا کلید امضای تولیدکننده دسترسی پیدا کند، لازم نیست کد منبع قابل‌مشاهده را تغییر دهد. او مستقیم باینری نهایی را آلوده می‌کند. در SolarWinds همین سناریو رخ داد: مهاجمان وارد فرایند ساخت Orion شدند و به‌روزرسانی‌های آلوده بین مارس و ژوئن ۲۰۲۰ به مشتریان رسید.
ابزارهای توسعه و خط CI/CD
ابزارهای کمکی، مثل آپلودر پوشش کد یا اسکریپت‌های خط انتشار، معمولاً به متغیرهای محیطی، توکن‌ها و کلیدهای سرویس ابری دسترسی دارند. آلوده شدن این ابزارها به مهاجم دسترسی به اسرار بسیاری از پروژه‌ها می‌دهد، بدون اینکه هیچ‌کدام از آن‌ها مستقیم هک شده باشند.
نقش مخازن کد و وابستگی‌های متن‌باز در سطح حمله
نرم‌افزار سازمانی امروز عمدتاً از اجزای متن‌باز ساخته می‌شود و هر جزء، خودش وابستگی‌های دیگری دارد. سطح حمله بنابراین فقط کد داخلی نیست؛ شامل مخازن پکیج مانند npm و PyPI، مخازن کد مانند GitHub، سرویس‌های CI/CD، کانتینرهای پایه و حساب‌های نگهدارندگان است. حملات به مخازن کد و پکیج‌ها چون هزینه کمی دارند و دسترسی گسترده می‌دهند، برای مهاجمان جذاب‌اند.
دو ویژگی این سطح حمله را خطرناک می‌کند. اول، وابستگی‌های غیرمستقیم (Transitive) که تیم توسعه هرگز آن‌ها را صراحتاً انتخاب نکرده است. دوم، تمرکز اعتماد روی تعداد کمی نگهدارنده؛ نفوذ به یک حساب می‌تواند پروژه‌ای را آلوده کند که میلیون‌ها نصب دارد.
پنج رخداد مستند زیر از جدیدترین به قدیمی‌ترین مرتب شده‌اند.
- Shai-Hulud در npm (سپتامبر ۲۰۲۵؛ موج دوم از ۲۴ نوامبر ۲۰۲۵): کرمی خودتکثیر شونده بیش از ۵۰۰ بسته npm را آلوده کرد. این کرم توکن‌ها و اسرار توسعه‌دهندگان را سرقت می‌کرد و با حساب قربانی بسته‌های بیشتری منتشر می‌کرد. سیسا (CISA) در ۲۳ سپتامبر ۲۰۲۵ هشدار رسمی داد. موج دوم شرکت‌های شناخته‌شده و بیش از ۲۵ هزار مخزن کد را درگیر کرد.
- XZ Utils، CVE-2024-3094 (کشف در ۲۹ مارس ۲۰۲۴): در نسخه‌های ۵.۶.۰ و ۵.۶.۱ کتابخانه liblzma درِ پشتی برای دور زدن احراز هویت SSH جاسازی شده بود. آندرس فروند، توسعه‌دهنده PostgreSQL، آن را به‌طور اتفاقی پس از مشاهده کندی ورود SSH کشف کرد. کد مخرب فقط در بسته‌های منتشرشده بود، نه در مخزن Git.
- 3CX (افشا در ۲۹ مارس ۲۰۲۳؛ گزارش Mandiant در ۲۰ آوریل ۲۰۲۳): نسخه آلوده نرم‌افزار دسکتاپ 3CX از وب‌سایت خود شرکت توزیع شد. بررسی‌ها نشان داد منشأ نفوذ، نصب نسخه آلوده نرم‌افزار X_TRADER از شرکت Trading Technologies بود و این اولین حمله زنجیره تأمینی شناخته‌شده بود که به حمله زنجیره تأمینی دیگر منجر شد.
این پنج رخداد، سه الگوی مشترک دارند: مهاجم از اعتماد موجود استفاده کرد، کشف حمله اغلب دیرهنگام یا اتفاقی بود، و قربانیان نهایی لزوماً هدف اصلی نبودند.
ریسک استفاده از نرم‌افزارهای شخص ثالث در سازمان‌ها
هر نرم‌افزار خارجی که سازمان نصب می‌کند، بخشی از سطح حمله آن می‌شود، به‌ویژه وقتی با سطح دسترسی بالا اجرا شود. ابزارهای مدیریت شبکه، سامانه‌های تلفن، نرم‌افزارهای پشتیبان‌گیری و عامل‌های پایش معمولاً امتیازهایی دارند که یک برنامه عادی ندارد. اگر چنین ابزاری آلوده شود، مهاجم از همان امتیازها بهره می‌برد.
چند پرسش ساده می‌تواند ریسک هر تأمین‌کننده را روشن کند:
- این نرم‌افزار با چه سطح دسترسی و به کدام دارایی‌ها اجرا می‌شود؟
- تأمین‌کننده فرایند ساخت و انتشار خود را چگونه کنترل می‌کند و آیا می‌تواند گزارش شفاف بدهد؟
- به‌روزرسانی‌ها خودکار نصب می‌شوند یا قبل از استقرار آزمایش می‌شوند؟
- اگر تأمین‌کننده دچار رخداد شود، چه مسیر اطلاع‌رسانی و چه نشانه‌های شناسایی در اختیار ماست؟
در نرم‌افزارهای سازمانی که خارج از دید تیم امنیت نصب می‌شوند (Shadow IT)، این پرسش‌ها اصلاً مطرح نمی‌شود. فهرست‌برداری از نرم‌افزارهای در حال استفاده گام اول است.
اهمیت SBOM و شناسایی اجزای تشکیل‌دهنده نرم‌افزار
SBOM (Software Bill of Materials) فهرست ماشین‌خوان اجزای یک نرم‌افزار است: نام و نسخه کتابخانه‌ها، تأمین‌کننده هر جزء و رابطه وابستگی‌ها. وقتی خبر یک رخداد مثل XZ Utils منتشر می‌شود، سازمانی که SBOM دارد می‌تواند در ساعت‌های اول بپرسد «آیا این نسخه در محصولات ما هست؟» و پاسخ بگیرد. سازمان بدون SBOM باید یک‌به‌یک تیم‌ها را بازرسی کند.
در عمل، سه نکته مهم است:
- SBOM را در فرایند ساخت تولید کنید، نه دستی و پس از انتشار، تا همیشه با نسخه واقعی همخوان باشد. قالب‌های استاندارد مانند SPDX و CycloneDX برای همین کار ساخته شده‌اند.
- از تأمین‌کنندگان نرم‌افزار SBOM بخواهید و آن را بخشی از معیار خرید و ارزیابی قرار دهید.
- محدودیت آن را بدانید: SBOM نشان می‌دهد چه چیزی داخل نرم‌افزار است، نه اینکه آلوده است یا نه. ریسک‌هایی مانند اسرار جاسازی‌شده یا سوءاستفاده از اعتبارنامه‌ها، که در حمله Shai-Hulud دیده شد، همیشه در SBOM معمولی ظاهر نمی‌شوند. پس SBOM باید با پایش و اعتبارسنجی همراه شود.
امضای دیجیتال، اعتبارسنجی بسته‌ها و کنترل فرایند انتشار
امضا و بررسی یکپارچگی
امضای دیجیتال نشان می‌دهد نسخه از سوی تولیدکننده منتشر شده، اما درباره سالم بودن آن تضمینی نمی‌دهد. اگر مهاجم به کلید یا سرور ساخت دسترسی داشته باشد، نسخه آلوده هم امضا می‌شود. ماجرای 3CX، که پس از رخداد گواهی امضای آن باطل شد، نمونه‌ای از همین مشکل است. بنابراین امضا لازم است، ولی کافی نیست.
کنترل‌هایی که ارزش اضافه دارند:
- تطبیق هش و چک‌سام پیش از اجرا. در رخداد Codecov، کشف حمله از همین تطبیق شروع شد.
- قفل کردن نسخه وابستگی‌ها (Lockfile و Pinning) و استفاده از آینه داخلی مخزن پکیج‌ها، به‌جای دریافت مستقیم و بی‌قیدوشرط از اینترنت.
- اثبات منشأ ساخت (Provenance) با چارچوب‌هایی مانند SLSA و ابزارهایی مانند Sigstore که مشخص می‌کنند یک artifact از کدام مخزن و فرایند ساخته شده است.
کنترل فرایند انتشار
زیرساخت ساخت باید مثل یک دارایی حساس مدیریت شود: احراز هویت چندعاملی برای نگهدارندگان، حداقل دسترسی برای توکن‌ها، بازبینی اجباری کد پیش از ادغام، جداسازی محیط ساخت و نگهداری کلیدهای امضا در سخت‌افزار امن یا سرویس مدیریت کلید. نمونه XZ Utils نشان داد که بازبینی کد به‌تنهایی کافی نیست، چون کد مخرب در بسته منتشرشده بود و در مخزن دیده نمی‌شد. مقایسه بسته منتشرشده با کد منبع هم باید بخشی از فرایند باشد.
راهکارهای کاهش ریسک در فرایند توسعه و استقرار
فهرست زیر را می‌توان به ترتیب اجرا کرد. همه موارد در یک سازمان لازم نیست همزمان اجرا شوند؛ اولویت با اجزای دارای بیشترین دسترسی است.
- شناسایی دارایی‌ها: فهرست نرم‌افزارها، تأمین‌کنندگان و وابستگی‌های مستقیم و غیرمستقیم را تهیه و به‌روز کنید.
- SBOM در خط ساخت: تولید و نگهداری خودکار برای محصولات داخلی و دریافت برای محصولات خریداری‌شده.
- کنترل ورودی پکیج‌ها: آینه داخلی، فهرست مجاز، قفل نسخه و هشدار برای وابستگی جدید یا تغییر ناگهانی مالک پکیج.
- صیانت از هویت‌ها و اسرار: احراز هویت چندعاملی برای حساب‌های نگهدارنده، توکن‌های کوتاه‌مدت، و چرخش سریع اسرار پس از هر رخداد مشکوک. حمله‌هایی مانند Codecov و Shai-Hulud نشان داد که اسرار موجود در CI هدف اصلی‌اند.
- تفکیک و حداقل دسترسی در CI/CD: هر مرحله فقط به همان اسراری دسترسی داشته باشد که نیاز دارد؛ اجرای اسکریپت‌های نصب خودکار پکیج‌ها را محدود کنید.
- استقرار تدریجی به‌روزرسانی‌ها: نسخه جدید نرم‌افزارهای دارای دسترسی بالا ابتدا روی گروه آزمایشی اجرا شود.
- آمادگی برای واکنش: سناریوی «تأمین‌کننده‌ای که نرم‌افزارش آلوده شده» را تمرین کنید: چه کسی نرم‌افزار را قطع می‌کند، اسرار را می‌چرخاند و شواهد را نگه می‌دارد.
برای طراحی نقشه راه، ارزیابی تأمین‌کنندگان و پیاده‌سازی کنترل‌ها در زیرساخت سازمان، می‌توان از خدمات مشاوره و پیاده‌سازی امنیت سایبری کمک گرفت.
نقش پایش امنیتی و تشخیص رفتار غیرعادی
هیچ فرایند پیشگیرانه‌ای صددرصد نیست. اگر نسخه آلوده از همه فیلترها عبور کرد، آخرین خط دفاع شناسایی رفتار غیرعادی پس از نصب است: اتصال به آدرس‌های ناشناس، اجرای فرایندهای غیرمعمول توسط نرم‌افزاری مورد اعتماد، دسترسی غیرعادی به اسرار یا حرکت جانبی در شبکه. در حمله‌های بررسی‌شده در این مقاله، اغلب همین رفتارها، و نه خود فایل، سرنخ اصلی بودند. برای نمونه کشف XZ Utils با دیدن رفتار غیرعادی SSH آغاز شد و آلودگی Codecov با ناهمخوانی در یکپارچگی اسکریپت.
این‌جا ابزارهای تشخیص و پاسخ در نقطه پایانی و فراتر از آن اهمیت پیدا می‌کنند. راهکارهای امنیت سازمانی کسپرسکی شامل خانواده Kaspersky Next است که EDR و XDR را برای جمع‌آوری تله‌متری، شکار تهدید و همبستگی هشدارها از منابع مختلف ارائه می‌کند. در سطح XDR، هشدارهای نقطه پایانی، ایمیل و محیط ابری به هم مرتبط می‌شوند تا تیم امنیت تصویر کامل‌تری از یک رخداد داشته باشد.
جمع‌بندی
حملات زنجیره تأمین نرم‌افزار نشان می‌دهند امنیت یک سازمان به امنیت کوچک‌ترین حلقه‌ای وابسته است که به آن اعتماد کرده است. رخدادهای SolarWinds، Codecov، 3CX، XZ Utils و Shai-Hulud از ۲۰۲۰ تا ۲۰۲۵ یک پیام مشترک دارند: اعتماد باید قابل‌راستی‌آزمایی باشد. فهرست اجزا، تأیید منبع، کنترل فرایند انتشار و پایش رفتار، چهار لایه‌ای هستند که کنار هم ریسک را کاهش می‌دهند. برای بررسی وضعیت سازمان و برنامه‌ریزی مرحله‌به‌مرحله، می‌توانید با کسپرسکی فارسی و تیم متخصص آتنا مشورت کنید.
دیدگاه کاربران
تعداد دیدگاه کاربران: 0 دیدگاه