Stronger_Cracker
- 25 Tem 2022
- 6,407 Mesaj
Yapay Zeka Tarafından Keşfedilen 0-day’lerin Artan Riskini Değerlendirme ve Azaltma
5 Şubat 2026 | Nicholas Carlini*, Keane Lucas*, Evyatar Ben Asher*, Newton Cheng, Hasnain Lakhani, David Forsythe ve Kyla Guru (*eşit katkı)
Bugün yayımlanan Claude Opus 4.6, yapay zeka modellerinin siber güvenlik yeteneklerinde anlamlı ilerlemelerin sürdüğünü gösteriyor. Geçen sonbahar, yapay zekanın siber güvenlikteki etkisi açısından bir dönüm noktasında olduğumuzu yazmıştık: ilerleme hızlanabilir ve savunmada yapay zekayı hızla devreye sokmanın tam zamanıydı. O günden bu yana gördüklerimiz bu görüşü güçlendirdi. Yapay zeka modelleri artık yüksek önemde güvenlik açıklarını kitlesel ölçekte tespit edebiliyor. Bize göre şu an hızlı hareket etme anı: savunmacıları güçlendirmek ve bu fırsat penceresi açıkken mümkün olduğunca fazla kodu güvence altına almak.
Opus 4.6, önceki modellere kıyasla yüksek önemde güvenlik açıklarını bulmada belirgin şekilde daha iyi; bu da işlerin ne kadar hızlı ilerlediğinin bir göstergesi. Güvenlik ekipleri yıllardır zafiyet keşfini otomatikleştiriyor, büyük ölçekte hata bulmak için fuzzing altyapısına ve özel test düzeneklerine ciddi yatırım yapıyor. Erken testlerde asıl dikkat çeken ise Opus 4.6’nın, göreve özel araçlar, özel iskelet ya da özel promptlar olmadan, kutudan çıkar çıkmaz ne kadar hızlı zafiyet bulduğu oldu. Daha da ilginci, bulma biçimi. Fuzzer’lar, kodun ne zaman kırıldığını görmek için koda çok büyük miktarda rastgele girdi gönderir. Opus 4.6 ise kodu insan bir araştırmacı gibi okuyup üzerinde akıl yürütüyor: geçmiş düzeltmelere bakıp ele alınmamış benzer hataları arıyor, sorun çıkarma eğilimindeki kalıpları yakalıyor ya da bir mantık parçasını, hangi girdinin onu bozacağını bilecek kadar iyi anlıyor. En iyi test edilmiş kod tabanlarına (yıllardır fuzzer’lara tabi tutulmuş, milyonlarca saat CPU biriktirmiş projelere) Opus 4.6’yı yönelttiğimizde, yüksek önemde zafiyetler buldu; bazıları onlarca yıldır fark edilmemişti.
Teraziyi savunmacılardan yana çevirmek, bir kısmıyla kendi işimizi yapmaktan geçiyor. Artık Claude’u açık kaynak yazılımlardaki zafiyetleri bulmak ve düzeltmeye yardımcı olmak için kullanıyoruz. Açık kaynakla başladık çünkü her yerde çalışıyor—kurumsal sistemlerden kritik altyapıya kadar—ve oradaki zafiyetler tüm interneti etkiliyor. Bu projelerin birçoğu küçük ekipler veya özel güvenlik kaynağı olmayan gönüllüler tarafından yürütülüyor; bu yüzden insan tarafından doğrulanmış hataları bulup, insan tarafından incelenmiş yamalar sunmak gerçekten fark yaratıyor.
Şu ana kadar 500’den fazla yüksek önemde zafiyet tespit edip doğruladık. Bunları raporlamaya başladık, ilk yamalarımız projelere girmeye başladı ve diğerlerini yamamak için bakımcılarla çalışmaya devam ediyoruz. Bu yazıda metodolojimizi adım adım anlatacak, Claude’un keşfettiği zafiyetlerden erken dönem örnekler paylaşacak ve bu yetenekler geliştikçe kötüye kullanımı sınırlamak için aldığımız önlemleri ele alacağız. Bu çalışmaların yalnızca başı. İş büyüdükçe paylaşacak daha çok şeyimiz olacak.
Claude’un hayal ürünü hata üretmediğinden (yani var olmayan sorunları uydurmadığından emin olmak için—açık kaynak geliştiricilere giderek daha fazla yük bindiren bir durum—her hatayı raporlamadan önce ayrıntılı biçimde doğruladık. Odaklandığımız alan bellek bozulması (memory corruption) zafiyetleri oldu; çünkü bunlar nispeten kolay doğrulanabiliyor. Programın çalışmaya devam ettiği mantık hatalarının aksine, bellek bozulması zafiyetleri programın çökmesini izleyerek ve address sanitizers gibi araçlarla non-crashing memory hatalarını yakalayarak tespit edilebiliyor. Ancak programı çökerten her girdi yüksek önemde bir zafiyet olmadığı için, kalan çökmeleri Claude’a eleştirtip tekrarları ayıklattık ve öncelikleri yeniden belirlettik. İlk bulgu turunda her zafiyeti kendi güvenlik araştırmacılarımız doğruladı ve yamaları elle yazdı. Bulgu sayısı arttıkça doğrulama ve yama geliştirme için dışarıdan (insan) güvenlik araştırmacılarını da sürece dahil ettik. Amacımız, bakımcıların raporlarımızla gerçekten işini kolaylaştırmaktı; bu yüzden süreç yanlış pozitifleri azaltacak şekilde kurgulandı. Aynı zamanda, bulduğumuz hataları güvenilir biçimde gidermek için yama geliştirmeyi otomatikleştirme çalışmalarını hızlandırıyoruz.
• GhostScript — PostScript ve PDF dosyalarını işleyen bir araç. Claude zafiyet ararken önce birkaç çıkmaz sokağa girdi: hem kodu fuzz’lamayı denedi hem de bu işe yaramayınca manuel analize geçti. İki yöntem de kayda değer bir sonuç vermedi. Sonunda farklı bir yol izledi: Git commit geçmişini okumaya başladı. Kısa sürede güvenlikle ilgili bir commit’e rastladı ve şu yorumu yaptı:
Buradan sonra Claude, neyin değiştiğini anlamak için koda baktı:
Bunu düşünerek Claude, yamanmamış benzer zafiyetleri bulmak için bu fonksiyonun çağrıldığı diğer yerlere baktı.
Bu gözlemin ardından Claude, öngörülerini kanıtlayan bir proof-of-concept çökmesi (GhostScript’e verildiğinde çökmeye neden olan bir dosya) hızlıca oluşturdu.
OpenSC — Akıllı kart verilerini işleyen bir komut satırı aracı. Claude yine önce fuzz’lama ve manuel analiz denedi; sonuç vermeyince depoda sıkça zafiyet barındıran fonksiyon çağrılarını aramaya başladı.
Claude kısa sürede, ardışık birden fazla strcat kullanılan bir yeri tespit etti. Bu fonksiyonlar C’de genelde güvensiz sayılır; çünkü birleştirilen dizginin toplam uzunluğunu kontrol etmeden birleştirme yaparlar. Bu yüzden programcının çıktı tamponunun birleştirilmiş girdiyi alacak kadar büyük olduğunu doğrulaması çok önemlidir. OpenSC’de asıl sorun şu koddaydı:
Claude bunun buffer overflow’a açık olduğunu tespit etti. Mevcut fuzzer’ların bu satırı ne sıklıkla fuzz’ladığına baktığımızda, geleneksel fuzzer’ların bu satırı nadiren incelediğini görüyoruz; çünkü tetiklenmesi için bir sürü ön koşul gerekiyor. Claude ise hangi kod parçalarının ilginç olduğunu akıl yürüterek çıkarıp çabasını oraya yoğunlaştırabildi, tüm satırlara eşit çaba harcamak yerine.
CGIF, GIF dosyalarını işleyen bir kütüphane. Bu örnekte bizi şaşırtan, Claude’un hatayı nasıl bulduğu değil, hatayı nasıl doğruladığı ve zafiyetin gerçek olduğunu kanıtlayan bir proof-of-concept üretmesi oldu.
Kısaca, Claude bu kütüphanenin sıkıştırılmış verinin her zaman orijinal boyuttan küçük olacağını varsaydığını (normalde makul bir varsayım) ve bu varsayımın istismar edilebileceğini tespit etti. Bunu yapma biçimi zorlu bir süreçti. GIF dosya formatı veriyi LZW sıkıştırma algoritmasıyla sıkıştırır. Eşleşmeleri (mesafe, uzunluk) çiftiyle kodlayan daha geleneksel LZ77 tabanlı sıkıştırıcıların aksine, LZW sık kullanılan token çiftlerinden (tek karakterler veya token çiftleri) bir sözlük oluşturur. Sıkıştırıcı aynı token’a ikinci kez rastladığında “bu token’ı tekrar çıktıla” anlamına gelen daha kısa bir bit dizisi üretebilir. (Dil modellerine aşina olanlar için LZW, ruh olarak BPE tokenization sürecine çok benzer.)
CGIF, sıkıştırılmış bir dizginin sıkıştırılmış boyutunun her zaman sıkıştırılmamış boyuttan küçük olacağını örtük olarak varsaymıştı — bu neredeyse her zaman doğrudur. Yine de Claude buradaki zafiyeti hemen fark etti:
Yani Claude, LZW’nin sabit boyutlu bir sembol tablosu tuttuğunu; bu tablonun boyutu üst sınıra ulaştığında LZW’nin veri akışına özel bir “clear” token’ı eklediğini fark etti. Bu da “sıkıştırılmış” çıktı boyutunun sıkıştırılmamış boyutu aşmasına, dolayısıyla bir buffer overflow zafiyetinin tetiklenmesine yol açıyor.
Bu zafiyet özellikle ilginç çünkü tetiklenmesi LZW algoritmasının ve GIF dosya formatıyla ilişkisinin kavramsal olarak anlaşılmasını gerektiriyor. Geleneksel fuzzer’lar (hatta kapsam rehberli fuzzer’lar bile) bu tür zafiyetleri tetiklemekte zorlanıyor; çünkü belirli dallanma seçimlerinin yapılması gerekiyor. Hatta CGIF’te satır ve dal kapsamı %100 olsa bile bu zafiyet fark edilmeyebilirdi: çok spesifik bir işlem dizisi gerektiriyor.
Uygulama tarafında, bu yeni tespit mimarisiyle uyumlu olacak şekilde pipeline’larımızı geliştiriyoruz. Buna, probe tabanlı tespitten yararlanan siber uygulama iş akışlarımızı güncellemek ve siber kötüye kullanıma karşı aldığımız aksiyonların kapsamını genişletmek dahil. Özellikle, zararlı olarak tespit ettiğimiz trafiği engellemek de dahil gerçek zamanlı müdahale uygulayabiliriz. Bu, meşru araştırma ve bir kısım savunma odaklı çalışmayı zorlaştırabilir; güvenlik araştırma topluluğuyla, bu tür zorluklar ortaya çıktıkça nasıl ele alacağımızı birlikte çalışarak belirlemek istiyoruz. Claude’u hem güvenli hem etkili kılmak için çalışarak siber güvenlikte ön saflarda tutmaya kararlıyız.
Bu değişiklikler birlikte, kötüye kullanımı önleme becerimizde anlamlı bir adım oluşturuyor: yalnızca ne tespit edebildiğimizde değil, tespit ettiklerimize ne kadar hızlı ve etkili müdahale edebildiğimizde.
İleriye baktığımızda hem bizim hem de geniş güvenlik topluluğunun rahatsız edici bir gerçekle yüzleşmesi gerekecek: dil modelleri yeni zafiyetleri tespit edebilecek düzeyde ve yakında uzman insan araştırmacıların hızıyla ölçeğini bile geçebilir.
Aynı zamanda mevcut ifşa (disclosure) normlarının da evrilmesi gerekecek. Sektördeki standart 90 günlük süreler, LLM’lerin keşfettiği hataların hızı ve sayısı karşısında yeterli kalmayabilir; sektörün de bu hıza ayak uyduracak iş akışlarına ihtiyacı olacak.
Bu devam eden bir çalışma; bu yeteneklerin nasıl geliştiği ve güvenlik topluluğunun bunları en iyi nasıl kullanabileceği konusunda öğrendiklerimiz dahil, yakında paylaşacak daha çok şeyimiz olacak.
Claude Code , Anthropic , Opus 4.6 , BufferOverflow , AI NEWS , 0-DAY , GGIF
5 Şubat 2026 | Nicholas Carlini*, Keane Lucas*, Evyatar Ben Asher*, Newton Cheng, Hasnain Lakhani, David Forsythe ve Kyla Guru (*eşit katkı)
Bugün yayımlanan Claude Opus 4.6, yapay zeka modellerinin siber güvenlik yeteneklerinde anlamlı ilerlemelerin sürdüğünü gösteriyor. Geçen sonbahar, yapay zekanın siber güvenlikteki etkisi açısından bir dönüm noktasında olduğumuzu yazmıştık: ilerleme hızlanabilir ve savunmada yapay zekayı hızla devreye sokmanın tam zamanıydı. O günden bu yana gördüklerimiz bu görüşü güçlendirdi. Yapay zeka modelleri artık yüksek önemde güvenlik açıklarını kitlesel ölçekte tespit edebiliyor. Bize göre şu an hızlı hareket etme anı: savunmacıları güçlendirmek ve bu fırsat penceresi açıkken mümkün olduğunca fazla kodu güvence altına almak.
Opus 4.6, önceki modellere kıyasla yüksek önemde güvenlik açıklarını bulmada belirgin şekilde daha iyi; bu da işlerin ne kadar hızlı ilerlediğinin bir göstergesi. Güvenlik ekipleri yıllardır zafiyet keşfini otomatikleştiriyor, büyük ölçekte hata bulmak için fuzzing altyapısına ve özel test düzeneklerine ciddi yatırım yapıyor. Erken testlerde asıl dikkat çeken ise Opus 4.6’nın, göreve özel araçlar, özel iskelet ya da özel promptlar olmadan, kutudan çıkar çıkmaz ne kadar hızlı zafiyet bulduğu oldu. Daha da ilginci, bulma biçimi. Fuzzer’lar, kodun ne zaman kırıldığını görmek için koda çok büyük miktarda rastgele girdi gönderir. Opus 4.6 ise kodu insan bir araştırmacı gibi okuyup üzerinde akıl yürütüyor: geçmiş düzeltmelere bakıp ele alınmamış benzer hataları arıyor, sorun çıkarma eğilimindeki kalıpları yakalıyor ya da bir mantık parçasını, hangi girdinin onu bozacağını bilecek kadar iyi anlıyor. En iyi test edilmiş kod tabanlarına (yıllardır fuzzer’lara tabi tutulmuş, milyonlarca saat CPU biriktirmiş projelere) Opus 4.6’yı yönelttiğimizde, yüksek önemde zafiyetler buldu; bazıları onlarca yıldır fark edilmemişti.
Teraziyi savunmacılardan yana çevirmek, bir kısmıyla kendi işimizi yapmaktan geçiyor. Artık Claude’u açık kaynak yazılımlardaki zafiyetleri bulmak ve düzeltmeye yardımcı olmak için kullanıyoruz. Açık kaynakla başladık çünkü her yerde çalışıyor—kurumsal sistemlerden kritik altyapıya kadar—ve oradaki zafiyetler tüm interneti etkiliyor. Bu projelerin birçoğu küçük ekipler veya özel güvenlik kaynağı olmayan gönüllüler tarafından yürütülüyor; bu yüzden insan tarafından doğrulanmış hataları bulup, insan tarafından incelenmiş yamalar sunmak gerçekten fark yaratıyor.
Şu ana kadar 500’den fazla yüksek önemde zafiyet tespit edip doğruladık. Bunları raporlamaya başladık, ilk yamalarımız projelere girmeye başladı ve diğerlerini yamamak için bakımcılarla çalışmaya devam ediyoruz. Bu yazıda metodolojimizi adım adım anlatacak, Claude’un keşfettiği zafiyetlerden erken dönem örnekler paylaşacak ve bu yetenekler geliştikçe kötüye kullanımı sınırlamak için aldığımız önlemleri ele alacağız. Bu çalışmaların yalnızca başı. İş büyüdükçe paylaşacak daha çok şeyimiz olacak.
KURULUM
Bu çalışmada Claude’u, açık kaynak projelerin güncel sürümlerine erişebildiği bir “sanal makine”nin (gerçek anlamıyla simüle edilmiş bir bilgisayar) içinde çalıştırdık. Standart araçlar (örneğin temel coreutils veya Python) ve zafiyet analiz araçları (örneğin hata ayıklayıcılar, fuzzer’lar) verdik; ancak bu araçları nasıl kullanacağına dair özel talimat vermedik, zafiyet bulmayı kolaylaştıracak özel bir test düzeneği de sunmadık. Yani Claude’un “kutudan çıkar çıkmaz” yeteneklerini doğrudan test ettik; yalnızca modern büyük dil modellerinin, elindeki araçları en iyi nasıl kullanacağını zaten akıl yürüterek çıkarabilen genel amaçlı ajanlar olduğu varsayımına dayandık.Claude’un hayal ürünü hata üretmediğinden (yani var olmayan sorunları uydurmadığından emin olmak için—açık kaynak geliştiricilere giderek daha fazla yük bindiren bir durum—her hatayı raporlamadan önce ayrıntılı biçimde doğruladık. Odaklandığımız alan bellek bozulması (memory corruption) zafiyetleri oldu; çünkü bunlar nispeten kolay doğrulanabiliyor. Programın çalışmaya devam ettiği mantık hatalarının aksine, bellek bozulması zafiyetleri programın çökmesini izleyerek ve address sanitizers gibi araçlarla non-crashing memory hatalarını yakalayarak tespit edilebiliyor. Ancak programı çökerten her girdi yüksek önemde bir zafiyet olmadığı için, kalan çökmeleri Claude’a eleştirtip tekrarları ayıklattık ve öncelikleri yeniden belirlettik. İlk bulgu turunda her zafiyeti kendi güvenlik araştırmacılarımız doğruladı ve yamaları elle yazdı. Bulgu sayısı arttıkça doğrulama ve yama geliştirme için dışarıdan (insan) güvenlik araştırmacılarını da sürece dahil ettik. Amacımız, bakımcıların raporlarımızla gerçekten işini kolaylaştırmaktı; bu yüzden süreç yanlış pozitifleri azaltacak şekilde kurgulandı. Aynı zamanda, bulduğumuz hataları güvenilir biçimde gidermek için yama geliştirmeyi otomatikleştirme çalışmalarını hızlandırıyoruz.
ZAFİYETLER
Claude’un bulduğu (şu an bakımcılar tarafından yamanmış) üç zafiyet aşağıda. Bunların, büyük dil modellerinin diğer araçlara kıyasla sahip olduğu benzersiz avantajları gösterdiğine inanıyoruz.• GhostScript — PostScript ve PDF dosyalarını işleyen bir araç. Claude zafiyet ararken önce birkaç çıkmaz sokağa girdi: hem kodu fuzz’lamayı denedi hem de bu işe yaramayınca manuel analize geçti. İki yöntem de kayda değer bir sonuç vermedi. Sonunda farklı bir yol izledi: Git commit geçmişini okumaya başladı. Kısa sürede güvenlikle ilgili bir commit’e rastladı ve şu yorumu yaptı:
Buradan sonra Claude, neyin değiştiğini anlamak için koda baktı:
Bunu düşünerek Claude, yamanmamış benzer zafiyetleri bulmak için bu fonksiyonun çağrıldığı diğer yerlere baktı.
Bu gözlemin ardından Claude, öngörülerini kanıtlayan bir proof-of-concept çökmesi (GhostScript’e verildiğinde çökmeye neden olan bir dosya) hızlıca oluşturdu.
OpenSC — Akıllı kart verilerini işleyen bir komut satırı aracı. Claude yine önce fuzz’lama ve manuel analiz denedi; sonuç vermeyince depoda sıkça zafiyet barındıran fonksiyon çağrılarını aramaya başladı.
Claude kısa sürede, ardışık birden fazla strcat kullanılan bir yeri tespit etti. Bu fonksiyonlar C’de genelde güvensiz sayılır; çünkü birleştirilen dizginin toplam uzunluğunu kontrol etmeden birleştirme yaparlar. Bu yüzden programcının çıktı tamponunun birleştirilmiş girdiyi alacak kadar büyük olduğunu doğrulaması çok önemlidir. OpenSC’de asıl sorun şu koddaydı:
Kod:
char filename[PATH_MAX]; // this buffer is 4096 bytes
r = sc_get_cache_dir(card->ctx, filename,
sizeof(filename) - strlen(fp) - 2);
if (r != SC_SUCCESS)
goto err;
strcat(filename,"/");
strcat(filename,fp);Claude bunun buffer overflow’a açık olduğunu tespit etti. Mevcut fuzzer’ların bu satırı ne sıklıkla fuzz’ladığına baktığımızda, geleneksel fuzzer’ların bu satırı nadiren incelediğini görüyoruz; çünkü tetiklenmesi için bir sürü ön koşul gerekiyor. Claude ise hangi kod parçalarının ilginç olduğunu akıl yürüterek çıkarıp çabasını oraya yoğunlaştırabildi, tüm satırlara eşit çaba harcamak yerine.
CGIF, GIF dosyalarını işleyen bir kütüphane. Bu örnekte bizi şaşırtan, Claude’un hatayı nasıl bulduğu değil, hatayı nasıl doğruladığı ve zafiyetin gerçek olduğunu kanıtlayan bir proof-of-concept üretmesi oldu.
Kısaca, Claude bu kütüphanenin sıkıştırılmış verinin her zaman orijinal boyuttan küçük olacağını varsaydığını (normalde makul bir varsayım) ve bu varsayımın istismar edilebileceğini tespit etti. Bunu yapma biçimi zorlu bir süreçti. GIF dosya formatı veriyi LZW sıkıştırma algoritmasıyla sıkıştırır. Eşleşmeleri (mesafe, uzunluk) çiftiyle kodlayan daha geleneksel LZ77 tabanlı sıkıştırıcıların aksine, LZW sık kullanılan token çiftlerinden (tek karakterler veya token çiftleri) bir sözlük oluşturur. Sıkıştırıcı aynı token’a ikinci kez rastladığında “bu token’ı tekrar çıktıla” anlamına gelen daha kısa bir bit dizisi üretebilir. (Dil modellerine aşina olanlar için LZW, ruh olarak BPE tokenization sürecine çok benzer.)
CGIF, sıkıştırılmış bir dizginin sıkıştırılmış boyutunun her zaman sıkıştırılmamış boyuttan küçük olacağını örtük olarak varsaymıştı — bu neredeyse her zaman doğrudur. Yine de Claude buradaki zafiyeti hemen fark etti:
Yani Claude, LZW’nin sabit boyutlu bir sembol tablosu tuttuğunu; bu tablonun boyutu üst sınıra ulaştığında LZW’nin veri akışına özel bir “clear” token’ı eklediğini fark etti. Bu da “sıkıştırılmış” çıktı boyutunun sıkıştırılmamış boyutu aşmasına, dolayısıyla bir buffer overflow zafiyetinin tetiklenmesine yol açıyor.
Bu zafiyet özellikle ilginç çünkü tetiklenmesi LZW algoritmasının ve GIF dosya formatıyla ilişkisinin kavramsal olarak anlaşılmasını gerektiriyor. Geleneksel fuzzer’lar (hatta kapsam rehberli fuzzer’lar bile) bu tür zafiyetleri tetiklemekte zorlanıyor; çünkü belirli dallanma seçimlerinin yapılması gerekiyor. Hatta CGIF’te satır ve dal kapsamı %100 olsa bile bu zafiyet fark edilmeyebilirdi: çok spesifik bir işlem dizisi gerektiriyor.
ÖNLEMLER
Claude Opus 4.6’nın yayımlanmasıyla birlikte, Safeguards ekibimizin Claude’un siber amaçlı kötüye kullanımını tespit edip müdahale etmesini destekleyecek yeni bir tespit katmanı devreye alıyoruz. Bu çalışmanın merkezinde probe’lar var: model cevap üretirken içindeki aktivasyonları ölçüyor ve belirli zararları kitlesel ölçekte tespit etmemizi sağlıyor. Bu sürümle birlikte, Claude’un siber güvenlik alanındaki olası kötüye kullanımını daha iyi izleyip anlamak için siber odaklı yeni probe’lar ekledik.Uygulama tarafında, bu yeni tespit mimarisiyle uyumlu olacak şekilde pipeline’larımızı geliştiriyoruz. Buna, probe tabanlı tespitten yararlanan siber uygulama iş akışlarımızı güncellemek ve siber kötüye kullanıma karşı aldığımız aksiyonların kapsamını genişletmek dahil. Özellikle, zararlı olarak tespit ettiğimiz trafiği engellemek de dahil gerçek zamanlı müdahale uygulayabiliriz. Bu, meşru araştırma ve bir kısım savunma odaklı çalışmayı zorlaştırabilir; güvenlik araştırma topluluğuyla, bu tür zorluklar ortaya çıktıkça nasıl ele alacağımızı birlikte çalışarak belirlemek istiyoruz. Claude’u hem güvenli hem etkili kılmak için çalışarak siber güvenlikte ön saflarda tutmaya kararlıyız.
Bu değişiklikler birlikte, kötüye kullanımı önleme becerimizde anlamlı bir adım oluşturuyor: yalnızca ne tespit edebildiğimizde değil, tespit ettiklerimize ne kadar hızlı ve etkili müdahale edebildiğimizde.
SONUÇ
Claude Opus 4.6, özel bir iskelet olmadan bile iyi test edilmiş kod tabanlarında anlamlı 0-day zafiyetleri bulabiliyor. Sonuçlarımız, dil modellerinin mevcut keşif araçlarının üzerine gerçek bir değer katabileceğini gösteriyor. Yukarıda anlattığımız Safeguards çalışması, bunun yarattığı çift kullanım riskini yönetmek için hayati.İleriye baktığımızda hem bizim hem de geniş güvenlik topluluğunun rahatsız edici bir gerçekle yüzleşmesi gerekecek: dil modelleri yeni zafiyetleri tespit edebilecek düzeyde ve yakında uzman insan araştırmacıların hızıyla ölçeğini bile geçebilir.
Aynı zamanda mevcut ifşa (disclosure) normlarının da evrilmesi gerekecek. Sektördeki standart 90 günlük süreler, LLM’lerin keşfettiği hataların hızı ve sayısı karşısında yeterli kalmayabilir; sektörün de bu hıza ayak uyduracak iş akışlarına ihtiyacı olacak.
Bu devam eden bir çalışma; bu yeteneklerin nasıl geliştiği ve güvenlik topluluğunun bunları en iyi nasıl kullanabileceği konusunda öğrendiklerimiz dahil, yakında paylaşacak daha çok şeyimiz olacak.
Claude Code , Anthropic , Opus 4.6 , BufferOverflow , AI NEWS , 0-DAY , GGIF
