YORUM
Sonrasında Log4j, yazılım tedarik zincirleri güvenlik sorunları açısından daha fazla inceleme altındadır. ABD hükümeti zorunlu yazılım malzeme listeleri (SBOM’lar) federal yazılım projeleri için kullanılır; böylece güvenlik ekipleri yazılım bileşenlerinden kaynaklanan potansiyel riskleri anlayabilir. Siber Güvenlik ve Altyapı Güvenliği Ajansı (CISA), Avrupa Birliği Komisyonu, Birleşik Krallık Ulusal Siber Güvenlik Merkezi ve Japonya, SBOM’ların nasıl daha kullanışlı ve değerli hale getirileceği konusunda işbirliği yapıyor.
Ancak aşılması gereken sorunlar var. Aslında SBOM’ları uygulamak, birçok bilgi güvenliği sorumlusu (CISO) için hâlâ öncelikler listesinde yer alıyor. Birleşik Krallık’taki CISO’lara nedenini sorduğumda konu önceliklendirmeye geldi. Başa çıkmanız gereken bu kadar çok sorun varken, bugün bir SBOM ne kadar değer sağlıyor?
Bunun yanı sıra, söz konusu yazılımın bakımından kimin sorumlu olduğu sorunu da var. Bu, dahili ekibinizin oluşturduğu birinci taraf uygulaması mı, yoksa bir tedarikçiden satın aldığınız üçüncü taraf uygulaması mı? Kuruluşunuz için üçüncü taraf bir geliştirici tarafından geliştirilen dış kaynaklı yazılıma ne dersiniz? SBOM’u ve kodu yönetme sorumluluğunu kim üstlenmeli?
Yazılım Tedarik Zinciri Güvenliği ve Sorumluluk Atama
Yazılım dünyasında, iş yükleri talebe göre dakikadan dakikaya oluşturulup durdurulabildiğinden, nelerin kullanıldığını takip etmek zordur. Ancak, nelerin kurulu, nelerin çalışmakta olduğu ve nelerin savunmasız olabileceğine ilişkin doğru listelere sahip olmak, risk yönetimi söz konusu olduğunda çok önemli olacaktır.
Bütün bunlar teoride mantıklıdır. Peki neden CISO’ların, güvenlik ekiplerinin ve geliştiricilerin öncelik listesinde yer alıyor? Buradaki zorluk, bu programların uygulamaya nasıl aktarılacağıdır. İlgilenmesi gereken bu kadar çok BT, gerçekleşen çok fazla değişiklik ve takip edilmesi gereken çok fazla yazılım varken, veriler ekipleri bunaltabilir.
Uygulama güvenliği ve yönetimine ilişkin sorumluluğun oluşturulması, pratik sorumluluklara odaklanmalıdır. Örneğin, yazılım genellikle dış kaynaklı sağlayıcılar tarafından oluşturulur. Bu sözleşmeler, geliştirme görevinin bir parçası olarak SBOM teslimatının yanı sıra zaman içinde bu belgelerin muhafazasından kimin sorumlu olacağını da içermelidir. En önemli unsur, birinin sorumlu tutulması ve organizasyonun geri kalanının da sorumluluklarını bilmesidir.
Ekiplerin Etkili Bir Şekilde İşbirliği Yapmasına Yardımcı Olmak
SBOM’lar hızla olgunlaşıyor ancak standartlaştırılmadan önce hala kat edecekleri yol var. Çoğu zaman, güvenlik sorunları meşhur sıcak patates haline gelir ve mümkün olduğunca çabuk bir sonraki kişiye aktarılır. Geliştiricilere yüzlerce veya binlerce yazılım sorununu düzeltmeleri için atamak, bu düzeltmelerin sihirli bir şekilde gerçekleşmesini sağlamaz; Aslında takımlar neye konsantre olacaklarını bilemediğinden daha fazla soruna yol açabilir.
Bunu çözmek için, SBOM’lar ve varlık yönetiminden başlayıp güvenlik ve geliştirici ekipleri arasında uygun önceliklendirme tartışmalarıyla devam ederek yazılım tedarik zinciri güvenliği konusunda daha iyi uygulamalar uygulamamız gerekiyor. Her iki ekibin de sorunları düzeltme veya güncellemeleri dağıtma sürecini daha fazla otomatikleştirmesi gerekiyor.
Güvenlik açısından bu, düşük riskli sorunlar için otomatik yamalamayı içerecektir. Geliştiriciler için bu, güvenliği tasarım uygulamalarıyla uygulamak anlamına gelecektir. BT güvenliği, geliştiricilerin iş akışlarına erkenden entegre olan araçlar sağlayabilir, böylece sorunlar daha erken çözülebilir. Güvenlik, sorunları gidermenin diğer yollarını işaretleyerek de yardımcı olabilir.
Örneğin birlikte çalıştığım bir CISO’nun hem güvenlik hem de yazılım geliştirmede ekiplerin morali bozuldu. Uç noktalarda, uygulamalarda ve altyapıda bir milyondan fazla yazılım sorunu ve güvenlik açığı mevcuttu. Bu sorunun temel nedenini bulmak için sorunların nerede var olduğuna baktık. Yazılım görüntü kitaplıklarındaki güncellemelerden doğrudan sorumlu kimsenin olmadığı kısa sürede anlaşıldı. Her iki taraf da sorunlarla başa çıkmak için çok çalışıyordu, ancak o kütüphaneden ne zaman yeni bir görüntü yaratılsa, “eski” sorunlar yeniden ortaya çıkıyordu. Bu görüntüler aynı zamanda Java’nın birden fazla sürümünü de içeriyordu ve bu da onları görüntü başına yüzlerce güvenlik açığı tespitinden sorumlu kılıyordu.
Herkesi bir masa etrafında toplamak ve bu görüntüleri düzeltmek, güvenlik açıklarının ve uyarıların sayısını önemli ölçüde azaltır. Ekip, olağanüstü güvenlik açığı sayısının yarı yarıya azaldığını gördü, bu da zaman kazandırdı ve her iki tarafın da birbirini daha fazla takdir etmesini sağladı.
Veriler olmadan bu tür bir tartışma mümkün değildir. Dolayısıyla SBOM’ların öncelik listesinin çok gerisinde olduğunu söyleyenlere göre bunların yeterince yüksek olmadığını gördüm. Daha fazla bilgi edinmek, birinci taraf yazılımlar da dahil olmak üzere tüm sistemlerinizde önceliklendirme yapmanıza yardımcı olur; böylece ekipleriniz için daha fazla işbirliği, gerçek değişim ve gerçek başarı elde edebilirsiniz.