چگونه امنیت زنجیره تامین نرم افزار را حل خواهیم کرد

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

چه کسی امنیت زنجیره تامین نرم افزار را در اختیار دارد؟ توسعه دهندگان؟ یا پلتفرم و تیم های مهندسی امنیت از آنها پشتیبانی می کنند؟

در گذشته، CIO، CISO یا CTO و تیم امنیتی آنها تصمیم می گرفتند که شرکت از کدام توزیع لینوکس، سیستم عامل و پلتفرم زیرساختی قراردادهای پشتیبانی و SLA های امنیتی خود را دریافت کند. امروزه، توسعه‌دهندگان همه این کارها را در Docker Files و GitHub Actions انجام می‌دهند، و آن نوع نظارت سازمانی که قبل از واگذاری کارها به سمت توسعه‌دهندگان وجود داشت، وجود ندارد.

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

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

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

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

آنچه نرم افزار منبع باز را برای توسعه دهندگان عالی می کند، آن را برای هکرها نیز عالی می کند.

باز است

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

مهاجمان دوست دارند: هر کسی که یک حساب GitHub داشته باشد می‌تواند کد را به کتابخانه‌های مهم کمک کند. ارتکاب کدهای مخرب اغلب اتفاق می افتد. کتابخانه‌ها تصرف می‌شوند و به صاحبان مختلفی منتقل می‌شوند که بهترین منافع همه را در ذهن ندارند.

یک مثال معروف افزونه کروم به نام The Great Suspender بود. شخصی که آن را نگهداری می کند آن را به شخص دیگری تحویل می دهد که بلافاصله شروع به وصل کردن بدافزار کرد. نمونه های متعددی از این نوع تغییر از مشارکت کننده خیرخواه به مشارکت کننده مخرب وجود دارد.

شفاف است

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

مهاجمان دوست دارند: حجم وسیع منبع باز، ممیزی کد را غیرعملی می کند. به علاوه، بسیاری از کدها در منبعی متفاوت از نحوه مصرف واقعی آن توزیع می‌شوند.

به عنوان مثال، حتی اگر به کد منبع یک بسته Python یا Node.js نگاه کنید، وقتی pip install یا npm install را اجرا می کنید، در واقع شما گرفتن یک بسته از آنچه که کامپایل شده است، و هیچ تضمینی وجود ندارد که بسته واقعاً از کد منبعی که شما ممیزی کرده اید آمده باشد.

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

رایگان است

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

مهاجمان عاشق: حمله Heartbleed از سال ۲۰۱۴، اولین تماس بیدارباش بود که نشان می داد چه مقدار از زیرساخت های حیاتی اینترنت با کار داوطلبانه اجرا می شود. نمونه معروف دیگر کتابخانه گلانگ به نام Jwt-go بود. این یک کتابخانه بسیار محبوب بود که در کل اکوسیستم Golang (از جمله Kubernetes) استفاده می‌شد، اما وقتی آسیب‌پذیری در داخل آن پیدا شد، نگهدارنده دیگر برای ارائه اصلاحات در اطراف نبود. این منجر به هرج و مرج شد که در آن مردم با وصله‌های مختلف برای رفع این اشکال کار می‌کردند. در یک نقطه، پنج یا شش نسخه وصله رقیب برای یک باگ وجود داشت، که همگی راه خود را به درخت وابستگی باز می‌کردند، قبل از اینکه بالاخره یک وصله ظاهر شد و آسیب‌پذیری را برای همیشه برطرف کرد.

متن باز برای امنیت زنجیره تامین نرم افزار نیز عالی است

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

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

SLSA

SLSA (سطوح زنجیره تامین برای مصنوعات نرم افزاری، تلفظ شده “سالسا”) مجموعه ای از الزامات تجویزی و مترقی برای ایجاد امنیت سیستم چهار سطح وجود دارد که کاربر تفسیر و پیاده سازی می کند. سطح ۱ استفاده از یک سیستم ساخت است (این کار را با دست روی لپ تاپ انجام ندهید). سطح ۲ صادر کردن برخی گزارش‌ها و ابرداده‌ها است (بنابراین می‌توانید بعداً موارد را جستجو کنید و پاسخ حادثه را انجام دهید). سطح ۳ دنبال کردن یک سری از بهترین شیوه ها است. سطح ۴ استفاده از یک سیستم ساخت واقعا امن است.

تکتون 

Tekton یک سیستم ساخت متن باز است که با در نظر گرفتن امنیت طراحی شده است. بسیاری از سیستم های ساخت می توانند به روش هایی برای ایمن بودن اجرا شوند. Tekton یک نمونه شاخص از پیش فرض های خوب با SLSA است. 

In-Toto

In-Toto و TUF (در زیر) هر دو سالها قبل از اینکه کسی باشد از یک آزمایشگاه تحقیقاتی در دانشگاه نیویورک بیرون آمدند. صحبت در مورد امنیت زنجیره تامین نرم افزار. آنها مجموعه دقیق مراحلی را که در طول یک زنجیره تامین اتفاق می‌افتد ثبت می‌کنند و زنجیره‌های رمزنگاری را به هم متصل می‌کنند که می‌توانند بر اساس سیاست‌ها تأیید شوند. In-Toto روی قسمت ساخت تمرکز می کند، در حالی که TUF روی قسمت توزیع تمرکز می کند (آیا دستکاری شده است؟).

TUF 

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

Sigstore

Sigstore یک چارچوب امضای کد رایگان و آسان برای مصنوعات نرم افزار منبع باز است. امضا کردن راهی برای ایجاد یک زنجیره نگهداری رمزنگاری قابل تایید است، به عنوان مثال، یک رکورد ضد دستکاری از منشاء نرم افزار.

حفاظ های بهتر برای زنجیره تامین نرم افزار

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

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

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

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

New Tech Forum مکانی برای کاوش و بحث در مورد فناوری سازمانی نوظهور در عمق و وسعت بی سابقه ای فراهم می کند. انتخاب ذهنی است، بر اساس انتخاب ما از فناوری هایی که معتقدیم مهم هستند و برای خوانندگان InfoWorld بیشترین علاقه را دارند. InfoWorld وثیقه بازاریابی را برای انتشار نمی پذیرد و حق ویرایش تمام محتوای ارائه شده را برای خود محفوظ می دارد. همه سوالات را به newtechforum@infoworld.com ارسال کنید.