امنیت منبع باز در سال ۲۰۲۲ مبارزه کرد

یک سال پس از فاجعه Log4j، تلاش‌های جامعه منبع باز و زنجیره‌های ابزار توسعه‌دهنده جدید در حال بررسی چالش‌های امنیت زنجیره تامین نرم‌افزار هستند.

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

Log4j برای بسیاری از سازمان‌ها یک رویداد فلج‌کننده بود که تلاش می‌کردند بفهمند که آیا و در کجا ابزار گزارش‌گیری منبع باز محبوب را در محیط‌های خود اجرا می‌کنند یا خیر. اما Log4j همچنین صنعت را وادار کرد تا با ماهیت گذرای اکسپلویت‌های زنجیره تامین نرم‌افزار و اینکه چقدر آسان است برای اکسپلویت‌ها از بین وابستگی‌های نرم‌افزاری جهش پیدا کند. پایان دادن به سال ۲۰۲۱ برای تیم های امنیتی روش جالبی نبود.

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

به عبارت دیگر، فروشندگان امنیت افکار و دعاها را می فروختند، نه راه حل های واقعی.

همه در پاسخ خود آنقدر مبهم نبودند. این چالش امنیتی زنجیره تامین نرم افزار به طور خاص به منبع باز متصل است. واقعیت این است که برنامه‌های کاربردی مدرن عمدتاً با چارچوب‌های منبع باز با منشأ امنیتی ناشناخته ساخته می‌شوند. شما فقط نمی توانید یک راه حل سازمانی داشته باشید که همه منبع باز را ایمن کند – در آن جهت کار نمی کند. به نظر می رسد که پاسخ باید از خود جامعه منبع باز باشد. در سال ۲۰۲۲، این کار را انجام داد.

یک پاسخ عظیم جامعه

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

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

جای تعجب نیست که بنیاد لینوکس و بنیاد محاسبات بومی ابری به شدت در تحقق این امر در پروژه‌های منبع باز کلیدی مشارکت داشته‌اند. برای مثال، قالب SPDX SBOM راه خود را به پلتفرم‌های بزرگی مانند Kubernetes باز کرده است. بنیاد امنیت منبع باز بیش از ۱۰۰ عضو و میلیون ها دلار بودجه برای استانداردها و ابزارهای بیشتر دارد. زبان‌های ایمن برای حافظه مانند Rust توسط هسته لینوکس پشتیبانی می‌شوند برای جلوگیری از آسیب‌پذیری‌های مرتبط با مصنوعات نرم‌افزاری.

احتمالاً قابل‌توجه‌ترین فناوری فردی که در طول سال گذشته در معرض استفاده قرار گرفته است، Sigstore است، ابزار امضای کد که در Google و Red Hat متولد شد و عملاً به “واکس” تبدیل شده است. seal” اکنون در رجیستری های نرم افزار منبع باز و زنجیره های ابزار تعبیه شده است. Kubernetes، npm و PyPi از جمله پلتفرم ها و رجیستری هایی هستند که Sigstore را به عنوان استانداردهای امضای خود پذیرفته اند. نکته مهم این است که همه این امضاهای Sigstore وارد یک گزارش شفافیت عمومی می شوند، که ضربان قلب جدید مهمی برای اکوسیستم امنیتی برای شروع اتصال نقاط بین امضای نرم افزار، صورتحساب های مواد نرم افزاری (SBOM) و کل زنجیره تامین امنیت نرم افزار زنجیره ابزار منشأ امنیتی است. .

یک جهش آشنا از منبع باز به تجاری

هرکسی که در ۲۰ سال گذشته – یا حتی دو سال گذشته – به منبع باز توجه داشته باشد، از اینکه ببیند علایق تجاری در اطراف این فناوری های منبع باز محبوب شروع به شکوفا شدن کند، تعجب نخواهد کرد. همانطور که استاندارد شده است، آن موفقیت تجاری معمولاً c-l-o-u-d نوشته می شود. در اینجا یک مثال برجسته وجود دارد: در ۸ دسامبر ۲۰۲۲، Chainguard، شرکتی که بنیانگذاران آن Sigstore را در زمانی که در Google بودند، ایجاد کردند، Chainguard Enforce Signing را منتشر کرد که به مشتریان امکان می دهد از Sigstore-as-a-service برای تولید امضای دیجیتالی برای مصنوعات نرم افزاری در داخل سازمان خود با استفاده از هویت فردی خود و یک بار استفاده کنند. -از کلیدها استفاده کنید.

این قابلیت جدید به سازمان‌ها کمک می‌کند از یکپارچگی تصاویر کانتینر، تعهدات کد، و سایر مصنوعات با امضای خصوصی اطمینان حاصل کنند که می‌توانند در هر نقطه‌ای که مصنوع باید تأیید شود، تأیید شوند. همچنین اجازه می دهد تا یک خط تقسیم را ایجاد کند که در آن مصنوعات نرم افزار منبع باز به صورت باز در یک گزارش شفافیت عمومی امضا می شوند. با این حال، شرکت ها می توانند نرم افزار خود را با همان جریان امضا کنند، اما با نسخه های خصوصی که در گزارش عمومی نیستند. مسیر Chainguard مشابه GitHub است: توسعه دهندگان می توانند مخازن عمومی نامحدود ایجاد کنند اما باید برای مخازن تیم خصوصی هزینه کنند.

این همه به کجا می رود؟

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

مدیر عامل Chainguard و خالق Sigstore، Dan Lorenc، اولین کسی است که اعتراف می کند که تا چه حد باید پیش رفت، به ویژه در اطراف SBOM ها که در آن فضای خالی زیادی بین تئوری و واقعیت برای توسعه دهندگان وجود دارد. او به شوخی می گوید اگر توسعه دهندگان روش های آسانی برای ایجاد امنیت در مصنوعات نرم افزاری در اوایل چرخه عمر توسعه نرم افزار نداشته باشند، نتیجه «حدس-BOMs» است.

Lorenc به امضای نرم‌افزاری اشاره می‌کند که توسط Sigstore امکان‌پذیر شده است و به طور کلی پروژه‌های بزرگی که توسط سازمان‌های منبع باز (صنعت و دولت) حمایت می‌شوند. او آن را به عنوان مدرکی می‌بیند که بسیاری از قدرت برای حل این چالش امنیتی زنجیره تامین نرم‌افزار در جایی که متعلق به آن است قرار می‌گیرد: در دست توسعه‌دهندگان با ابزارهای مناسب.