Dependabot’ta Bekleme Süresi: Neden Üç Gün?
GitHub, tedarik zinciri güvenliğini sertleştirmek için Dependabot’un varsayılan davranışını değiştirdi: Güvenlikle ilgili olmayan sürüm güncellemeleri artık yayınlanan yeni bir sürüm için pull request açmadan önce en az üç gün bekliyor. Bu “cooldown” (soğuma) süresi, kötü niyetli bir sürümün fark edilip kayıt defterinden kaldırılması için bakımcılara ve güvenlik araştırmacılarına zaman tanımayı hedefliyor.
Bu değişikliği tetikleyen olay
Eylül 2025’te bir saldırgan, tek bir npm bakımcısının kimlik bilgilerini oltalama yöntemiyle ele geçirdi ve chalk, debug ile birlikte haftalık toplam 2 milyardan fazla indirilen yaklaşık on iki paketin tuzaklı sürümlerini yayımladı. Enjekte edilen kod, paketin yüklendiği tarayıcı uygulamalarında kripto para cüzdanı adreslerini yeniden yazacak şekilde tasarlanmıştı. Zehirlenmiş sürümler yaklaşık iki saat boyunca erişilebilir kaldı ve topluluğun fark etmesiyle npm tarafından kaldırıldı.
İki saat, tepki süresi olarak hızlı sayılır. Ancak otomatik güncelleme araçları için bu süre fazlasıyla yeterlidir; çünkü sürüm güncelleme araçları en yeni yayını çıktığı anda alacak biçimde tasarlanmıştır. Yeni sürümü görüp pull request açması ve ekibin önüne getirmesi genellikle dakikalar sürer.
Dependabot’un iki farklı görevi
Dependabot, GitHub’ın bağımlılıkları güncel ve güvenli tutmak için sunduğu yerleşik araçtır ve birbirinden ayrı iki işi yapar:
- Güvenlik güncellemeleri, bilinen bir zafiyete yanıt verir. Kullandığınız bir paket için advisory yayınlandığında Dependabot uyarı üretir ve yamalı sürüme geçmek için pull request açar.
- Sürüm güncellemeleri, mevcut sürümünüzde bir sorun olup olmadığına bakmaksızın yeni yayınlar çıktıkça bağımlılıklarınızı güncel tutar.
Üç günlük yeni varsayılan cooldown yalnızca sürüm güncellemeleri için geçerlidir. Güvenlik güncellemeleri hâlâ anında açılır; çünkü halka duyurulmuş bir açık için düzeltmeyi geciktirmek anlamsız olurdu. Bu yazıdaki tüm anlatım, amacı güncel kalmak, riski ise gözden geçirilmemiş bir sürümü hemen benimsemek olan sürüm güncellemelerine odaklıdır.
Kısa ömürlü kötü amaçlı sürümler
Popüler bir paket ele geçirildiğinde zehirlenmiş sürüm çoğunlukla kısa ömürlü olur: yayımlanır, kendisini yükleyen ne varsa üzerine yayılır ve genellikle saatler içinde tespit edilir. Yukarıdaki chalk/debug vakasının iki saatlik pencereye sığması buna örnektir. Aynı örüntü Solana web3.js, Axios ve ua-parser-js gibi yaygın kullanılan paketlerin ele geçirilmiş sürümlerinde de görüldü; bunların her biri yayımlandıktan birkaç saat sonra fark edildi.
GitHub bu örüntüyü GitHub Advisory Database üzerinden doğrudan gözlemliyor. Mayıs 2026’da biten bir yıllık dönemde veri tabanına 6.500’ün üzerinde npm zararlı yazılım kaydı eklendi; bir önceki yıl bu sayı yaklaşık 6.200’dü. Bu, günde ortalama 18 yeni kötü amaçlı npm paketinin kataloglandığı anlamına geliyor. Cooldown, tam da bu ilk pencerenin dışında kalmanızı ve yayının size ulaşmadan önce bir miktar incelemeye tabi tutulmasını sağlıyor.
Neden üç gün?
2018-2026 arasında yaygın biçimde raporlanan 21 tedarik zinciri olayı üzerine yapılan bir inceleme, aynı örüntüyü doğruluyor: axios, Solana web3.js, ua-parser-js ve Ledger Connect Kit’in kötü niyetli sürümleri yayımlandıktan saatler sonra kaldırıldı. Bir cooldown, bu kısa ömürlü yayınların büyük bölümünü kimse yüklemeden önce eleyebilirdi.
Üç günlük varsayılan iki hedef arasında denge kuruyor: saldırıların çoğunun yaşadığı pencerenin ötesine geçmek ve bağımlılıkları gereğinden uzun süre eski tutmamak. Topluluğun diğer üyeleri de benzer bir üç günlük süreye (bazıları daha uzun) ulaştığı için bu varsayılan, geliştiriciler farklı araçlar arasında geçiş yaparken tutarlılığı da koruyor.
Daha uzun veya daha kısa bir pencereyi dependabot.yml dosyasındaki cooldown yapılandırma seçeneği üzerinden istediğiniz zaman ayarlayabilirsiniz.
Cooldown’un sınırları ve derinlemesine savunma
Cooldown belirli bir örüntüye karşı tasarlandı: yayımlanan, hızla yayılan ve kısa sürede fark edilen kötü niyetli bir sürüm. Uzun soluklu senaryolara karşı fazla bir şey yapmaz: yayınlara yerleştirilip uykuda bekletilen arka kapılar, bakımcı sabotajı veya ele geçirilmiş bir yapılandırma sistemi gibi durumlar bunun dışındadır. Varsayılanın amacı, sık karşılaşılan ve zamana duyarlı bir saldırı yolunu ortadan kaldırmaktır; savunmanın geri kalanının yerini almak değil.
Bu nedenle cooldown, birçok katmandan yalnızca biri olarak konumlandırılmalıdır. Alınabilecek ek adımlar arasında bağımlılıkları lockfile ile sabitlemek, mümkün olan yerlerde CI ortamında install script’lerini devre dışı bırakmak, yapı hattındaki token’ların kapsamını daraltmak ve güncellemeleri birleştirmeden önce gözden geçirmek yer alır.
Güvenilirliği yüksek dahili paketler ile genel kayıt defterleri için farklı gecikme süreleri belirlemek istiyorsanız dependabot.yml yapılandırma belgeleri ve Dependabot yapılandırma referansı tüm cooldown parametrelerini kapsıyor.
Ne değişecek?
Yeni davranış varsayılan olarak açık geliyor; etkinleştirmek için ek bir yapılandırma gerekmiyor. Sürüm güncellemesi PR’larınızın yeni bir yayından hemen sonra açılmadığını görürseniz bu bekleyiş kasıtlıdır. İş akışınıza uymadığını düşünüyorsanız cooldown süresini değiştirmek veya belirli paketler için özelleştirmek elinizde. Ekibin geri bildirimleri için Dependabot topluluk tartışmalarını takip edebilirsiniz.
Kaynaklar ve İleri Okuma
- Orijinal yazı: The case for a cooldown — GitHub Blog
- Dependabot güvenlik güncellemeleri belgeleri
- Dependabot sürüm güncellemeleri belgeleri
- GHSA-jcxm-7wvp-g6p5, GHSA-fw8c-xr5c-95f9, GHSA-pjwm-rvh2-c87w
- The simplest supply chain defense — Dani Akash
- İlgili yazı: Dependabot artık sbt’yi görüyor: Java ekosisteminde küçük ama etkili değişim
- İlgili yazı: Innersource Security Advisories GA: Kurum İçi Zafiyet Yönetimi
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
3 comments