Container İmaj Güvenliği ve Runtime Drift: Neden Hâlâ Kritik?

Image Scan Gerekli Ama Yeterli Değil

Konteyner güvenliği çoğu kurumda image scan ile başlayıp image scan ile bitiyor. Bu değerli bir başlangıç noktası; ancak üretim gerçeği çok daha karmaşık. Cluster içinde çalışan şey yalnızca build edilip taranmış imaj değil. Runtime davranışı, mount edilen secret'lar, başlatılan süreçler, oluşturulan ağ yolları ve deploy sonrası biriken durum kayması da işin parçası.

Çalışma Zamanı Sapması (Runtime Drift) Neden Önemli?

Çalışma zamanı sapması (runtime drift), platformun çalışmasını beklediği ile şu anda gerçekte çalışan arasındaki boşluğu tanımlıyor. Bu boşluk şunları kapsayabilir:

orijinal imajda bulunmayan paketlerin çalışan konteynere yüklenmesi.

beklenen uygulama temelini karşılamayan süreçlerin başlatılması.

normal uygulama davranışının dışındaki hedeflere ağ bağlantıları kurulması.

image build taraması sırasında görünür olmayan secret'ların runtime'da mount edilmesi.

konteyner runtime politikasının öngörmediği yetki yükseltmeleri.

Bunların her biri, image scan'in tek başına tespit edemediği gerçek bir güvenlik durumunu temsil ediyor. Temiz taranan bir imaj, runtime ortamı izlenmiyorsa deploy sonrası dakikalar içinde ele geçirilmiş konteynere dönüşebilir.

Tedarik Zinciri Boyutu

Image scan önemli bir risk sınıfını ortaya koyuyor: build sırasında çekilen temel imaj ve üçüncü taraf bağımlılıklarındaki zafiyetler. Bu, konteyner güvenliğinin tedarik zinciri boyutu. Kritik CVE içeren bir temel imaj, uygulama katmanı ne olursa olsun üzerinde inşa edilen her konteynere bu zafiyeti taşıyor.

Konteynerler için etkili tedarik zinciri hijyeni şunları içeriyor:

sessiz temel imaj güncellemelerini önlemek için kayan etiketler yerine imaj digest'lerini sabitlemek.

her imaj katmanında hangi CVE'lerin bulunduğunu ve hangilerinin uygulamanın gerçekten yüklediği paketlerde olduğunu takip etmek.

upstream zafiyetler yamalandığında imajları derhal yeniden oluşturmak.

imajda var olan zafiyet ile konteynerin runtime konfigürasyonu göz önüne alındığında bir saldırgan tarafından gerçekten erişilebilir olan zafiyet arasındaki farkı anlamak.

Bu son nokta önemli. Uygulamanın yüklemediği bir kütüphanedeki kritik CVE, her istekte çağrılan bir kütüphanedeki kritik CVE'den farklı. Erişilebilirlik bağlamı, tarama sonucunu ham sayıdan önceliklendirilmiş eylem listesine dönüştürüyor.

Runtime Güvenlik Kontrolleri Neye Benziyor?

Konteynerler için runtime güvenliği, deploy sonrasında anormal davranışları tespit etmeye ve engellemeye odaklanıyor. Pratik kontroller:

Süreç izin listesi: bir konteynerin içinde hangi süreçlerin çalışması gerektiğini tanımlamak ve beklenmedik süreçler göründüğünde uyarı vermek.

Ağ politikası zorlaması: çıkış ve girişi beklenen hedeflerle kısıtlamak ve konteynerler politika dışı bağlantı girişiminde bulunduğunda uyarı üretmek.

Dosya sistemi değişmezliği: mümkün olan yerlerde konteyner dosya sistemini salt okunur olarak ele almak ve beklenmedik konumlara yazma girişimlerini tespit etmek.

Syscall filtreleme: uygulamanın meşru bir ihtiyacı olmayan sistem çağrılarını engellemek için seccomp profillerini kullanmak.

Yetki kısıtlaması: root olmayan çalıştırmayı zorlamak ve çekirdek düzeyinde yetki yükseltmesini önlemek.

Bu kontrollerden hiçbiri yalnızca image scan'den türetilemiyor. Hepsi runtime görünürlüğü gerektiriyor.

Kubernetes Katmanı

Kubernetes ortamlarında konteyner güvenliği pod ve cluster düzeyine uzanıyor. Güvenlik açısından kritik konfigürasyonlar:

temel güvenlik duruşunu zorlayan Pod Security Standards veya admission controller'lar.

namespace'ler ve pod'lar arasında yanal hareketi kısıtlayan ağ politikaları.

hangi service account'ların yetki yükseltme için kullanılabileceğini sınırlayan RBAC konfigürasyonları.

anormal cluster operasyonlarını tespit etmek için API sunucusu düzeyinde denetim günlüğü.

Temiz imajlı ve sağlam runtime kontrollerine sahip bir konteyner, Kubernetes RBAC konfigürasyonu service account'ın yetki yükseltmesine veya secret sızdırmasına izin veriyorsa yine de ele geçirilebilir.

Dockerfile Güvenlik En İyi Uygulamaları

Sertleştirme build aşamasında başlar. Aşağıdaki tablo yaygın Dockerfile hatalarını bunları gideren güvenlik kontrolüyle eşliyor:

| Uygulama | Ne Yapılmalı | Neden Önemli |

| --- | --- | --- |

| Minimal base image kullan | ubuntu:latest yerine alpine veya distroless | Daha az paket = daha küçük CVE yüzeyi |

| Base image digest'i sabitle | FROM alpine@sha256:abc123... | CVE getiren sessiz upstream güncellemelerini önler |

| Root olmayan kullanıcıyla çalıştır | CMD'den önce USER nonroot | Konteyner kaçışının blast radius'unu sınırlar |

| Capability'leri düşür | Çalışma zamanında --cap-drop=ALL | Uygulamanın ihtiyaç duymadığı Linux capability'lerini kaldırır |

| Çok aşamalı build kullan | Bir aşamada derle, temiz aşamaya binary kopyala | Build araçlarını ve derleyicileri üretim imajından çıkarır |

| Salt okunur dosya sistemi ayarla | Çalışma zamanında --read-only + yazılabilir yollar için tmpfs | Beklenmedik yazma işlemlerini tespit eder ve engeller |

| Seccomp profili uygula | Docker'ın varsayılanı veya özel profil kullan | Konteynerin yapabileceği sistem çağrılarını kısıtlar |

Bunlar image scanning'in zorlayamadığı build-time ve runtime kontroller. CI/CD pipeline'larında ve konteyner runtime politikasında bilinçli konfigürasyon gerektiriyorlar.

MyVuln Yaklaşımı

MyVuln, imaj tarama bulgularını CVE severity, exploitation durumu ve etkilenen sürüm aralıklarıyla ilişkilendirerek konteyner zafiyet takibini destekliyor. Zafiyetli konteynerin internete açık olup olmadığı ve hangi süreçleri ortaya çıkardığı gibi çalışma zamanı maruziyet bağlamıyla birleştirildiğinde, elde edilen önceliklendirme ağırlıksız tarama bulguları listesi yerine gerçek operasyonel riski yansıtıyor. MyVuln'un zafiyet veritabanı CVE'leri etkilenen paket ve sürüm aralığına göre izliyor — böylece ekipler base image katmanındaki CVE'nin konteynerin çalışma zamanı konfigürasyonu göz önüne alındığında gerçekten erişilebilir olup olmadığını belirleyebiliyor.

Image scanning size build anındaki gerçeği verir. İmaj derlendiğinde hangi paketlerin mevcut olduğunu, o anda temel katman ve yüklü yazılımla ilişkili bilinen CVE'lerin neler olduğunu ve derlenmenin registry push zamanındaki politikaları karşılayıp karşılamadığını yanıtlar. Runtime drift (çalışma zamanı sapması) ise farklı ve çoğu zaman operasyonel açıdan daha kritik bir hikâye anlatır: üretime gerçekte ne ulaştı ve imaj onaylandığından bu yana ne değişti.

Tarama anı ile çalışma zamanı arasındaki boşluk teorik değildir. Somut bir drift örneği:

Registry tarama sonucu (onaylandı):
  temel: ubuntu:22.04
  paketler: nginx 1.24.0, openssl 3.0.2
  CVE'ler: 0 kritik, 2 düşük (kabul edildi)
  Durum: ONAYLANDI ✓

Çalışma zamanı durumu (72 saat sonra):
  Deploy sonrası eklendi: python3, pip, requests kütüphanesi (debug oturumu)
  Mount edilmiş credential'lar: özgün onaydan daha geniş kapsam (ops config yamaladı)
  Aktif süreçler: /bin/bash (etkileşimli shell — operatör açık bıraktı)
  Ağ bağlantıları: 203.0.113.42:4444'e beklenmedik egress
  Durum: KRİTİK DRIFT — araştırma gerekiyor

Bu kritik bir boşluktur: registry taramasından temiz geçen bir imaj, birikimli runtime değişiklikleri nedeniyle önemli ölçüde farklı bir güvenlik duruşuna dönüşebilir. Bu sorun yoğun debug pratiğinin, geçici operasyonel müdahalelerin ve yetersiz runtime politika uygulamasının bulunduğu ortamlarda en keskin biçimde ortaya çıkar. Önem taşıyan sorular yalnızca "imaj taramadan geçti mi?" ile sınırlı değildir: çalışan iş yükü beklenen binary'yi mi çalıştırıyor? Beklenen sistem çağrılarını mı yapıyor? Mount edilmiş credential'ların kapsamı değişti mi? Container'a etkileşimli erişim kalıcı bir operasyonel kalıba mı dönüştü?

Olgun yaklaşım build ve runtime katmanlarını birbirini tamamlayan kanıtlar olarak birlikte okur. Image scanning, registry kapısında erken uyarı sağlar; runtime görünürlüğü ise bu sertifikalandırılmış durumun üretimde varlığını sürdürüp sürdürmediğini gösterir. Bir kurum bu katmanları ilişkilendirebildiğinde "build anındaki bilinen zafiyet" ile "aktif runtime riski" arasındaki boşluğu kapatır. Container güvenliği böylece bir CI pipeline adımından çıkıp; yalnızca registry'de onaylanmış olanı değil, üretimde gerçekte çalışanı izleyen sürekli, yaşayan bir iş yükü izleme modeline olgunlaşır.