Anthropic OSS Scanner Ne Vaat Ediyor, Nerede Zorlanıyor

OSS Scanner nedir, kimden geliyor

Anthropic 8 Ekim 2026'da OSS Scanner adlı ücretsiz bir hizmet duyurdu. Hizmet, şirketin Anthropic Cyber Mission adını verdiği yeni girişimin parçası ve aynı duyuruda operasyonel teknoloji savunucularına yönelik bir Critical Infrastructure Defense Program da yer alıyor. Fikir basit: başvuran ve kabul edilen açık kaynak projeler, Anthropic'in en güçlü modelleriyle düzenli güvenlik taramasından para ödemeden geçiyor.

Taramalarda Claude Mythos da kullanılıyor ve BetaNews'in aktardığına göre proje seçimi OSS-Fuzz'a benzer kriterlerle, tek tek yapılıyor. Hizmetin ücretsiz kalmasını sağlayan kaynak ise Anthropic'in Ağustos'ta kurduğu Defender Advantage Fund. Şirket bunun yanında Python Software Foundation, Apache Software Foundation ve Linux Foundation üzerinden Alpha-Omega ile OpenSSF'ye de fon sağladığını belirtiyor.

Duyurunun kendisi kadar önemli olan soru şu: bu hizmet, kodu tarayıcıdan geçen bakımcılar ve o koda dayanan şirketler için pratikte ne değiştiriyor? Bu yazıda hizmeti kendimiz denemedik; kayıt belgelerini, Anthropic'in yayımladığı rakamları ve lansman haberlerini bir araya getirerek değerlendiriyoruz.

Bir proje nasıl kaydoluyor

Kayıt, klasik bir form doldurma süreci değil, tamamen GitHub üzerinden ilerliyor. Anthropic'in SSS sayfasına göre projenin çekirdek bakımcıları, anthropics/oss-scanner deposuna projects/<proje>/project.yaml dosyasını ekleyen bir pull request açıyor. Anthropic de kabulden önce başvuranın gerçekten çekirdek bakımcı olduğunu elle kontrol ediyor.

Deponun kendi şablonu gereken parçaları net biçimde sıralıyor. Burada dikkat edilmesi gereken bir ayrıntı var: project.yaml içindeki e-posta adresleri herkese açık. Kişisel adresinizi değil, proje için ayrılmış bir güvenlik adresini yazmak mantıklı olur.

Tarama sıklığı konusunda kaynaklar yalnızca "düzenli" ya da "periyodik" ifadesini kullanıyor, kesin bir takvim verilmiyor. Bakımcı olarak raporların hangi aralıklarla geleceğini önceden bilemiyorsunuz; bu da ekip planlamasını biraz belirsiz bırakıyor. The Hacker News'in yazdığı sırada 116 kayıt pull request'i gönderilmişti.

• project.yaml içinde zorunlu alanlar: depo adresi ve tek bir primary_contact e-postası
• İsteğe bağlı alanlar: her rapora kopya eklenecek auto_ccs adresleri ve proje ana sayfası
• Projenin nasıl derleneceğini gösteren bir Dockerfile (zorunlu)
• İsteğe bağlı threat_model.md dosyası: projenin tehdit modelini anlatan belge
• Raporların PGP ile şifrelenebilmesi
• disabled: true ayarıyla kaydı silmeden raporları duraklatabilme

Tarama nasıl işliyor, rapor neler içeriyor

Cybersecurity News'in aktardığı akışa göre tarayıcı önce projeyi izole bir sanal makinede derliyor. Bu aşamada bağımlılıklar kurulabilsin diye ağ erişimi açık. Güvenlik denetimi başlamadan önce internet bağlantısı kesiliyor. Bu ayrım bence önemli: model, denetim sırasında dışarıyla konuşamıyor, yalnızca derlenmiş proje üzerinde çalışıyor.

Raporlar e-postayla geliyor. Her birinde bir yeniden üretme adımı (reproducer), açıklama, hatanın muhtemelen hangi commit'te girdiğini gösteren (mevcutsa) bir bisect ve mümkün olduğunda önerilen bir yama bulunuyor. Anthropic, hattaki ajanların hataları ikinci kez kontrol ettiğini ve kök nedeni incelediğini söylüyor. Ancak bu kontrol de model tarafında yapılıyor; araya bir insan girmiyor.

Reproducer'ın olması, bakımcı açısından raporun en değerli kısmı. Çalışan bir yeniden üretme adımı varsa iddiayı çok daha hızlı doğrulayabilir ya da çürütebilirsiniz. Olmadığında ise model ne kadar ikna edici yazmış olursa olsun, iş yine sizin önünüze uzun sürebilecek bir inceleme olarak düşüyor.

Rapor kalitesi: rakamlar ne söylüyor, ne söylemiyor

Anthropic'in yayımladığı doğrulama rakamları ilk bakışta iyi görünüyor. Security Affairs'in aktardığına göre erken bir sürümün 48 projede bulduğu 97 kritik ve yüksek seviyeli bulgu sızma testi uzmanlarına kontrol ettirilmiş. Bunların 85'i (yüzde 88) koordineli zafiyet bildirimi çıtasını geçmiş, 11'i gerçek ama zaten bilinen ya da başka taramalarda bulunmuş tekrarlar çıkmış, yalnızca biri yanlış alarm olmuş. Saha tarafında da benzer bir sinyal var: gömülü şifreleme kütüphanesi wolfSSL, erken denemelerde aldığı 74 raporun ikisi hariç hepsinin geçerli olduğunu ve beşinin CVE'ye dönüştüğünü söylüyor.

Öte yandan resmin geri kalanı daha bulanık. Implicator'ın derlediği verilere göre modeller 29.000'den fazla aday zafiyet işaretlemiş, ancak 2 Ekim itibarıyla dış firmalar bunların dörtte birinden azını incelemişti. Aynı tarihte bildirim panosunda bakımcılara iletilmiş 6.157 bulgu görünüyordu; bunların 4.824'ü doğrudan gönderilmişti ve yanlış alarm içerebilir. 6.157 bulgunun 516'sı kaynak projede yamalanmıştı.

Benim okumam şu: yüzde 88, erken bir sürümün 48 projedeki 97 kritik/yüksek bulgusundan oluşan, yalnızca en yüksek şiddet sınıflarını kapsayan bir örneklemden geliyor. İnsan incelemesinden hiç geçmeyen 4.824 raporun da aynı oranda isabetli olacağını varsaymak için elimizde veri yok; o raporlar farklı şiddet seviyelerini ve daha geniş bir proje yelpazesini içeriyor olabilir. Üstelik bu doğrulama bağımsız olarak denetlenmemiş.

Bir uyarı daha var. Lansman haberlerinin özetlerine yansıyan bakımcı yorumlarına göre bazı bakımcılar şiddet derecelerinin olduğundan yüksek gösterildiğini ya da tarayıcının projelerinin tehdit modelini yanlış anladığını belirtmiş; bu yorumları yukarıdaki kaynaklardan birine doğrudan bağlayamadığımızı not edelim. Yine de threat_model.md dosyasının neden isteğe bağlı bırakıldığını sorgulamak için yeterli bir işaret. Bence ciddi her başvuruda bu dosya fiilen zorunlu sayılmalı.

İnsan incelemesi olmamasının bedeli

Anthropic bu konuda açık sözlü. Engadget'in aktardığına göre şirket çıktının "insan incelemesi ya da triyaj olmadan, tamamen model tarafından üretileceğini" söylüyor; bunun daha hızlı ve daha sık tarama sağladığını, ama bazı raporların yanlış ya da geçersiz olabileceği anlamına geldiğini kabul ediyor. Yani hız ve kapsam, doğruluk kontrolünün bakımcıya devredilmesiyle elde ediliyor. iTechPost'un da vurguladığı gibi gerçek hatayı yanlış alarmdan, tekrardan ve abartılı şiddet derecesinden ayırmak artık bakımcının işi.

Anthropic bu yükü hafifletmek için iki şey yapıyor. Birincisi, yanlış alarm ihtimali yüzünden bu bulgulara 90 günlük ifşa süresi dayatmıyor; kimse sizi bir geri sayımla sıkıştırmıyor. İkincisi, ham bulgulara yetişecek ekibi olmayan projeler Anthropic'in mevcut bildirim süreci üzerinden insan tarafından doğrulanmış raporlar almaya devam ediyor.

Hizmetin kimin için olmadığını SSS aslında kendisi söylüyor. Implicator'ın aktardığına göre SSS, birçok projenin zaten raporlar altında ezildiğini kabul ediyor ve OSS Scanner'ın doğrulanmış yüksek ve kritik raporlara zaten yetişebilen projeler için tasarlandığını belirtiyor. Hafta sonları gönüllü olarak bakılan tek kişilik bir kütüphaneyseniz, önce şunu hesaba katın: seçim kriterleri oturmuş ve altyapı açısından kritik projeleri öncelediği için böyle bir projenin kabul edilmesi zaten garanti değil. Kabul edilse bile ham rapor akışı yardımdan çok iş yükü getirebilir; bu durumda insan tarafından doğrulanmış koordineli bildirim yolu açık kalıyor.

Çoğu kişinin atlayacağı bir ayrıntı daha var: kayıt, Anthropic'in tüketici koşullarına tabi ve bu koşullar girdiler ile çıktılar üzerinde eğitime izin veriyor. Kodunuz zaten açık kaynak olduğu için bu birçok proje için sorun olmayabilir. Yine de güvenlik raporlarının ve önerilen yamaların da bu kapsama girdiğini bilerek karar vermek gerekiyor.

OSS-Fuzz, CodeQL ve Snyk ile kıyaslamak mümkün mü

Burada dürüst olmak gerekiyor: incelediğimiz kaynakların hiçbiri OSS Scanner'ı GitHub CodeQL ya da Snyk ile doğrudan karşılaştırmıyor. Elimizdeki tek bağlantı, Engadget'in aktardığı gibi hizmetin Google ve OpenSSF'nin OSS-Fuzz'ından ilham aldığı. Proje seçim kriterlerinin de OSS-Fuzz'a benzediği, altyapı ve kullanıcı güvenliği açısından önemli, oturmuş projelerin öncelendiği belirtiliyor.

Rakamsal bir kıyas yapamıyoruz, ama konumlandırma farkını görmek mümkün. OSS Scanner, sizin seçmediğiniz ve sizin çalıştırmadığınız bir taramadır: Anthropic, kabul ettiği kaynak projeleri tarar, sonucu o projenin bakımcısına gönderir. Şirketinizin kendi kod tabanında ve kendi CI hattında çalıştırdığı araçlar ise kontrolü sizde tutar. Bu ikisi birbirinin yerine geçmiyor.

Anthropic'in genel kod tarama ve yamalama için ayrıca ücretli bir ürünü, Claude Security de var. Ücretsiz tarayıcının aynı zamanda bu ürünün yeteneklerini gösteren bir vitrin işlevi gördüğünü düşünmek bence haksızlık olmaz. Bu, hizmetin faydasını azaltmıyor ama motivasyonu anlamak için akılda tutulmalı.

Orta ölçekli bir şirket bağımlılık listesiyle ne yapmalı

Önce beklentiyi doğru kuralım. OffSeq'in değerlendirmesine göre son kullanıcıların ve kurumların, isterlerse kaydolmak dışında doğrudan bir şey yapması gerekmiyor. DEV Community'deki yazının hatırlattığı gibi OSS Scanner şirketinizin kullandığı her bağımlılığı taramıyor, yalnızca kayıt olmuş ve uygun bulunmuş projeleri kapsıyor. Yani bu duyuru sizin yerinize iş yapmıyor; ama kayıtlı projelerde yama sıklığı artabilir ve buna hazır olmak gerekir.

Pratikte bunun anlamı şu: yalnızca üst katmandaki birkaç paketi değil, kritik bağımlılıklarınızı gerçekten görebilmeniz gerekiyor. Kaynak projelerden gelen güvenlik duyurularını takip etmeyen bir ekip için daha fazla bulgu, daha fazla kaçırılmış yama demek. Bir de şu tuzağa düşmemek lazım: bir kütüphanenin OSS Scanner'a kayıtlı olması onun güvenli olduğunu göstermez, sadece birinin baktığını gösterir.

• Üretimde çalışan uygulamalarınızın doğrudan ve dolaylı bağımlılıklarını çıkarın, kritik olanları (ağa açık bileşenler, kimlik doğrulama, şifreleme, dosya ayrıştırma) işaretleyin.
• Kritik bağımlılıkların kayıt durumuna anthropics/oss-scanner deposundaki projects klasöründen ve açık pull request'lerden bakabilirsiniz. Ancak açık bir pull request henüz kabul edilmiş bir kayıt değildir, klasördeki bir dosya da disabled: true ile duraklatılmış olabilir; birleştirilme durumunu ve disabled alanını mutlaka kontrol edin.
• Bu projelerin güvenlik duyurularını ve sürüm notlarını izleyen bir sorumlu belirleyin; yama çıktığında sürüm yükseltmenin kimde olduğu belli olsun.
• Sürüm yükseltmeyi hızlı yapabilmek için test kapsamınızı gözden geçirin; yama çıkıp da siz kırılma korkusuyla aylarca bekliyorsanız tarayıcının size faydası sınırlı kalır.
• Şirket içinde bakımını üstlendiğiniz ya da çatalladığınız açık kaynak projeler varsa, ekibinizin ham raporlara yetişip yetişemeyeceğini dürüstçe değerlendirdikten sonra kaydı düşünün.

Kim kazanır, kim yük taşır

OSS Scanner'ın arkasındaki yaklaşım cesur ve bence büyük ölçüde doğru yönde. Reproducer, bisect ve önerilen yamayla gelen bir rapor, tek satırlık "burada bir açık olabilir" mesajlarından çok daha kullanışlı. wolfSSL gibi deneyimli bir ekibin geri bildirimi de kalitenin en azından bazı projelerde ciddiye alınacak düzeyde olduğunu gösteriyor.

Zayıf nokta da aynı yerde duruyor: insan kontrolünün tamamen bakımcıya bırakılması. Yayımlanan isabet oranı, erken bir sürümün 48 projedeki 97 kritik/yüksek bulgusundan oluşan, yalnızca en yüksek şiddet sınıflarını kapsayan bir örneklemden geliyor; bağımsız denetim yok ve binlerce bulgu hiç incelenmeden gönderilmiş. Güçlü güvenlik ekibi olan büyük projeler bundan kazançlı çıkar. Kabul edilse bile dar bir ekiple ayakta duran projeler için aynı hizmet, zaten ağır olan yükün üstüne bir katman daha ekleyebilir.

Şirketler açısından mesaj net: bu tarayıcı sizin güvenlik süreçlerinizin yerine geçmiyor. Yapılması gereken iş, bağımlılıkları tanımak, kaynak projeleri izlemek ve yama geldiğinde hızlı hareket edebilmek. Bunlar yapılmıyorsa, kaynak projelerde ne kadar çok açık bulunduğunun sizin için pek bir önemi kalmıyor.