Güvenlik

Container İmaj Taraması ve Tedarik Zinciri Güvenliği

Yeşil renkli bir tarama raporu güvenli imaj demek değildir. Neyin tarandığını, neyin dışarıda kaldığını ve tedarik zincirinin hangi halkalarında sessiz risk kaldığını anlatıyoruz.

Container imaj taraması, güvenlik pratiğinin en kolay ölçülebilir ama en yanıltıcı halkasıdır. Bir imaj için sıfır bulgu gösteren rapor, imajın güvenli olduğunu göstermez; yalnızca kullanılan tarayıcının kendi veri tabanında bilinen bir kayıt bulamadığını gösterir. Rapor ile gerçeklik arasındaki fark, tedarik zinciri güvenliğinin başlangıç noktasıdır.

Tarama neyi görüyor, neyi görmüyor

Statik bir imaj tarayıcısı, katmanları açar, paket yöneticisinin (apk, apt, yum) kurdukları paketleri listeler ve bunları bir zafiyet veri tabanı ile eşleştirir. Bu adımda görebildikleri sınırlıdır: yalnızca paket veri tabanında kayıtlı olan sürüm bilgisi görülür.

Görmediği çok şey vardır. İmajın curl ile indirdiği bir ikili dosya paket kaydı bırakmaz. Statik derlenmiş bir kütüphane, hangi sürümü içerdiğini dışarı vermez. Base imaj katmanları alt alta binerken silinen ama katmanda hâlâ duran dosyalar görünmezleşir. Bir de bilinmeyen zafiyetler vardır; tanım gereği bilinmediği için taranamaz da. Bu sınırların farkında olmadan verilen "sıfır bulgu" güvencesi, yanlış bir güven duygusu üretir.

SBOM olmadan tarama körlemesine

SBOM (Software Bill of Materials), bir imajın içinde tam olarak nelerin olduğunu yazılı bir envanter olarak tutar. CVE listesi bu envanterin zamanla değişen zafiyet veri tabanıyla eşleşmesidir. İkisi farklı şeydir: SBOM statiktir ve imaj için bir kez oluşturulur; CVE listesi her gün değişir.

Bunun pratik sonucu şudur: bugün yayımlanan bir CVE için hangi imajlarınızın etkilendiğini geriye dönük görebilmeniz, yalnızca eski imajlar için SBOM tutuyorsanız mümkündür. Aksi halde her imajı yeniden tarayıp yeniden değerlendirmek gerekir; bu da tarama pahalıysa (yani gerçek bir üretim ortamında) pratikte yapılmaz. Kendi container registry hizmetimizde her push edilen imaj için SBOM üretiliyor ve imajın yaşam süresi boyunca yeni CVE'lerle otomatik olarak yeniden eşleştiriliyor.

CVE değil, sömürülebilir CVE

Bir imajda bulunan CVE'lerin çoğu, o imajın çalıştığı yerde sömürülebilir değildir. Bir CVE'nin sömürülmesi için o kodun gerçekten yürütülmesi, saldırgan girdisinin oraya ulaşabilmesi ve uygun bir tetikleyicinin var olması gerekir. Bir cron job olarak çalışan ve dışarı hiçbir port açmayan bir konteynerdeki HTTP kütüphanesi CVE'si, teorik olarak vardır ama uygulamada erişilebilir değildir.

Bu ayrımı yapmayan bir güvenlik ekibi, yüzlerce bulgu içeren raporlar önünde önceliklendirme yapamaz ve zamanla listeyi kapatır. Doğru işleyiş bulgu sayısını değil, bulguların çalışma zamanındaki karşılığını önceliklendirmektir: internetle konuşan bir servisteki uzaktan kod çalıştırma zafiyeti, bir batch işindeki aynı zafiyetten önce ele alınır. Zafiyet yönetimi tarafında bu önceliklendirmeyi çalışma zamanı bağlamıyla birleştiriyoruz.

İmzalama ve admission politikası

Tarama, imajın içindeki risklerle ilgilenir; imzalama ise imajın kaynağının doğrulanmasıyla. Bu ayrı bir tehdit sınıfıdır: tedarik zincirinin bir yerinde birinin sizin imajınızın yerine başka bir imaj koyması. İmza, imajı üreten sürecin özel anahtarıyla oluşturulur; cluster tarafındaki admission controller imzayı doğrular ve doğrulanmamış imajı çalıştırmayı reddeder.

Bu tek başına yeterli değildir. Politika tarafında ek kurallar gerekir: imaj hangi registry'den gelebilir, hangi imza sertifikası ile imzalanmış olmalı, kritik namespace'lerde hangi imajlara izin verilir. Bu kurallar admission katmanında yazılmadığı sürece imzalama kâğıt üstünde bir güvence olarak kalır. Aynı disiplinin ağ tarafındaki karşılığını zero-trust ve mikro segmentasyon yazısında ele almıştık; imaj politikaları o resmi tamamlar.

Sık sorulan sorular

İmaj taraması hangi zafiyetleri görmez?

Statik bir tarama yalnızca paket veri tabanında kayıtlı olanı görür. İmaja sonradan indirilen ikili dosyaları, derleme sırasında birleştirilen kütüphaneleri ve base imajın altında gizli kalan katmanları çoğu zaman kaçırır. Bilinmeyen bir CVE ise tanım gereği taranamaz.

SBOM ile CVE listesi aynı şey mi?

Hayır. SBOM, imajın içinde ne olduğunun envanteridir; CVE listesi ise o envanterin bilinen zafiyetlere karşı eşleştirilmiş halidir. SBOM olmadan yeni bir CVE yayımlandığında hangi imajlarınızın etkilendiğini geriye dönük görmek çok zordur.

Tarama nerede yapılmalı: build'de mi, registry'de mi?

İkisi de. Build zamanı taraması geliştiriciye erken uyarı verir; registry taraması imajın yayımlandıktan sonra yeni çıkan CVE'lerle olan durumunu izler. Sadece build'de tarayıp bırakmak, imajın ömrü boyunca yeni zafiyetlerin görünmez kalmasına yol açar.

İmaj imzalama neyi çözüyor?

İmzalama, cluster'ın çalıştırdığı imajın gerçekten sizin build sürecinizden çıktığını doğrular. Aradaki tedarik zincirinde imaj değiştirildiyse imza geçersizleşir ve admission controller çalıştırmayı reddedebilir.

Base imajı ne sıklıkla yenilemeliyim?

Sabit bir sürüm etiketine değil, düzenli yeniden build'e bağlanmalıdır. Base imajın altındaki paketler günlük olarak yamalanır; sizin imajınız aynı base'i haftalarca kullanırsa bilinen yamalar sizde çalışmıyor demektir. Haftalık otomatik yeniden build makul bir alt sınırdır.

Tarama ve imza altyapısını biz kuralım

SBOM üretimi, sürekli CVE eşleştirme ve imzalı imaj politikaları dahil registry tarafını uçtan uca yönetiyoruz.

Container registry hizmeti Uzmanla görüşün

İlgili yazılar

DevOps

CI/CD'de Secret Yönetimi

İmajı üreten pipeline'ın kendisinde sırların nerede sızdığı ve nasıl kapatıldığı.

Güvenlik

Zero-Trust ve Mikro Segmentasyon

Cluster içi trafiğin varsayılan olarak düz olduğu bir dünyada ağın nasıl kapatıldığı.