این سومین قسمت از یک سری مقالات درباره شایعترین نوع حملات زنجیره تامین نرمافزار: حملاتی که از یک رجیستری عمومی سوءاستفاده میکنند منبع باز اجزای نرمافزار. پس از تجزیه و تحلیل در قسمت قبل «آناتومی بستههای مخرب: روندها چیستند؟«چگونه بازیگران بد، رفتار مخرب را به اجزای منتشر شده جدید یا موجود تزریق میکنند، ما آمادهایم تا جلیقههای آتشنشانی خود را بپوشیم و بررسی کنیم که چگونه میتوانیم با موفقیت نرمافزارهای مخربی را که از این طریق ارائه میشوند، مسدود کنیم، یا به طور جایگزین، با یک حادثه سایبری بالقوه جدی مقابله کنیم، زیرا رویکرد اشتباهی را اتخاذ کردهایم.»
اکثر متخصصان آگاه به مسائل امنیتی، ایدههایی در مورد چگونگی برخورد با این تهدید دارند. ما شنیدهایم که مدیران امنیتی بدون هیچ تردیدی میگویند که SCA ابزارها از قبل به شما میگویند که چه زمانی یک نسخه از بسته، بدافزار است. یا اینکه به اجزای نرمافزاری شناختهشده و بسیار بررسیشده وابسته هستند، که در آن هرگونه بدافزاری به سرعت شناسایی و حذف میشود. آنها از نسخههای جزئی/پچ باز برای دریافت خودکار رفع آسیبپذیریها استفاده میکنند و این روش مناسب و توصیهشده برای کاهش خطر در وابستگیهای متنباز است، که از «زود وصله بزنید، مرتب وصله بزنید”اصل.
در این قسمت، بررسی خواهیم کرد که چرا این ایدهها اشتباه هستند و چگونه چنین تصورات غلطی در محبوبیت این مکانیسم حمله و خطر بزرگی که سازمانها با آن مواجه هستند، نقش دارند. در پایان، به مواردی که مؤثر هستند و تلاش و منابع لازم برای این کار اشاره خواهیم کرد.
باورهای غلط رایج
در طول سفرمان با امنیت نرمافزار، شاهد تکامل تکنیکهای حمله و طیف گستردهای از ایدهها از سوی افراد آگاه به امنیت بودیم. سازمانها اغلب در مورد اینکه چه چیزی در برابر این تهدید مؤثر است، دچار سوءتفاهم میشوند، بنابراین ابتدا بررسی خواهیم کرد که چه چیزی مؤثر نیست، که در ادامه، فهرستی نه چندان جامع از تصورات غلط، خلاصه شده است.
باور غلط شماره ۱: SCA ابزارها از قبل اجزای مخرب را گزارش میدهند
در واقع! اما بعد از این واقعیت... زمانی که احتمالاً خیلی دیر شده است اگر عنصر در ساخت نرمافزار استفاده شده باشد، و بازیگران بد قبلاً در یک توسعهدهنده یا ... جای پایی پیدا کردهاند. CI/CD میزبان. ممکن است اطلاعات محرمانه از سیستم خارج شده باشند، بدافزارهای اضافی دانلود و نصب شده باشند، و شاید مهاجم به صورت جانبی حرکت کرده و از قبل به جای دیگری دسترسی پیدا کرده باشد.
تحلیل ترکیب نرمافزار (SCAابزارهایی برای شناسایی آسیبپذیریهای شناختهشده بالقوه طراحی شدهاند. ابزارهای مدرن با افزایش نسبت سیگنال به نویز، کار بزرگی انجام میدهند و مشخص میکنند که آیا آسیبپذیری واقعاً قابل دسترسی یا قابل بهرهبرداری است یا خیر. اما آنها در برابر بدافزارهای جدید بیفایده هستند. یک مؤلفه مخرب را به عنوان یک آسیبپذیری روز صفر در نظر بگیرید: تنها زمانی که رفتار مخرب آن شناسایی شود، مؤلفه به رجیستری نگهدارنده گزارش میشود که پس از بررسی توسط یک تیم امنیتی، به عنوان مخرب تأیید شده و از رجیستری حذف میشود. [1].
در آن زمان، جهان (از جمله SCAمیداند که نصب یا استفاده از کامپوننت (یا نسخه(های) یک کامپوننت موجود) کار خوبی نیست. اما این زمانی است که کامپوننت از رجیستری در دسترس نباشد.دانستن اینکه من در اجزای شخص ثالث یا حتی اجزایی که توسط رجیستری به عنوان مخرب طبقهبندی شدهاند، آسیبپذیریهایی دارم، خوب است، اما متأسفانه SCA یا ابزارهای حسابرسی رایج در این زمینه کمکی نمیکنند. مگر اینکه SCAابزار /audit میتواند قبل از استفاده از یک جزء در سازمان شما، از مخرب بودن آن مطلع شود..
به یاد داشته باشید، هر راهکاری که علیه اجزای متنباز مخرب ارائه میشود، باید آنها را شناسایی کند. در پروازبین زمانی که کامپوننت در رجیستری منتشر میشود و زمانی که کامپوننت (نسخه) برای اولین بار در سازمان شما استفاده میشود. و این شامل کامپوننتهای انتقالی نیز میشود.
تصور غلط شماره ۲: کنترل اسکریپتهای نصب در زمان ساخت، از رفتارهای مخرب اجزای متنباز جلوگیری میکند
مدیران بستههای مختلف، امکان اجرای اسکریپتها را ارائه میدهند (که در فایل فشرده کامپوننت گنجانده شدهاند). [2]), به دلایل موجه، مانند کامپایل موارد مورد نیاز در پلتفرمهای مختلف، تولید کد یا اجرای تستها، و همه ما باید بدانیم که اگر اسکریپتهای مخرب در فایل فشرده گنجانده شوند، یا اگر مهاجم بتواند اسکریپت مخربی را به جای اسکریپت خوب اجرا کند، میتوانند توسط افراد بد مورد سوءاستفاده قرار گیرند.
با دانستن این موضوع، میتوانیم مدیر بسته را طوری پیکربندی کنیم که اسکریپتها را نادیده بگیرد. برای مثال، با NPM –نادیده گرفتن اسکریپتها پرچم (یا یک ویژگی پیکربندی در npmrc فایل) در حین نصب، اسکریپتها را نادیده میگیرد. این ممکن است مشکلاتی ایجاد کند زیرا اجرای اسکریپتها در بسیاری از اکوسیستمها رایج است: برخی از مدیران بسته حتی اجازه غیرفعال کردن اجرای اسکریپت را نمیدهند (راهنمایی: prompt "کدام مدیر بستهها اجازه غیرفعال کردن اجرای اسکریپتهای نصب را نمیدهند؟«در هوش مصنوعی مورد علاقهتان»). اما این به طور کلی محافظت نمیکند (ما باید تضمین کنیم که پیکربندی غیرفعال کردن رد شدن در همه جا وجود داشته باشد).
و وقتی رفتار مخرب در اسکریپتهای نصب قرار ندارد، بلکه در نرمافزاری است که باید در زمان اجرا اجرا شود، این گزینه به تنهایی از ما محافظت نمیکند.
تصور غلط شماره ۳: پین کردن نسخه مانع از نصب اجزای مخرب میشود
بین وصله کردن زودهنگام و وصله کردن مکرر، یک بدهبستان وجود دارد. نسخههای باز (به مدیر بسته اجازه میدهد تا در صورت وجود اصلاحات امنیتی، بهروزرسانیهای جدید را بهطور خودکار نصب کند) و پین کردن نسخه (داشتن تمام وابستگیهای مستقیم و انتقالی برای یک نرمافزار در یک نسخه ثابت). اصول امنیتی سرسخت و گاهی متناقض هستند، همانطور که در مورد «بهروزرسانی زودهنگام، بهروزرسانی مکرر» و «ارتقاء نباید ساده گرفته شود»برخی از مدیران بسته، بهروزرسانیهای خودکار را با محدودههای سرور، به روش توصیهشده انجام میدهند. اگر میخواهید بهروزرسانیهای مخرب را نیز دریافت کنید، عالی است! بله، اجزا باید بهروزرسانی شوند تا اصلاحات امنیتی که آسیبپذیریها را در اسرع وقت میبندند، دریافت کنند، اما ... هرگز اجازه ندهید که مدیر بسته این کار را بهطور خودکار انجام دهد.
تصور غلط شماره ۴: استفاده از اجزای قابل اعتماد ایمن است. هر نسخه مخربی به سرعت پیدا، افشا و حذف میشود.
چرا یک کامپوننت مورد اعتماد است؟ احتمالاً به این دلیل که بسیار محبوب است، افراد زیادی به دنبال آسیبپذیریهای آن هستند، تعداد زیادی مشارکتکننده برای نگهداری دارد، و چندین نگهدارنده اصلی دارد که با دقت همه چیز را بررسی میکنند. pull requestsواقعیت کاملاً متفاوت است. برخی از اجزای ضروری توسط یک توسعهدهندهی واحد و بدون حقوق نگهداری میشوند. چارچوبهای پرکاربرد چند همکار دائمیبا کاهش سریع تعداد commitبه ازای هر نگهدارنده (پروژههای محبوب تعداد زیادی مشارکتکننده دارند که برخی از کارها را به صورت خودجوش انجام میدهند) commit و دیگر هرگز برنمیگردد). و پروژههای محبوب با یک نگهدارنده واحد فراوانند.
خودت رو تصور کن که میگی «ما از Spring Boot / Angular / React / PyTorch / ایمیجهای رسمی Docker استفاده میکنیم، بنابراین ریسکی که شما در موردش صحبت میکنید بسیار کم است.» شاید این درست باشد، ما فروشندگان امنیتی همیشه در حال ایجاد ترس هستیم و دخالت در کار تیمهای توسعه برای کاهش یک ریسک قابل بحث، بیمعنی است. ممکن است وسوسه شوید که به پاراگراف پذیرش ریسک (در بخش بعدی) بروید و تمام. متأسفانه، محبوبترین مؤلفهها، اهدافی برای بازیگران بد هستند و برای مثال، محبوب کتابخانه PyTorch مورد حمله قرار گرفت در گذشته است.
«به سرعت پیدا، افشا و حذف شد». حذف یک مؤلفه مخرب جدید از رجیستری عمومی روزها طول میکشد. رجیستریها در مورد حذف نسخه مؤلفه محتاط هستند، البته به خاطر منافعشان. تجربه ما نشان میدهد که پس از گزارش از طرف ما، میانگین زمان لازم برای حذف نسخه آسیبدیده توسط رجیستری ۳۹ ساعت است، یعنی بیش از یک روز و نیم. مؤلفههای مخربی وجود دارند که یک هفته پس از گزارش اولیه ما در رجیستری، قبل از حذف، وجود دارند. و در برخی موارد، مؤلفه تنها پس از گزارش یک قربانی یا یک شرکت واکنش به حوادث مربوط به آن مؤلفه، حذف میشود.
چه چیزی در برابر اجزای مخرب کار نمیکند؟
هر رویکرد نامشخصی به طرز فجیعی شکست خواهد خورد. این یک امر قطعی است، شما اقدامات متقابل موثری برای ریسک مرتبط با این تهدید ارائه نمیدهید.
سنتی SCA ابزارها در مورد بدافزارهای شناخته شده به شما اطلاعات میدهند اما بازه زمانی زیادی برای مواجهه با آنها دارند. مگر اینکه آنها به صورت پیشگیرانه بدافزار را با مسدود کردن اجباری اجزای مخرب شناسایی کنند، در غیر این صورت در برابر این تهدید کار نمیکنند.
غیرفعال کردن اسکریپتهای نصب میتواند مفید باشد، اما باید در هر جایی که یک جزء نیاز به نصب دارد، اعمال شود. در مورد پین کردن نسخه نیز همینطور است، زیرا نسخهها را نمیتوان برای همیشه از حالت اولیه امن پین کرد.
فرض اینکه اجزای محبوب به اندازه کافی مورد توجه قرار میگیرند که نمیتوان بدون تشخیص تقریباً آنی برای جلوگیری از هرگونه خسارت، در یک حمله زنجیره تأمین، رفتار ناخواستهای به آنها تزریق کرد، سادهلوحانه و پرخطر است. شما که نمیخواهید در حاشیه زندگی کنید، نه؟
اگر در این مرحله متوقف شوید، پذیرش ریسک تنها کاری که میتوانید انجام دهید این است: این یک ...cisمواردی که باید در مدل تهدید/ارزیابی ریسک شما مستند شوند، از جمله منطق پذیرش ریسک و پیامدهای بالقوه آن. با اطلاعرسانی به مدیریت و سایر طرفهای ذیربط، آگاهیبخشی کنید. برخی احتمالی میتوان زمانی که یک جزء مخرب نصب یا در نرمافزار شما گنجانده میشود، برنامهریزی کرد، اما این کار دشوار است زیرا مهاجمان مسیرهای زیادی برای دنبال کردن دارند. جزئیات یک حمله زنجیره تأمین مبتنی بر استفاده از یک جزء مخرب، افشای عمومی حادثه را به شدت تغییر خواهد داد، که احتمالاً طبق چارچوب نظارتی سازمان شما اجباری است. همچنین میتوانید به موارد زیر بپردازید: کنترلهای جبرانی or ریسک انتقال مثلاً با بیمه
با این حال، کنترلهایی وجود دارد که به تهدید رسیدگی میکنند و اگر از پذیرش ریسک راضی نیستید، باید در نظر گرفته شوند. لطفاً ادامه مطلب را بخوانید.
چه چیزی در برابر حملاتی که از اجزای مخرب استفاده میکنند، مؤثر است؟
مدیریت نسخههای ثابت
پین کردن نسخه با استفاده از نسخههای کنترلشده و آگاهانه، راهی برای ایجاد تعادل بین نیاز به حذف آسیبپذیریها بدون دریافت بدافزار است. اما تصور غلط شماره ۳ را به خاطر داشته باشید: پین کردن نسخه به تنهایی برای جلوگیری از ورود کد مخرب از نسخههای جدید کافی نیست، زیرا در آینده نیاز خواهید داشت که نسخهها را در هرگونه وابستگی مستقیم یا غیرمستقیم بهروزرسانی کنید. در آن لحظه، به شواهد کافی نیاز دارید که نشان دهد همه نسخههای اصلاحشده حاوی بدافزار نیستند.
هشدار زودرس
یک رویکرد برای مشکل اجزای مخرب، یک سیستم هشدار اولیه است (که در اینجا به عنوان ... نامگذاری شده است). هشدار زودهنگام بدافزار یا MEW)، که در آن نسخههای جدید منتشر شده (برای اجزای جدید یا موجود) توسط یک موتور تشخیص تجزیه و تحلیل میشوند، که وقتی شواهد کافی یافت شود، ممکن است نسخه جدید را به عنوان بالقوه مخرب طبقهبندی کند.
اتوماسیون در اینجا ضروری است، زیرا بررسی دستی تمام اجزای جدید با سرعت انتشار فعلی غیرممکن است. بنابراین موتور تشخیص باید تکنیکهای متنوعی را ترکیب کند، شاید از جمله تجزیه و تحلیل استاتیک، پویا و قابلیت، اعتبار کاربر و شواهدی که از اختلاف بین ابردادههای مؤلفه و محتوای tarball یا بین tarball و مخزن منبع که ظاهراً مؤلفه از آن میآید، حاصل میشود.
وجود دارد منطقه تاریک بین زمان انتشار و زمانی که موتور محتوای اجزا را تجزیه و تحلیل میکند، اما نباید از چند دقیقه بیشتر شود. این طرح را میتوان تغییر داد، به عنوان مثال با انتظار برای تجزیه و تحلیل اجزای جدید قبل از اجازه نصب و استفاده از آنها در ساخت نرمافزار. pipelineیا در صورت نیاز آنها را بر اساس تقاضا تجزیه و تحلیل کنید. یک جزء در یک نسخه معین تغییرناپذیر است. [3]بنابراین، فقط یک بار نیاز به تجزیه و تحلیل دارد.
اتوماسیون کامل امکانپذیر نیست و بررسی امنیتی برای اجزای بالقوه مخرب مورد نیاز است. مراقب طرفداران اکسیر دیجیتال باشیدهوش مصنوعی و یادگیری ماشینی به اندازه کافی توسعه نیافتهاند که بتوانند حرف آخر را در تأیید وجود بدافزار در یک مؤلفه مشکوک بزنند. مطمئناً، یادگیری ماشینی نقش کلیدی در موتور تشخیص در طبقهبندی مؤلفه ورودی از شواهد خام جمعآوریشده ایفا میکند، اما پس از «قرنطینه» شدن مؤلفه، حرف آخر را یک تیم امنیتی با تجربه در مؤلفههای مخرب، بررسی دستی آن میزند. این کار هرگونه بدافزار بالقوه را تأیید میکند یا آن را به عنوان ایمن طبقهبندی مجدد میکند. و مدت زمان آن در محدوده ساعت است.
رجیستری در مورد نسخه/مولفه مخرب گزارش میدهد؛ سپس رجیستری بررسی خود را برای تأیید انجام میدهد و به افشای عمومی و حذف از رجیستری ادامه میدهد. برخی از رجیستریها یک بسته امنیتی نگهداری میکنند. محدوده زمانی در اینجا روزها یا هفتهها از زمان انتشار است که همان «ساکن زمان' یا 'پنجره نوردهیبرای اکثر اجزای مخرب.
آیا میتوان فهمید که آیا یک نسخه از کامپوننت مخرب است یا خیر؟
بنابراین برای هشدار اولیه، باید به این سوال پاسخ رضایتبخشی بدهیم: چگونه میتوانم بفهمم که یک کتابخانه یا بسته مخرب است (یا نیست؟) چگونه شواهد کافی از رفتار مخرب جمعآوری کنیم؟ ممکن است، اما دشوار است، زیرا مهاجمان از نبوغ زیادی برای جلوگیری از شناسایی استفاده میکنند. رویکردهای مختلفی وجود دارد که هر کدام مزایا و معایبی دارند.
تجزیه و تحلیل استاتیک میتواند تمام مسیرهای اجرا را بررسی کند، تکنیکهای مورد استفاده مهاجمان را بدون اجرای مؤلفه بررسی کند و وظایف پیشپردازشی مانند رفع ابهام یا رمزگشایی را انجام دهد. از آنجایی که مهاجمان سعی میکنند شیطنت خود را پنهان کنند، تلاشهای مبهمسازی در واقع نشانهای از بدافزار است (اما توجه داشته باشید که مؤلفههای قانونی برای حفظ مالکیت معنوی، کد را مبهم میکنند که با «منبع باز«). تنها تعداد کمی از حملات بسیار پیچیده با مبهمسازی قوی نیاز به سندباکسینگ دارند، اما چنین مبهمسازی قویای نشانهی آشکاری از بدخواهی است. لطفاً توجه داشته باشید که روشهای مرسوم SAST ابزارها برای آسیبپذیریهای غیرعمدی طراحی شدهاند، نه برای اهداف مخرب مانند درهای پشتی.
تحلیل دینامیک کامپوننت را اجرا میکند و با ابزاربندی زمان اجرا، معمولاً با فراهم کردن یک محیط سندباکس، پاسخ را بررسی میکند. رفتار مخربی که تحت شرایط خاصی ایجاد میشود، ممکن است شناسایی نشود: لطفاً توجه داشته باشید که بدافزار ممکن است از تکنیکهای گریز مانند موارد زیر استفاده کند: مجازی سازی / فرار از جعبه شن و ماسه فقط زمانی فعال شود که تحت بررسی دقیق نباشد، و همچنین نشانهی آشکاری از فعالیت مخرب برای هر موتور تحلیل استاتیک باشد.
تحلیل قابلیتها بررسی میکند که آن مؤلفه چه کاری انجام میدهد: به کجا متصل میشود، به کدام فایلها دسترسی پیدا میکند، کدام دستورات یا برنامهها اجرا میشوند، ورودی/خروجی ترمینال یا دستگاه انجام میشود، یا کدام فراخوانیهای سیستمی فراخوانی میشوند. این انگشتنگاری رفتاری میتواند (برای یک مؤلفه موجود) در نسخههای مختلف مقایسه شود، بنابراین وقتی رفتار غیرمنتظرهای شناسایی میشود، این شواهد میتواند سوءظن به فعالیت مخرب احتمالی تزریق شده در نسخه جدید را ایجاد کند. این رویکرد از مراحل اولویتبندی پیروی میکند که تحلیلگران امنیتی هنگام مواجهه با بدافزار بالقوه دنبال میکنند: بازرسی با استفاده از رشته های یا ابزارهای مشابه. این رویکرد، رفتار مخرب را صرف نظر از شرایط تحریک، تشخیص میدهد و زمانی که هیچ کد منبعی در دسترس نباشد، کار میکند.
تحلیل زمینه اطلاعاتی در مورد نحوه انتشار و توسط چه کسی مؤلفه جمعآوری میکند. کمپینهای بازیگران بد اغلب از یک حساب کاربری جدید استفاده میکنند که مشمول هیچ فرآیند بررسی دقیقی نیست. ردیابی فعالیتهای گذشته ممکن است بینشهایی در مورد کاربر اصلی ارائه دهد، عمدتاً برای ناهنجاریهایی که ممکن است به یک سازش بالقوه اشاره داشته باشند. کسب اعتبار بسیار دشوار و از دست دادن آن بسیار آسان است! کاربری که هیچ فعالیتی در گذشته ندارد، خنثی است، اما کارما افراد بدخواه را تعقیب میکند. هکتیویستها یا کاربران عادی که اعتبارنامههای انتشارشان به سرقت رفته است، باید با دقت ردیابی شوند.
یکی دیگر از اطلاعات زمینهای، هرگونه اختلاف بین مخزن منبع که ظاهراً برای ایجاد فایل فشرده کامپوننت استفاده شده و محتویات خود فایل فشرده است. و همچنین پیروی از شیوههای خوب، مانند ایجاد برچسبها یا نسخههایی در مخزن منبع که با نسخههای کامپوننت منتشر شده در رجیستری عمومی مطابقت دارند. هنگامی که مخزن منبع در یک ... خاص commit با برچسب انتشار مشخص شده باشد، و ناگهان یک نسخه از آن پیروی نکند، همین به تنهایی مدرک محکمی است که نشان میدهد کامپوننت میتواند آلوده باشد: ممکن است عامل مخرب، حسابی را که برای انتشار کامپوننت استفاده شده است، به خطر انداخته باشد، اما هیچ مجوز نوشتن در مخزن کد منبع ندارد. بسیاری از حملات به طور معمول با استفاده از این قوانین شناسایی میشوند: به عنوان مثال، حمله به لجر به راحتی میتوان در این راستاها تشخیص داد. بنابراین، تحلیل زمینه، چنین ناهنجاریهایی را در فرآیند انتشار شناسایی میکند.
فایروال وابستگی
یک رویکرد متفاوت، داشتن یک لیست سفید جامع از کامپوننتها برای تمام گرافهای وابستگی مورد استفاده در نرمافزار شماست، بنابراین در هر ساختی pipeline فقط نسخههای تأیید شدهی کامپوننت که در سازمان شما اجرا میشوند، قابل نصب و استفاده هستند. «فایروال«با استفاده از یک رجیستری داخلی اعمال میشود که در آن فایلهای فشرده (tarball) برای نسخههای مجاز کامپوننت (ذخیره شده یا پروکسی شده) ارائه میشوند. لطفاً توجه داشته باشید که هیچ لیست سفیدی کار نخواهد کرد، مگر اینکه فناوری لازم برای طبقهبندی هر نسخه جدید به عنوان نسبتاً ایمن را داشته باشید تا بتوان آن را به لیست سفید اضافه کرد.
لطفاً توجه داشته باشید که هشدار زودهنگام (تشخیص سریع در اسرع وقت پس از انتشار نسخه جدید) باید با روشی برای استفاده پیشگیرانه از آن اطلاعات ترکیب شود تا مؤلفهای که بر ساخت تأثیر میگذارد مسدود شود. pipelineیا دستگاههای توسعهدهندگان [4]ما به این میگوییم «فایروال وابستگی«: یک مکانیزم قرنطینه برای محافظت از ساختهای خودکار در برابر بستههای مخرب. بستههای داخلی و رجیستریهای تصویر برای محافظت سازمانها از شر بیرونی خوب هستند، اما شواهد کافی برای مؤثر بودن قرنطینه لازم است.»
سندباکسینگ در زمان اجرا
یک رویکرد جایگزین برای تشخیص در زمان انتشار، تجزیه و تحلیل رفتار در زمان اجرا است. ایده این است که رفتار مورد انتظار از نرمافزار ثبت شود و هرگونه ناهنجاری یافت شده شناسایی (یا مسدود) شود. این خط عمل، مشکل نیاز به ابزار دقیق در زمان اجرا برای نظارت یا مسدود کردن را دارد و این ایده امیدوارکنندهای است که به مجموعه مکانیسمهای محافظت در برابر آفت مؤلفه مخرب اضافه خواهد شد.
تعیین یک استراتژی جامع
استراتژی پیشنهادی باید تکنیکهای مختلفی را در فرآیند توسعه نرمافزار ترکیب کند و کنترل بهروزرسانیهای نسخه را برای مسدود کردن اجزای مخرب ورودی در دست بگیرد. ما باید پینگذاری نسخه را برای جلوگیری از آلودگی خودکار با بهروزرسانی نسخهها برای دریافت رفع آسیبپذیریهای مهم، در نظر بگیریم؛ یک ارزیابی سریع و کارآمد از وابستگیهای مستقیم و غیرمستقیم در طول بهروزرسانی نسخهها داشته باشیم تا شواهد کافی مبنی بر آلوده نبودن آنها به بدافزار وجود داشته باشد. ساخت نرمافزارهایی که به اجزای مخرب شناخته شده وابسته هستند باید مسدود شوند. و همه باید اجرا شوند.
در صورت امکان از پین کردن نسخه استفاده کنید، زیرا باعث میشود نسخهها قابل تکرارتر باشند. پین کردن نسخه با برآمدگیهای نسخه کنترلشده و تأییدشده دستیو با کمک فناوری کمکیباید ارزیابی کند که آیا بهروزرسانی، بدافزار به همراه دارد یا نرمافزار را خراب میکند، و بهروزرسانی برای رفع آسیبپذیریها را با اجتناب از آلودگی به بدافزار تطبیق دهد. ابزارسازی میتواند در اینجا با (1) اولویتبندی آسیبپذیریهایی که واقعاً مهم هستند (قابل دسترسی و قابل بهرهبرداری، با خطر بالای هدف قرار گرفتن توسط مهاجمان)، (2) انتخاب نسخههای هدف که با کاربردهای فعلی مؤلفه سازگار هستند و نرمافزار را خراب نمیکنند، (3) انتخاب نسخههای هدف که حاوی رفتار مخرب نیستند، و (4) بهروزرسانی نسخه برای وابستگیهای مستقیم و غیرمستقیم را با پیشنهاد تغییراتی در فایلهای مانیفست که میتوانند به سرعت تأیید شوند، به سرعت انجام دهد. مرحله (3) به اطلاعات خاصی در مورد مؤلفههای مخرب تا حد امکان نزدیک به زمان انتشار آنها نیاز دارد.
این فرآیند بهروزرسانی وابستگیها باید اعمال شده و تایید در همه جا. این فرآیند باید مستندسازی شود و همه طرفهای درگیر باید آموزش ببینند، زیرا اغلب توسعه و ساخت/استقرار نرمافزار به خارج از سازمان منتقل میشود. CI/CD pipelines باید بر این اساس اصلاح شوند، تا خودکارسازی اجازه ندهد وابستگی غیرمستقیم مخرب وارد ساختار شود: guardrails اگر شواهد کافی مبنی بر وجود بدافزار بالقوه در یک وابستگی وجود داشته باشد، مسدود کردن ساخت، روش پیشنهادی است.
اگر سازمان شما دارای یک رجیستری داخلی است که به عنوان یک پروکسی امنیتی برای نگهداری نسخههای مجاز اجزا عمل میکند، باید قبل از افزودن یک جزء درخواستی به لیست مجاز، اطلاعاتی در مورد اجزای مخرب (علاوه بر سایر معیارها) کسب کنید تا آن را بررسی کنید.
استفاده از نرمافزارهای متنباز با رعایت نکات ایمنی آسان نیست و باید عامل بدافزار را کاملاً در نظر گرفت و تلاش مشابهی را برای مدیریت آسیبپذیریها به کار گرفت.
یک یادداشت آخر: منشأ منبع، به شکل گواهیهای نرمافزاری، که در زمان ساخت مؤلفه تولید میشوند، بخش کلیدی دیگری در تلاش برای ردیابی مصنوع (فایل فشرده مؤلفه) با منابع و فرآیند ساختی است که آن را تولید کرده است. توجه داشته باشید که این پیوند بین تصویر لحظهای منبع + محیط ساخت و مصنوع نرمافزاری مرتبط (امضا شده توسط سیستم ساخت مورد اعتماد) به خودی خود مانع از این نمیشود که مؤلفه حاوی رفتار مخرب نباشد، اما تزریق بدافزار را برای افراد بدخواه دشوارتر میکند. و تبدیل اعتبارسنجی منشأ به یک الزام رایج برای مصرف مؤلفههای منبع باز، زمان زیادی میبرد و فقط ... اخیراً به NPM اضافه شده استمقاومسازی سیستمهای ساخت و استقرار مورد اعتماد در برابر دستکاری، یا فعالسازی تشخیص هرگونه دستکاری در ساخت، داستان متفاوتی است که خارج از محدوده این پست میباشد.
مطالعه بیشتر
قسمت بعدی بستههای مخرب متنباز: رویکرد Xygeni استراتژیای که ما در Xygeni دنبال میکنیم را ارائه خواهیم داد. هشدار زودهنگام بدافزار سیستم (MEW). نسخههای جدید بسته در بستههای عمومی و رجیستریهای تصویر اسکن میشوند و شواهد با استفاده از ترکیبی از تحلیلهای ایستا، پویا، قابلیتها و زمینهای به دست میآیند. شواهد، همراه با اعتبار کاربر و تاریخچه تغییرات در مخازن کد منبع، امکان طبقهبندی کاملاً خودکار یک مؤلفه را به دستههای پرخطر و احتمالاً مخرب فراهم میکند. سیستم از شواهد گذشته جمعآوریشده از بستهها یاد میگیرد تا موارد مثبت کاذب را به حداقل برساند.
سازمانهای مشترک، هنگام طبقهبندی یک نسخه مخرب، یک اعلان هشدار برای مؤلفههایی که به طور مستقیم یا غیرمستقیم از آنها استفاده میکنند، دریافت میکنند. سپس تحلیلگران ما یک تجزیه و تحلیل دستی انجام میدهند که طبقهبندی را تأیید یا رد میکند. برای بدافزارهای تأیید شده، به رجیستری عمومی اطلاع داده میشود تا بتواند تجزیه و تحلیل خود را انجام دهد و معمولاً نسخه مخرب را حذف کند یا اقدامات اضافی مانند مسدود کردن یا حذف حساب کاربری مورد نظر را انجام دهد.
ما توضیح خواهیم داد که چگونه به NPM، PyPI، GitHub و سایر زیرساختهای کلیدی در اکوسیستم متنباز کمک میکنیم تا زمان ماندگاری یک مؤلفه مخرب جدید منتشر شده را تا زمان تأیید بدافزار و حذف آن از رجیستری، کاهش دهند. و چگونه سازمانها میتوانند از سیستم MEW برای محافظت بسیار بهتر در برابر حملات زنجیره تأمین نرمافزار که شامل مؤلفههای متنباز میشود، بهرهمند شوند.
- [1] در هر صورت، کاربران این کامپوننت باید بررسی کنند که آیا فایل فشرده کامپوننت در جایی، مثلاً در یک رجیستری داخلی، ذخیره یا ثبت شده است یا خیر، تا مشکل ریشه کن شود.
- [2] کامپوننت بستهبندیشده شامل یک مانیفست است که محتویات و فرادادههای آن، کد منبع یا کامپایلشده، اسکریپتهای نصب و موارد اضافی مانند مجموعههای آزمایشی را طبق قالب بستهبندی و معمولاً به صورت فشرده اعلام میکند. به این «فایل فشرده کامپوننت» گفته میشود.
- [3] حتی اگر عامل مخرب بتواند یک جزء منتشر شده را به دلیل نقض در خود رجیستری تغییر دهد، یک خلاصه رمزنگاری ساده میتواند هرگونه تغییر در فایل فشرده (tarball) را پس از انجام تجزیه و تحلیل تشخیص دهد.
- [4] به یاد داشته باشید که برخی از اجزای مخرب در زمان نصب اجرا میشوند، بنابراین میتوانند بر گرههای توسعهدهندهای که ناخواسته دستور "npm install X" را با X که یک جزء مخرب است اجرا میکنند، تأثیر بگذارند.
