Dependabot Alerts REST API Artık Sürüm Bilgisi Veriyor
Dependabot uyarılarını REST API üzerinden çeken ekipler artık bağımlılığın depoda kayıtlı sürümünü doğrudan yanıt gövdesinde görüyor. GitHub her uyarının dependency nesnesine version_requirement adında bir alan ekledi; bu alan, Dependabot’un o uyarı için en son kaydettiği sürümü ya da sürüm kısıtını taşıyor. Güvenlik verisini başka araçlara aktaran ekipler için bir ara adım ortadan kalkıyor.
Daha önce neden ek adım gerekiyordu?
Uyarı yanıtları güvenlik danışma belgesinin (advisory) etkilenen sürüm aralığını zaten içeriyordu, yani “hangi sürümler zafiyetli” sorusunun cevabı yanıttaydı. Eksik olan, “benim depomda hangi sürüm var” sorusunun cevabıydı. İkisi birbirinin yerine geçmez; advisory aralığı genel bir tanım verir, önceliklendirme ve raporlama ise depodaki gerçek sürüme dayanır.
Bu boşluk yüzünden ekipler iki yoldan birini seçiyordu. Ya lockfile dosyalarını kendileri ayrıştırıp çözümlenmiş sürümü çıkarıyor ya da vulnerableRequirements alanını almak için ayrı bir GraphQL isteği atıyorlardı. İkisi de fazladan kod, fazladan bakım ve senkronizasyon sırasında ek gecikme demekti. Yeni alanla bu ara adımlar devre dışı kalıyor, tek bir REST çağrısı hem uyarı bağlamını hem kayıtlı sürümü getiriyor.
Değer nasıl belirleniyor?
version_requirement alanının içeriği, Dependabot’un bağımlılığı hangi yöntemle tespit ettiğine göre değişiyor. GitHub bu davranışı üç durum üzerinden tanımlıyor:
- Lockfile mevcutsa alan, çözümlenmiş (resolved) sürümü içerir. Çalışma zamanında gerçekten kullanılan sürüme en yakın bilgi budur.
- Lockfile olmayan manifest dosyalarında alan, manifest içinde beyan edilmiş sürümü ya da sürüm kısıtını taşır. Tek bir kesin sürüm yerine bir kısıt ifadesi görebilirsiniz.
- Dependency submission API ile gönderimde alan, derleme (build) araçlarınızın gönderdiği çözümlenmiş sürümü yansıtır.
Alanın adının neden “version” yerine version_requirement olduğu da buradan anlaşılıyor. Kimi durumda elinizde net bir sürüm numarası olacak, kimi durumda bir kısıt ifadesi. Entegrasyonlarınızı yazarken iki olasılığı da karşılayan bir ayrıştırma mantığı kurmanız gerekiyor.
Dikkat edilmesi gereken sınırlar
GitHub, alanın davranışına ilişkin üç sınırı açıkça belirtiyor. Bunları entegrasyon tasarımına baştan dahil etmek, sonradan yanlış raporlama üretmenin önüne geçiyor.
Birincisi, değer bulunmadığında alan null döner. Kodunuzun boş değeri güvenli şekilde ele alması, eksik veriyi “sürüm yok” diye yorumlamaması gerekir.
Bir diğeri, bir uyarı aynı bağımlılığın birden fazla zafiyetli sürümünü kapsıyorsa alanın yalnızca kaydedilmiş tek bir değeri taşıması; bu değer tüm sürümleri temsil etmeyebilir. Çok sürümlü senaryolarda alan tek başına tam bir envanter kaynağı sayılmaz.
Son olarak, uzun sürüm kısıtları kısaltılabiliyor (truncated). Karmaşık kısıt ifadelerinin tam metnine bağlı bir mantık kuruyorsanız kesilmiş değer ihtimalini hesaba katın.
Alanın göründüğü yerler
version_requirement tek bir uç noktayla sınırlı değil. GitHub’ın duyurduğu kapsam şöyle:
- Tekil uyarı yanıtlarında,
- Depo (repository) düzeyindeki uyarı listelerinde,
- Organizasyon düzeyindeki uyarı listelerinde,
- Enterprise düzeyindeki uyarı listelerinde,
dependabot_alertwebhook yüklerinde.
Webhook tarafının da kapsama girmesi, olay tabanlı (event-driven) mimariler açısından işe yarıyor. Uyarı oluştuğu anda tetiklenen akışta sürüm bilgisi için ayrıca API’ye dönmeye gerek kalmıyor, veri doğrudan payload içinde geliyor.
Hangi ortamlarda kullanılabilir?
GitHub’a göre alan şu anda github.com üzerinde ve veri ikametgahı (data residency) özellikli GitHub Enterprise Cloud ortamlarında kullanılabiliyor. GitHub Enterprise Server tarafında ise 3.24 sürümüyle gelecek. Kendi barındırdığı Enterprise Server kurulumlarında çalışan ekipler, entegrasyonlarını planlarken bu sürüm eşiğini hesaba katmalı.
Pratikte ne değişiyor?
Dependabot uyarılarını bir SIEM’e, güvenlik panosuna ya da kendi iç envanter sisteminize aktaran bir boru hattınız varsa, bu hattın “depodaki sürüm” bilgisini elde etmek için kurduğu yardımcı mekanizma artık gereksiz. Lockfile ayrıştırıcıları ve ikinci bir GraphQL çağrısı hem kod karmaşıklığı hem hata yüzeyi demekti; tek yanıt içinde gelen veri o yüzeyi küçültüyor.
Öte yandan alanın sınırları, onu tek doğruluk kaynağı olarak konumlandırmayı zorlaştırıyor. Çoklu zafiyetli sürüm durumunda eksik temsil, uzun kısıtlarda kısaltma, değer yoksa null dönüşü… Alanı destekleyici bir sinyal olarak ele almak daha sağlıklı. Raporlama mantığınızı kurarken bu üç durumu açıkça karşılamanız, sonradan yanlış pozitif ya da eksik envanter sorunlarından kaçınmanıza yardımcı olur.
Tedarik zinciri güvenliği tarafında Dependabot ekosistemindeki diğer gelişmeler için Dependabot’un sbt desteğine ve uyarı gürültüsünü azaltmaya yönelik gruplama ve zamanlama yaklaşımlarına göz atabilirsiniz.
Kaynaklar ve İleri Okuma
- Dependabot alerts REST API now includes dependency versions — The GitHub Blog
- Dependabot alerts için REST API uç noktaları — GitHub Docs
- Webhook olayları ve payload yapıları (dependabot_alert dahil) — GitHub Docs
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.
Yorum gönder