امنیت زنجیره تأمین متنباز در ۲۰۲۶
حملات به npm، GitHub Actions و پکیجهای محبوب دیگر نظری نیستند. یک برنامه عملی حداقل برای تیمهای محصول که نمیخواهند امنیت را به یک اسکنر تنها واگذار کنند.
علی مرتضوی
بنیانگذار پارادایس کد
تهدید واقعی است، وحشت لازم نیست
سالهای اخیر نشان داد که یک پکیج کوچک با maintainer خسته میتواند به نقطه ورود تبدیل شود. هدف این نیست که متنباز را ترک کنید؛ هدف این است که اعتماد را مهندسی کنید: چه چیزی نصب میشود، با چه هویتی، و با چه مجوزی در CI اجرا میشود.
تیمهای کوچک هم میتوانند کنترلهای با ROI بالا داشته باشند بدون اینکه یک برنامه compliance شرکتی پیاده کنند.
قفل، شفافیت، و بهروزرسانی
lockfile را commit کنید و نصب را در CI با حالت immutable انجام دهید. Dependabot یا Renovate را روشن کنید اما merge خودکار را فقط برای patchهای کمریسک بگذارید. majorها صاحب انسانی میخواهند.
دانستن آنچه دارید نیمهی راه است: تولید SBOM در بیلد و نگهداری فهرست سرویسها و پکیجهای بحرانی. وقتی CVE مهم منتشر شد، نباید دو روز دنبال این بگردید که اصلاً استفاده میکنیم یا نه.
حداقل دسترسی در CI و Secrets
توکنهای GitHub با دسترسی وسیع، secrets روی pull_requestهای فورکشده، و credentials در لاگ، کلاسیکترین مسیر حادثهاند. GITHUB_TOKEN را محدود کنید، محیطهای protected بسازید، و OIDC به ابر را به کلیدهای طولانیعمر ترجیح دهید.
اسکریپتهای postinstall را جدی بگیرید. برای پکیجهای حساس، بررسی کنید چه چیزی در install اجرا میشود. نادیدهگرفتن lifecycle scripts در بعضی محیطهای CI یک لایه دفاعی است — با آگاهی از سازگاری.
بررسی وابستگی قبل از عاشق شدن
قبل از افزودن یک پکیج جدید: آخرین انتشار، تعداد maintainer فعال، آیا جایگزین استاندارد وجود دارد، اندازه و وابستگیهای تو در تو، و مجوز. یک utility دهخطی را خودتان بنویسید ارزانتر از نگهداری یک درخت مشکوک است.
پکیجهایی که به credentials، فایلسیستم، یا شبکه در زمان import دست میزنند باید سختگیرانهتر نقد شوند. در AI SDK و ابزارهای ایجنت، سطح حمله بزرگتر شده چون ابزارها به سیستم واقعی وصل میشوند.
امضا، provenance، و رجیستری
در ۲۰۲۶، توجه به provenance و انتشار با هویت تأییدشده بیشتر شده است. جایی که اکوسیستم پشتیبانی میکند، تأیید provenance را در CI وارد کنید. رجیستری خصوصی برای پکیجهای داخلی اجباری است — نه انتشار تصادفی به npm عمومی.
پین کردن Actionهای GitHub به commit SHA بهجای تگ متحرک هنوز توصیه عملیاتی معتبری است (industry practice پایدار). تگها میتوانند جابهجا شوند؛ SHA نه.
پاسخ به حادثه وابستگی
یک runbook یکصفحهای داشته باشید: چگونه نسخه مخرب را شناسایی کنیم، چگونه lockfile را برگردانیم، چگونه توکنها را بچرخانیم، و چه کسی به مشتری اطلاع میدهد. تمرین روی یک CVE بیخطر بهتر از بداهه در جمعه شب است.
بعد از حادثه، فقط پکیج را عوض نکنید — بپرسید چرا کنترلها ندیدند. نبود تست، نبود مرور PR، یا توکن بیشازحد وسیع معمولاً ریشه است.
حداقل برنامه ۹۰ روزه
روز ۱ تا ۳۰: lock immutable، محدودسازی توکن CI، فهرست پکیجهای بحرانی. روز ۳۱ تا ۶۰: SBOM، سیاست آپدیت، پین کردن Actions. روز ۶۱ تا ۹۰: تمرین پاسخ حادثه و حذف حداقل ۳ وابستگی زائد.
امنیت زنجیره تأمین یک محصول جدا نیست؛ بخشی از تعریف تمامشده برای هر قابلیت است که وابستگی جدید میآورد.
سؤالات متداول
آیا npm audit به تنهایی کافی است؟
خیر. سیگنال مفیدی است اما بدون کنترل CI، مرور وابستگی و مدیریت secret، پوشش ناقص میدهد.
همه CVEها را فوراً رفع کنیم؟
بر اساس قابلیت بهرهبرداری و دسترسی شبکه اولویت بدهید. CVE پر سر و صدا همیشه بحرانی عملی نیست.
برای تیم سه نفره از کجا شروع کنیم؟
از lockfile immutable، توکن محدود، و عدم merge کور majorها. همان سه کار بخش بزرگی از ریسک را کم میکند.
دانش و مقالات
نیاز به اجرای همین مفاهیم در محصولتان دارید؟
پارادایس کد از مشاوره تا پیادهسازی کامل کنار شماست.