CNCF, 7 Eylül 2026’da «Güvenlik açığı bildirimleriyle başa çıkma» (Handling vulnerability reports: Recipe card) başlıklı bir rehber kartı yayımladı. Kart, esas olarak güvenliğe odaklanmayan küçük ve orta ölçekli açık kaynak projelerini hedefliyor. Materyal, Edera’dan Marina Moore (aynı zamanda TAG Security eş başkanı) ve Red Hat’ten Sherine Khoury (TAG Security lideri) tarafından hazırlandı.
Rehberin temel fikri, güvenlik bildirimlerinin çözüm hazır olmadan önce kamuya açık bir tartışmaya dönüşmesini önlerken bakım sorumluları ve kullanıcılar üzerindeki ek işi azaltmak. CNCF, güvenlik açığını sistemin gizliliğini, bütünlüğünü veya kullanılabilirliğini etkilemek için kullanılabilecek bir kusur olarak açıklıyor; ancak her yazılım kusuru istismar edilebilir veya güvenlik açığı olarak sınıflandırılabilir değil.
Açık ve özel bir bildirim kanalıyla başlayın
Yönergeler, README.md dosyasında kolayca bulunabilecek açık bir güvenlik bölümü bulunmasını; talimatların doğrudan bu dosyaya eklenmesini veya havuzun kök dizinindeki SECURITY.md dosyasına yönlendirme yapılmasını öneriyor. Amaç, araştırmacıları sorunun ayrıntılarını herkesin okuyabileceği genel bir issue’da yayımlamak yerine özel bir kanala yönlendirmek.
Bildirim talimatları; tehdit modelini veya bir bildirimin güvenlik açığı sayılması için kabul edilebilir asgari koşulları, gönderim yerini, bildirim biçimini, incelenmesinin beklenen süresini ve açıklanmasına kadar geçecek yaklaşık süreyi kapsayan çeşitli unsurları açıklamalı. GitHub’ın özel güvenlik açığı bildirim mekanizması veya özel bir e-posta listesi kullanılabilir. Ödül programı ise küçük ve orta ölçekli projeler için, bunu işletme kapasitesine sahip değillerse zorunlu değil.
Bir bildirimi güvenlik açığı olarak ele almadan önce niteliğini doğrulayın
Bildirim alındıktan sonra ilk olarak bunun gerçekten istismar edilebilir bir güvenlik açığına mı, yoksa istismar edilemeyen bir kusura, beklenen davranışın yanlış anlaşılmasına veya belgelendirme hatasına mı işaret ettiği belirlenmeli. CNCF, bildirimin sahibiyle ve projedeki uygun uzmanlarla görüşülmesini; katılımcı sayısının sınırlı tutulmasını ve bildirim kamuya açık hâle gelene kadar herkesin gizliliğe uymasını öneriyor.
Yöneltilebilecek pratik sorular arasında şunlar bulunuyor: Kullanıcılar için mevcut bir azaltma mekanizması var mı? Kusur bir ihlale, veri sızıntısına veya başka bir kötü amaçlı faaliyete yol açabilir mi? Sorun yalnızca belgelendirmede mi? Bildirimin güvenlik açığı olmadığı anlaşılırsa, sahibi genel bir issue oluşturmaya yönlendirilebilir; gerektiğinde kullanıcıları bilgilendirmek için uygun yayımlama süreçleri kullanılabilir.
Belirsizlik hâlinde yönergeler, bildirim ayrıntılarını genel kanalların dışında tutarak TAG Security and Compliance ekibinden veya CNCF personelinden yönlendirme istenebileceğini belirtiyor. Ayrıca gizli tutulma süresinde yer alacak katılımcılar dikkatle seçilmeli ve çözüme gerçekten yardımcı olması gereken kişiler sürece dâhil edilmeli; böylece düzeltme sağlanmadan önce bilginin saldırganlara sızması önlenmeli.
Düzeltmeyi kamuya açmadan geliştirin ve test edin
CNCF, düzeltmenin yayımlanmasının veya genel bir pull request’te tartışılmasının, kullanıcılara güncelleme yapma fırsatı verilmeden önce güvenlik açığının niteliğini ortaya çıkarabileceği konusunda uyarıyor. GitHub’ın özel bildirim mekanizması kullanılıyorsa bildirimden özel bir dal oluşturulabilir. Diğer durumlarda düzeltme özel bir kanal üzerinden geliştirilebilir ve incelenebilir.
Düzeltme, normal sürekli entegrasyon ortamı özel dallarla çalışmasa bile test edilmeli. Bu durumda testler, bakım sorumlularının değerlendirmesine ve değişikliğin kapsamına göre yerel olarak gerçekleştirilebilir. Düzeltmenin sorunu giderdiği ve testlerin yeterli olduğu doğrulandıktan sonra yönergeler, düzeltmenin hızla birleştirilmesini ve oluşturulması ile test edilmesine yeterli sayıda bakım sorumlusunun katılmasını öneriyor. Genel yayımdan önce kod yeniden incelenmeli ve güvenlik açığının gerçekten kapatıldığı doğrulanmalı.
Sürümü CVE açıklamasıyla koordine edin
Düzeltme tamamlandıktan sonra CNCF, bildirimin alınmasından sonraki 90 gün içinde açıklanmasını yaygın bir uygulama olarak değerlendiriyor. Proje kaynakları elveriyorsa özel bir kullanıcı listesini önceden bilgilendirebilir; ancak güncel bir iletişim listesi tutmak, çoğu küçük projenin karşılayamayacağı bir yük oluşturuyor.
Bu nedenle kart daha basit bir yaklaşım öneriyor: Düzeltmeyi içeren sürümü kullanıma sunmak ve güvenlik açığını aynı anda duyurmak; böylece kullanıcılar sorun açıklandığında düzeltmeye de erişebilsin. Bunun için düzeltme eklendikten hemen sonra yeni bir sürüm oluşturulmalı ve ardından CVE yayımlanmalı. GitHub’ın özel mekanizması kullanılıyorsa bu işlem GitHub arayüzünden gerçekleştirilebilir.
CVE numarası, CNA tarafından, yani CVE Numaralandırma Otoritesi tarafından atanmalı. GitHub bu otoritelerden biridir ve süreci yürütebilir; proje ile araştırmacı, listelenen CNA otoritelerinden biriyle doğrudan da iletişime geçebilir. CVE’nin önem derecesi bir dizi soru aracılığıyla belirlenir; proje, yanıtların doğruluğundan emin olmak ve atanan derece üzerinde anlaşmak için araştırmacıyla birlikte çalışmalı.
Bu yönergeler neden önemli?
Pratikte kart, güvenlik açığı yönetimi sorumluluğunu rastgele bir tepkiden uygulanabilir bir sürece dönüştürüyor: özel kanal, sınırlı doğrulama, kamuya açıklanmamış düzeltme, ardından koordineli sürüm ve açıklama. CVE yayımlandıktan sonra bilgiler OSV ve diğer güvenlik açığı veritabanlarında görünür; bu da kullanıcıların tarama araçlarının güncelleme gereksinimini tespit etmesine yardımcı olur.
Ancak reçetenin kapsamı açıkça sınırlı: güvenlik konusunda uzmanlaşmamış küçük ve orta ölçekli projelere yönelik ve yüksek riskli veya güvenlik açısından hassas projeler için daha karmaşık bir programın yerine geçmiyor. CNCF ayrıca düzeltmenin kullanıma sunulmasından sonra, kullanıcılara güncelleme için ek süre tanımak amacıyla bir süre geçmesinin ardından kavram kanıtı yayımlanmasının düşünülmesini öneriyor; ancak özel bildirim kullanıldığında bunun uygulanmasının zor olabileceğini kabul ediyor.