SolarWinds saldırısı ve Apache Log4j güvenlik açığı gibi son zamanlardaki yüksek profilli siber güvenlik olayları, yazılım tedarik zinciriyle ilişkili tehditleri ortaya çıkardı. Bunlar, bilinen güvenlik açıklarının oldukça basit istismarlarından çok karmaşık saldırılara kadar değişebilir. ulus devlet aktörleri.
Ticari kullanıma hazır veya COTS yazılımı olarak da bilinen kurumsal yazılımlara yapılan yıllık harcama artık yaklaşıyor %11,5 büyüme oranıyla 600 milyar dolar. Yine de, bu yatırımın büyüklüğü göz önüne alındığında, işletmeler yazılım tedarik zincirlerini güvence altına almak için bir kuruş harcıyorlar. COTS yazılımını bu kadar tehlikeli yapan da budur – açık kaynak bileşenlerinde güvenlik açıkları “gizlenebilir”. Ancak, bir yazılım malzeme listesinde (SBOM) bunun için bir düzeltme vardır.
COTS Güvenlik Duruşunu İyileştirme
Geleneksel olarak işletmeler, yazılım satıcılarının kabul edilen yazılım mühendisliği en iyi uygulamalarını izleyerek ve yazılımlarını desteklemek için güvenlik uygulamalarını açıklayarak gerekli güvenlik durum tespitini gerçekleştirdiğine güvenir. Müşteriler ise, satıcı riski ve yazılım güvenliği ile ilgili bilgileri paylaşmak için dernekler veya kullanıcı grupları aracılığıyla kullandıkları ürünlerin güvenliğini araştırmak zorunda kalırlar.
Apache Log4j güvenlik açığının gösterdiği gibi bu yaklaşımlar açıkça yeterli değildir. Yazılım satıcılarının en iyi niyetlerine rağmen, COTS yazılımı oluşturmak için kullanılan açık kaynaklı bileşenlerde çok fazla güvenlik açığı gizleniyor. Bu, satıcıların kendilerinin bile bilmediği bir yazılım güvenliği kör noktasını temsil eder. Bu kör noktayı aydınlatmak için gereken anahtar eser SBOM’dur.
SBOM, bir yazılım ürününü oluşturan yazılım bileşenlerinin bir envanter raporudur. – JTıpkı gıda ürünlerindeki etiketlerde olduğu gibi, bir içerik listesi ve beslenme bilgileri vardır.
SBOM’lar ve Güvenlik Açığı Tespiti
Yazılım tedarik zinciri güvenliğini otomatikleştirmek, COTS uygulamalarına ilişkin derin bir görünürlük gerektirir. Bu, kuruluşa yönelik güvenlik risklerini gerçekten anlamak için bir Malzeme Listesine erişimin yanı sıra ayrıntılı güvenlik açığı bilgilerini içerir.
Ek olarak, bir SBOM genellikle uyumluluğun sağlanmasına yardımcı olmak ve yazılımın piyasaya sürülmesi veya lisanssız bileşenlerle tüketilmesi riskini azaltmak için lisans bilgilerini içerir. Bu lisans bilgileri, birden çok Apache Log4j sürümünde olduğu gibi, bir açık kaynak bileşeninin hangi sürümünün bir güvenlik tehdidine karşı savunmasız olduğunu araştırırken adli tıpta da yardımcı olabilir.
SBOM Çıktıları ile Riski Azaltma
Bir güvenlik açığı keşfedildiğinde, bir SBOM tarafından sağlanan verileri kullanmanın birkaç yolu vardır. İlk olarak, sonuçları olasılık ve etki açısından değerlendirin. Olasılık, keşfedilen güvenlik açığı kullanılarak bir saldırının başarılı olma olasılığının belirlenmesidir. Etki, şirket markasına, kârlılığa ve müşteri deneyimine yönelik hem anlık hasarı hem de uzun vadeli etkiyi dikkate almalıdır.
Aşağıdaki kadran yaklaşımı, COTS yazılımında bulunan açık kaynak güvenlik açıklarını değerlendirmenin etkili bir yoludur. Örneğin, bazı güvenlik açıklarına sahip ve düşük etkiyle kullanılmasının muhtemel olmadığı düşünülen yazılımlar, yalnızca düşük risk düzeyini kabul ederek satın alma, yenileme veya bakım sözleşmesi için onaylanabilir. Açıkçası, etkisi yüksek, saldırı güvenlik açıkları olasılığı yüksek olan yazılımların reddedilmesi gerekebilir.
Ancak, iş için kritik olan yazılımları basitçe reddetmek çoğu zaman mümkün değildir. COTS tedarik sürecinde SBOM verilerinin kullanılması nispeten yeni bir disiplin olsa da, buradaki varsayım, hem müşterinin hem de satıcının, ürünün güvenliğini artırmak ve zaman içinde güvenlik riskini azaltmak için iyi niyetle hareket edeceğidir. Bu değerlendirme süreci, halihazırda dağıtılan yazılıma da uygulanabilir. Aşağıdaki çizim, SBOM sonuçları elde edildiğinde izlenecek daha incelikli bir karar iş akışını göstermektedir.
-Reddetmeyi onayla
SBOM ve güvenlik açığı raporu, kabul edilemez sayıda yüksek düzeyde güvenlik açığı olduğunu gösteriyorsa ve risk çok yüksekse, ürün reddedilmelidir (sol üstte). Benzer şekilde, ürün sadece küçük bir risk arz ediyorsa kabul edilebilir.
–Koşullu Onay
Bir ürünün güvenlik sorunları ortaya çıkardığı (sağ üstte) ancak yazılım için iş gereksinimlerinin risklerden ağır bastığı durumlarda, ürün şartlı olarak onaylanabilir. Bu durumlarda, güvenlik ekibi uygulayabilir telafi edici güvenlik kontrolleri dağıtımdan önce ve bilinen güvenlik açıklarını hedefleyen potansiyel tehdit etkinliğini izleyin. Ek olarak, satıcı bu güvenlik açıklarından habersiz olabileceğinden, riski gidermek için satıcıyla birlikte çalışmak çok önemlidir. Açıklama ve işbirliği anahtardır.
-Şartlı olarak Reddet
Yazılım ürünü iş açısından kritikse ancak güvenlik riski çok yüksekse (yukarıdaki alt çeyrekler), ürün koşullu olarak reddedilebilir. Bu gibi durumlarda, dağıtıma devam etme kararı, yazılımın işletme için ne kadar kritik olduğuna bağlı olacaktır. Güvenlik riskinin çok yüksek olduğu durumlarda, kuruluş sorunların dağıtımdan önce düzeltilmesinde ısrar edebilir veya yazılımın güvenlik açığını gideren yeni bir sürümünü bekleyebilir.
Yazılımın iş için kritik olduğu ve günlük operasyonlar için gerekli olduğu aşırı durumda, kuruluş, satıcıyla kullanımına ilişkin finansal, yasal ve sorumluluk koşullarını müzakere edebilir.
SBOM’lar tarafından sağlanan veriler, yeni ürün tedarikinden konuşlandırılmış uygulamaların korunmasına kadar yazılım tedarik zinciri güvenliğini geliştirmek için kullanılabilir. COTS yazılımı söz konusu olduğunda, yukarıda sunulan risk kadran modeline SBOM çıktılarının uygulanması, kuruluşların proaktif olarak riski azaltmasına ve işlerini yürüten yazılımdaki tehditleri ortadan kaldırmasına yardımcı olabilir.
