Siber güvenlik artık Proof of Work gibi çalışıyor

• Anthropic'in LLM'i Mythos, karmaşık ağ saldırısı simülasyonlarında insanlardan daha hızlı ve daha hassas performans gösteriyor; erişim yalnızca sınırlı sayıdaki çekirdek geliştiriciye veriliyor
• AI Security Institute testlerinde Mythos, 32 aşamalı kurumsal ağ saldırısı simülasyonunu 10 denemenin 3'ünde tamamen başarıyla tamamladı ve token bütçesi arttıkça performansının yükseldiği görüldü
• Bu sonuç, güvenliğin savunma için saldırgandan daha fazla token harcamayı gerektiren bir yapıya, yani Proof of Work tipi bir rekabete dönüştüğünü gösteriyor
• LiteLLM ve Axios tedarik zinciri saldırılarının ardından, açık kaynak bağımlılıklarını LLM ile değiştirme ya da token harcayarak güvenliği güçlendirme girişimleri yayılıyor
• Güvenlikte belirleyici unsur teknik yaratıcılıktan çok kaynak yatırımı haline geliyor; bu da geliştirme sürecine bir hardening aşaması eklenmesi yönünde bir akıma yol açıyor

---

Güvenliğin Proof of Work gibi işlediği yapı

• Anthropic'in LLM'i Mythos, bilgisayar güvenliği görevlerinde dikkat çekici performans gösterdiği için genel kullanıma açılmadan yalnızca çekirdek yazılım üreticilerine sunuluyor
  • Mythos, karmaşık ağ saldırısı simülasyonlarını insanlardan çok daha hızlı yürütüyor
  • AI Security Institute (AISI) değerlendirmelerinde de önceki modellere kıyasla bir seviye daha yüksek siber saldırı yürütme yeteneği sergiledi
• The Last Ones adlı 32 aşamalı kurumsal ağ saldırısı simülasyonunda Mythos, 10 denemenin 3'ünde tam başarı elde etti
  • AISI, her denemede 100 milyon token (yaklaşık 12.500 dolar) kullandı
  • Test edilen modeller arasında tüm saldırıyı tamamlayan yalnızca Mythos oldu ve token bütçesi arttıkça performans da artmaya devam etti
• Bu sonuç, güvenliğin ekonomisinin şu basit formüle vardığını gösteriyor: "Savunmak için saldırganın kullandığından daha fazla token harcamak gerekir."
  • Güvenliği güçlendirme, yaratıcılıktan çok kaynak yatırımı tarafından belirleniyor
  • Bu, kripto paralardaki Proof of Work mekanizmasına benzer bir yapı; daha fazla hesaplama kaynağı koyan taraf kazanıyor

Yeni güvenlik ekonomisinin gösterdikleri

• Açık kaynak yazılımın öneminin artması

  • Son dönemdeki LiteLLM ve Axios tedarik zinciri saldırılarının ardından, bazı çevrelerde bağımlılık kodlarını AI agent'larla yeniden yazma önerileri ortaya çıktı
  • Andrej Karpathy, "Bağımlılıklar yeniden değerlendirilmelidir ve basit işlevler için doğrudan LLM kullanmak daha iyidir" dedi
  • Eğer güvenlik yatırılan token miktarıyla orantılıysa, şirketler açık kaynak kütüphanelere token harcayarak güvenliği artırdıkça daha güvenli hale gelebilir
  • Ancak yaygın kullanılan OSS'nin saldırı değeri yüksek olduğundan, saldırganların da daha fazla kaynak yatırması için teşvik oluşuyor

• Geliştirme sürecine Hardening aşaması eklenmesi

  • Bugün geliştiriciler geliştirme → kod inceleme şeklinde iki aşamalı bir süreç izliyor ve her aşamada farklı modeller kullanıyor
  • Anthropic, yalnızca kod incelemeye yönelik bir hizmet (Code Review) sunuyor; maliyeti inceleme başına 15-20 dolar seviyesinde
  • Gelecekte geliştirme → inceleme → hardening şeklindeki üç aşamalı döngünün yaygınlaşması mümkün görünüyor
    1. Geliştirme: Özelliklerin uygulanması ve kullanıcı geri bildirimine dayalı yineleme
    2. İnceleme: Dokümantasyon, refaktöring ve kalite iyileştirmesi
    3. Hardening: Bütçenin izin verdiği ölçüde otomatik zafiyet araması yürütülmesi
  • İlk aşamada sınırlayıcı unsur insan zamanı, son aşamada ise maliyet oluyor

Maliyet yapısı ve güvenliğin sınırları

• Kod yazmanın kendisi hâlâ ucuz, ancak güvenliği sağlamak için saldırgandan daha fazla token satın almak gerekiyor
• Modellerin çıkarım verimliliği iyileşse bile, güvenliği güçlendirme maliyeti saldırının değeri tarafından belirlendiği için tam bir maliyet düşüşü zor
• Sonuç olarak güvenlik, teknik yaratıcılıktan çok piyasa temelli bir kaynak rekabetine dönüşüyor

[GN⁺]

Hacker News görüşleri

• Kod tabanına erişim kilit önemde. Şu anki LLM tabanlı güvenlik taraması fiilen basit bir bash scripti seviyesinde; tüm dosyaları dolaşıp “açık bul” diye prompt atmak gibi çalışıyor.
  Ancak savunmacı kaynak kodunun tamamını kontrol ediyorsa çok daha verimli çalışabilir. Örneğin yalnızca PR bazında değişen dosyaları tarayabilir ya da güvenlikle ilgili koda daha fazla token ayırabilir. Saldırgan her seferinde yeniden taramak zorundayken, savunmacı tek bir taramayla tüm potansiyel açıkları önceden bulabilir.
  Sonuçta bir maliyet asimetrisi var ve verimlilik açısından savunma tarafı avantajlı hale geliyor. Saldırganın çok aşamalı bir exploit zincirini tamamlaması gerekirken, savunmacının bunların içindeki en zayıf halkalardan sadece birini engellemesi yeterli.

  • Saldırgan çok, savunmacı tekken ölçek ekonomisinin savunmacının lehine olduğunu söylemek ikna edici gelmiyor. Kod erişiminin olmayacağını varsaymak güvenlik açısından iyi değil. Tüm güvenlik incelemeleri kaynak koda erişimi varsayar.
  • Yine de bu yaklaşım yazılım geliştirme maliyetini artırıyor. “Bizi kim hedef alsın ki” gibi rehavet artık işlemez.
  • Yakın zamanda Security Cryptography Whatever podcast’inde de değinildiği gibi, şu anda harness iyileştirmektense “bir sonraki modeli bekleme stratejisi” daha verimli görünüyor; bu da ilginç.
  • Sorun şu ki bu yaklaşım, “bir geliştiricinin PC’sinin ele geçirildiği tedarik zinciri saldırısı” düzeyindeki bir olayı, “tüm kaynak kodunun sızdırılması ve otomatik denetimi” seviyesine büyütebilir. Böyle bir dünya startup’lar için karanlık bir orman gibi olur.
  • Savunmacı her şeyi güçlendirmek zorunda, ama saldırganın yalnızca tek bir açık bulması yeterli.

• Yazıda geçen AI Security Institute(AISI) ilgimi çektiği için baktım; ağırlıklı olarak DeepMind ya da OpenAI kökenli kişilerden oluşan bir yapıymış. Güvenlik sektöründen isim neredeyse yok. Bu yüzden “sistemi güçlendirmek için daha fazla token harcamak gerekir” sonucunun biraz AI sektörü merkezli bir mantık gibi geldiğini düşünüyorum. Neden formel doğrulama (formal verification) gibi alternatiflerden söz edilmediği de soru işareti. NVIDIA’nın bu mantığı GPU satışı için kullanabileceğini de düşündürüyor.

  • Buna karşı çıkabilecek tanınmış güvenlik araştırmacıları kim olurdu diye merak ediyorum. Pratikte birçok araştırmacı bu görüşe katılıyor gibi. Şu an tartışmanın odağı, LLM’lerin fuzzing seviyesinde bir yenilik mi sunduğu yoksa bunun ötesine mi geçtiği.
  • Bu arada AISI, Birleşik Krallık hükümetine bağlı ve Bilim, Yenilik ve Teknoloji Bakanlığı’na (DSTI) bağlı bir kurum. Yine de grafikleri basit doğrusal çizmek gibi analiz yöntemleri biraz zayıf kalmış.

• Tony Hoare’un şu sözü etkileyiciydi: “Yazılım tasarımında iki yaklaşım vardır. Ya o kadar basittir ki kusuru yoktur, ya da o kadar karmaşıktır ki kusurlar görünmez.”

  • Her şeyi tamamen basit hale getirmek tüm saldırıları engellemez, ama saldırı yüzeyini azaltma etkisi büyüktür. Örneğin ağ mesajlarını işlemeden önce mutlaka imza doğrulaması yapılacak şekilde tasarlarsanız, imzasız mesajların kabul edilmesini zorlaştırırsınız. Bugünkü birçok sistemde tehdit modeli gerekenden fazla geniş.
  • Ama “karmaşıklık” ölçütü insanlar ve LLM’ler için aynı değil. İnsana karmaşık görünen şey LLM için basit olabilir. Bu yüzden bu yaklaşımın ne kadar geçerli olacağı belirsiz.

• Güvenlik her zaman karşı tarafın ne kadar para harcadığıyla ilgili bir oyun oldu. LLM’ler çıktı diye ilke değişmiş değil. Karpathy’nin söylediği “dependency yerine copy” felsefesi de zaten Go dilinin eski bir deyişi olarak vardı. “Güvenlik gizlemeyle sağlanamaz” ilkesi de yeni değil.

  • Ama obscurity tamamen anlamsız da değil. Savunmanın katmanlarından biri olarak işe yarayabilir. İdeal olan, sistemi tamamen şeffaf varsayarak güçlendirmek ve bunun üstüne bir miktar opaklık eklemektir.
  • “Savunmak için saldırganın kullandığından daha fazla token harcamak gerekir” sözü de yeni değil. Fiziksel güvenlikte de durum buydu. Sonuçta AI çağında da AI’ı AI ile savunmak gerekecek. Önce geliştiricilerin kullandığı kod üretim modellerinin prompt’larını denetlemek lazım.

• Yazının genel tezine büyük ölçüde katılıyorum. “Puanlar zekâ üzerinden verilmiyor” ifadesi biraz tehlikeli. Siber güvenliğin özü hâlâ insan sistemlerinde yatıyor. GPU zamanı harcamak gerekli olabilir ama nihayetinde sonucu belirleyen şey kurumun güvenlik kültürü ve disiplini olacaktır. Nükleer ya da havacılık sektöründekine benzer, ancak kazalardan sonra oluşan türden bir disipline ihtiyaç var.
  Bu bağlamda bir yıl önce yazılmış şu metin, bugünkü durumu neredeyse kehanet gibi anlatıyor.

• “Sistemi güçlendirmek için saldırgandan daha fazla token harcamak gerekir” iddiasına karşılık, geçmişte Ticketmaster API otomasyonu için bizzat script yazmışlığım var. Onlar savunmayı PerimeterX ile güçlendirmişti ama ben 3 gün içinde aştım. Daha yakın zamanda ChatGPT’nin Cloudflare Turnstile korumasını aşmanın da benzer bir yolunu uyguladım.
  Bu, on milyonlarca dolara geliştirilen güvenlik ürünlerinin pratikte işe yaramaz kalabildiğini gösteren bir örnekti.
  İlgili HN yazısı

• LLM’lerin bulduğu güvenlik olaylarının gerçekten yeni açıklar mı olduğu, yoksa mevcut güvenlik bilgisinin uzantısı mı olduğu merak konusu. Eğer ikincisiyse, neden bunları kendimiz sistematik biçimde bulamadığımız da ayrı bir soru.

• Bu araştırmanın Proof of Work gibi görünmesinin nedeni, AISI’nin “daha fazla token kullandıkça performansın artmaya devam ettiğini” söylemesi. Yani saldırı başarı oranının token tüketimiyle orantılı olduğu varsayılıyor. Ama deney, 32 adımlı bir ağ sızma senaryosuydu ve bunu tamamlayan tek model Mythos’tu. Basit kod kütüphanelerinde azalan getiri noktası çok daha erken gelebilir.
  Açık kaynak projelerde hem savunmacının hem de saldırganın token tüketimi artacağından, bu sınıra daha hızlı ulaşılması mümkün olabilir.

  • Mythos her denemede başarılı olmadı ve deney ağı da gerçek savunma sistemlerine sahip değildi. Yine de AI’ı küçümsemek için neden yok. Üç ay sonraki modeller bambaşka bir seviyede olabilir.
  • Siber güvenlik hakkında çok bilgim yok ama 32 adımdan 33 adıma geçmenin token maliyeti artış oranı burada kilit nokta gibi görünüyor. Savunma adımları birbirinden bağımsızsa saldırı başarı olasılığı p^N olarak hızla düşer.

• Sonunda soru şu: İnsanların yazdığı bir kod tabanını korumak mı daha ucuz, yoksa ajan ordularının ürettiği kodu korumak mı?

• Modelleri bugün olduğu gibi tüm kod tabanının üzerine körlemesine atmak verimsiz. Benim denemelerimde, modeli source-to-sink trace yolunu yapısal olarak arayacak şekilde ayarlamak maliyeti ciddi biçimde düşürdü.
  Artık sistemlerin kodun tüm bağlamını görselleştirip kırılma noktalarını isabetle işaretleyebildiği bir döneme girdik. Bu, yazılım kalitesini artırmada büyük bir dönüm noktası olacak.