XZ Utils Scare حقایق سخت را در امنیت نرم افزار افشا می کند

کشف اخیر یک درب پشتی در ابزار فشرده سازی داده XZ Utils - که تقریباً در تمام توزیع‌های اصلی لینوکس وجود دارد - یادآور این است که سازمان‌هایی که اجزای منبع باز را مصرف می‌کنند، در نهایت مسئولیت امنیت نرم‌افزار را بر عهده دارند.

XZ Utils، مانند هزاران پروژه منبع باز دیگر، به صورت داوطلبانه اجرا می شود و در مورد خود، یک نگهدارنده دارد که آن را مدیریت می کند. چنین پروژه هایی اغلب منابع کمی برای رسیدگی به مسائل امنیتی دارند، به این معنی که سازمان ها از نرم افزار با مسئولیت خود استفاده می کنند. کارشناسان امنیتی می گویند، این بدان معناست که تیم های امنیتی و توسعه باید اقداماتی را برای مدیریت ریسک منبع باز به همان روشی که با کدهای توسعه یافته داخلی انجام می دهند، اجرا کنند.

جیمی اسکات، موسس مدیر محصول در آزمایشگاه اندور می‌گوید: «در حالی که بعید است که یک سازمان بتواند به طور مؤثر از [همه] قرار گرفتن در معرض خطرات زنجیره تأمین جلوگیری کند، سازمان‌ها می‌توانند کاملاً بر روی یک استراتژی برای کاهش احتمال موفقیت‌آمیز بودن حمله زنجیره تأمین تمرکز کنند».

منبع باز با برون سپاری یکسان نیست: «نگهبانان منبع باز نرم افزار داوطلب هستند. در سطح صنعت، ما باید با آنها به این شکل رفتار کنیم. ما صاحب نرم افزار خود هستیم. ما مسئول نرم افزاری هستیم که دوباره استفاده می کنیم.»

با نیت خوب، کم منابع

نگرانی در مورد امنیت نرم افزار منبع باز به هیچ وجه جدید نیستند اما اغلب به اکتشافاتی مانند آسیب پذیری Log4Shell و درب پشتی در XZ Utils واقعاً نشان می دهد که سازمان ها چقدر در برابر مؤلفه های کد خود آسیب پذیر هستند. و اغلب، این کد از پروژه‌های منبع باز با نیت خوب و در عین حال ناامیدکننده‌ای می‌آید که دارای منابع کمتری هستند و حداقل نگهداری می‌شوند.

به عنوان مثال، XZ Utils اساساً یک پروژه یک نفره است. فرد دیگری موفق شد درب پشتی را به داخل ابزارآلات مخفی کنید طی یک دوره تقریباً سه ساله، با به دست آوردن تدریجی اعتماد کافی از طرف نگهدار پروژه. اگر یک توسعه‌دهنده مایکروسافت در اواخر ماه مارس هنگام بررسی رفتارهای عجیب و غریب مرتبط با نصب دبیان به آن برخورد نمی‌کرد، ممکن بود درب پشتی روی میلیون‌ها دستگاه در سراسر جهان از جمله دستگاه‌های متعلق به شرکت‌های بزرگ و سازمان‌های دولتی به پایان برسد. همانطور که مشخص شد، درب پشتی کمترین تأثیر را داشت زیرا نسخه‌های XZ Utils را که فقط در نسخه‌های ناپایدار و بتا Debian، Fedora، Kali، open SUSE و Arch Linux وجود داشتند، تحت تأثیر قرار داد.

سوء استفاده از کد منبع باز بعدی می تواند بسیار بدتر باشد. دونالد فیشر، یکی از بنیانگذاران و مدیرعامل Tidelift می گوید: ترسناک ترین بخش برای سازمان های سازمانی این است که برنامه های کاربردی آنها بر روی پروژه های نرم افزاری منبع باز درست مانند XZ Utils ساخته شده اند. او می‌گوید: «XZ Utils یک بسته ده‌ها هزار نفری است که هر روز توسط سازمان‌های سازمانی معمولی استفاده می‌شود.

او خاطرنشان می کند که اکثر این سازمان ها دید کافی نسبت به امنیت و انعطاف پذیری این بخش از زنجیره تامین نرم افزار خود ندارند تا بتوانند ریسک را ارزیابی کنند.

اخیر مدرسه کسب و کار هاروارد این مطالعه ارزش تقاضای نرم افزار منبع باز را 8.8 تریلیون دلار برآورد کرد. فیشر می گوید که نگهدارنده ها در هسته این اکوسیستم قرار دارند و بسیاری از آنها به تنهایی پرواز می کنند. نظرسنجی انجام شده توسط Tidelift در سال گذشته نشان داد که 44٪ از نگهبانان پروژه منبع باز خود را تنها نگهدارنده پروژه های خود توصیف می کنند. شصت درصد خود را به عنوان سرگرمی های بدون دستمزد معرفی کرده اند و همین درصد نیز گفته اند که یا ترک کرده اند یا به ترک نقش خود به عنوان نگهبان پروژه فکر کرده اند. فیشر می‌گوید بسیاری از نگهبانان تلاش‌های خود را به‌عنوان کاری استرس‌زا، تنها و بدون پاداش مالی توصیف کردند.

فیشر می‌گوید: «هک XZ Utils خطرات سرمایه‌گذاری کم در سلامت و انعطاف‌پذیری زنجیره تأمین نرم‌افزار منبع باز [که] سازمان‌های سازمانی به آن تکیه می‌کنند، کاهش می‌دهد. «سازمان‌های سازمانی باید بدانند که اکثر بسته‌های متن‌باز که بیشترین اعتماد را دارند، توسط داوطلبانی نگهداری می‌شوند که خود را به عنوان سرگرمی‌های بدون دستمزد توصیف می‌کنند. این نگهدارنده‌ها تامین‌کنندگان سازمانی نیستند، اما انتظار می‌رود که مانند آنها کار کنند و تحویل دهند.»

خطر: وابستگی های گذرا

A مطالعه ای که اندور انجام داد در سال 2022 متوجه شد که 95 درصد از آسیب‌پذیری‌های منبع باز در وابستگی‌های گذرا یا بسته‌های منبع باز ثانویه یا کتابخانه‌هایی وجود دارند که بسته‌های منبع باز اولیه ممکن است به آن‌ها وابسته باشند. اغلب، این‌ها بسته‌هایی هستند که توسعه‌دهندگان مستقیماً خودشان آن‌ها را انتخاب نمی‌کنند، اما به‌طور خودکار توسط یک بسته منبع باز در پروژه توسعه‌شان استفاده می‌شوند.

اسکات می‌گوید: «به عنوان مثال، وقتی به یک بسته Maven اعتماد می‌کنید، به‌طور میانگین ۱۴ وابستگی اضافی وجود دارد که به طور ضمنی به آنها اعتماد دارید. این عدد در اکوسیستم‌های نرم‌افزاری خاص مانند NPM که در آن شما به‌طور متوسط ​​۷۷ جزء نرم‌افزار دیگر را برای هر مورد اعتماد وارد می‌کنید، حتی بیشتر است.

او می‌گوید یکی از راه‌های شروع به کاهش خطرات منبع باز توجه به این وابستگی‌ها و انتخابی بودن در مورد پروژه‌هایی است که انتخاب می‌کنید.

سازمان‌ها باید وابستگی‌ها را بررسی کنند، به‌ویژه بسته‌های کوچک‌تر و تک‌نفره‌ای که توسط تیم‌های یک و دو نفره اداره می‌شوند. دیمیتری استیلیادیس، مدیر ارشد فناوری اندور و یکی از بنیانگذاران. آنها باید تعیین کنند که آیا وابستگی ها در محیطشان دارای کنترل های امنیتی مناسب هستند یا اینکه یک فرد تمام کدها را انجام می دهد. آیا آنها فایل های باینری در مخازن خود دارند که هیچ کس از آنها اطلاعی ندارد. استیلیادیس می گوید یا حتی اگر کسی به طور فعال پروژه را حفظ کند.

اسکات "تلاش های خود را بر بهبود اثربخشی پاسخ خود متمرکز کنید - کنترل های اساسی مانند حفظ موجودی نرم افزار بالغ یکی از برنامه های با ارزشی است که می توانید برای شناسایی سریع، دامنه و پاسخ به ریسک های نرم افزاری پس از شناسایی داشته باشید." توصیه می کند.

ابزارهای تجزیه و تحلیل ترکیب نرم افزار، اسکنرهای آسیب پذیری، سیستم های EDR/XDR و SBOM ها نیز می توانند به سازمان ها کمک کنند تا به سرعت اجزای منبع باز آسیب پذیر و در معرض خطر را شناسایی کنند.

اعتراف به تهدید

فیشر از Tidelift می‌گوید: «کاهش مواجهه با درک مشترک و تصدیق در C-suite و حتی در سطح هیئت مدیره شروع می‌شود که تقریباً 70 درصد از اجزای یک محصول نرم‌افزاری متوسط، نرم‌افزار متن‌باز است که به‌طور تاریخی توسط مشارکت‌کنندگان عمدتاً بدون غرامت ایجاد شده‌اند».  

مقررات و دستورالعمل‌های جدید در صنعت خدمات مالی، FDA و NIST نحوه توسعه نرم‌افزار در سال‌های آینده را شکل می‌دهند و سازمان‌ها باید اکنون برای آن‌ها آماده شوند. او می گوید: «برندگان در اینجا به سرعت از یک استراتژی واکنشی به یک استراتژی پیشگیرانه برای مدیریت ریسک مرتبط با منبع باز تطبیق می یابند.

فیشر توصیه می کند که سازمان ها از تیم های امنیتی و مهندسی خود بخواهند تا نحوه ورود اجزای منبع باز جدید به محیط آنها را شناسایی کنند. آن‌ها همچنین باید نقش‌هایی را برای نظارت بر این مؤلفه‌ها تعریف کنند و آن‌هایی را که با ریسک‌پذیری شرکت سازگاری ندارند، حذف کنند. "واکنش به مشکلات مرحله آخر به روشی ناکارآمد برای مقابله با مقیاس خطر برای تجارت در چند سال گذشته تبدیل شده است و دولت آمریکا سیگنال می دهد آن دوران رو به پایان است.»

• محتوای مبتنی بر SEO و توزیع روابط عمومی. امروز تقویت شوید.
• PlatoData.Network Vertical Generative Ai. به خودت قدرت بده دسترسی به اینجا.
• PlatoAiStream. هوش وب 3 دانش تقویت شده دسترسی به اینجا.
• PlatoESG. کربن ، CleanTech، انرژی، محیط، خورشیدی، مدیریت پسماند دسترسی به اینجا.
• PlatoHealth. هوش بیوتکنولوژی و آزمایشات بالینی. دسترسی به اینجا.
• منبع: https://www.darkreading.com/application-security/xz-utils-scare-exposes-hard-truths-in-software-security