Google, teknoloji devi yazılım tedarik zincirinin güvenliğini sağlamak için en iyi uygulamaları derinlemesine inceledikten sonra, kuruluşların daha iyi yazılım güvenliği ve bütünlüğü sağlamak için yazılım oluştururken Yazılım Eserleri için Tedarik Zinciri Düzeyleri (SLSA) çerçevesini uygulamaları gerektiğini savunuyor.
9 Aralık’ta yayınlanan bir raporda Google, tedarik zinciri güvenliğini desteklemek için kuruluşların açık kaynaklı yazılımlar için daha doğrudan sorumluluk alma ihtiyacı ve riskleri ele almak için daha bütüncül bir yaklaşım benimseme ihtiyacı da dahil olmak üzere çeşitli öneriler ortaya koydu. Log4J güvenlik açığı ve SolarWinds ihlali.
Google’ın yazılım güvenliğiyle ilgili raporu, yeni bir “Güvenlik Perspektifleri” Gelişmekte olan güvenlik trendlerini ve bunların nasıl ele alınacağını inceleyen araştırma serisi. Raporun yayınlanması, SolarWinds ihlali ifşasının ikinci yıldönümünde geliyor ve rapordaki tavsiyeler, Google’ın bu olayla ilgili analizine ve o zamandan bu yana çok sayıda diğer yazılım tedarik zinciri ihlallerine dayanıyor. • Bunlar, Codecov, Kaseya’daki olayları ve PyPI gibi genel kod havuzlarını içeren olayları içerir.
İhlaller, yazılım tedarik zinciri güvenliğini kurumsal BT gündeminin en önemli maddesi haline getirdi. Mandiant’ın yakın tarihli bir raporu, tedarik zinciri tavizlerini şu şekilde tanımladı: tüm izinsiz girişlerin %17’sine katkıda bulunuyor 2021’de, sadece bir yıl önceki %1’in altındaydı. Aslında tedarik zinciri sorunları, 2021’deki yazılım güvenlik açığı istismarlarından sonra en sık görülen ikinci ilk saldırı vektörüydü.
Güvenlikle İlgili Karar Vericiler İçin İki Temel Çıkarım
Google’ın mühendislikten sorumlu başkan yardımcısı Royal Hansen, “Kurumsal BT ve güvenlik karar vericilerinin, yazılımın bütünlüğünü güvenli bir şekilde oluşturmalarına ve doğrulamalarına yardımcı olacak, bu rapordan çıkarılacak iki ana çıkarım var” diyor.
Birincisi, belirtildiği gibi, güvenlik liderlerinin yazılım tedarik zinciri saldırılarına karşı savunmayı güçlendirmek için daha bütüncül bir yaklaşım benimsemeye odaklanması gerektiğidir: “Kuruluşlar ayrıca Software Artifacts (SLSA) çerçevesi için SupplyChain Düzeyleri güvenlik topluluğunun tüm yazılım tedarik zinciri ekosistemindeki tehditleri azaltmasını sağlamak için” diyor.
SLSA (“salsa” olarak telaffuz edilir), yazılım geliştiricilere, üretime kadar tüm yazılım geliştirme yaşam döngüsü boyunca yazılım güvenliğini ve bütünlüğünü sağlamak için bir dizi kontrol ve uygulama sağlar. Temel hedeflerinden biri, kuruluşlara SolarWinds’te meydana gelen ve bir saldırganın sisteme kötü amaçlı kod eklediği türden kurcalamayı önleme ve tespit etme yolu sunmaktır. — ve imzalı bir yazılım güncellemesi aracılığıyla dağıttı.
SLSA, kural koyucu bir kontrol listesidir, yani kuruluşların atması gereken adımları açıklar. Buna, örneğin, yazılımlarındaki tüm açık kaynaklı ve üçüncü taraf bileşenlerin kaynağının doğrulanması ve yazılımda herhangi bir tahrifat yapılmadığından emin olunması dahildir.
Diğer şeylerin yanı sıra, kuruluşların kaynak kodunu süresiz olarak muhafaza etmelerini ve yazılımlarının bütünlüğünü kurcalamaya dayanıklı kaynak bilgileriyle doğrulama yeteneğine sahip olmalarını da gerektirir.
Google, SLSA çerçevesini, kuruluşların bir yazılım malzeme listesi (SBOM’ler), yani belirli bir yazılım parçasındaki tüm bileşenlerin bir listesi gibi şeylerin faydalarını optimize etmesine izin verdiği şeklinde algılar.
Daha Fazla Sorumluluk Üstlenmek
Google, tedarik zinciri güvenliğini endüstri düzeyinde desteklemenin diğer anahtarlarından birinin de kuruluşların kendi açık kaynak ve tescilli yazılım tedarik zincirlerini güvence altına almaları olduğunu söyledi.
Bu, oluşturdukları veya başka kaynaklardan edindikleri tüm yazılımların temel güvenlik standartlarını ve kontrollerini uygulamasını sağlamak anlamına gelir. Örnek olarak Google, aralarında Okta, Salesforce, Slack ve Venafi’nin de bulunduğu birkaç başka şirketle işbirliği içinde geliştirdiği kurumsal kullanıma hazır yazılımlar için Minimum Uygulanabilir Güvenli Ürün (MVSP) gereksinimlerine işaret etti.
MVSP bir temel güvenlik kontrollerinin kontrol listesi bir yazılım geliştiricinin makul ölçüde güvenli bir ürün sağlamak için en azından uygulaması gerekir. Kontrol listesi, yazılım satıcısının veya yayıncının güvenlik açığı raporları yayınlayıp yayınlamadığı, kendi kendine değerlendirmeler ve harici testler yapıp yapmadığı ve SSO, HTTPS ve güvenlik başlıkları gibi uygulamaları uygulayıp uygulamadığı gibi şeyleri içerir.
Google, yazılım satın alanların, bir ürünün bu gereksinimleri karşılayıp karşılamadığını değerlendirmek için taban çizgisini kullanabileceğini, daha büyük şirketlerin ise üçüncü taraf yazılım tedarikçilerinin güvenlik duruşlarını öncelik sırasına koyarken MVSP’yi standart anketleri olarak dahil edebileceğini söyledi. Google, tedarik ekiplerinin bunları teklif istekleri (RFP) belgelerine dahil edebileceğini ve satıcı seçimi için güvenlik temeli olarak kullanabileceğini söyledi.
Hansen, güvenlik liderlerinin ve uygulayıcılarının yazılım tedarik zinciri güvenliğini desteklemek için başka önlemler de alabileceklerini söylüyor. “Rapordan elde edilen bulgular, yazılım tedarik zinciri ağlarının daha kapsamlı bir şekilde anlaşılması, potansiyel risklerin belirlenmesi ve risk azaltma planlarının uygulanması ve yazılım tedariki için güvenlik gereksinimlerinin oluşturulması gerektiğini gösteriyor” diye belirtiyor.
Hansen, güvenlik kuruluşlarının, örneğin Açık Kaynak Güvenlik Vakfı’na (OSSF) ve açık kaynak kodundaki güvenlik açığını bulan ve düzelten açık kaynak yazılım projesi sahiplerine fon sağlayarak bir rol oynayabileceğini söylüyor.