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

زنجیره تأمین نرم‌افزار چیست؟

زنجیره تأمین نرم‌افزار، مجموعه‌ای از فرآیندها، ابزارها، کتابخانه‌ها، خدمات و افراد است که در ایجاد، آزمایش، انتشار و نگهداری نرم‌افزار نقش دارند. هر مرحله‌ای که کدی تولید، وارد یا اجرا می‌شود، می‌تواند در این زنجیره باشد. حتی یک توسعه‌دهنده بیرونی که در GitHub مشارکت می‌کند یا یک پکیج NPM می‌نویسد، بخشی از این زنجیره است. همین گستردگی، این زنجیره را به هدفی وسوسه‌برانگیز برای مهاجمان تبدیل کرده است.

حمله Supply Chain چیست و چرا خاص است؟

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

چرا این حملات خاص هستند؟

• مهاجم از مسیر قانونی وارد می‌شود.

• قربانی معمولاً متوجه حضور مهاجم نمی‌شود.

• شناسایی آن‌ها بسیار دشوار و گاهی ماه‌ها طول می‌کشد.

• اثر آن می‌تواند به صدها یا هزاران سازمان سرایت کند.

انواع رایج حملات Supply Chain

در ادامه به برخی از متداول‌ترین الگوهای این نوع حمله اشاره می‌کنیم:

۱. تزریق کد مخرب در کتابخانه‌های متن‌باز

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

۲. حملات Typosquatting و Package Hijacking

مهاجم‌ها پکیجی با نامی بسیار شبیه به یک پکیج معتبر منتشر می‌کنند (مثلاً react-router-domm به‌جای react-router-dom). توسعه‌دهنده‌ای که اشتباهاً آن را نصب کند، قربانی می‌شود. یا اینکه مهاجم کنترل یک پکیج متروکه را به‌دست گرفته و نسخه‌ای مخرب از آن منتشر می‌کند.

۳. نفوذ به زنجیره CI/CD

اگر مهاجم موفق به نفوذ به سیستم‌های Build مانند Jenkins، GitLab CI یا GitHub Actions شود، می‌تواند کدی آلوده را در زمان ساخت نرم‌افزار وارد کند، طوری که در خروجی رسمی منتشر شود.

۴. حمله به توسعه‌دهنده (Developer Targeting)

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

مثال‌هایی واقعی و مشهور از این حملات

• SolarWinds (Sunburst) – سال ۲۰۲۰

بدافزار Sunburst از طریق یک به‌روزرسانی قانونی از سوی شرکت SolarWinds در نرم‌افزار Orion توزیع شد. این نرم‌افزار توسط سازمان‌های دولتی آمریکا و صدها شرکت استفاده می‌شد و مهاجم برای ماه‌ها به داده‌های حساس دسترسی داشت.

• حمله به Event-Stream در NPM – سال ۲۰۱۸

در این رویداد، یک مهاجم کنترل پکیج event-stream را در اختیار گرفت و وابستگی آلوده‌ای به آن افزود. هدف این کد سرقت کلیدهای کیف پول بیت‌کوین بود.

• حمله به 3CX – سال ۲۰۲۳

شرکت 3CX مورد حمله پیچیده‌ای قرار گرفت که در آن، نسخه رسمی نرم‌افزار دسکتاپ این شرکت به بدافزار آلوده شده بود. بسیاری از کاربران نهایی بدون اینکه بدانند بدافزار را از وب‌سایت رسمی دریافت کرده بودند.

چرا این حملات بسیار خطرناک هستند؟

• پنهان‌کاری بالا: از آنجایی که بدافزار از طریق مسیرهای قانونی منتشر می‌شود، شناسایی آن توسط آنتی‌ویروس‌ها دشوار است.

• اثر چندلایه‌ای: آلوده شدن یک مؤلفه می‌تواند ده‌ها مؤلفه دیگر را نیز درگیر کند (وابستگی‌های تو در تو).

• هزینه جبران بالا: بررسی و حذف آلودگی ممکن است ماه‌ها طول بکشد و میلیاردها تومان خسارت وارد کند.

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

وضعیت امنیت Supply Chain در ایران

بسیاری از سازمان‌های ایرانی، به‌ویژه استارتاپ‌ها، شرکت‌های نرم‌افزاری و حتی نهادهای دولتی، به‌شدت به ابزارهای متن‌باز و سرویس‌های شخص ثالث خارجی وابسته‌اند. اما چالش‌های زیر مشاهده می‌شود:

• استفاده گسترده از ابزارهای کرک‌شده یا بدون اعتبارسنجی

• نبود استانداردهای DevSecOps و تست امنیتی در مراحل توسعه

• نبود لیست شفاف SBOM برای محصولات نرم‌افزاری

• عدم استفاده از ابزارهای تحلیل آسیب‌پذیری وابستگی‌ها

• ضعف در ارزیابی امنیتی ریپازیتوری‌های داخلی

چگونه با این حملات مقابله کنیم؟

۱. ایجاد و نگهداری SBOM (Software Bill of Materials)

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

۲. تحلیل و اسکن مداوم وابستگی‌ها

ابزارهایی مانند Snyk، OWASP Dependency-Check، Trivy و Grype کمک می‌کنند تا آسیب‌پذیری‌های موجود در پکیج‌ها قبل از استفاده شناسایی شوند.

۳. محدودسازی دسترسی‌ها در CI/CD

از مدل Least Privilege استفاده کنید. هیچ کاربری نباید بیشتر از آنچه نیاز دارد، دسترسی داشته باشد — به‌ویژه در سیستم‌های Build و Deployment.

۴. آموزش تخصصی تیم‌های توسعه

توسعه‌دهندگان باید از تهدیدات Supply Chain آگاه باشند و نحوه انتخاب منابع مطمئن، شناسایی بسته‌های مشکوک و تحلیل رفتار کد را بدانند.

۵. امضای دیجیتال و تأیید منابع

استفاده از امضای دیجیتال برای کد و بسته‌ها (مانند Sigstore) باعث اطمینان از تغییر نکردن آن‌ها در مسیر انتقال می‌شود.

مزایا و معایب استفاده از کد شخص ثالث