Anthropic ücretsiz açık kaynak taraması açtı; bulgular insan onayı beklemiyor

Anthropic, 8 Ekim 2026 tarihli lansmanıyla OSS Scanner adlı ücretsiz güvenlik tarama hizmetini açık kaynak projelerine açtı. Katılan projeler düzenli taramalar alacak; modelin ürettiği bulgu raporları ise insan incelemesinden geçmeden bakımcılara gönderilecek. Bu hız, rapordaki açığın gerçek olup olmadığını ve önerilen düzeltmenin güvenle uygulanıp uygulanamayacağını belirleme işini projeye bırakıyor.

Anthropic’in teknik duyurusuna göre şirket son altı ayda 29.000’den fazla aday açık buldu, bunların yaklaşık 6.000’ini elle inceleyebildi; HotCRP’den Eddie Kohler ilk raporları “The bug reports were thorough and clear” sözleriyle değerlendirdi. OSS Scanner, bu inceleme kuyruğunu beklemek istemeyen uygun projeler için isteğe bağlı bir yol sunuyor. Başvuru kabul edilse bile her bulgunun doğruluğu veya önem derecesi önceden bir uzman tarafından onaylanmış olmuyor.

OSS Scanner’a hangi projeler kabul ediliyor?

Hizmet, her açık kaynak deposuna kendiliğinden açılmıyor. OSS Scanner’ın başvuru koşulları, altyapı ve kullanıcı güvenliği üzerinde kritik etkisi olan yerleşik projelerin ayrı ayrı değerlendirileceğini belirtiyor. Uzaktan saldırıya açık bileşenler, güvenilmeyen girdileri işleyen kütüphaneler ve projeye bağımlı kullanıcıların ya da başka projelerin sayısı bu değerlendirmede dikkate alınıyor.

Başvuruyu çekirdek bakımcıların, Anthropic’in OSS Scanner deposuna proje yapılandırması ekleyen bir pull request açarak yapması gerekiyor. Yapılandırmada taranacak Git deposunun adresi, raporların ulaşacağı birincil e-posta adresi ve projeyi kurup derlemek için kullanılacak Dockerfile yolu yer alıyor; Dockerfile, başvuru deposunda ayrıca da sağlanabiliyor. Taranacak kodun GitHub’da barındırılması şart değil. Anthropic, projeyi kabul etmeden önce başvuran kişinin çekirdek bakımcı olduğunu ayrıca doğruluyor.

İsteğe bağlı tehdit modeli dosyası, hangi kodun inceleneceğini, hangi girdilerin saldırgan tarafından kontrol edilebildiğini ve hangi durumların kapsam dışında kaldığını anlatabiliyor. Bakımcılar bu dosyada önem derecesi ölçütlerini ve bekledikleri rapor biçimini de tarif edebiliyor. Dosya eklenmezse tarayıcı bu konularda kendi varsayımlarını kullanıyor. Program, doğrulanmış ciddi güvenlik raporlarını zaten ele alabilecek kapasitesi olan projelere yönelik.

Kabul edilen proje nasıl taranıyor, bakımcıya ne geliyor?

Kabulün ardından ilk tarama yapılıyor; sonraki taramalar hem yeni eklenmiş açıkları hem de önceki incelemelerde gözden kaçmış olabilecek sorunları arıyor. Ek taramaların sıklığı sabit bir takvime bağlanmış değil: programa katılan proje sayısı ve tarama hattının kullanımı bu aralığı etkileyebiliyor. Projenin kurulması için gereken bağımlılıklar Dockerfile hazırlanırken indirilebiliyor, ancak güvenlik incelemesini yapan aracılar daha sonra internet erişimi kapalı bir ortamda çalışıyor.

Bakımcının yapılandırmada verdiği adrese e-postayla bir bulgu paketi gönderiliyor. Her raporda hatayı yeniden üretmeye yarayan bağımsız bir örnek ve açığın teknik açıklaması bulunuyor; mümkünse hatanın hangi değişiklikle ortaya çıktığına ilişkin inceleme ve aday yama da ekleniyor. Tarama hattındaki otomatik aracılar bulguları yeniden kontrol ediyor, kök nedeni araştırıyor ve düzeltme önerebiliyor. Bu adımların otomatik olması, teslim edilen rapora bir insanın güvenlik onayı verdiği anlamına gelmiyor.

Buradaki fark, Anthropic’in olağan koordineli açık bildirim süreciyle ilgili. Olağan süreçte uzmanlar bulguları bakımcıya iletmeden önce değerlendiriyor; OSS Scanner’a katılan proje ise model çıktısını bu aşamayı beklemeden alıyor. Dolayısıyla rapordaki yeniden üretim örneği araştırmayı hızlandırabilir, fakat raporun kendisi doğrulanmış bir açık kaydı ya da doğrudan birleştirilmeye hazır yama sayılmaz.

İnsan incelemesi yokken rapor nasıl doğrulanır?

Bakım ekibinin ilk kararı, raporun kendi desteklediği sürüm ve kurulumda gerçek bir sorunu gösterip göstermediği. İlk denemelere ilişkin geri bildirimlerde bazı önem derecelerinin yüksek tahmin edildiği ve kimi proje tehdit modellerinin yanlış yorumlandığı belirtiliyor. Bu nedenle yeniden üretim örneği, saldırganın erişebildiği koşullar ve önerilen yama ayrı ayrı değerlendirilmeli; otomatik raporda bunların birlikte sunulması aralarındaki farkı ortadan kaldırmıyor.

1. Rapordaki sürümü, bileşeni ve girdi koşullarını belirleyip yeniden üretim örneğini projenin desteklediği kurulumda çalıştırın. Örnek çalışmıyorsa gereken yapılandırmayı ve raporda atlanmış olabilecek bağımlılıkları ayırın.
2. Hatanın oluştuğu girdiyi gerçekte kimin kontrol edebildiğini tehdit modeliyle karşılaştırın. Uzaktan erişim veya gerekli yetki hakkındaki yanlış bir varsayım, bulgunun önem derecesini değiştirebilir.
3. Aynı sorunun önceden bildirilip bildirilmediğini ve paketteki başka raporlarla örtüşüp örtüşmediğini inceleyin. Yinelenen bulguları ayırmak, ayrı düzeltme gerektiren açıkların önceliğini belirlemeyi kolaylaştırır.
4. Önerilen yamayı ayrı bir değişiklik olarak sınayın. Yeniden üretim örneğinin artık başarısız olması kadar projenin beklenen davranışının ve ilgili testlerin korunması da önemlidir.

Bu sıralama bakımcı için bir değerlendirme çerçevesidir; tarayıcının otomatik olarak tamamladığı bir onay zinciri değildir. Gerçek bir hata yanlış önem derecesiyle raporlanabilir, işe yarar görünen bir aday yama da başka desteklenen kurulumları bozabilir. Raporda yama bulunmadığında ise yeniden üretilebilirlik ve etki değerlendirmesi, düzeltmenin kapsamını belirlemek için hâlâ gereklidir.

Açıklama süresi ve rapor yükü nasıl değişiyor?

İnsan tarafından doğrulanmamış OSS Scanner bulgularına otomatik bir koordineli açıklama süresi uygulanmıyor. Anthropic daha sonra aynı bulguyu olağan insan incelemeli süreçte doğrularsa o sürecin bildirim ve açıklama kuralları devreye girebiliyor. Proje, yapılandırmasını değiştirerek otomatik raporları geçici olarak duraklatabiliyor veya başvurusunu kaldırarak programdan çıkabiliyor; böylece olağan insan incelemeli bildirimleri almaya devam ediyor.

Ücretsiz tarama açık arama maliyetini proje adına karşılıyor, fakat gelen e-postaları ayıklama, etkisini belirleme ve yamaları sınama kapasitesini sağlamıyor. Bakımcı açısından belirleyici sonuç, rapor sayısından çok doğrulanıp güvenle düzeltilebilen sorunlar olacak. Otomatik bildirimlerin ekibin inceleme kapasitesini aşması halinde akışı duraklatabilmek, hizmetin başvuru koşulları kadar önemli bir sınırı.

Ayrıca okuyun:

• ServiceNow’da üç 10,0’lık açık: Şirket içi kurulum beklemez
• Archive yatırım aldı: Müşteri sayısı açık, turun büyüklüğü açıklanmadı
• Türkiye’de AI ajanı denetimi zayıf: İnsan onayı yalnızca yüzde 13