امنیت پکیجهای شخص ثالث: از کولداون تا رجیستری اختصاصی
خلاصهٔ کاملتر
حملات زنجیره تأمین نرمافزار یه الگوی تکراری و آشنا دارن: مهاجم به حساب یه نگهدارنده (Maintainer) یا سیستم بیلد دسترسی پیدا میکنه، یه آپدیت مخرب پوش میکنه و منتظر میمونه پروژههای پاییندستی اون رو Pull کنن. فاصله بین آلودگی و کشف معمولاً چند ساعت تا چند روزه — و همین کافیه.
مارس ۲۰۲۶ نمونههای تازهای از این حملات رو به نمایش گذاشت. در ماجرای trivy-action، مهاجمین ۷۵ تا از ۷۶ تگ نسخه رو force-push کردن و سکرتهای هر پایپلاینی که اسکن Trivy اجرا میکرد رو به سرقت بردن. اعتبارنامههای دزدیدهشده به آلوده کردن پکیجهای PyPI از جمله LiteLLM (با ۱۲۰ هزار نصب هفتگی) هم کشیده شد. در ماجرای axios هم نسخههای مخرب 1.14.1 و 0.30.4 تنها سه ساعت زنده بودن — اما با توجه به ۱۰۰ میلیون دانلود ماهانه، همین سه ساعت کافی بود.
کاهش وابستگیها؛ اولین قدم
اولین و سادهترین دفاع اینه که اصلاً وابستگی کمتری داشته باشی. پکیجهای سادهای مثل left-pad رو خودت پیادهسازی کن یا فورک کن. هدف داشتن یه گراف وابستگی کمعمقتره، چون ریسک از طریق وابستگیهای تراجعی (transitive) هم منتقل میشه.
کولداون؛ سلاح ساده ولی قوی اکثر پکیجهای مخرب ظرف چند ساعت تا چند روز شناسایی و حذف میشن. اگه نصب آپدیتها رو کمی به تأخیر بندازی، مکانیزمهای تشخیص اکوسیستم فرصت دارن قبل از اینکه تو آسیب ببینی کارشون رو بکنن. ابزارهایی مثل Renovate، Dependabot، pnpm و uv همه از تأخیر قابل تنظیم پشتیبانی میکنن. جالبه که یه کولداون ۷ روزه میتونست جلوی ۹۰ درصد حملات اخیر رو بگیره!
لاکفایل و هش؛ پین کردن دقیق نسخهها
لاکفایلها نسخه دقیق رو پین میکنن و هشها محتوا رو تأیید میکنن. در npm، دستور npm install میتونه لاکفایل رو تغییر بده، به همین خاطر در CI باید از npm ci استفاده کرد. نکته مهم اینه که لاکفایلها و هشها کنترل وابستگیهای تراجعی رو تضمین نمیکنن. پذیرش لاکفایل هم در اکوسیستمها فرق میکنه — Go با پیشفرضهای امن به ۹۹.۷٪ پذیرش رسیده، در حالی که npm حدود ۵۰٪ هست.
غیرفعال کردن اجرا در زمان نصب
بدافزارهای رایج اغلب روی اجرا در زمان نصب (install-time execution) حساب میکنن چون فقط یه npm install کافیه. غیرفعال کردن اسکریپتهای نصب این بردار حمله رو میبنده. pnpm کنترل دانهای داره و npm گزینه ignore-scripts رو ارائه میده. البته یه بلاک کامل بعضی پکیجهای قانونی رو هم میشکنه، پس باید با رویکرد تدریجی و allowlist پیش رفت.
کنترلهای سازمانی؛ محافظت از محیط اجرا برای سازمانها، محیطهای توسعه ابری (CDE) اجرای کد رو از لپتاپ توسعهدهنده به زیرساخت ایزوله و ephemeral منتقل میکنن. اسکریپتهای مخرب به جای دسترسی به کردنشالهای لوکال، SSH Key و کانفیگ ابری، در یه محیط ایزوله اجرا میشن. رویکرد Zero Trust Production هم که گوگل پیشگامش بوده، هر تغییر در پروداکشن رو ملزم به تأیید اتوماتیک یا مکانیزمهای auditشده میکنه.
کنترل ورود پکیجها به محیط یه پروکسی pull-through بین توسعهدهنده و رجیستری عمومی میشینه، درخواستها رو فوروارد میکنه و یه نقطه تمرکز برای سیاستگذاری فراهم میکنه. ابزارهایی مثل Artifactory، Nexus و CodeArtifact این حالت رو پشتیبانی میکنن. یه قدم جلوتر، رجیستریهای کیوریتشده هستن که فقط پکیجهای از پیش تأییدشده رو در دسترس میذارن — friction بالاست ولی برای مسیرهای حیاتی بسیار مؤثره. مسیر پیشنهادی اینه که اول با پروکسی برای visibility شروع کنی و بعد برای مسیرهای حیاتی به رجیستری کیوریتشده برسی.
نکات کلیدی:
- بیشتر حملات زنجیره تأمین در بازه چند ساعته تا چند روزه رخ میدن؛ سرعت واکنش اکوسیستم کلیدیه
- کولداون ۷ روزه میتونست ۹۰٪+ حملات اخیر رو دفع کنه
- در CI از
npm ciبه جایnpm installاستفاده کن تا لاکفایل تغییر نکنه - غیرفعال کردن install scripts با رویکرد allowlist یه لایه دفاعی مؤثره
- محیطهای توسعه ابری (CDE) در عصر AI Coding Agent اهمیت بیشتری پیدا کردن
- از پروکسی رجیستری برای visibility شروع کن، بعد به رجیستری کیوریتشده برای مسیرهای حیاتی برس
- هیچ سیستمی کامل نیست؛ لایههای detection مکمل لایههای prevention هستن




