Bir hatanın söylentisi bile açığı bulmaya yetiyor, diyor OCaml geliştiricisi

Dakikalar içinde taranan bir düzeltme

OCaml ekosistemi geliştiricisi ve Cambridge araştırmacısı Anil Madhavapeddy, 22 Ağustos'ta açık kaynak güvenlik sürecinin nasıl değiştiğine dair bir not yayımladı. Yol geçişi hatasını gideren cohttp 6.3.0 güvenlik güncellemesini çıkardı. Bildirim Jane Street üzerinden bir Slack kanalına özel olarak gelmişti ve kendi ifadesiyle Claude Fable ile bulunmuştu.

Normalde hata özel olarak düzeltilir, etkilenen kullanıcılar bilgilendirilir ve ardından kamuya açık bir uyarı yayımlanırdı. Bu kez, canlı sunucu günlüklerinde hatanın tam kalıbını taşıyan istekleri, düzeltme PR'ını açtıktan dakikalar sonra gördü. Kendi ajanını etkilenen koda yönlendirip yerel bir sunucu için bir dakikadan kısa sürede istismar kodu ürettiğini ve otomatik bir saldırının başlaması için on dakikanın oldukça uzun bir pencere olduğunu yazdı.

Ambargolar artık zaman kazandırmıyor

Notun ikinci bölümü ambargoların etkinliğine ayrılıyor. Geleneksel süreç ayrıntıların gizli tutulmasına dayanıyor, ancak yazara göre bugün ajan tabanlı bir sisteme yalnızca genel bir arama yönü yeterli. Fang ve arkadaşlarının 2024 tarihli çalışmasında GPT-4 tabanlı bir ajan, CVE açıklaması verildiğinde 15 açıklık içeren bir kıyas setinin yüzde 87'sini istismar etti; açıklama olmadan bu oran yüzde 7'de kaldı.

İstismara kadar geçen ortalama süre artık negatif: yaklaşık eksi yedi gün, yani istismar yamadan önce geliyor. Bu değer 2018-2019'da 63 gün civarındaydı ve sıfırı 2024'te geçti. İki örnek: marimo'nun CVE-2026-39987 açığına ilk istismar girişimi, kamuya açık bir kanıt kodu olmamasına rağmen uyarıdan 9 saat sonra geldi; Langflow'un CVE-2026-33017 açığında ise 20 saat sürdü.

Notta ayrıca bugonomics terimini ortaya atan Mayıs 2026 tarihli bir makaleye atıf yapılıyor: makaleye göre darboğaz, savunma tarafındaki düzeltme kapasitesine kaydı; zira dil modelleri istismar üretirken geliştiricilerin triyaj ve sürüm hızı sabit kaldı. Yazar, Project Glasswing kapsamında sınır modellere erişimin 15 ülkedeki 150 kuruluşa genişletildiğini, küçük geliştiricilerin ise bu erişimden hâlâ yoksun olduğunu belirtiyor.

Geliştiriciler ne yapabilir

Üç yön tartışılıyor. Birincisi düzeltmeleri gerçekten kapalı bir ortamda hazırlamak; GitHub'ın geçici özel fork'ları bunu ancak kısmen sağlıyor, çünkü CI bu fork'lara erişemiyor ve fork'a yalnızca tek bir pull request birleştirilebiliyor. İkincisi ambargolardan vazgeçip sürekli sürüm çıkarmak: Chrome haftalık güvenlik güncellemeleriyle bunu yapıyor; Linux çekirdeği düzeltmeleri en fazla yedi, istisnai olarak on dört gün erteliyor. Üçüncüsü protokol katmanında savunma: yüzdeyle kodlanmış yol ayırıcılarını normalleştirmek, bildirim geldiği anda uygulanabiliyor; tam düzeltme ise inceleme, test ve paketleme sürecinden geçiyor.

Yazara göre açık kaynak, ticari bir CDN dışında bu tür kuralları dağıtacak bir mekanizmaya sahip değil. Cloudflare 2021'de Log4shell açığını kapatmak için yönetilen kurallar yayına aldı, ancak daha geniş ekosistem için hızla yayılan benzer bir savunma yok. Not, sorunu bildiren Sapphire Livingstone'a ve düzeltmeyi inceleyenlere teşekkürle bitiyor; yazar bunun tek kişilik bir iş olmadığını vurguluyor.