حمله Supply Chain چیست؟ خطر افزونه‌ها و کتابخانه‌های آلوده برای امنیت سایت

پاسخ کوتاه: حمله Supply Chain یا حمله زنجیره تأمین نرم‌افزار زمانی رخ می‌دهد که مهاجم به‌جای حمله مستقیم به سایت، یکی از اجزای مورد اعتماد در مسیر توسعه، توزیع یا به‌روزرسانی نرم‌افزار را آلوده یا تصاحب کند. افزونه WordPress، Theme، کتابخانه JavaScript یا PHP، Packageهای npm و Composer، سرویس CDN، مخزن کد، CI/CD و حتی حساب توسعه‌دهنده می‌توانند بخشی از این زنجیره باشند. مدیریت Dependencyها، استفاده از منابع معتبر، SBOM، کنترل Updateها، Lock File، بررسی Integrity و کاهش Third-Party Code از مهم‌ترین راهکارهای دفاعی هستند.

وقتی درباره هک شدن یک سایت صحبت می‌کنیم، معمولاً اولین تصویر این است که مهاجم مستقیماً به سرور یا فرم ورود سایت حمله می‌کند؛ رمز عبور Administrator را به دست می‌آورد، یک آسیب‌پذیری در Application پیدا می‌کند یا از ضعف Web Server سوءاستفاده می‌کند.

اما یکی از خطرناک‌ترین مدل‌های حمله دقیقاً برعکس عمل می‌کند.

مهاجم ممکن است اصلاً سایت شما را هدف اولیه خود قرار ندهد.

به‌جای آن، توسعه‌دهنده افزونه‌ای را که هزاران سایت نصب کرده‌اند هدف می‌گیرد؛ حساب Maintainer یک Package را تصاحب می‌کند؛ Repository ساخت نرم‌افزار را دستکاری می‌کند؛ فایل JavaScript روی CDN را تغییر می‌دهد یا فرآیند Update محصول مورد اعتماد را آلوده می‌کند.

سپس کاربران خودشان نسخه آلوده را روی سیستم‌هایشان نصب می‌کنند.

این همان چیزی است که با عنوان Software Supply Chain Attack یا حمله زنجیره تأمین نرم‌افزار شناخته می‌شود.

اهمیت این تهدید در سال‌های اخیر به حدی افزایش یافته که در OWASP Top 10:2025، Software Supply Chain Failures با عنوان A03:2025 در رتبه سوم مهم‌ترین ریسک‌های امنیت Application قرار گرفته است. OWASP همچنین اعلام کرده در نظرسنجی جامعه Top 10، دقیقاً ۵۰ درصد پاسخ‌دهندگان این موضوع را در رتبه اول اهمیت قرار داده بودند. دامنه این دسته دیگر فقط «استفاده از Component آسیب‌پذیر» نیست و کل اکوسیستم Dependency، Build System و Infrastructure توزیع نرم‌افزار را در بر می‌گیرد.

برای مدیر یک سایت WordPress این موضوع اهمیت دوچندانی دارد؛ زیرا ممکن است سایت از ده‌ها Plugin و Theme استفاده کند و هرکدام از آن‌ها نیز کتابخانه‌ها و Dependencyهای دیگری درون خود داشته باشند.

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

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

هیچ نرم‌افزار مدرنی به‌طور کامل از صفر نوشته نمی‌شود.

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

• سیستم‌عامل
• Web Server
• PHP
• WordPress
• Pluginها
• Theme
• کتابخانه PHP
• JavaScript Library
• CSS Framework
• Composer Package
• npm Package
• CDN
• APIهای Third-Party
• Git Repository
• CI/CD Pipeline
• Container Image
• Development Tool

تمام این اجزا بخشی از Software Supply Chain هستند.

OWASP زنجیره تأمین نرم‌افزار را تنها به Libraryهای Third-Party محدود نمی‌کند. ابزارهای توسعه، Repository، Package Manager، Build Tool، CI/CD، Configuration Management و Componentهای داخلی نیز می‌توانند بخشی از زنجیره باشند. یک ضعف در هر حلقه ممکن است Integrity کل محصول نهایی را تحت تأثیر قرار دهد.

یک مثال ساده

فرض کنید یک سایت WordPress دارید.

سایت شما مستقیماً از:

WordPress Core

استفاده می‌کند.

اما همچنین پنج Plugin نصب کرده‌اید.

یکی از Pluginها نیز داخل خودش یک Library PHP دارد.

آن Library ممکن است خودش از یک Dependency دیگر استفاده کند.

در نتیجه ساختار واقعی می‌تواند چنین باشد:

Website ↓ WordPress ↓ Plugin ↓ PHP Library ↓ Dependency دیگر

شما شاید فقط Plugin را نصب کرده باشید، اما در عمل به چند Maintainer، Repository و Component مختلف اعتماد کرده‌اید.

این مفهوم اساس ریسک Supply Chain است.

حمله Supply Chain چیست؟

در حمله Supply Chain، مهاجم یکی از اجزایی را که قربانی به آن اعتماد دارد هدف قرار می‌دهد.

هدف می‌تواند یکی از این موارد باشد:

Plugin Developer

Package Maintainer

Source Repository

Build Server

Update Infrastructure

Package Registry

CDN

Third-Party Service

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

نکته خطرناک اینجاست:

کاربر ممکن است این Component را از مسیری دریافت کند که از نظر او کاملاً معتبر است.

مثلاً:

«برای Plugin آپدیت آمده است.»

کاربر روی Update کلیک می‌کند.

اما اگر Infrastructure توسعه‌دهنده قبلاً Compromise شده باشد، فایل Update ممکن است دیگر همان کدی نباشد که کاربر انتظار دارد.

به همین دلیل Supply Chain Attack تا حد زیادی یک حمله علیه Trust است.

چرا حملات Supply Chain خطرناک‌اند؟

یک مهاجم در حمله مستقیم ممکن است مجبور شود سایت‌ها را یکی‌یکی هدف قرار دهد.

اما اگر Componentی که ۵۰ هزار سایت استفاده می‌کنند Compromise شود، یک نقطه واحد از زنجیره می‌تواند تعداد بسیار بیشتری از کاربران را در معرض خطر قرار دهد.

به همین دلیل مفهوم زیر مهم است:

One-to-Many Compromise

یعنی:

یک Supplier آلوده ↓ تعداد زیادی Consumer

OWASP نیز اشاره می‌کند Componentهای Third-Party معمولاً با همان Privilege Application اجرا می‌شوند؛ بنابراین یک Dependency آسیب‌دیده می‌تواند اثر بسیار جدی روی Application داشته باشد.

برای مثال Plugin WordPress معمولاً فقط یک فایل تزئینی نیست.

Plugin می‌تواند در شرایط مختلف به:

• Database
• User Data
• WordPress Hooks
• File System
• wp-admin
• HTTP Requests
• REST API
• Cron
• Email

دسترسی داشته باشد.

اگر همان Plugin به Component مخرب تبدیل شود، محدودکردن خسارت بسیار دشوارتر خواهد بود.

تفاوت حمله Supply Chain با هک مستقیم سایت چیست؟

در حمله مستقیم:

Attacker ↓ Website

اما در حمله زنجیره تأمین:

Attacker ↓ Trusted Supplier ↓ Trusted Component ↓ Website

این تفاوت از نظر Detection مهم است.

در حمله مستقیم ممکن است Firewall یا WAF یک Request مشکوک را مشاهده کند.

اما در Supply Chain Attack ممکن است فایل مخرب از طریق:

Update رسمی

Deploy Pipeline

Package Manager

یا Repository مورد اعتماد

وارد Production شود.

در نتیجه سیستم دفاعی ممکن است در ابتدا آن را به‌عنوان یک عملیات عادی ببیند.

Software Supply Chain Failures در OWASP Top 10:2025

OWASP در نسخه 2025 دامنه دسته قبلی Vulnerable and Outdated Components را گسترش داده و آن را به:

A03:2025 – Software Supply Chain Failures

تبدیل کرده است.

طبق OWASP، ریسک فقط این نیست که Dependency شما نسخه قدیمی و آسیب‌پذیر داشته باشد.

مشکلات Supply Chain می‌توانند شامل این موارد باشند:

• Component آسیب‌پذیر
• Component بدون Maintainer
• Dependency غیرقابل Update
• Component از منبع غیرقابل اعتماد
• تغییر مخرب در Third-Party Code
• ضعف CI/CD
• ضعف Build System
• ضعف Artifact Repository
• نداشتن Inventory دقیق Dependencyها

OWASP همچنین توصیه می‌کند سازمان‌ها Dependencyهای مستقیم و Transitive را ردیابی کنند، SBOM داشته باشند، Componentها را فقط از Source معتبر تهیه کنند و در صورت امکان از Packageهای Signed و Artifactهایی با Provenance مشخص استفاده کنند.

خطر اول: افزونه WordPress آلوده

برای بسیاری از مدیران سایت، قابل‌لمس‌ترین نمونه Supply Chain Risk یک Plugin است.

Plugin می‌تواند به دو شکل خطرناک باشد:

Plugin از ابتدا مخرب است

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

نمونه‌های رایج Risk:

Pluginهای Nulled

نسخه کرک‌شده Plugin Premium

Plugin دانلودشده از سایت ناشناس

فایل ZIP ارسال‌شده در Telegram یا Forum

Plugin جعلی با نام مشابه محصول معروف

مشکل اصلی در این حالت این است که شما هیچ زنجیره اعتماد قابل‌اتکایی ندارید.

نمی‌دانید:

فایل را چه کسی Build کرده است؟

آیا از Source اصلی آمده؟

آیا Code تغییر کرده است؟

آیا فایل اضافی وارد Package شده است؟

Plugin معتبر بعداً Compromise می‌شود

سناریوی دوم پیچیده‌تر است.

ممکن است Plugin سال‌ها سالم باشد.

اما بعداً:

حساب Developer Compromise شود.

Repository دستکاری شود.

Update Server هک شود.

مالکیت پروژه تغییر کند.

یا Credential انتشار Package سرقت شود.

در چنین شرایطی حتی کاربری که Plugin را از قبل نصب کرده است ممکن است از طریق Update در معرض خطر قرار گیرد.

این یکی از مهم‌ترین تفاوت‌های Supply Chain Attack با Plugin جعلی است.

آیا نصب از WordPress.org خطر را کاملاً از بین می‌برد؟

خیر.

استفاده از Source رسمی و معتبر یکی از بهترین راه‌های کاهش Risk است، اما هیچ Repository بزرگی نمی‌تواند تضمین کند هیچ Componentی در آینده آسیب‌پذیر یا Compromise نخواهد شد.

WordPress.org برای Pluginهای خود Guideline و فرآیندهای امنیتی دارد. مستندات رسمی WordPress تأکید می‌کنند مسئولیت امنیت محتوای Plugin با Developer است و در صورت پیدا شدن مشکل امنیتی، Plugin می‌تواند تا زمان رفع مسئله از Directory بسته شود؛ در شرایط خاص نیز WordPress Security Team می‌تواند برای حفاظت کاربران مداخله کند.

بنابراین:

Official Repository = کاهش Risk

اما:

Official Repository ≠ صفر شدن Risk

مدیر سایت همچنان باید Componentها را مدیریت و پایش کند.

Plugin Nulled چرا ریسک زنجیره تأمین بالایی دارد؟

نسخه Nulled معمولاً یک Package تغییرکرده است.

شما دیگر فایل Original Vendor را نصب نمی‌کنید.

یک واسطه ناشناس Package را تغییر داده است.

این تغییر ممکن است صرفاً برای حذف Licensing باشد، اما شما راه مطمئنی برای اثبات اینکه فقط همین تغییر انجام شده ندارید.

ممکن است Code دیگری نیز اضافه شده باشد.

از دید Supply Chain:

Vendor ↓ Unknown Modifier ↓ You

یک حلقه غیرقابل اعتماد وارد زنجیره شده است.

برای سایت Production، مخصوصاً:

WooCommerce

Membership

LMS

سایت شرکتی

و سایت دارای اطلاعات کاربران

این Risk منطقی نیست.

خطر دوم: Theme آلوده

Theme نیز می‌تواند Code PHP و JavaScript اجرا کند.

بنابراین تصور اینکه:

«قالب فقط ظاهر سایت است.»

اشتباه است.

یک Theme می‌تواند:

Functionهای PHP داشته باشد.

AJAX Handler تعریف کند.

Library خارجی Load کند.

فایل ایجاد کند.

Query اجرا کند.

Request خارجی ارسال کند.

به همین دلیل Themeهای ناشناس یا Nulled نیز از نظر Supply Chain همان ریسک Pluginها را دارند.

خطر سوم: کتابخانه‌های PHP

توسعه‌دهندگان WordPress و PHP معمولاً از Libraryهای آماده استفاده می‌کنند.

برای مثال یک Plugin ممکن است برای:

HTTP Client

JWT

PDF Generation

Logging

Email

Parsing

از Library خارجی استفاده کند.

مزیت این کار واضح است:

نیازی نیست هر قابلیت از صفر نوشته شود.

اما در مقابل Dependency Risk ایجاد می‌شود.

اگر Library دارای Vulnerability باشد یا Maintainer آن Compromise شود، Application مصرف‌کننده نیز ممکن است تحت تأثیر قرار گیرد.

Composer و Dependencyهای PHP

Composer استاندارد رایج مدیریت Dependency در PHP است.

فایل:

composer.json

Dependencyهای موردنیاز Project را تعریف می‌کند.

و:

composer.lock

Versionهای دقیق Resolve‌شده را ثبت می‌کند.

مستندات رسمی Composer توصیه می‌کنند در Applicationها composer.lock داخل Version Control نگهداری شود تا Developer، CI و Production همگی Dependencyهای یکسانی دریافت کنند. این موضوع باعث Reproducibility بیشتر Build می‌شود.

چرا Lock File اهمیت دارد؟

فرض کنید Code خود سایت هیچ تغییری نکرده است.

اما هنگام Deploy جدید، Package Manager آخرین نسخه مجاز Dependency را دانلود کند.

اگر Dependency در این فاصله تغییر کرده باشد، Production شما دیگر دقیقاً همان مجموعه‌ای نیست که قبلاً Test کرده‌اید.

Lock File کمک می‌کند Version واقعی Dependencyها قابل کنترل و تکرار باشد.

اما نکته مهم:

Lock کردن نسخه به معنی امن بودن همیشگی آن نیست.

اگر نسخه Lockشده بعداً دارای CVE شود، باید Update شود.

پس دو نیاز داریم:

Reproducibility

و

Vulnerability Management

خطر چهارم: npm و JavaScript Dependencyها

Frontend مدرن می‌تواند صدها Package داشته باشد.

گاهی Developer فقط چند Dependency مستقیم تعریف کرده، اما Package Manager تعداد زیادی Transitive Dependency نصب می‌کند.

این یعنی:

Application ↓ Package A ↓ Package B ↓ Package C ↓ Package D

شما شاید Package D را هرگز به‌صورت مستقیم انتخاب نکرده باشید، اما Code آن وارد Build شما شده است.

OWASP تأکید می‌کند Dependency Inventory باید فقط Dependencyهای مستقیم را پوشش ندهد و Transitive Dependencyها نیز باید ردیابی شوند.

package-lock.json چه کمکی می‌کند؟

در npm، فایل:

package-lock.json

درخت دقیق Dependency نصب‌شده را ثبت می‌کند.

مستندات npm توضیح می‌دهند Lock File با هدف تولید یک Dependency Tree مشخص و قابل تکرار ایجاد می‌شود تا Development، CI و Deployment نسخه‌های یکسانی نصب کنند. همچنین metadata مربوط به Integrity Packageها نیز در Lock File نگهداری می‌شود.

بنابراین حذف بی‌دلیل Lock File یا تولید مداوم آن بدون Review می‌تواند کنترل تغییرات Dependency را ضعیف کند.

Transitive Dependency چیست؟

Dependency مستقیم یعنی Packageای که خود Developer انتخاب کرده است.

مثلاً:

Project → A

اما A خودش ممکن است به B نیاز داشته باشد:

Project → A → B

B یک:

Transitive Dependency

است.

در Projectهای بزرگ این زنجیره ممکن است چندین سطح ادامه پیدا کند.

مشکل این است که Developer معمولاً شناخت مستقیمی از همه Packageهای پایین زنجیره ندارد.

به همین دلیل SBOM و Software Composition Analysis اهمیت پیدا می‌کنند.

خطر پنجم: Dependency Confusion

Dependency Confusion یک کلاس حمله Supply Chain است که از نحوه Resolve شدن Packageها میان Repositoryهای داخلی و عمومی سوءاستفاده می‌کند.

در یک معماری سازمانی ممکن است Packageهایی با نام داخلی وجود داشته باشند.

اگر Configuration Package Manager به شکلی باشد که منبع عمومی را به‌اشتباه برای Package مشابه ترجیح دهد، Component ناخواسته می‌تواند وارد Build شود.

تمرکز دفاعی باید بر این موارد باشد:

• Namespace Management
• Registry Configuration
• Private Repository Policy
• Version Control
• Package Source Validation
• Lock File
• CI Security

هدف این مقاله آموزش اجرای Dependency Confusion نیست؛ نکته مهم برای تیم توسعه این است که منبع هر Dependency باید Explicit و قابل اعتماد باشد.

خطر ششم: Typosquatting در Packageها

Typosquatting زمانی است که Package مخربی با نامی بسیار شبیه Package معتبر منتشر می‌شود.

مثلاً Developer به دلیل یک اشتباه تایپی ممکن است Package متفاوتی را نصب کند.

دفاع مناسب:

نام Package را Copy/Paste کنید.

Publisher را بررسی کنید.

Repository را بررسی کنید.

تاریخچه Project را ببینید.

Package ناشناس را صرفاً بر اساس نام نصب نکنید.

این مسئله در محیط‌های Package-Based به‌خصوص برای Developer Workstation مهم است.

خطر هفتم: حساب Maintainer تصاحب می‌شود

ممکن است خود Source Code اصلی سالم باشد، اما Credential انتشار Package سرقت شود.

Attacker در این حالت می‌تواند خودش را به‌عنوان Maintainer معتبر معرفی کند.

ریسک بالاتر است اگر:

Password ضعیف باشد.

MFA وجود نداشته باشد.

Token طولانی‌عمر باشد.

Credential در Repository قرار گرفته باشد.

Account بین چند نفر Share شده باشد.

OWASP برای اجزای زنجیره تأمین مانند Code Repository، Developer Workstation و Build System روی MFA، Least Privilege، Access Control و محافظت از Secretها تأکید می‌کند.

خطر هشتم: CI/CD آلوده

CI/CD یکی از حساس‌ترین بخش‌های زنجیره است.

چرا؟

چون Pipeline معمولاً می‌تواند:

Code را دریافت کند.

Dependency نصب کند.

Build ایجاد کند.

Secret بخواند.

Artifact تولید کند.

Production را Deploy کند.

اگر Attacker کنترل Pipeline را بگیرد، ممکن است حتی بدون تغییر آشکار Source Repository روی Artifact نهایی اثر بگذارد.

به همین دلیل Security CI/CD نباید ضعیف‌تر از Application باشد.

موارد مهم:

• MFA
• Least Privilege
• Branch Protection
• Secret Management
• Signed Artifacts
• Immutable Build
• Audit Log
• Separation of Duties

OWASP صریحاً هشدار می‌دهد CI/CD پیچیده و ضعیف می‌تواند یکی از عوامل Supply Chain Failure باشد.

Build Artifact چیست؟

Artifact خروجی نهایی فرآیند Build است.

مثلاً:

Plugin ZIP

JavaScript Bundle

Docker Image

Binary

Release Package

یک الگوی امن این است که همان Artifactی که Test شده وارد Production شود.

نه اینکه:

Development Build ↓ Test

و سپس:

Production ↓ Build مجدد از اینترنت

انجام شود.

چون Build دوم ممکن است Dependencyهای متفاوتی دریافت کند.

OWASP نیز توصیه می‌کند Artifactها قابل ردیابی، دارای Provenance و در صورت امکان Signed باشند و همان Artifact میان Environmentها Promote شود.

خطر نهم: CDN و JavaScript خارجی

فرض کنید سایت مستقیماً Script زیر را از یک Domain خارجی Load می‌کند:

third-party.example/script.js

Browser هر بار JavaScript را از Server خارجی دریافت می‌کند.

اگر آن Server Compromise شود، Script تغییرکرده ممکن است در Context سایت شما اجرا شود.

MDN این سناریو را صریحاً یک Supply Chain Risk معرفی می‌کند و توضیح می‌دهد JavaScript Third-Party می‌تواند در صورت دستکاری Host خارجی برای سایت مصرف‌کننده خطر ایجاد کند.

این موضوع برای:

Analytics

Chat Widget

Ad Script

UI Library

Payment Script

CDN JavaScript

اهمیت زیادی دارد.

Subresource Integrity یا SRI چیست؟

Subresource Integrity یکی از مکانیزم‌های مفید Browser برای محافظت از Script و Stylesheet خارجی است.

با SRI، Developer Hash مورد انتظار فایل را تعریف می‌کند.

Browser فایل را دانلود می‌کند.

سپس Hash آن را بررسی می‌کند.

اگر فایل با نسخه‌ای که Developer انتظار دارد تطابق نداشته باشد، Browser آن را Load نمی‌کند.

MDN توضیح می‌دهد SRI برای <script> و برخی <link>ها قابل استفاده است و دقیقاً برای سناریوهایی مانند تغییر غیرمنتظره فایل روی CDN یک لایه دفاعی ایجاد می‌کند.

SRI چه چیزی را حل نمی‌کند؟

SRI زمانی مفید است که محتوای Resource باید ثابت باشد.

اگر Script به‌صورت دائمی و Dynamic تغییر می‌کند، مدیریت Hash پیچیده‌تر خواهد شد.

همچنین SRI جایگزین بررسی Supplier نیست.

اما برای Libraryهای Static روی CDN می‌تواند Defense in Depth ارزشمندی ایجاد کند.

خطر دهم: Third-Party Script بدون کنترل

گاهی تعداد Scriptهای Third-Party سایت به مرور افزایش پیدا می‌کند.

مثلاً:

Analytics A

Analytics B

Live Chat

Heatmap

Marketing Pixel

Popup Tool

A/B Testing

هر Script اضافی بخشی از Trust Boundary سایت می‌شود.

یک اصل مهم:

هر Script خارجی که در صفحه اجرا می‌کنید، بخشی از Software Supply Chain شماست.

بنابراین باید Periodically Review شود.

آیا هنوز لازم است؟

چه Dataای می‌بیند؟

از کدام Domain Load می‌شود؟

چه کسی Vendor است؟

آخرین بار چه زمانی Review شده؟

تفاوت Dependency آسیب‌پذیر و Dependency آلوده

این دو موضوع مشابه‌اند اما یکسان نیستند.

Vulnerable Dependency

Developer Component را با نیت سالم ساخته است.

اما Bug امنیتی دارد.

مثلاً:

Input Validation ضعیف

RCE

XSS

Authentication Bypass

Malicious Dependency

Code عمداً برای رفتار مخرب تغییر داده شده است.

برای مثال ممکن است هدف آن:

سرقت Secret

ایجاد Backdoor

Exfiltration

یا اجرای رفتار غیرمجاز

باشد.

از دید Defender هر دو Risk هستند.

اما Incident Response آن‌ها می‌تواند متفاوت باشد.

در Vulnerable Component شاید Update کافی باشد.

در Component مخرب باید Scope Compromise، Secret Exposure و Integrity کل Environment بررسی شود.

افزونه آلوده چه خطرهایی برای WordPress دارد؟

اگر Plugin مخرب با Privilege عادی WordPress اجرا شود، بسته به Code و Permission محیط می‌تواند به بخش‌های مختلف دسترسی پیدا کند.

پیامدهای احتمالی:

• تغییر فایل
• تغییر Database
• ایجاد User
• سرقت Credential
• ایجاد Request خارجی
• تغییر محتوا
• دسترسی به اطلاعات مشتری
• افزودن Code مخرب
• ایجاد Persistence

این موارد به معنای آن نیست که هر Plugin چنین دسترسی‌هایی دارد، بلکه نشان می‌دهد Third-Party Code در CMS باید به‌عنوان Software واقعی و حساس مدیریت شود.

چرا WooCommerce حساس‌تر است؟

در سایت WooCommerce، Third-Party Component ممکن است در محیطی اجرا شود که با:

Customer Data

Order

Billing Information

Coupon

Payment Flow

Email

Administrator Panel

در ارتباط است.

افزونه‌های WooCommerce معمولاً Integrationهای بیشتری نیز دارند.

برای مثال:

درگاه پرداخت

SMS

Accounting

Shipping

CRM

بنابراین Supply Chain یک فروشگاه می‌تواند بسیار بزرگ‌تر از چیزی باشد که مدیر سایت در نگاه اول تصور می‌کند.

Plugin زیاد یعنی ریسک بیشتر؟

تعداد Plugin به‌تنهایی معیار Security نیست.

یک سایت با ۳۰ Plugin سالم و مدیریت‌شده ممکن است امن‌تر از سایتی با ۵ Plugin ناشناس باشد.

اما هر Component جدید موارد زیر را افزایش می‌دهد:

• Code Base
• Dependency
• Update
• Vendor
• Attack Surface
• Monitoring Requirement

بنابراین اصل مناسب این است:

حداقل Component لازم.

Plugin فقط به این دلیل که «شاید روزی لازم شود» نباید روی Production باقی بماند.

Plugin غیرفعال چطور؟

غیرفعال بودن Plugin به معنی حذف فایل‌های آن نیست.

بسته به نوع آسیب‌پذیری، صرف Deactivate بودن همیشه به معنای حذف کامل Risk نیست.

اگر Plugin واقعاً استفاده نمی‌شود، بهترین راه معمولاً:

Backup در صورت نیاز ↓ Delete

است.

مستندات WordPress نیز روی کاهش Componentهای غیرضروری و رعایت اصول امنیت Plugin تأکید دارند. WordPress Developer Documentation به‌طور مشخص Plugin و Theme را از نقاطی می‌داند که خارج از Core می‌توانند ضعف ایجاد کنند.

Plugin بدون Update چه خطری دارد؟

عدم Update همیشه به معنی Vulnerable بودن نیست.

اما Projectی که مدت طولانی Maintainer فعال ندارد Risk بیشتری دارد.

مسائل ممکن:

• Bugهای جدید رفع نشوند.
• ناسازگاری PHP ایجاد شود.
• Vulnerability Patch نشود.
• Dependencyهای داخلی قدیمی بمانند.
• Contact Security وجود نداشته باشد.

OWASP استفاده از Third-Party Component بدون Maintainer را یکی از CWEهای مرتبط با Supply Chain Failures معرفی می‌کند.

قبل از نصب افزونه چه چیزهایی را بررسی کنیم؟

مدیر سایت بهتر است قبل از افزودن Component جدید این موارد را بررسی کند:

منبع

آیا Plugin از Source اصلی آمده است؟

توسعه‌دهنده

آیا Developer شناخته‌شده و قابل پیگیری است؟

Update

آیا پروژه هنوز Maintained است؟

Security History

آیا Vendor هنگام Vulnerability پاسخگو بوده است؟

نیاز واقعی

آیا قابلیت Plugin واقعاً لازم است؟

Permission

Plugin چه دسترسی یا Integrationهایی ایجاد می‌کند؟

Dependency

آیا کتابخانه‌های زیادی همراه خود دارد؟

این بررسی ساده می‌تواند زنجیره تأمین سایت را تا حد زیادی کوچک‌تر و قابل مدیریت‌تر کند.

Auto Update؛ خوب یا بد؟

پاسخ مطلق ندارد.

Update سریع از نظر Patch Management بسیار مهم است.

اما Supply Chain Attack نشان می‌دهد Update نیز باید بخشی از Trust Model باشد.

برای سایت کوچک ممکن است Auto Update افزونه‌های شناخته‌شده انتخاب عملی و امنی باشد.

برای یک سیستم بسیار حساس ممکن است مدل مناسب‌تر چنین باشد:

Update دریافت شود. ↓ Staging ↓ Security/Compatibility Test ↓ Deploy مرحله‌ای

OWASP نیز توصیه می‌کند Updateها در سیستم‌های حساس Staged Rollout داشته باشند و همه Systemها به‌طور هم‌زمان Update نشوند تا در صورت Compromise شدن Vendor، Exposure محدودتر باشد.

پس:

Update نکردن خطرناک است.

Update بدون کنترل نیز می‌تواند Risk داشته باشد.

راهکار درست:

Risk-Based Update Management

است.

چرا Rollback مهم است؟

اگر Update جدید رفتار مشکوکی ایجاد کرد، باید امکان بازگشت سریع وجود داشته باشد.

Rollback Plan شامل:

Backup

نسخه قبلی Artifact

Database Backup

Deployment History

Recovery Procedure

است.

بدون Rollback، تیم ممکن است مجبور شود Component مشکوک را برای مدت بیشتری روی Production نگه دارد.

Software Bill of Materials یا SBOM چیست؟

SBOM را می‌توان به‌طور ساده «فهرست مواد اولیه نرم‌افزار» دانست.

همان‌طور که روی یک محصول غذایی Ingredient List وجود دارد، SBOM نشان می‌دهد نرم‌افزار از چه Componentهایی تشکیل شده است.

مثلاً:

Application ├── Library A 2.1 ├── Library B 4.5 │ └── Library C 1.2 └── Framework D 7.0

CISA، NIST و OWASP از SBOM به‌عنوان یکی از ابزارهای مهم Visibility در زنجیره تأمین نرم‌افزار استفاده می‌کنند. CISA در راهنمای Minimum Elements سال 2025 تأکید می‌کند SBOM باید Componentهای نرم‌افزار از جمله Transitive Dependencyها را پوشش دهد و برای Version یا Releaseهای جدید نیز به‌روز شود.

SBOM چه مشکلی را حل می‌کند؟

فرض کنید خبر منتشر شود:

Library X نسخه 3.1 دارای Vulnerability جدی است.

اولین سؤال:

«آیا ما از Library X استفاده می‌کنیم؟»

اگر Dependency Inventory ندارید، پاسخ دادن ممکن است ساعت‌ها یا روزها طول بکشد.

ممکن است Library X مستقیم نصب نشده باشد و داخل Plugin دیگری قرار داشته باشد.

SBOM Visibility ایجاد می‌کند.

بدون Visibility نمی‌توان Risk را سریع مدیریت کرد.

آیا SBOM خودش امنیت ایجاد می‌کند؟

خیر.

SBOM فقط Inventory است.

داشتن فهرست Componentها به‌تنهایی Vulnerability را Patch نمی‌کند.

مدل واقعی:

SBOM + Vulnerability Monitoring + Risk Assessment + Patch Management + Incident Response

است.

SBOM باید Operational باشد، نه صرفاً یک فایل که برای Compliance تولید شده و فراموش شود.

Software Composition Analysis یا SCA چیست؟

SCA ابزار یا فرآیندی برای تحلیل Dependencyهای نرم‌افزار است.

هدف معمولاً:

شناسایی Component

Version

License

Vulnerability شناخته‌شده

Dependency Tree

است.

OWASP برای Inventory و Vulnerability Monitoring ابزارها و فرآیندهای Software Composition Analysis و SBOM-Based Monitoring را توصیه می‌کند.

SCA برای سایت‌های Custom Development بسیار مهم است.

آیا Scanner می‌تواند Component مخرب جدید را پیدا کند؟

نه همیشه.

اگر Package جدید هنوز Signature یا CVE شناخته‌شده نداشته باشد، Scanner مبتنی بر Database ممکن است آن را سالم گزارش کند.

Supply Chain Security فقط Vulnerability Scanning نیست.

کنترل‌های مکمل:

• Source Trust
• Code Review
• Provenance
• Signing
• Change Review
• Runtime Monitoring
• Behavioral Detection

لازم‌اند.

Code Signing چیست؟

Code Signing یعنی Release یا Artifact با یک Key دیجیتال Sign شود تا Consumer بتواند Publisher و Integrity آن را بررسی کند.

هدف:

«آیا این فایل همان چیزی است که Publisher مورد انتظار منتشر کرده؟»

اما Signing نیز Limit دارد.

اگر Signing Key سرقت شود، Attacker ممکن است Artifact مخرب را Sign کند.

بنابراین Key Management خود بخشی از Supply Chain Security است.

Hash چه کمکی می‌کند؟

Hash می‌تواند نشان دهد File تغییر کرده یا نه.

اگر Vendor Hash رسمی Package را منتشر کند، دریافت‌کننده می‌تواند Integrity Download را بررسی کند.

اما Hash زمانی قابل اعتماد است که Reference Hash نیز از مسیر معتبر دریافت شود.

اگر:

Package

و

Hash

هر دو از یک Infrastructure Compromiseشده بیایند، ارزش کنترل کاهش پیدا می‌کند.

پس Integrity Verification باید بخشی از Trust Chain بزرگ‌تر باشد.

Provenance چیست؟

Software Provenance اطلاعاتی درباره منشأ Artifact می‌دهد.

برای مثال:

کد از کدام Repository آمده؟

با چه Build Processی ساخته شده؟

چه Commitی مبنا بوده؟

چه CI Jobی آن را ایجاد کرده؟

چه کسی Release را تأیید کرده؟

Provenance کمک می‌کند سازمان فقط به نام فایل اعتماد نکند.

این موضوع در Supply Chainهای سازمانی و CI/CD اهمیت زیادی دارد.

امنیت Repository کد

Repository قلب بسیاری از پروژه‌هاست.

کنترل‌های مهم:

• MFA
• Branch Protection
• Review
• Least Privilege
• Audit Log
• Secret Scanning
• Backup
• Protected Release Process

یک Developer معمولی نباید لزوماً بتواند بدون Review مستقیم روی Production Release اثر بگذارد.

OWASP روی Separation of Duties نیز تأکید دارد: ideally یک نفر نباید بتواند Code را بنویسد و بدون نظارت آن را تا Production Promote کند.

چرا Secret داخل Repository خطرناک است؟

Repository ممکن است:

Clone شود.

Fork شود.

Backup شود.

در CI Cache باقی بماند.

در History باشد.

اگر API Key یا Token داخل Code Commit شود، حذف فایل در Commit بعدی الزاماً Secret قبلی را از History پاک نمی‌کند.

Secret باید از Code جدا و قابل Rotation باشد.

اگر احتمال Exposure وجود دارد:

اول Rotate

سپس Cleanup

Developer Workstation هم بخشی از Supply Chain است

این بخش معمولاً فراموش می‌شود.

اگر Laptop توسعه‌دهنده Compromise شود، مهاجم ممکن است به:

Git Credential

Package Token

SSH Key

Cloud Access

Build Secret

Repository

دسترسی پیدا کند.

در نتیجه Endpoint Security توسعه‌دهنده مستقیماً با امنیت Production ارتباط دارد.

OWASP Developer Workstation را صریحاً یکی از اجزایی می‌داند که باید Patch، Monitor و با MFA محافظت شود.

NIST درباره Supply Chain Security چه می‌گوید؟

NIST در SP 800-161 Rev.1، Cybersecurity Supply Chain Risk Management یا C-SCRM را یک فرآیند سازمانی برای شناسایی، ارزیابی و کاهش Riskهای محصولات و خدمات در کل Supply Chain می‌داند.

یکی از مشکلات اصلی که NIST مطرح می‌کند، کاهش Visibility سازمان درباره نحوه توسعه، Integration و Deployment فناوری‌هایی است که از Supplier دریافت می‌کند.

این دقیقاً مشکل سایت‌های مدرن نیز هست:

شما شاید Plugin را می‌شناسید.

اما تمام Libraryهای درون Plugin را نمی‌شناسید.

و تمام Supplierهای آن Libraryها را نیز نمی‌شناسید.

NIST SSDF چیست؟

Secure Software Development Framework یا SSDF مجموعه‌ای از Practiceهای سطح بالا برای افزودن Security به SDLC است.

NIST توضیح می‌دهد هدف SSDF کاهش تعداد Vulnerabilityهای Software، کاهش Impact ضعف‌های کشف‌نشده و کمک به رفع Root Cause مشکلات امنیتی است.

برای تیم توسعه سایت، SSDF کمک می‌کند Security فقط در مرحله آخر Testing نباشد.

Security از:

انتخاب Dependency

تا:

Build

Release

Update

Maintenance

در نظر گرفته شود.

معماری دفاعی پیشنهادی برای Supply Chain سایت

می‌توان دفاع را در چند لایه طراحی کرد.

لایه اول: کاهش Dependency

هر Component غیرضروری حذف شود.

کمترین:

Plugin

Theme

Library

External Script

استفاده شود.

لایه دوم: Trust

Component فقط از Source رسمی و شناخته‌شده دریافت شود.

لایه سوم: Inventory

تمام Dependencyهای مستقیم و Transitive ثبت شوند.

لایه چهارم: Integrity

Hash، Signature، Lock File، SRI و Provenance بررسی شوند.

لایه پنجم: Update

Security Advisory و CVEها Monitor شوند.

لایه ششم: Build Security

Repository و CI/CD با MFA، Access Control و Audit محافظت شوند.

لایه هفتم: Deployment

Update ابتدا Test و سپس Stage شود.

لایه هشتم: Monitoring

تغییر فایل، Network Behavior و Logها پایش شوند.

این مدل Defense in Depth است.

چک‌لیست Supply Chain Security برای مدیر WordPress

برای یک سایت WordPress بهتر است به‌صورت دوره‌ای این موارد بررسی شوند:

• Plugin فقط از Source معتبر نصب شود.
• Plugin و Theme Nulled استفاده نشود.
• Pluginهای بلااستفاده حذف شوند.
• Themeهای بلااستفاده حذف شوند.
• تعداد Administratorها محدود باشد.
• 2FA برای مدیران فعال باشد.
• Updateهای امنیتی عقب نیفتند.
• Plugin بدون Maintainer بررسی و در صورت لزوم جایگزین شود.
• Backup قبل از Update مهم وجود داشته باشد.
• Staging برای Updateهای حساس استفاده شود.
• File Integrity Monitoring در سایت مهم بررسی شود.
• JavaScriptهای Third-Party Inventory شوند.
• Integrationهای قدیمی حذف شوند.
• Vendor Plugin Premium معتبر باشد.
• License Account با MFA محافظت شود.
• Backup مستقل از Hosting وجود داشته باشد.

چک‌لیست توسعه‌دهنده PHP و WordPress

برای Projectهای اختصاصی:

• composer.lock داخل Repository باشد.
• Dependency Source مشخص باشد.
• Updateها Review شوند.
• Dependencyهای بلااستفاده حذف شوند.
• Vulnerability Monitoring فعال باشد.
• Packageهای Abandoned شناسایی شوند.
• Version تغییرکرده بدون Test Deploy نشود.
• CI/CD Credential حداقل دسترسی داشته باشد.
• Build Environment محافظت شود.
• Artifact قابل تکرار باشد.
• SBOM تولید شود.
• Secret داخل Repository نباشد.
• Release Process Review داشته باشد.
• Source Third-Party بررسی شود.

چک‌لیست Frontend و JavaScript

اگر سایت از npm یا Scriptهای External استفاده می‌کند:

• package-lock.json یا Lock File مربوطه نگهداری شود.
• Dependencyهای Transitive Inventory شوند.
• Package ناشناس نصب نشود.
• Package Name و Publisher قبل از نصب بررسی شوند.
• Third-Party Scriptها حداقل باشند.
• SRI برای Script و CSS Static خارجی بررسی شود.
• CDN فقط HTTPS باشد.
• External Domainها داخل CSP محدود شوند.
• Update Library قبل از Production Test شود.
• npm Token و Registry Credential محافظت شوند.
• CI دارای Least Privilege باشد.

اشتباهات رایج در امنیت Supply Chain

«Plugin معروف است، پس هر Update آن 100٪ امن است»

شهرت Risk را کاهش می‌دهد اما صفر نمی‌کند.

Supplier معتبر نیز ممکن است Compromise شود.

«فقط Pluginهای WordPress مهم‌اند»

نه.

npm، Composer، CDN، CI/CD، Cloud Integration و Developer Tool نیز بخشی از Chain هستند.

«اگر Antivirus چیزی پیدا نکرد، Package سالم است»

Malware Detection فقط یک کنترل است.

Supply Chain نیازمند Trust و Integrity Verification نیز هست.

«Version را Lock کردیم، پس دیگر Update نمی‌کنیم»

Lock File برای Reproducibility است، نه فرار از Patch Management.

«هر Update را بلافاصله روی Production نصب می‌کنیم»

برای سایت بسیار حساس Staging و Rollout مرحله‌ای می‌تواند Risk را کاهش دهد.

«SBOM داریم، پس امن هستیم»

SBOM فقط Visibility ایجاد می‌کند.

«Plugin غیرفعال مشکلی ندارد»

Component غیرضروری بهتر است حذف شود.

«Nulled فقط License Check را حذف کرده»

بدون Source و Build قابل اعتماد چنین فرضی قابل اثبات نیست.

چگونه Plugin مشکوک را بررسی کنیم؟

اگر Plugin یا Updateی مشکوک است:

اول روی Production آزمایش تجربی انجام ندهید.

روش دفاعی:

منبع را بررسی کنید

فایل از کجا آمده است؟

Vendor Advisory را بررسی کنید

آیا Vendor Incident اعلام کرده؟

فایل‌ها را مقایسه کنید

آیا تغییرات غیرمنتظره وجود دارد؟

Log را بررسی کنید

آیا رفتار جدیدی بعد از Update شروع شده؟

Network Connection را بررسی کنید

آیا Plugin به Destination جدیدی متصل شده؟

Staging استفاده کنید

Analysis را در محیط ایزوله انجام دهید.

برای Analysis عمیق‌تر بهتر است از متخصص Incident Response کمک گرفته شود.

نشانه‌های احتمالی Supply Chain Compromise

هیچ نشانه واحدی اثبات حمله نیست، اما موارد زیر نیازمند بررسی‌اند:

• فایل جدید پس از Update
• Administrator ناشناس
• Request خارجی غیرمنتظره
• تغییر ناگهانی JavaScript
• افزایش Spam
• Redirect مشکوک
• تغییر Cron
• تغییر Plugin بدون Change Record
• Secret Exposure
• رفتار متفاوت پس از Dependency Update
• Integrity Alert
• Vendor Security Notice

Correlation میان زمان Update و شروع Incident اهمیت زیادی دارد.

اگر افزونه آلوده نصب شده باشد چه کنیم؟

تنها Disable کردن Plugin ممکن است کافی نباشد.

فرآیند Incident Response باید بررسی کند آیا Component توانسته تغییر دیگری در سیستم ایجاد کند یا خیر.

مرحله اول: Containment

دسترسی Component متوقف شود.

مرحله دوم: Evidence

Log و Timeline حفظ شود.

مرحله سوم: Scope

بررسی شود چه فایل، User، Database و Secretهایی تحت تأثیر بوده‌اند.

مرحله چهارم: Credential Rotation

اگر احتمال Exposure وجود دارد:

• Admin Password
• API Key
• Database Credential
• Hosting Credential
• SSH Key

بر اساس Risk Rotate شوند.

مرحله پنجم: Clean Restore

در Incident جدی ممکن است Restore از Backup سالم مطمئن‌تر از پاک‌کردن دستی چند فایل باشد.

مرحله ششم: Root Cause

مشخص شود Component چگونه وارد Chain شده است.

مرحله هفتم: Prevention

Policy اصلاح شود تا مسیر تکرار نشود.

چرا فقط حذف Malware کافی نیست؟

فرض کنید Plugin مخرب Admin جدید ساخته باشد.

شما فایل Plugin را حذف می‌کنید.

اما Admin همچنان وجود دارد.

یا:

API Key سرقت شده است.

حتی بعد از حذف Plugin، Key قبلی هنوز معتبر است.

به همین دلیل Supply Chain Incident را باید Compromise احتمالی کل Trust Boundary در نظر گرفت، نه فقط یک فایل خراب.

Backup و Supply Chain

Backup یکی از مهم‌ترین ابزارهای Recovery است.

اما Backup باید:

قبل از Compromise

و

سالم

باشد.

اگر برای سه ماه Plugin مخرب در سایت وجود داشته، آخرین Backup دیروز نیز ممکن است آلوده باشد.

به همین دلیل Retention چندنسخه‌ای اهمیت دارد.

برای سایت حساس بهتر است Backup:

• خارج از Hosting اصلی
• با Retention مناسب
• با Access Control
• تست‌شده

باشد.

File Integrity Monitoring چه کمکی می‌کند؟

File Integrity Monitoring یا FIM تغییر Fileها را ثبت می‌کند.

اگر Plugin Update طبق انتظار فقط ده فایل را تغییر دهد اما فایل‌های دیگری نیز خارج از Directory خودش تغییر کنند، Alert می‌تواند ارزشمند باشد.

اما FIM نیز باید Baseline داشته باشد.

در WordPress Updateهای عادی Fileهای زیادی را تغییر می‌دهند، بنابراین Monitoring بدون Context می‌تواند Noise تولید کند.

آیا WAF جلوی Supply Chain Attack را می‌گیرد؟

معمولاً نه به‌تنهایی.

WAF Requestهای ورودی Web را کنترل می‌کند.

اما Supply Chain Code ممکن است از قبل روی Server باشد.

با این حال WAF می‌تواند بعضی رفتارهای ثانویه حمله را محدود کند.

پس:

WAF = Defense in Depth

نه:

Supply Chain Protection کامل

Least Privilege چگونه خسارت را کم می‌کند؟

اگر Plugin فقط همان Permission لازم را داشته باشد، Blast Radius کاهش می‌یابد.

در معماری WordPress سنتی جداسازی Permission Pluginها آسان نیست، اما در لایه Infrastructure هنوز می‌توان:

Database Privilege را محدود کرد.

Filesystem Permission را سخت‌گیرانه تنظیم کرد.

Container Isolation داشت.

Outbound Network را در سیستم حساس محدود کرد.

Secretها را Scope کرد.

اصل Least Privilege در تمام زنجیره باید اعمال شود.

Outbound Network Monitoring چرا مهم است؟

بسیاری از تیم‌ها فقط Inbound Traffic را Monitor می‌کنند.

اما Component مخرب ممکن است بخواهد داده‌ای را به بیرون ارسال کند.

برای Server حساس، بررسی:

DNS

Outbound HTTP

Destination جدید

Volume غیرعادی

می‌تواند در Detection مفید باشد.

به‌خصوص اگر Application معمولاً فقط با چند API مشخص ارتباط دارد.

آیا Self-Hosting Library بهتر است؟

گاهی Self-Hosting External JavaScript Dependency باعث می‌شود Control بیشتری داشته باشید.

اما مسئولیت Update نیز بر عهده شما می‌آید.

CDN معتبر می‌تواند Performance و Availability خوبی داشته باشد.

Self-Hosted بودن به خودی خود Secure نیست.

تصمیم باید بر اساس:

Integrity

Update

Performance

Availability

Threat Model

گرفته شود.

اگر از Third-Party Static CDN استفاده می‌کنید، SRI می‌تواند لایه حفاظتی مهمی باشد.

آیا Open Source خطرناک‌تر است؟

نه به‌طور ذاتی.

Open Source و Closed Source هر دو Supply Chain Risk دارند.

Open Source می‌تواند مزایایی مانند:

شفافیت Code

Community Review

Visibility

داشته باشد.

اما Project بدون Maintainer یا Package ناشناس Risk ایجاد می‌کند.

Closed Source نیز ممکن است Build Process و Dependencyهای غیرقابل مشاهده داشته باشد.

عامل مهم‌تر:

Supply Chain Governance

است.

چگونه Vendor را ارزیابی کنیم؟

برای Component مهم سازمانی می‌توان پرسید:

آیا Security Contact دارد؟

آیا Vulnerability Disclosure Process دارد؟

آیا Update منظم منتشر می‌کند؟

آیا Release Note شفاف دارد؟

آیا MFA برای Publisherها دارد؟

آیا SBOM ارائه می‌کند؟

آیا Software Signing دارد؟

آیا Incidentها را شفاف اعلام می‌کند؟

آیا Product هنوز Maintained است؟

CISA نیز در راهنمای Supply Chain توصیه می‌کند Componentهای Third-Party پیش از Integration ارزیابی شوند و تا حد امکان از Supplier شناخته‌شده و قابل اعتماد تهیه شوند.

Supply Chain Security برای سایت کوچک

ممکن است تصور شود SBOM و Supply Chain فقط برای شرکت‌های Enterprise هستند.

اما حتی مدیر یک WordPress کوچک می‌تواند نسخه ساده‌ای از این اصول را اجرا کند:

یک Spreadsheet داشته باشید.

نام Pluginها را ثبت کنید.

Vendor را ثبت کنید.

Version را ثبت کنید.

Premium Account را مشخص کنید.

تاریخ آخرین Update را ثبت کنید.

Plugin بلااستفاده را حذف کنید.

برای سایت کوچک لازم نیست فرآیند پیچیده Enterprise بسازید.

مهم Visibility است.

Supply Chain Security برای تیم حرفه‌ای

در سازمان بزرگ‌تر می‌توان ساختار پیشرفته‌تری داشت:

• Automated SBOM
• SCA
• Dependency Policy
• Private Registry
• Artifact Repository
• Signed Build
• Provenance
• CI/CD Hardening
• Canary Deployment
• Automated Vulnerability Alerts
• Vendor Risk Management

سطح کنترل باید با Risk Application متناسب باشد.

جدول ریسک اجزای زنجیره تأمین سایت

چک‌لیست نهایی جلوگیری از Supply Chain Attack

قبل از نصب هر Component:

منبع را بررسی کنید.

بعد از نصب:

Inventory داشته باشید.

در طول عمر Component:

Security Advisory را Monitor کنید.

هنگام Update:

Change را Test کنید.

برای Deployment:

Artifact کنترل‌شده استفاده کنید.

برای Dependency:

Lock File و SCA داشته باشید.

برای Third-Party Script:

SRI را بررسی کنید.

برای Developer:

MFA فعال کنید.

برای Incident:

Rollback و Backup داشته باشید.

و مهم‌تر از همه:

هر Component غیرضروری را از Chain حذف کنید.

سؤالات متداول درباره حمله Supply Chain

حمله Supply Chain چیست؟

حمله Supply Chain زمانی رخ می‌دهد که مهاجم یکی از اجزای مورد اعتماد در مسیر توسعه، توزیع یا Update نرم‌افزار را Compromise کند و از طریق آن به مصرف‌کنندگان نهایی برسد.

آیا افزونه WordPress می‌تواند باعث حمله Supply Chain شود؟

بله. اگر Plugin مخرب باشد یا Infrastructure توسعه‌دهنده و Update آن Compromise شود، Code آلوده ممکن است از طریق افزونه وارد سایت مصرف‌کننده شود.

آیا Plugin Nulled خطرناک است؟

استفاده از Plugin Nulled ریسک بالایی دارد، زیرا Package توسط واسطه‌ای خارج از زنجیره رسمی تغییر داده شده و Integrity آن را نمی‌توان صرفاً بر اساس ظاهر فایل تضمین کرد.

SBOM چیست؟

SBOM یا Software Bill of Materials فهرستی از Componentها و Dependencyهای یک نرم‌افزار است. این Inventory به سازمان کمک می‌کند هنگام انتشار Vulnerability بفهمد آیا Component آسیب‌دیده در سیستم وجود دارد یا خیر.

Lock File چه نقشی دارد؟

Lock File نسخه دقیق Dependencyهای Resolveشده را نگهداری می‌کند و باعث می‌شود Environmentهای مختلف Dependencyهای یکسان‌تری نصب کنند. Lock File جایگزین Vulnerability Management نیست.

SRI چیست؟

Subresource Integrity یا SRI مکانیزمی در Browser است که اجازه می‌دهد Hash مورد انتظار Script یا Stylesheet خارجی تعریف شود. اگر فایل CDN تغییر کند و Hash تطابق نداشته باشد، Browser از Load شدن آن جلوگیری می‌کند.

آیا Auto Update افزونه‌ها ناامن است؟

Auto Update ذاتاً ناامن نیست و Update سریع برای Patch کردن Vulnerabilityها بسیار مهم است. در سایت‌های حساس بهتر است Updateهای مهم در Staging بررسی و سپس به‌صورت کنترل‌شده Deploy شوند.

آیا Antivirus می‌تواند تمام Supply Chain Attackها را پیدا کند؟

خیر. Supply Chain Security به مجموعه‌ای از کنترل‌ها مانند Inventory، Vendor Trust، SCA، Signing، Provenance، Integrity Verification و Monitoring نیاز دارد.

جمع‌بندی؛ چگونه خطر افزونه‌ها و کتابخانه‌های آلوده را کاهش دهیم؟

حمله Supply Chain یکی از مهم‌ترین تغییرات در مدل تهدید نرم‌افزار مدرن است.

سال‌ها تمرکز اصلی Security روی این بود که:

«آیا Code خودمان امن است؟»

اما سؤال امروزی باید گسترده‌تر باشد:

«آیا تمام Code و ابزارهایی که به آن‌ها اعتماد کرده‌ایم امن هستند؟»

یک سایت WordPress ممکن است فقط چند هزار خط Code اختصاصی داشته باشد، اما در کنار آن میلیون‌ها خط Code از:

WordPress Core

Pluginها

Theme

PHP Libraries

JavaScript Libraries

npm

Composer

و Third-Party Serviceها

استفاده کند.

در چنین محیطی Attack Surface فقط Code نوشته‌شده توسط تیم شما نیست.

کل Software Supply Chain بخشی از Attack Surface است.

OWASP نیز همین تغییر نگرش را در Top 10:2025 منعکس کرده و دسته Vulnerable and Outdated Components را به Software Supply Chain Failures گسترش داده است.

برای مدیر WordPress اولین و مؤثرترین اقدامات بسیار ساده‌اند:

Plugin و Theme را فقط از Source معتبر دریافت کنید.

نسخه Nulled نصب نکنید.

Component بلااستفاده را حذف کنید.

Updateهای امنیتی را عقب نیندازید.

Plugin بدون Maintainer را زیر نظر بگیرید.

برای سایت مهم از Staging استفاده کنید.

Backup سالم داشته باشید.

برای توسعه‌دهندگان نیز کنترل‌های پیشرفته‌تر اهمیت پیدا می‌کنند:

SBOM

SCA

Lock File

Dependency Inventory

MFA

Repository Protection

CI/CD Hardening

Artifact Signing

Provenance

SRI

و Staged Deployment.

NIST نیز Supply Chain Security را یک فرآیند مستمر Risk Management می‌داند، نه یک بررسی یک‌باره هنگام خرید یا نصب نرم‌افزار.

قاعده مهم این مقاله را می‌توان در یک جمله خلاصه کرد:

هر Library، Plugin، Theme، Script و Tool که وارد Project می‌کنید، بخشی از اعتماد امنیتی سایت شما می‌شود.

هرچه این زنجیره کوتاه‌تر، شفاف‌تر، قابل‌ردیابی‌تر و قابل‌کنترل‌تر باشد، احتمال اینکه یک Component خارجی به مسیر نفوذ مهاجم تبدیل شود کمتر خواهد شد.