بحران یکپارچگی در مدیریت بسته‌ها: تحلیل امنیتی ۲۵ ابزار محبوب

در یک بررسی جامع روی ۲۵ مورد از محبوب‌ترین مدیریت‌های بسته (Package Managers)، مشخص شد که بسیاری از این ابزارها قادر به شناسایی تزریق کدهای مخرب توسط مخازن (Repositories) به خطر افتاده نیستند. این نقص در یکپارچگی (Integrity) کد، علی‌رغم وجود راهکارهای رمزنگاری مانند هش‌ها و امضاها، همچنان در بسیاری از ابزارهای توسعه نرم‌افزار دیده می‌شود.

نقاط ضعف در فایل‌های قفل (Lockfiles)

یک راهکار رایج برای تضمین یکپارچگی، استفاده از هش رمزنگاری (Cryptographic Hash) در فایل‌های قفل است تا پس از دانلود بسته، هش آن بررسی شود. نتایج این تحقیق نشان می‌دهد که:

• کمتر از نیمی از مدیریت‌های بسته بررسی شده، به‌صورت پیش‌فرض از Lockfile برای شناسایی تغییرات غیرمجاز استفاده می‌کنند.
• ابزارهایی مانند Bun، Cargo، npm و Poetry در این زمینه عملکرد بهتری دارند و هش‌ها را تأیید می‌کنند.
• برخی ابزارها مانند Pub (مربوط به Dart و Flutter)، حتی در صورت عدم تطبیق هش، هش جدید را جایگزین کرده و نصب بسته را ادامه می‌دهند، مگر اینکه کاربر از فلگ‌های خاصی مانند --enforce-lockfile استفاده کند.
• مدیریت بسته‌هایی نظیر Conan و CocoaPods از هش‌هایی (مانند MD5 یا SHA-1) استفاده می‌کنند که یا برای امنیت طراحی نشده‌اند و یا در برابر حملات برخورد (Collision) آسیب‌پذیرند.

چالش‌های سیستم‌های امضای دیجیتال (Signatures)

استفاده از امضاها می‌تواند نیاز به توزیع هش برای تک‌تک بسته‌ها را برطرف کند، اما پیاده‌سازی آن در دنیای واقعی با چالش‌های زیادی روبروست:

• امضای مخزن (Repository Signing): در این روش، مخزن بسته را امضا می‌کند. این روش در برابر آینه‌های (Mirrors) غیرقابل اعتماد موثر است اما اگر خود مخزن اصلی به خطر بیفتد، مهاجم می‌تواند بسته‌های مخرب را به‌طور قانونی امضا کند.
• امضای توسعه‌دهنده (Developer Signing): در این مدل، توسعه‌دهنده با کلید خصوصی خود بسته را امضا می‌کند. مشکل اصلی در اینجا، مدیریت کلیدها توسط توسعه‌دهندگان و نبود یک زنجیره اعتماد (Chain of Trust) متمرکز است.
• امضای مبتنی بر هویت (Identity-based Signing): راهکاری مدرن مانند Sigstore اجازه می‌دهد توسعه‌دهندگان بدون مدیریت کلیدهای طولانی‌مدت، از طریق توکن‌های OIDC (مانند GitHub یا Google) بسته‌ها را امضا کنند. این روش که به Trusted Publishing معروف است، در حال پذیرش در PyPI و npm است.

شکاف بین وجود امضا و تأیید آن

یکی از تکان‌دهنده‌ترین یافته‌های این تحقیق این است که حتی در محیط‌هایی که امضای دیجیتال وجود دارد، ابزارهای مدیریت بسته به‌صورت پیش‌فرض آن‌ها را تأیید نمی‌کنند. برای مثال، در npm، اجرای npm install امضاهای مخزن را بررسی نمی‌کند و کاربر باید به‌طور جداگانه دستور npm audit signatures را اجرا کند. در NuGet نیز حالت پیش‌فرض روی accept است، به این معنی که بسته‌هایی با امضای نامعتبر نیز نصب می‌شوند مگر اینکه تنظیمات به‌صورت دستی تغییر یابد.

نتیجه‌گیری برای تیم‌های امنیتی

تکیه بر پروتکل HTTPS به تنهایی برای امنیت زنجیره تأمین (Supply Chain) کافی نیست، زیرا تنها ارتباط را رمزنگاری می‌کند و اعتبار محتوای بسته را تضمین نمی‌کند. تیم‌های SOC و مهندسان امنیت باید بر استفاده از فایل‌های قفل (Lockfiles) متعهد شوند و در صورت امکان، پیکربندی‌های مدیریت بسته را برای اجبار به تأیید امضاها (Signature Verification) به‌روزرسانی کنند.