İmsak Vakti 02:00
Bir yazılımın güvenliği artık yalnızca kurumun kendi yazdığı kodla açıklanamaz. Açık kaynak paketleri, dış hizmetler, derleme araçları, güncelleme kanalları ve dağıtım süreçleri aynı zincirin parçalarıdır. Bu zincirin herhangi bir halkası zayıfsa saldırgan, hedef kuruma doğrudan girmek yerine güvenilen bir bileşen üzerinden ilerleyebilir.
Olgu: Yazılım tedarik zinciri riski, kurumun kontrol alanı dışındaki bileşenlerin ürün ve hizmet güvenliğini etkileyebilmesinden doğar. Yorum: Bu risk, tedarikçiye güvenip denetimi bırakmayı değil, güveni ölçülebilir kontrollerle sınırlamayı gerektirir.
Bir kurum hangi uygulamada hangi paket sürümünün, hangi kütüphanenin ve hangi derleme aracının kullanıldığını bilmiyorsa, zafiyet duyurusuna anlamlı yanıt veremez. Bu nedenle ilk adım, yazılım bileşenlerinin görünür bir envanterini oluşturmaktır. Envanter yalnızca ürünün adını değil, sürümünü, sahibini, kullanım amacını ve güncelleme yolunu da içermelidir.
Envanterin sürekli güncellenmesi gerekir. Elle hazırlanan ve değişiklikleri gecikmeli yansıtan listeler, güvenlik kararlarını yanlış yönlendirebilir. Kod depoları, paket yönetimi ve dağıtım süreçleriyle ilişkilendirilen otomatik kayıtlar daha yararlı bir temel sağlar.
Bağımlılık tarama araçları bilinen zafiyetleri görünür kılabilir; fakat her uyarı aynı riski taşımaz. Kullanılmayan bir modül, erişimi sınırlı bir bileşen veya kritik veriye ulaşan bir servis farklı önceliklerde ele alınmalıdır. Teknik bulgunun iş bağlamı olmadan sıralanması, ekipleri düşük etkili işlere yöneltebilir.
Ayrıca saldırı yüzeyi yalnızca kaynak kodundan oluşmaz. Derleme ortamındaki kimlik bilgileri, imza anahtarları, otomasyon hesapları ve dağıtım yetkileri de korunmalıdır. Kod güvenli görünürken üretim hattı ele geçirilirse, saldırgan meşru bir süreçten yararlanarak zararlı değişikliği içeri sokabilir.
Derleme ve dağıtım süreçlerinde görev ayrımı, güçlü kimlik doğrulama, en az yetki ve değişiklik kayıtları temel kontrollerdir. Kritik işlemlerin kim tarafından başlatıldığı, hangi girdilerle çalıştığı ve hangi çıktıyı ürettiği sonradan anlaşılabilmelidir. Bu kayıtlar yalnızca denetim için değil, olay sırasında geriye dönük inceleme için de gereklidir.
Üretilen yazılımın bütünlüğünü korumak amacıyla imzalama ve doğrulama mekanizmaları kullanılabilir. Ancak imza, güvenilirliğin son kanıtı değildir. İmzalama anahtarı kötü korunuyorsa veya süreçte yetkisiz değişiklik yapılabiliyorsa, teknik doğrulama saldırganın işini kolaylaştıran bir perdeye dönüşebilir.
Sözleşmeye birkaç güvenlik maddesi eklemek yeterli değildir. Tedarikçinin erişimleri, olay bildirim yükümlülükleri, güncelleme yöntemi, alt yüklenicileri ve hizmet sona erdiğinde yapılacak işlemler düzenli biçimde gözden geçirilmelidir. Risk, sözleşme imzalandığı gün sabitlenmez; ürün ve tehdit ortamı değiştikçe yeniden hesaplanır.
Gerçekçi savunma, zinciri kusursuzlaştırma iddiasında bulunmaz. Hangi bileşene güvenildiğini, bu güvenin nasıl sınırlandığını ve bir halkanın bozulması halinde etkinin nasıl daraltılacağını gösterir. Yazılım güvenliği, bir tarama raporunun temiz çıkmasıyla değil, değişikliklerin izlenebilir, yetkilerin sınırlı ve toparlanma planının uygulanabilir olmasıyla olgunlaşır.
Sıfır Güven, Teknolojiden Önce Alışkanlıkları Değiştirir