Container güvenliğinde en yaygın refleks, imajı registry’ye göndermeden önce bir zafiyet tarayıcısından geçirip kritik bulgu varsa yayını durdurmaktır. Bu temel yaklaşım gereklidir ama tek başına yeterli değildir. Çünkü çoğu ekip aslında hangi bileşenleri taşıdığını bilmeden yalnızca anlık CVE çıktısına göre karar verir. SBOM tabanlı kabul kapısı ise kararı daha sağlam zemine taşır: önce imajın içeriğini görünür kılar, sonra politikayı bu envanter ve zafiyet birleşimi üzerinden uygular.
Neden yalnızca tarama skoru yetmez?
Bir imaj bugün temiz görünebilir, yarın yeni bir CVE ile riskli hale gelebilir. Ayrıca aynı imajda gereksiz shell araçları, unutulmuş dil runtime’ları ya da kurumsal olarak yasaklı paketler bulunabilir. Bunlar doğrudan CVE puanına yansımayabilir. SBOM burada iki şeyi mümkün kılar:
- İmajın içeriğini sürüm bazında kayıt altına almak
- Zafiyet dışındaki politika ihlallerini de konuşabilmek
Syft bu envanteri üretmek için, Grype ise bu envanteri ve imajı zafiyet verisiyle eşlemek için oldukça pratik araçlar sunar.
Basit akış nasıl kurulur?
En yalın boru hattı şu adımlardan oluşur:
- İmajı build edin
- Syft ile SPDX veya CycloneDX formatında SBOM üretin
- Grype ile imajı veya üretilen SBOM’u tarayın
- Çıktıyı bir politika eşiğine göre yorumlayın
- Kabul edilen imajı imzalayıp registry’ye gönderin
Örnek Syft komutu:
syft registry.example.com/platform/api:1.4.2 -o cyclonedx-json > sbom.jsonArdından Grype ile aynı imajı ya da dosyayı tarayabilirsiniz:
grype sbom:sbom.json --fail-on highBu komut yalnızca başlangıçtır. Gerçek değer, --fail-on seviyesini iş bağlamınıza göre ayarladığınızda oluşur.
Politikayı CVE eşiğinden ibaret bırakmayın
Kurumsal kapıda şu kurallar daha sağlıklı sonuç verir:
- Üretim imajlarında kritik zafiyet sıfır tolerans
- Yüksek zafiyetlerde yalnızca istisna kaydıyla geçiş
- Desteklenmeyen taban imajlara otomatik red
- Yasaklı paket veya shell araçlarında red
- SBOM dosyası olmayan build’lerde doğrudan red
Bu sayede kabul kapısı, reaktif tarama adımı olmaktan çıkıp supply chain kontrolü haline gelir.
CI içinde nasıl bağlanır?
GitHub Actions, GitLab CI ya da kendi Jenkins hattınızda temel mantık aynıdır. Build sonrası önce SBOM üretin, sonra tarayın, son olarak sonucu artefact olarak saklayın. Basit bir örnek:
docker build -t app:${GIT_SHA} .
syft app:${GIT_SHA} -o spdx-json > artifacts/sbom.spdx.json
grype sbom:artifacts/sbom.spdx.json --fail-on high --output json > artifacts/grype.jsonSonraki adımda JSON çıktısını politika dosyanızla yorumlayabilirsiniz. Örneğin belirli paket ailelerini yasaklayabilir, CVE skorunu çalışma zamanı profiliyle ağırlıklandırabilir veya yalnızca internete açık servislerde daha sert eşik uygulayabilirsiniz.
Hangi kayıtlar saklanmalı?
Uygulamada şu artefact’ları saklamak önemli fark yaratır:
- İmaj digest’i
- SBOM dosyası
- Grype raporu
- Kabul veya red kararı
- İstisna varsa onay kaydı ve son kullanma tarihi
Böylece üç ay sonra “bu imaj neden geçmişti?” sorusuna savunulabilir cevap verebilirsiniz.
Sık yapılan hata
En sık hata, tüm kırmızı bulguları anında bloklayıp ekiplerin sisteme güvenini kırmaktır. Eğer başlangıçta taban imajlar zaten kirliyse, politika bir gecede tam sertleştirilmemelidir. Daha iyi yaklaşım, önce görünürlük, sonra zorunlu eşik, en son istisna yönetimi katmanı kurmaktır.
Sonuç
Syft ve Grype ile SBOM tabanlı imaj kabul kapısı, container güvenliğini anlık tarama refleksinden çıkarıp tekrar edilebilir tedarik zinciri kontrolüne dönüştürür. SBOM üretmek, zafiyet taramak ve sonucu kayıtlı politika ile değerlendirmek birlikte çalıştığında hem güvenlik kalitesi artar hem de ekipler hangi imajın neden geçtiğini daha net görür. Güçlü kapı, en çok alarm veren değil; en tutarlı kabul kararını üreten kapıdır.