Güvenlik açığı raporları artık özel değil

• Açık kaynak bakımında genel issue’lar ve PR’lar isteğe bağlı olarak ele alınabilir, ancak geçmişte güvenlik açığı raporları kullanıcıları korumak nedeniyle ayrı bir müdahale gerektiren istisnaydı
• Bu istisnai durum, araştırmacının saldırgandan önce düzeltme yapma fırsatı vermesini sağlayan nadir içgörü ve gizliliği sunuyordu; projeler de bunu hızlı yanıt, inceleme, ilerleme paylaşımı ve katkı kredisiyle karşılıyordu
• 2026’da hem bakımcılar hem de saldırganlar LLM çalıştırabildiği için darboğaz, potansiyel issue bulmaktan gerçek güvenlik açıklarını ayıklamaya kayıyor
• Güven ilişkisi olmayan dış araştırmacılar bu ayıklamaya büyük katkı sağlayamıyor ve LLM çıktısını incelemekle security@ gelen kutusunu gözden geçirmenin sinyal/gürültü oranı benzer hale geliyor
• Bakımcıların zamanı, raporları yanıtlamanın kendisinden çok sınıflandırma, hızlı düzeltme ve önleme için kullanılmalı; ayrıca LLM analizini CI içinde çalıştırmanın yolları da gerekli

---

Güvenlik açığı raporlarının neden istisna olduğu

• Kamusal biçimde çalışan açık kaynak bakımcıları issue’ları, PR’ları ve geri bildirimleri birer hediye gibi kabul eder; ihtiyaçlarına göre benimseyebilir, görmezden gelebilir ya da yalnızca bir kısmını kullanabilir
• Geçmişte güvenlik açığı raporları bu ilkenin dışında kalan özel bir vakaydı
  • Güvenlik araştırmacıları hemen kamuya açıklamak yerine özel raporlamayı seçerek projeye önce düzeltme yapma zamanı tanıyordu
  • Projelerin raporu hızla teyit etmesi, araştırması, raporlayan kişiyle ilerlemeyi paylaşması ve sonunda keşif için kredi vermesi genel beklentiydi
• Bu beklenti, raporlayan kişinin bug düzeltmesi ya da özellik talep eden biri değil, projeye hizmet sunan biri olduğu varsayımına dayanıyordu
  • Temel değer, saldırgan exploit yayımlamadan önce düzeltmenin dağıtılmasını mümkün kılan içgörü ve gizlilikti
  • Güvenlik açığı raporlarını yok saymak, kullanıcı güvenliğinin önemsenmediği yönünde bir sinyal olarak görülüyordu

2026’da çöken varsayımlar

• 2026’da güvenlik açığı raporlarını özel kılan varsayımları sürdürmek artık zorlaştı
  • LLM’ler neredeyse tüm güvenlik araştırmacıları kadar iyi ve herkes tarafından çalıştırılabiliyor
  • Aynı araçları bakımcılar da saldırganlar da çalıştırabiliyor
• Kıt olan şey potansiyel issue bulma yeteneği değil, bunların hangisinin gerçek bir güvenlik açığı olduğunu ayırt etmeye yönelik sınıflandırma işi
• Önceden kurulmuş bir güven ilişkisi olmayan dış araştırmacılar bu sınıflandırma sürecine anlamlı biçimde katkı sağlamakta zorlanıyor
  • LLM çıktısını gözden geçirmekle security@ gelen kutusunu taramanın sinyal/gürültü oranı neredeyse aynı
• Gizlilik, ambargo ve koordinasyonun önemi de eskisine göre azaldı
  • Saldırganlar tam kamu açıklamasını beklemeden kendi LLM’lerine güvenlik açıklarını sorabiliyor
  • Yine de saldırganların da savunmacılarla aynı sınıflandırma darboğazını yaşaması muhtemel

Bakımcıların önceliklerindeki değişim

• Güvenlik açığı raporlarının özel olduğu dönem bitmiş olabilir
• Artık daha önemli olan şey sınıflandırma, hızlı düzeltme ve önleme
• LLM analizini CI içinde çalıştırmanın yolları bulunmalı
• Bu görüş, Go Security ekibinin resmî görüşü değil; eski Go Security ekip liderinin kişisel değerlendirmesi
• Güvenlik açığı raporlarını işleme ile Code of Conduct uygulaması çatıştığında tek bir doğru cevap yok
  • Davranışın ciddiyetine, bunun özel bir mesele mi yoksa topluluğu etkileyen bir durum mu olduğuna ve security@ ekibinin kaynaklarına göre karar vermek gerekir
• Kamusal açıklama pratiklerinin karmaşık bir geçmişi var
  • Geçmişte iyi niyetli araştırmacılar hukuki tehditlerle ya da kovuşturmayla karşılaşabiliyordu
  • 2026’nın açık kaynak gerçekliğinde, güvenlik açığı raporları nedeniyle kovuşturmadan korkan araştırmacı yok; projeler de belgelenmiş raporlama politikasına alternatif olarak kovuşturma imasında bulunmamalı
• curl’ün güvenlik açığı raporlama kanalını bir aylığına durdurması ilk başta aşırı gelmişti, ancak kullanıcıları korumak için güvenlik açığı raporlarına yanıt vermenin zamanın en iyi kullanımı olup olmadığı artık net değil

[GN⁺]

Lobste.rs görüşleri

• Aceleyle yapılan güvenlik açığı ifşalarının hâlâ savunmacılardan çok saldırganlara yaradığı kanaatindeyim. Bizzat yaşayıp gördüğüm kadarıyla, en gelişmiş modeller kullanılsa bile yanlış pozitif oranı %90’a yaklaşabiliyor
  Ayrıca, “açık kaynak kripto protokollerinin sürdürülebilir bakımı ve geliştirilmesi, blockchain teknolojisinin geniş çapta benimsenmesi için önemlidir” ifadesi göze çarpıyor; blockchain teknolojisine hâlâ inanan insanlar olması şaşırtıcı

  • O ifadenin neden orada olduğunu anlayamamıştım, meğer Fillippo’nun sponsorlarından birinin gönderdiği bir mesajmış
    Bu noktada blockchain teknolojisinin dünyaya yaptığı en değerli katkı, gerçekten güvenli kripto protokol implementasyonları üretmek için güçlü finansal teşvikler sağlamış olması olabilir. Bunların bir kısmı diğer herkes için de faydalı hâle gelebilir
  • Buradaki yanlış pozitiften ne kastedildiğini merak ediyorum. Model bir güvenlik açığı bulduğunu iddia ediyor ama doğrulayınca aslında sorun olmadığı mı anlaşılıyor?
    Bu aşamada güvenlik açığı bulma ve genel olarak kod anlama işlerinin LLM’lerin iyi olduğu alanlar olarak epey yerleştiğini sanıyordum; pratikte durumun gerçekten böyle olup olmadığını merak ediyorum. Bizzat yaşadıklarını biraz daha anlatabilir ya da bakılabilecek kaynaklar paylaşabilirsen iyi olur. LLM kullanmadığım için güncel seviyeyi kestirmekte zorlanıyorum; varsayımlarımı değiştirip değiştirmem gerektiğini gerçekten merak ediyorum

• Özel güvenlik açığı raporlarına özel muamele yapılmalı ve savunmacı tarafta daha iyi doğrulama yöntemleri ile açıkça tanımlanmış tehdit modelleri bulunmalı. Böylece insanların harika bir rapor olarak kabul edilmek için daha yüksek standartları karşılayıp karşılamadıkları doğrulanabilir

  • Sonuçta mesele buna varabilir. Güvenlik açığı raporları genel olarak özel değildir, ama ciddiyeti yüksek veya güvenilirliği yüksek bazı raporlar özel güvenlik açığı raporları olarak görülmelidir

• Güvenlik sorunlarını bulmak kolaylaştığı ve giriş bariyeri düştüğü için güvenlik mailing listelerinde eskisine göre daha fazla gürültü oluştuğu görüşüne katılıyorum. Yine de Trail of Bits veya Zellic gibi itibarlı güvenlik danışmanlık şirketlerinden gelen hata raporlarını hâlâ net biçimde önceliklendirirdim
  Bunun nedeni sadece onların özensiz raporlar göndermeyeceğine güvenmem değil; CI içinde LLM’i rastgele çalıştırmaktan ziyade üst düzey güvenlik araştırmacıları ile LLM kombinasyonunun daha iyi olduğuna inanmam

  • Yakın zamanda bu tür tedarikçilerle çalıştım ve özensiz raporlar hâlâ geliyor. Sadece raporların genel kalitesi daha yüksek oluyor
    LLM, onu kim yönlendirirse yönlendirsin tehdit modelini yanlış anlayabilir ve “exploit”i kanıtlama biçiminde tembellik edebilir. Güvenlik araştırmacısı bu hataları gözden kaçırırsa, sonuçta bunlar bizim gibi bakımcılara iletiliyor. containerd, bu tür tedarikçilerden, LLM araştırma şirketlerinden, bilinen temel model şirketlerinden ve internetteki J Random User’lardan da özensiz raporlar aldı
    Filippo’nun burada yeterince değinmediği bir başka zorluk da mükerrer raporlar. containerd’nin son advisories kayıtlarına bakarsanız, triage ve dikkat dağılımında bir diğer büyük sorunun mükerrerlik olduğunu görebilirsiniz. Örneğin 9 separate researchers/groups için kredi verildi; bunların arasında az önce bahsedilen itibarlı gruplar da var. Bu durum, (a) LLM’lerin kim kullanırsa kullansın aynı sorunların çoğunu bulduğunu ve (b) bilinen bir raporlayıcıdan gelen bildirimin mutlaka özel olmadığı gösteriyor. Buna karşılık this one için gerçekten mükerrer rapor yoktu, bu yüzden yalnızca bir kişiye kredi verildi; o raporlayıcı da bizim önceden tanıdığımız ya da ilişkimiz olan biri değildi