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

از امضای بسته تا SBOM تا زنجیره‌های ابزار توسعه‌دهنده جدید، بخش‌های ایمن‌سازی زنجیره تامین نرم‌افزار شروع به جمع شدن می‌کنند.

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

از آن زمان، ما برای بهبود در حال دویدن هستیم.

شاید مهم‌تر از همه، پروژه Sigstore، که Google آن را منبع باز کرد، تبدیل به روش امضای واقعی برای مصنوعات نرم‌افزاری شد که توسط همه اکوسیستم‌های زبان اصلی از جمله جاوا، پایتون، نود، روبی پذیرفته شد. ، و بیشتر. این پروژه به یکی از سریع‌ترین پروژه‌های امنیتی منبع باز پذیرفته شده در تاریخ تبدیل شد و به توسعه‌دهندگان یک “مهر مومی” از اعتبار برای تعیین منشا و منشأ بلوک‌های سازنده نرم‌افزارشان داد.

پس، آیا ما هنوز آنجا هستیم؟

امپراتوری امنیتی پاسخ می دهد

نه واقعا. نه هنوز. مفهوم لایحه مواد نرم افزاری (SBOM) معرفی شده توسط فرمان کاخ سفید در می ۲۰۲۱ همچنان دور از ذهن است. این مفهوم از زبان فرانسه برای توسعه دهندگان برای به اشتراک گذاشتن لیستی از مواد تشکیل دهنده در بسته های نرم افزاری دارای چندین فرمت در حال ظهور (SPDX، CycloneDX) است که همه چیز را پیچیده می کند. بدتر از آن، مشخص نیست که SBOMها واقعاً چگونه در جریان کار توسعه‌دهندگان قرار می‌گیرند و توسعه‌دهنده چه مزایای خاصی در این فرآیند به دست می‌آورد.

آنچه شروع به جمع‌آوری همه این‌ها می‌کند – و ایجاد فوریت بیشتر برای ایجاد یک استراتژی منسجم در مورد امضای نرم‌افزار، SBOM‌ها و گردش کار توسعه‌دهنده – مقرراتی است که مستلزم مالکیت دقیق‌تر یکپارچگی امنیت نرم‌افزار است.

در ماه آوریل، آژانس امنیت سایبری و زیرساخت (CISA) درخواستی برای اظهار نظر در مورد فرم تایید توسعه نرم افزار ایمن که مسئولیت را بر عهده مدیران عامل شرکت های نرم افزاری می گذارد تا تأیید کنند که نرم افزار آنها در محیط های امن ساخته شده است و تلاش های معقول و حسن نیت برای حفظ کد منبع قابل اعتماد انجام شده است. زنجیره های تامین.

چه چیزی “معقول” محسوب می شود؟

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

صبر کن، چی؟ مسئول کدهای تصادفی نگهدارنده پروژه هستید؟ ظاهرا بله. آیا این “معقول” است؟

این گسترش سرگیجه‌آور ملاحظات مربوط به CISOها به سرچشمه تعدادی از میم‌های توییتر تبدیل شده است:

یک زنجیره ابزار برای زنجیره تامین

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

Chainguard ممکن است چنین شخصی باشد.

Chainguard شرکتی است که توسط کارمندان سابق Google در پروژه Sigstore رهبری می‌شود. در تلاش است تا همه اینها را در یک زنجیره ابزار منسجم برای توسعه دهندگان جمع کند. تلاش‌های اولیه این استارت‌آپ بر مراحل قفل کردن فرآیند ساخت و ایجاد ویژگی‌هایی مانند امضا، منشأ و SBOM بومی زنجیره‌های تامین نرم‌افزار و فرآیند ساخت نرم‌افزار متمرکز بود. سال گذشته با Wolfi اولین انجمن لینوکس را معرفی کردند   (غیر)توزیع که به طور خاص حول محورهای اولیه امنیت زنجیره تامین ساخته شده است. آنها همچنین Chainguard Images را راه‌اندازی کردند که تصاویر پایه برای باینری‌های مستقل، برنامه‌هایی مانند nginx و ابزارهای توسعه مانند کامپایلرهای Go و C هستند.

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

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

Chainguard دو طرف مشکل را هدف قرار داده است. اول، به عنوان نگهبان Sigstore، این شرکت امضای نرم‌افزار، گواهی‌نامه‌ها و مدیران گواهی را به تمامی زبان‌های برنامه‌نویسی و ثبت‌های اصلی هدایت می‌کند، بنابراین یکنواختی و سازگاری در نحوه ایجاد SBOM توسط این پروژه‌های منبع باز وجود دارد. با انتشار اخیر Enforce، پلتفرم به‌طور خودکار یک SBOM با استفاده از Syft ایجاد می‌کند تا توسعه‌دهندگان برای دیدن اطلاعات بسته جامع برای هر تصویر نیازی به انجام مراحل اضافی نداشته باشند.

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

یاد بگیرید SBOM را دوست داشته باشید

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

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

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