- Konu sahibi
- #1
Bağımlılık güvenlik açığı bildirimi nasıl değerlendirilir?
Bir bağımlılık için güvenlik açığı bildirimi aldığınızda önce bildirimin gerçekten kullandığınız paket ve sürümü etkileyip etkilemediğini doğrulayın; ardından açığın uygulamanızda çalıştırılabilir olup olmadığını, maruziyetin kapsamını ve düzeltme seçeneğini belirleyin. Yalnızca bildirimin önem derecesine bakarak paketi hemen güncellemek veya bildirimi yok saymak yerine, kanıtları kayıt altına alarak kontrollü bir karar verin.
1. Bildirimi kimlik ve sürüm açısından doğrulayın
Bildirimin paket adı, ekosistemi, etkilenen sürüm aralığı, düzeltilmiş sürümü ve güvenlik açığı kimliği gibi bilgileri içermesi gerekir. Paket adının benzer isimli başka bir paketle karıştırılmadığını kontrol edin. Uygulamanın doğrudan tanımladığı bağımlılık ile başka bir paket üzerinden gelen geçişli bağımlılığı da ayırın.
Kullandığınız gerçek sürümü kilit dosyasından veya bağımlılık ağacından belirleyin. Manifest dosyasındaki geniş sürüm aralığı tek başına yeterli kanıt değildir; dağıtıma gerçekten giren sürüm esas alınır. Bildirimdeki etkilenen aralık ile bu sürümü karşılaştırın. Sürüm aralığı belirsizse bunu çözülmüş kabul etmeyin; paket bakımcısının düzeltme duyurusu veya güvenlik kayıtlarıyla ek doğrulama yapın.
2. Açığın uygulamanızdaki etkisini inceleyin
Bir paketin etkileniyor olması, açığın her kurulumda kullanılabildiği anlamına gelmez. Şu sorulara yanıt verin:
- Etkilenen kod yolu uygulama tarafından gerçekten çağrılıyor mu?
- Açığın tetiklenmesi için saldırganın hangi girdiyi, isteği veya dosyayı kontrol etmesi gerekiyor?
- Girdi doğrulama, kimlik doğrulama veya ağ katmanı bu koşulu engelliyor mu?
- Paket üretim ortamında mı, yalnızca geliştirme veya test ortamında mı kullanılıyor?
- Açık, gizlilik, bütünlük veya hizmet sürekliliği bakımından hangi varlıkları etkileyebilir?
Varsayımsal bir görüntü işleme paketindeki taşma açığı, yalnızca dışarıdan yüklenen görseller uygulama sunucusunda işleniyorsa doğrudan önem kazanır. Paket yalnızca geliştirici makinesinde test verisi üretmek için kullanılıyorsa üretim maruziyeti farklı değerlendirilir; ancak geliştirici ortamı veya CI sistemi güvenlik sınırının dışındaymış gibi varsayılmamalıdır.
3. Kararı kanıtla ve önceliklendir
Aşağıdaki ayrım, bildirimi “etkileniyor”, “etkilenmiyor” veya “belirsiz” olarak sınıflandırmanıza yardımcı olur. Belirsiz kayıtlar, kanıt bulunmadığı için kapatılmamalı; sorumlu kişi ve yeniden değerlendirme koşulu atanmalıdır.
| Sonuç | Gerekli kanıt | Uygun karar |
|---|---|---|
| Etkileniyor | Kilitli sürüm etkilenen aralıkta ve açık kod yolu kullanılabilir | Düzeltmeyi planla; gerekiyorsa geçici önlem uygula |
| Etkilenmiyor | Sürüm aralık dışında veya açık kod yolu bu dağıtımda kanıtla erişilemez | Kanıtı kaydet ve izlemeyi sürdür |
| Belirsiz | Sürüm, kullanım yolu veya tetikleme koşulu doğrulanamıyor | Sahip ata ve kısa süreli inceleme görevi aç |
Düzeltme sürümüne yükseltmeden önce geriye dönük uyumluluğu, kilit dosyasındaki değişiklikleri ve test sonucunu kontrol edin. Uygulama davranışı değişiyorsa sürümü körlemesine zorlamak yerine uyumlu bir düzeltme sürümü, yama veya güvenli yapılandırma seçin. Geçici önlem; etkilenen uç noktayı kapatmak, riskli girdi türünü sınırlamak veya paketi güvenilmeyen girdilerden ayırmak olabilir. Bu önlemler açığı düzeltmez; yalnızca düzeltme uygulanana kadar maruziyeti azaltır.
4. Uygulanabilir değerlendirme adımları
- Bildirimin paket adını, kimliğini, etkilenen aralığını ve düzeltme bilgisini kayıt sistemine ekleyin.
- Üretimde dağıtılan kilitli bağımlılık ağacından gerçek sürümü ve bağımlılığın doğrudan mı geçişli mi olduğunu çıkarın.
- Etkilenen modülün uygulama kodunda ve çalışma yapılandırmasında kullanılıp kullanılmadığını inceleyin.
- Saldırganın kontrol ettiği girdinin uygulamaya ulaşabildiğini ve açığı tetikleyen koşulların mevcut olduğunu test ortamında doğrulayın.
- Düzeltme sürümünü ayrı bir dalda uygulayın; ilgili işlev, hata senaryosu ve normal akış testlerini çalıştırın.
- Dağıtım sonrasında kullanılan sürümü, uygulanan geçici önlemleri ve kalan sınırlamaları kayıt altına alıp bildirimi yeniden değerlendirme tarihi belirleyin.
Test sırasında gerçek kullanıcı verisi veya üretim trafiği kullanmayın. Güvenlik açığını tetiklemeye yönelik denemeler yalnızca yetkili, izole bir ortamda yapılmalıdır. Beklenen sonuç, düzeltme sürümünün kilit dosyasına yansıması ve ilgili testlerin geçmesidir. Sürüm güncellenmesine rağmen araç hâlâ açığı raporluyorsa eski bir kilit dosyası, ayrı bir bağımlılık yolu veya konteyner imajında kalan kopya bulunabilir; raporu kapatmadan dağıtılan artefaktı tekrar inceleyin.
Sık yapılan hatalar
- Yalnızca doğrudan bağımlılık listesini kontrol etmek: Açık geçişli bir bağımlılıktan gelebilir.
- Manifest sürümünü gerçek dağıtım sürümü sanmak: Kilit dosyası ve oluşturulan artefakt ayrıca doğrulanmalıdır.
- Genel önem derecesini uygulama riskinin tamamı kabul etmek: Saldırı koşulları ve kullanılan kod yolu ayrıca incelenmelidir.
- Sürümü güncelledikten sonra eski imajı veya önbelleği dağıtmak: Çalışan örneğin gerçekten yeni sürümü içerdiği doğrulanmalıdır.
- “Kullanılmıyor” kararını kanıtsız vermek: Kullanım dışı olduğu kod, yapılandırma ve dağıtım incelemesiyle gösterilmelidir.
