همفکران فناوری شریف
۱مقدمه
بخش بزرگی از کد هر نرم‌افزار مدرن را کتابخانه‌ها و بسته‌های متن‌باز تشکیل می‌دهند. این وابستگی، توسعه را سریع‌تر می‌کند، اما سطح حمله را نیز گسترش می‌دهد.
۲بررسی موضوع
حمله‌های زنجیرهٔ تأمین با تزریق کد مخرب به یک بستهٔ پرکاربرد یا جعل نام بسته‌ها (Typosquatting) انجام می‌شوند و به‌طور هم‌زمان هزاران سازمان را آلوده می‌کنند.
راهکارهای کلیدی شامل تهیهٔ فهرست اجزای نرم‌افزار (SBOM)، پویش خودکار وابستگی‌ها برای آسیب‌پذیری‌های شناخته‌شده، تثبیت نسخه‌ها و استفاده از مخازن داخلی تأییدشده است.
امنیت زنجیرهٔ تأمین باید بخشی از چرخهٔ توسعه (DevSecOps) باشد؛ یعنی کنترل‌ها به‌صورت خودکار در هر مرحلهٔ ساخت و انتشار اجرا شوند، نه به‌صورت بررسی دستی پایانی.
حملهٔ SolarWinds در سال ۲۰۲۰ نمونه‌ای شاخص از این تهدید بود: مهاجمان با نفوذ به فرایند ساخت نرم‌افزار یک شرکت مدیریت شبکه، کد مخرب را در به‌روزرسانی رسمی محصول جاسازی کردند و از این طریق به شبکهٔ هزاران سازمان، از جمله نهادهای دولتی، دسترسی یافتند. این رخداد نشان داد که حتی نرم‌افزارهای امضاشده و معتبر نیز می‌توانند حامل تهدید باشند.
آسیب‌پذیری Log4Shell در کتابخانهٔ پرکاربرد Log4j در پایان سال ۲۰۲۱، جنبهٔ دیگری از این مسئله را آشکار کرد: بسیاری از سازمان‌ها حتی نمی‌دانستند این کتابخانه در کدام سامانه‌هایشان به کار رفته است. فهرست اجزای نرم‌افزار (SBOM) دقیقاً برای پاسخ سریع به همین پرسش طراحی شده است و امروز در بسیاری از الزامات قانونی و قراردادهای خرید نرم‌افزار درخواست می‌شود.
چارچوب SLSA که با حمایت جامعهٔ متن‌باز توسعه یافته، سطوح بلوغ امنیت زنجیرهٔ تأمین را تعریف می‌کند؛ از مستندسازی فرایند ساخت در سطوح پایه، تا ساخت در محیط‌های ایزوله و امضای قابل راستی‌آزمایی هر محصول در سطوح بالاتر. امضای دیجیتال بسته‌ها و کانتینرها و بررسی آن پیش از استقرار، از کنترل‌های کلیدی در این چارچوب است.
۳جمع‌بندی
برای تیم‌های توسعهٔ سامانه‌های مالی، چند اقدام عملی بیشترین اثر را دارد: حذف وابستگی‌های بلااستفاده، به‌روزرسانی منظم کتابخانه‌ها با فرایند آزمون خودکار، فعال کردن هشدار خودکار برای آسیب‌پذیری‌های جدید در وابستگی‌ها، و محدود کردن دسترسی سامانهٔ ساخت و انتشار به حداقل افراد و سرویس‌های ضروری.
منابع
