توسعه دهندگان نرم افزار یک مشکل امنیتی زنجیره تامین دارند

هر روز، توسعه‌دهندگان نرم‌افزار به طور ضمنی به بسته‌های نرم‌افزاری، تصاویر کانتینر، نگهدارنده‌های وابستگی، اپراتورهای مخزن، و سیستم‌هایی می‌سازند که ما چیزی درباره آن‌ها نمی‌دانیم. این برعکس Zero Trust است.

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

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

محیط‌های ساخت ما به اندازه محیط‌های تولیدی ما ایمن نیستند.

این همان چیزی است که در ۱۲ ماه گذشته به تعداد زیادی حملات پرمخاطب منجر شد، از SolarWinds، حمله Codecov، تا افشای اسرار Travis CI. ما آنقدر در محافظت از زیرساخت‌هایمان خوب عمل کرده‌ایم که مهاجمان به دنبال راه آسان‌تری برای ورود به آن بودند و آن را در درهایی که در زنجیره تامین باز گذاشته‌ایم پیدا کردند.

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

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

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

حتی به عنوان کاربران اینترنت، ما ریشه های اعتماد داریم. ما URI ها، URN ها و URL ها را داریم—در واقع فضاهای نامی در اینترنت هستند که هویت، نام و مکان سایت هایی را که در حال مرور هستیم به هم متصل می کنند. گواهی‌های SSL به مرورگرهای ما می‌گویند که سایت‌ها امن هستند. فایروال های DNS بین حل کننده های بازگشتی کاربر قرار می گیرند تا مطمئن شوند حافظه پنهان ما با درخواست های بد بارگیری نمی شود. همه این‌ها در پشت صحنه اتفاق می‌افتند و برای چندین دهه در حمایت از میلیاردها کاربر اینترنت به‌طور باورنکردنی مؤثر بوده‌اند.

اما امروز این را برای مصنوعات نرم افزاری نداریم.

توسعه‌دهندگان به طور ضمنی بیش از حد اعتماد دارند

رویدادی را مانند نصب Prometheus (یک پروژه مشاهده‌پذیری منبع باز محبوب) از مرکز مصنوعی Cloud Native Computing Foundation (CNCF) معمول کنید. اگر نصب Helm خود را انجام دهید و سپس به تمام تصاویری که کشیده می شوند نگاه کنید و شروع به اجرای کلاستر خود کنید، تصاویر کانتینری زیادی را مشاهده می کنید که در نهایت با یک نصب ساده اجرا می شوند. توسعه دهندگان مجموعه ای کامل از چیزها را به دسته ای کامل از افراد و سیستم های مختلف می سپارند. هر یک از اینها ممکن است دستکاری یا مورد حمله قرار گیرد، یا ممکن است مخرب باشد.

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

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

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

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

چاپ های امنیتی زنجیره تامین نرم افزار

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

مجاز فهرست کردن برچسب‌های خاص مرحله بعدی است. اگر برخی از آموزش‌های مربوط به بهترین شیوه‌ها را با Kubernetes مرور کنید، تنظیم آن بسیار آسان است. اگر همه تصاویر خود را به یک مکان فشار دهید، حداقل می توانید چیزها را به آن مکان محدود کنید. این خیلی بهتر از انجام هیچ کاری است، اما هنوز هم عالی نیست، زیرا هر چیزی که به آنجا فشار داده شود، اکنون در دایره اعتماد شما، درون آن حصار سیم خاردار قرار دارد، و این واقعاً Zero Trust نیست. فهرست مجاز مخازن خاص همه محدودیت‌های یکسانی برای فهرست کردن مجاز برچسب‌های خاص دارند.

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

زمان شروع به پرسیدن سؤالات مناسب است

فرض کنید در حال قدم زدن در پیاده‌روی خارج از محل کار خود هستید، و یک درایو انگشت شست USB را می‌بینید که روی زمین نشسته است. امیدوارم همه بدانند که شما مطلقاً نباید آن درایو را داخل دفتر خود ببرید و آن را به ایستگاه کاری خود وصل کنید. همه در نرم افزار باید (به درستی) فریاد بزنند، “نه!” حملات واقعی از این طریق اتفاق افتاده است و سازمان‌های امنیتی در سراسر جهان این هشدار را به عنوان بخشی از آموزش به همه کارکنان می‌دهند.

اما بنا به دلایلی، ما حتی قبل از اجرای docker pull یا npm install دوبار فکر نمی‌کنیم، حتی اگر این موارد مسلماً بدتر از اتصال تصادفی هستند. استیک USB. هر دو موقعیت شامل گرفتن کد از شخصی است که به او اعتماد ندارید و آن را اجرا می کند، اما ظرف Docker یا بسته NPM در نهایت به محیط تولید شما می رسد!

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

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

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

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

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