Dependabot Zararlı Paket Uyarıları Sekiz Ekosisteme Genişliyor
GitHub’ın yeni duyurusu ne söylüyor?
GitHub, 6 Ağustos 2026 tarihli teknik açıklamasında zararlı paket uyarılarının yalnızca npm ile sınırlı kalmayacağını duyurdu. Şirket, OpenSSF’nin malicious-packages veri kümesini GitHub Advisory Database’e aktaran yeni bir hat kurduğunu ve kapsamı npm, PyPI, Maven, RubyGems, NuGet, Go, crates.io ve PHP Composer olmak üzere sekiz büyük paket ekosistemine genişlettiğini belirtiyor. Böylece JavaScript dışındaki projeler de bilinen zararlı bağımlılıklar için Dependabot uyarılarından yararlanabilecek.
Bu gelişme sıradan bir güvenlik açığı taramasından farklı. Güvenlik açığı bulunan meşru bir paket, belirli koşullarda istismar edilebilen bir yazılım hatası içerir. Zararlı paket ise baştan itibaren kimlik bilgisi çalmak, dosyalara erişmek, dışarı veri göndermek veya saldırganın sonraki aşamasını hazırlamak amacıyla yayımlanmış olabilir. Böyle bir paket kurulum betiği çalıştığı anda zarar verebildiği için uyarının saatler veya günler gecikmesi kritik sonuçlar doğurabilir.
OpenSSF verisi neden önemli?
OpenSSF malicious-packages deposu, açık kaynak paket kayıtlarında tespit edilen zararlı paket raporlarını OSV biçiminde topluyor. Projenin kapsamına yazım hatasına benzeyen paket adlarıyla yapılan typosquatting saldırıları, bağımlılık karışıklığı, hesap ele geçirme yoluyla yayımlanan sürümler ve paketle birlikte indirilen zararlı hazır ikili dosyalar giriyor. Depo, güvenlik topluluğunun farklı kaynaklardan ürettiği raporları ortak ve makine tarafından okunabilir bir yapıda bir araya getiriyor.
GitHub’ın açıklamasına göre bu kaynak 15 binden fazla rapora ulaşmış durumda. GitHub sekiz ayrı algılama sistemi kurmak yerine tek bir içe aktarıcı geliştirerek OSV kayıtlarını mevcut Advisory Database yayın hattına bağlıyor. Bu yaklaşım yeni ekosistemlerin desteklenmesini hızlandırıyor; fakat dışarıdan gelen verinin hatalı veya kötü niyetli olabileceği varsayımını da tasarımın merkezine yerleştiriyor.
Kayıtlar nasıl işleniyor?
Yeni içe aktarıcı önce her OSV kaydındaki zorunlu alanları, veri türlerini ve biçimi şemaya göre doğruluyor. Uymayan kayıt sessizce düzeltilip kabul edilmiyor; reddediliyor ve kayda geçiriliyor. Geçerli veriler kaynak, tanımlayıcı, varsa CVE kimliği, orijinal kaydın anlık görüntüsü ve GitHub’ın yayın hattında kullanacağı eşlenmiş alanlarla normalleştiriliyor.
Normalleştirme özellikle ekosistem adları ve sürüm bilgileri için gerekli. Bir kaynak PyPI adını kullanırken GitHub aynı alanı pip olarak ifade edebilir. Bazı kayıtlar tek tek sürümler, bazıları sürüm aralıkları içerir; bazı raporlarda ise kullanılabilir bir sürüm bilgisi bulunmayabilir. Yanlış eşleme, meşru bir paketi zararlı gösteren hatalı uyarıya veya gerçekten zararlı bir sürümün gözden kaçmasına neden olabileceği için bu adım güvenlik açısından önem taşır.
GitHub ayrıca kendi ürettiği npm zararlı yazılım kayıtlarının OpenSSF üzerinden yeniden içeri alınarak döngü oluşturmasını engelliyor. OSV köken bilgisi ghsa-malware olan kayıtlar içe aktarım öncesinde filtreleniyor. Geri çekilmiş veya yanlış olduğu sonradan anlaşılan raporlar da OpenSSF deposundaki withdrawn yapısı üzerinden işlenebiliyor.
Otomatik yayın için üç güvenlik freni
Zararlı paket uyarıları insan incelemesini beklemeden otomatik yayımlanabiliyor. GitHub bu tercihi, saldırgan paketin o anda kimlik bilgisi çalabileceği ve uzun bir inceleme kuyruğunun saldırgana zaman kazandıracağı gerekçesiyle açıklıyor. Buna karşılık otomasyonun yanlış veriyi geniş ölçekte yaymaması için üç koruma katmanı kullanılıyor.
Birincisi toplu işlem sınırı. Tek çalışmada beklenenden çok daha fazla kayıt oluşursa sistem yalnızca ilk bölümü yayımlamıyor; işlemi tamamen durduruyor ve ekibi uyarıyor. İkincisi köken takibi. Her uyarı, OpenSSF deposundaki tam kaynak değişikliğine kadar izlenebiliyor. Üçüncüsü toplu geri alma. Hatalı bir grup yayımlanırsa kayıtları tek tek temizlemek yerine bütün grup tek işlemle geri çevrilebiliyor. Bu kontroller, hızlı yayın ile veri bütünlüğü arasında ölçülebilir bir denge kuruyor.
Ekipler özelliği nasıl etkinleştirmeli?
GitHub belgelerine göre zararlı paket uyarıları isteğe bağlı olarak etkinleştiriliyor. Depo yöneticisi önce Settings bölümündeki Advanced Security alanından Dependabot alerts seçeneğini, ardından Dependabot malware alerts seçeneğini açmalı. Organizasyon ve kurumsal hesaplarda aynı ayar özel güvenlik yapılandırmalarıyla çok sayıda depoya uygulanabiliyor. Duyuru yeni olduğundan, ekosistem kapsamının hesaplara kademeli yansıması mümkün; ekipler ayarın görünür olduğunu ve kullandıkları paket yöneticisinin gerçekten izlendiğini kendi güvenlik ekranlarında doğrulamalı.
Uyarı sistemi tüm saldırıları yakalayamaz. Yeni bir zararlı paket veritabanına henüz girmemiş olabilir; bildirim gecikebilir veya iç paket ile aynı ad ve sürüme sahip halka açık bir paket yanlış pozitif üretebilir. Manifest ve kilit dosyaları güncel tutulmadığında Dependabot gerçek bağımlılık ağını doğru çıkaramayabilir. Bu nedenle özellik, bağımlılık güvenliği programının tek kontrolü değil, erken uyarı katmanlarından biri olarak görülmeli.
Bir uyarı geldiğinde ne yapılmalı?
İlk olarak ilgili derleme ve dağıtım durdurulmalı, uyarının işaret ettiği manifest veya kilit dosyası incelenmeli ve paketin hangi sürümde, hangi tarihte eklendiği belirlenmeli. Zararlı paketin kurulum betiği CI ortamında veya geliştirici bilgisayarında çalıştıysa yalnızca bağımlılığı kaldırmak yeterli değildir. O ortamın erişebildiği depo anahtarları, kayıt sistemi belirteçleri, bulut kimlik bilgileri ve imzalama sırları ele geçirilmiş kabul edilerek döndürülmelidir.
Temiz bir ortamda bağımlılık ağacı yeniden kurulmalı, güvenilir sürüm veya alternatif paket seçilmeli ve yeni kilit dosyası üretilmelidir. Ağ günlükleri, beklenmedik dış bağlantılar, yeni kullanıcılar, değiştirilmiş iş akışları ve yayımlanmış şüpheli paket sürümleri araştırılmalıdır. Etkilenen derleme çıktıları geri çekilmeli; temiz kaynak ve temiz kimlik bilgileriyle yeniden üretilmelidir.
Kalıcı korunma için kilit dosyalarının zorunlu tutulması, bağımlılık değişikliklerinin kod incelemesinden geçmesi, CI işlerinin en az yetkiyle çalışması ve uzun ömürlü sırlar yerine kısa ömürlü kimliklerin kullanılması gerekir. Özel paket ad alanları net tanımlanmalı, kayıt kaynakları sınırlandırılmalı ve kurulum sırasında çalışan betikler yüksek riskli projelerde ayrıca denetlenmelidir.
Sonuç
GitHub’ın OpenSSF verisini Advisory Database’e bağlaması, zararlı paket savunmasını tek bir ekosistemden çok dilli yazılım tedarik zincirine taşıyor. Sekiz ekosistemin ortak OSV verisiyle izlenmesi görünürlüğü artırırken; şema doğrulama, toplu sınırlar, köken takibi ve geri alma mekanizması otomatik uyarı hattının güvenli çalışmasını destekliyor. En büyük kazanç ise ayarı açmakla değil, gelen uyarıyı kimlik bilgisi döndürme ve temiz yeniden derleme süreçlerine bağlamakla elde edilecek.