Araştırma: registry paketi yayınlamayan uygulamaların advisories'lerinin çoğu tarayıcılara görünmez kalıyor

dev.to'da yayımlanan bir araştırma, self-hosted bir uygulamanın kendi güvenlik advisories'lerinin bir vulnerability tarayıcısına ulaşıp ulaşmamasını güçlü biçimde öngören tek bir etken tespit etti: projenin kodunu, OSV veritabanının indekslediği bir package registry'ye yayınlayıp yaynlamaması.

Munim, Inc. adına MV2 takma adıyla yazan yazar, daha önceki çalışmasında self-hosted uygulamaların yayımladığı advisories'lerin kabaca yarısının OSV'de hiçbir paket adı içermediğini saptamıştı. Dependabot, npm audit ve pip-audit gibi araçlar advisories'leri kurulu yazılımlarla package adları üzerinden eşleştirir; bu yüzden hiçbir paket adı geçmeyen bir advisory bu araçlara fiilen görünmezdir. Yeni yazı hangi uygulamaların etkilendiğini ve maintainers'ların elinde bir kaldıraç olup olmadığını soruyor.

Araştırma körlüğü nasıl ölçtü

Bir advisory — en az 14 gün eski repository advisories'leriyle sınırlı — GitHub security advisory (GHSA) kimliği ve tüm CVE alias'ları üzerinden arandığında hiçbir OSV kaydı bir paket adı vermiyorsa kör sayılıyor. Repository'ler, tek bir advisory verisi toplanmadan önce dondurulmuş bir kuralla registry veya no_registry olarak etiketlendi: proje, kendi kodunu taşıyan resmi ve canlı bir paketi npm, PyPI veya Go module proxy gibi OSV'nin indekslediği bir registry'ye yayınlıyor mu? Karşılaştırma, repository düzeyinde, önceden sabitlenmiş bir seed ile 10.000 permütasyonlu iki taraflı bir permutation test kullanıyor.

İki test yapıldı. İlki, hipotezi ortaya koyan 27 repository'lik örneklemi (A2) yeniden kullandı. İkinci, ön kayıtlı test (A1) tamamen yeni 32 uygulama çekti; örnekleme çerçevesi ve tüm registry etiketleri tek bir advisory toplanmadan önce git'e işlendi; 32 uygulamanın 26'sında uygun advisories vardı.

Sonuçlar

Her iki örneklem de aynı yönü gösterdi ve örneklem dışı test ikisinden daha güçlüydü. A2'de 12 registry uygulamasının advisories'lerinin yüzde 24,9'u kördü (yüzde 95 güven aralığı 21,0–29,3), repository medyanı yüzde 4,8'di. 15 no_registry uygulamasında körlük yüzde 76,4'tü (72,5–79,9), medyan yüzde 100. Fark p = 0,0077 ile 51,5 puan oldu ve her gruptaki en ağır repository çıkarıldığında 75 puana (p = 0,0001) ulaştı. Yazar bunun fikri doğuran repository'leri yeniden kullandığını, dolayısıyla gerçek kanıt olarak kabul edilemeyeceğini vurguluyor.

A1 o kanıttı. Registry uygulamaları (10 repo) yüzde 26,6 kör (23,3–30,2), medyan yüzde 27,2 iken; no_registry uygulamaları (16 repo) yüzde 84,8 kör (82,2–87,1), medyan yüzde 100 idi — fark p = 0,0017 ile 58,2 puan, her gruptaki en ağır repo çıkarıldığında hâlâ 44,8 puan (p = 0,0086). Araştırmaya göre üç ön kayıtlı öngörünün üçü de gerçekleşti.

Yeni örneklemde net uçlar da vardı: ikisi de registry uygulaması olan NocoDB ve Strapi'de sıfır kör advisory vardı; Discourse, Mastodon, Metabase, Coolify, Outline, Wiki.js ve Zulip ise — hepsi no_registry — yüzde 100'de yer alıyordu.

Yazarın belirttiği uyarılar

Araştırma bunun bir ilişki olduğunu, nedensellik kanıtı olmadığını açıkça belirtiyor: registry durumu ecosystem, proje yaşı ve güvenlik süreci olgunluğuyla birlikte değişiyor; registry uygulamaları npm'e yayınlanan JavaScript projelerine, no_registry uygulamaları ise yalnızca Docker ile dağıtıma eğilim gösteriyor.

Yayınlamak tek başına da yeterli değil. İlk örneklemde Joplin bir npm paketi yayınlıyor olmasına rağmen yüzde 93,8 kördü; çünkü advisories'leri yayınlanan CLI'yi değil masaüstü uygulamasını ilgilendiriyordu. Yazarın savunduğu etkili kaldıraç, advisory'nin kendisinde etkilenen paketi yayınlamak ve adlandırmak.

Yazı ayrıca araştırma, kod ve metnin yazar için çalışan AI agent'lar tarafından üretildiğini açıklıyor. Her rakamın çalışmanın kendi çıktı dosyalarıyla doğrulandığı belirtilse de henüz bağımsız bir insan incelemesi yapılmamış. Veriler CC BY 4.0, kod ise Apache-2.0 altında yayımlandı.

Operatörler ve maintainers neler yapabilir

Uygulamayı yalnızca Docker imajı veya binary olarak self-host eden ekipler için tavsiye, o uygulamanın kendi advisories'leri konusunda bir dependency tarayıcısına güvenmemek — bunun yerine upstream repository'nin Security sekmesini izlemek ya da yazarın blindspot.py aracını repository üzerinde çalıştırmak. Maintainers için ise ecosystem'in registry'sine resmi bir paket yayınlamak ve bunu GHSA advisories'lerinde adlandırmak, advisories'leri tarayıcılar tarafından erişilebilir kılmanın somut ve düşük maliyetli bir yolu olarak tanımlanıyor.

Neden önemli

Vulnerability yönetimi iş akışları genellikle tarayıcıların önemli advisories'leri ortaya çıkaracağını varsayar. Bu araştırma, bu varsayımın yaygın olarak dağıtılan tüm bir self-hosted yazılım sınıfı — Mastodon, Discourse ve Metabase dahil — için geçersiz olduğunu gösteriyor; bu uygulamalarda operatörler giderilmiş vulnerability'lerden yalnızca upstream duyurularını izlemeleri halinde haberdar olabiliyor. Araştırma maintainers'lara spesifik ve ucuz bir çözüm de sunuyor; ön kayıtlı, örneklem dışı tasarımı sayesinde iddia, yayımlanan veri ve kodu kullanan herkes tarafından doğrulanabilir.