منبع باز ناامن نیست

منبع باز مشکل امنیتی ندارد. مشکل توزیع داره

فرانک کرین در مورد منبع باز صحبت نمی‌کرد که به قول معروف گفت: “اگر زیاد اعتماد کنید ممکن است فریب بخورید، اما اگر اعتماد کافی نداشته باشید در عذاب زندگی خواهید کرد.”

اما این یک راه عالی برای خلاصه کردن شکاف امروزی بین نحوه مصرف  واقعی منبع باز، در مقابل الگوهای اعتماد صفر است که شرکت‌ها در تلاش برای کدگذاری در شیوه‌های DevSecOps خود هستند. .

هر مطالعه ای که می بینم نشان می دهد که بین ۹۰٪ تا ۹۸٪ از نرم افزارهای جهان منبع باز هستند. همه ما در حال استفاده از کدهایی هستیم که توسط افراد دیگر نوشته شده است – روی شانه‌های غول‌ها ایستاده‌اند – و همه آن کد را ایجاد و اصلاح می‌کنیم و به طور ضمنی به هر نویسنده، نگه‌دارنده و مشارکت‌کننده‌ای که پیش از ما آمده است اعتماد می‌کنیم.

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

بیایید نگاهی به تکامل توزیع نرم‌افزار بیندازیم، و در کجا باید ریشه‌های اعتماد جدید برای پشتیبانی از نوآوری‌های منبع باز دهه‌های آینده کاشته شود.

نرم افزار منبع باز امن است

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

اما منبع باز ثابت کرده است که وقتی کد منبع شفاف دارید، یک اثر مثبت وجود دارد. تأثیر شبکه بسیاری از چشم‌ها بر روی کد منبع، آسیب‌پذیری‌ها را سریع‌تر آشکار می‌کند و چرخه‌های بسیار سریع‌تری برای اصلاح ایجاد می‌کند. نتایج به خودی خود صحبت می کنند: ۹۰٪ از آسیب پذیری های شناخته شده مورد سوء استفاده (در لیست CVE که توسط CISA نگهداری می شود) نرم افزار اختصاصی هستند، علی رغم این واقعیت که حدود ۹۷٪ از همه نرم افزارها منبع باز هستند.

هرگاه آسیب‌پذیری بزرگی وجود داشته باشد، بدتر کردن وضعیت کلی امنیت منبع باز بسیار آسان است. در واقع، بسیاری از این آسیب‌پذیری‌های دارای بالاترین مشخصات، قدرت امنیت منبع باز را نشان می‌دهند. برای مثال Log4shell، بدترین موردی برای آسیب‌پذیری OSS در مقیاس و سطح دید – این یکی از پرکاربردترین کتابخانه‌ها در یکی از پرکاربردترین زبان‌های برنامه‌نویسی بود. (Log4j حتی روی مریخ‌نورد اجرا می‌شد. از نظر فنی این اولین آسیب‌پذیری OSS بین کهکشانی بود!) آسیب‌پذیری Log4shell برای بهره‌برداری بی‌اهمیت، فوق‌العاده گسترده و پیامدهای جدی بود. نگهبانان توانستند آن را وصله کنند و در عرض چند روز عرضه کنند. این یک پیروزی بزرگ برای پاسخ امنیتی منبع باز در سطح نگهدارنده بود، نه یک شکست.

و این دستاورد باید به طور گسترده به رسمیت شناخته شود. زمان افشا و رفع چند روزه را با برنامه‌های افشای فروشندگان سفت‌افزار یا ارائه‌دهندگان ابری مقایسه کنید که در بهترین حالت ۳۰، ۶۰، حتی ۹۰ روز طول می‌کشد تا راه‌حل‌هایی مانند این را ارائه کنند. با این حال، شرکت ها در پاسخ به اقدامات لازم در برابر آسیب پذیری عقب مانده اند. بر اساس گزارش اخیر از Veracode، بیش از یک سوم یا ۳۸ درصد از برنامه‌هایی که Log4j را اجرا می‌کنند، هنوز از نسخه‌های آسیب‌پذیر برنامه استفاده می‌کنند.

اما منبع باز نیاز به اعتماد دارد

وقتی برای اولین بار شروع به ساختن نرم افزار خود می کنید، این فقط نوک کوه یخ بالای سطح است. شما در حال ساختن بر روی میلیون ها خط نرم افزار رایگان هستید که برای منافع عمومی و به صورت رایگان ساخته شده اند. این به دلیل اعتماد امکان پذیر است.

توزیع‌های لینوکس – علاوه بر مدیریت کامپایل کد منبع و دوری از کاربران OSS از کامپایل و اشکال‌زدایی – باید به خاطر نقش عظیمی که در ایجاد این اعتماد ایفا کردند، اعتبار داشته باشند. وقتی از باینری ها از یک توزیع لینوکس استفاده می کنید، به نگهبانان بالادستی اعتماد دارید که کد منبع و توزیع را می نویسند. این دو مجموعه متفاوت از افراد است. توزیع‌کنندگان لینوکس این را درک کردند و واقعاً در چند دهه گذشته، با رویکردهای پیشگام در زنجیره تأمین نرم‌افزار، و با ایجاد روش‌های سخت‌گیرانه برای بررسی نگه‌دارنده‌های بسته، وضعیت هنر در امنیت نرم‌افزار را ارتقا دادند.

دبیان یکی از برجسته‌ترین شرکت‌ها در این زمینه به دلیل پیچیدگی‌اش در رمزگذاری اعتماد در توزیع است. دبیان از سیستم علامت کلید PGP استفاده می کند، جایی که تنها در صورتی که نگهبانان کافی کلیدها را برای رویدادهای رمزگذاری امضا کنند، به کلید دبیان اضافه می شوند. این امضاها با آپلود بسته های جدید بررسی می شوند و سپس خود توزیع دبیان همه بسته هایی را که سوار شده اند دوباره امضا می کند. بنابراین وقتی از دبیان منتشر می‌شوند، کاربران می‌توانند بدون توجه به جایی که آن بسته‌ها را پیدا کنند، آن امضاها را بررسی کنند و مطمئن شوند که این بسته‌ها از طریق توزیع دبیان از نگهدارنده‌هایی که به آن‌ها اعتماد دارند و بسته‌ها در راه دستکاری نشده‌اند، آمده‌اند.

این مدلی است که فوق العاده خوب کار کرده است.

و وابستگی های OSS از مدل های اعتماد فراتر رفته اند

اما امروزه، بیشتر مصرف نرم افزار در خارج از توزیع اتفاق می افتد. خود مدیران بسته زبان برنامه‌نویسی – npm (جاوا اسکریپت)، pip (Python)، Ruby Gems (Ruby)، آهنگساز (PHP) )—شبیه مدیران بسته توزیع لینوکس به نظر می رسند و احساس می کنند، اما آنها کمی متفاوت عمل می کنند. آنها اساساً مدیریت صفر را ارائه می دهند – هر کسی می تواند یک بسته را آپلود کند و یک نگهدارنده زبان را تقلید کند. و چگونه می‌دانید به چه چیزی اعتماد دارید، وقتی یک نصب بسته واحد اغلب بسته‌هایی را از ده‌ها نفر دیگر تصادفی در اینترنت نصب می‌کند؟

Docker این مشکل اعتماد گذرا را چند برابر کرد. ساخت تصاویر Docker آسان است زیرا از مدیران بسته موجود در داخل آنها استفاده می کنند. می‌توانید از نصب npm برای دریافت بسته‌های npm استفاده کنید، سپس آن را در یک تصویر Docker قرار دهید. می توانید یک برنامه را با مدیران بسته هر زبانی نصب کنید، سپس آن را به عنوان یک توپ بزرگ TAR ارسال کنید. Docker این شکاف اعتماد را تشخیص داد و به اعتبار خود سعی کرد آن را با چیزی به نام Verified Builds، که به یک ویژگی در Docker Hub تبدیل شد، پر کند.

این Docker Verified Builds راهی برای کاربران بود تا اسکریپت ساخت تصویر Docker را در قالب یک فایل Docker در مخزن کد منبع مشخص کنند. نگهدارنده فایل Docker را می نویسد، اما سپس Docker ساخت را انجام می دهد، بنابراین آنچه در تصویر می بینید همان کد نگهدارنده اصلی آن است. Docker این را سال ها پیش عرضه کرد و به بهبود آن ادامه می دهد، بنابراین آنها سزاوار یک فریاد بزرگ هستند.

Docker تنها پخش کننده در این وب اعتماد برای نرم افزار بومی ابری نیست، هرچند. پیچیده تر می شود یک لایه در بالای Docker وجود دارد که معمولاً در قلمرو Kubernetes استفاده می‌شود. Helm به شما امکان می دهد مجموعه ای از تصاویر Docker و پیکربندی را بسته بندی کنید. این یک بسته بسته است.

بنابراین، برای مثال، اگر نمودار Helm را برای Prometheus نصب کنید، احتمالاً تعدادی عکس دیگر را نیز از پروژه‌های شخصی تصادفی دریافت خواهید کرد. ممکن است مطمئن باشید که Prometheus را از نگهبانان Prometheus دریافت می کنید، زیرا مرکز مصنوع نشان می دهد که از یک ناشر تأیید شده آمده است، اما Prometheus اغلب وابستگی هایی دارد که از ناشران تأیید شده نمی آیند.

مخزن رسمی Helm Charts که توسط سازندگان اصلی Helm نگهداری می‌شود، تلاشی تنظیم‌شده برای رمزگذاری اعتماد به این تصاویر بود. این پتانسیل را داشت که همان نوع مدیریت امنیتی ارائه شده توسط توزیع‌های لینوکس را به برنامه‌های بومی ابری بیاورد. اما متأسفانه مقیاس‌پذیری آن بسیار سخت بود و از مدل فدرال‌تری مانند مدیران بسته‌های زبان برنامه‌نویسی استفاده کرد، که در آن هر پروژه نمودار Helm خود را دارد.

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

ایمن سازی نرم افزار از ابتدا

توزیع نرم‌افزار به‌طور چشمگیری با ۲۰ سال پیش متفاوت است، زمانی که از فروشگاه‌هایی مانند CompUSA یا Best Buy نرم‌افزارهای بسته‌بندی شده خریداری می‌کردید. هنگامی که یک جعبه نرم افزار خریداری می کردید، دقیقاً می دانستید که چه چیزی دریافت می کنید. شما می‌دانستید که از طرف شخصی است که قرار است باشد، و دستکاری نشده است.

از آنجایی که توزیع نرم‌افزار از CD-ROM به اینترنت منتقل شد، توزیع‌های لینوکس به طرز شگفت‌آوری در ارائه اعتماد موفق بودند.

وقتی Log4j و SolarWinds برخی از شکاف‌هایی را که حملات زنجیره تامین نرم‌افزار جدید از آنها سوء استفاده می‌کنند را نشان دادند، تیم‌ها شروع به قفل کردن سیستم‌های ساخت با استفاده از چارچوب‌هایی مانند SSDF و SLSA، و بررسی امضاهای نرم افزار تولید شده توسط Sigstore (اکنون روش پیش‌فرض امضای نرم‌افزاری است که توسط Kubernetes و همه رجیستری‌های اصلی زبان برنامه‌نویسی استفاده می‌شود). این پیشرفت است.

این دامنه امنیتی منبع باز پیچیده است. ما در مورد مدل‌های اعتماد چند دهه در مقابل ۳۷۲ میلیون مخزن تنها در GitHub صحبت می‌کنیم!

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

در سال ۲۰۲۴، شاهد بسته شدن شکاف های امنیتی زنجیره تامین نرم افزار بین CVE ها، توزیع های لینوکس و بسته های نرم افزاری خواهیم بود. شاهد کاهش قابل توجهی در مصنوعات نرم افزاری غیرضروری خواهیم بود که در داخل توزیع ها و تصاویر ارسال می شوند و خود توزیع ها شروع به رقابت می کنند بر اساس اینکه چگونه می توانند رفع آسیب پذیری ها را با بیشترین سرعت ممکن انجام دهند، مانند Wolfi.

ما شروع به شنیدن تیم‌های امنیتی خواهیم کرد که انتظارات خود از امنیت زیرساخت برنامه‌ها را با مفاهیم اعتماد صفر همسو می‌کنند و دیگر دسته‌ای از موارد زیر را در توزیع‌ها و تصاویر خود که ممکن است شکاف‌ها و درهای پشتی را به وابستگی‌های گذرا معرفی کنند، نمی‌پذیریم. ما تیم‌های امنیتی را خواهیم دید که می‌خواهند با فناوری‌هایی مانند eBPF و Cilium به هسته نزدیک‌تر شوند و از اجرای سیاست‌های امنیتی در زمان اجرا که پروژه‌هایی مانند Tetragon می‌توانند ارائه کنند، استفاده کنند. و ما شاهد تسریع این قفل توسط موارد استفاده از هوش مصنوعی خواهیم بود که از شرکت‌ها می‌خواهند به چارچوب‌های حتی بیشتر با وابستگی‌های گذرا بیشتر، از جمله معماری‌های تخصصی GPU و درب‌های پشتی ظریف‌تر اعتماد کنند.

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

دن لورنک مدیر عامل و یکی از بنیانگذاران Chainguard< /a>. او قبلا مهندس نرم افزار کارکنان و سرپرست تیم امنیتی منبع باز گوگل (GOSST) بود. او پروژه هایی مانند Minikube، Skaffold، TektonCD و Sigstore را پایه گذاری کرد.

انجمن فناوری جدید مکانی را برای رهبران فناوری – از جمله فروشندگان و سایر مشارکت‌کنندگان خارجی – فراهم می‌کند تا فناوری سازمانی نوظهور را در عمق و وسعت بی‌سابقه بررسی و بحث کنند. انتخاب ذهنی است، بر اساس انتخاب ما از فناوری هایی که معتقدیم مهم هستند و برای خوانندگان InfoWorld بیشترین علاقه را دارند. InfoWorld وثیقه بازاریابی را برای انتشار نمی پذیرد و حق ویرایش تمام محتوای ارائه شده را برای خود محفوظ می دارد. همه پرس و جوها را به doug_dineley@foundryco.com.