۲۰۲۲: سال امنیت زنجیره تامین نرم افزار

تقویت زنجیره تامین نرم افزار باید اولویت شماره یک در سال جدید باشد. در اینجا سه ​​زمینه برای تمرکز وجود دارد.

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

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

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

به همین دلیل است که من سال ۲۰۲۲ را سال [منتظر آن باشید] امنیت زنجیره تامین نرم‌افزار اعلام می‌کنم. اما من فقط یک سال را اعلام نمی‌کنم و آن را باقی نمی‌گذارم (آلا مایکل ورشکستگی در “دفتر”).

در زیر سه روش وجود دارد که پیش‌بینی می‌کنم در سال ۲۰۲۲ اهمیت بیشتری پیدا کند (و باید) زیرا سازمان‌ها برای تقویت دفاع خود در برابر حملات زنجیره تامین نرم‌افزار تلاش می‌کنند.

غواصی در اعماق بیسترول

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

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

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

بررسی دقیق تصاویر ظرف و رجیستری

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

اکنون می توانم صدای شما را بشنوم: “اما این سرعت من را کاهش می دهد!” بله، خواهد شد. اما اصطلاح “یک سیب بد” صدق می کند. شما می توانید از شانس خود استفاده کنید، محصولات را با سرعت برق تولید کنید، و شاید همه چیز درست شود. یا می‌توانید فوق‌العاده مراقب باشید، آهسته‌تر، و کاملاً مثبت اندیش باشید که SolarWinds بعدی (یا Kaseya یا…) نخواهید بود.

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

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

ارزیابی SLSA 

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

SLSA بر اساس مجوز باینری برای Borg (BAB) داخلی Google است. ) پلتفرم، یک بررسی اجرای داخلی زمان استقرار که برای اطمینان از اینکه نرم افزار تولید و پیکربندی به درستی بررسی و مجاز شده است طراحی شده است. Google خاطرنشان می کند که پذیرش BAB به کاهش خطرات داخلی کمک می کند، از حملات جلوگیری می کند و از یکنواختی سیستم تولید پشتیبانی می کند.

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

و این روزها به دست آوردن آرامش واقعاً سخت است. اگر قبلاً در مورد همه اینها عصبی نیستید، این نقل قول از نیک ویور، محقق امنیتی در مؤسسه بین‌المللی علوم کامپیوتر دانشگاه برکلی را بررسی کنید و برای لرز در ستون فقرات خود آماده شوید: «حملات زنجیره تأمین ترسناک هستند زیرا واقعاً سخت هستند. برای مقابله، و از آنجایی که آنها به وضوح نشان می دهند که شما به یک محیط زیست کاملاً اعتماد دارید، ویور به Wired گفت. “شما به هر فروشنده ای که کد آن روی دستگاه شما است اعتماد دارید و به هر فروشنده ای اعتماد دارید.”

Google یک اثبات مفهومی SLSA منتشر کرده است که به کاربران امکان می دهد منشأ را در کنار مصنوعات ساخت خود ایجاد و آپلود کنند و بدین ترتیب به سطح SLSA 1 دست پیدا کنند. اثبات مفهوم را بررسی کنید به نظر من، SLSA همچنین به خوبی با درخواست دولت بایدن برای لایحه مواد نرم افزاری به عنوان بخشی از دستور اجرایی بهبود امنیت سایبری کشور.

هرگز زنجیره را نشکن

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

بدون این آرامش ذهنی، سازمان‌ها و مشتریان آن‌ها در وضعیتی مستمر از روی شانه‌های خود خواهند بود. البته، کل ایده یک زنجیره این است که به اندازه ضعیف ترین حلقه آن قوی است، به این معنی که هیچ سازمانی به تنهایی نمی تواند زنجیره تامین نرم افزار را ایمن کند. من در مورد این موضوع با عمق بیشتری در اینجا نوشتم: “بازرسی عمیق کانتینر: آنچه که ویروس Docker Hub Minor و نفوذ XcodeGhost می تواند در مورد کانتینرها آموزش دهد”.

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

ما همیشه به‌دنبال رویداد «قوی سیاه» بعدی هستیم – تهدید نادیده بعدی که می‌تواند سیستم را تکان دهد و تمام کارهایی را که برای ایجاد آن انجام داده‌ایم نابود کند. واقعاً تنها یک دفاع کلی برای این سناریو وجود دارد: به زنجیره تأمین خود توجه کافی داشته باشید!

در Red Hat، اسکات مک کارتی مدیر ارشد محصول RHEL Server است که مسلما بزرگترین تجارت نرم افزار منبع باز در جهان است. مناطق تمرکز شامل ابر، کانتینرها، گسترش حجم کاری و اتوماسیون است. اسکات با همکاری نزدیک با مشتریان، شرکا، تیم‌های مهندسی، فروش، بازاریابی، سایر تیم‌های محصول و حتی در جامعه، تجربه شخصی را با بازخورد مشتری و شریک ترکیب می‌کند تا قابلیت‌های استراتژیک را در لینوکس Red Hat Enterprise افزایش دهد. /p>