Defending Code Reference Harness - Yapay zeka destekli güvenlik açığı bulma ve düzeltme için Anthropic açık kaynak çerçevesi

• Defending Code Reference Harness, Claude ile otonom güvenlik açığı bulma ve düzeltme yapmak için hazırlanmış bir referans uygulamadır ve birden çok kuruluşun güvenlik ekipleriyle iş birliği içinde edinilen öğrenimlere dayanılarak oluşturulmuştur
• Bu depo bir ürün değil, bir referans uygulamadır; şu anda bakımı yapılmamakta ve katkı da kabul edilmemektedir
• Anthropic, yönetilen bir alternatif olarak Claude Security sunar; bu hizmet birden çok projenin kaynak kodunda güvenlik açıklarını bulup düzeltebilir ve triage, fix validation, rapid fix generation yaşam döngüsünü yönetebilir
• Claude Code için skills olarak /quickstart, /threat-model, /vuln-scan, /triage, /patch, /customize sunulur; bunlar etkileşimli kapsam belirleme, tarama, triage ve yama çalışmalarını destekler
• harness/, recon → find → verify → report → patch akışına sahip otonom bir referans boru hattıdır ve Docker ile ASAN kullanarak C/C++ bellek güvenlik açıklarını araştırmaya odaklanır
• Referans boru hattının genel yapısı, prompt'ları ve sandbox yaklaşımı yeniden kullanılabilir; ancak tüm kod tabanlarında doğrudan çalışmaz ve /customize ile dile, dedektörlere ve güvenlik açığı türüne göre uyarlanması gerekir
• /quickstart, /threat-model, /vuln-scan, /triage ve statik sonuçlar için /patch yalnızca dosya okuma-yazma işlemleri yapar; Claude Code içinde her aracın kullanımı gözden geçirilip onaylanırsa sandbox olmadan çalıştırılabilir
• Otonom referans boru hattı ve boru hattı sonuçları için /patch, hedef kodu çalıştırdığı için açıkça baypas edilmediği sürece gVisor sandbox dışında çalışmayı reddeder
• Boru hattını çalıştırmak için scripts/setup_sandbox.sh ile gVisor ve ajan imajlarının hazırlanması gerekir; ayrıca Docker ve ANTHROPIC_API_KEY ya da CLAUDE_CODE_OAUTH_TOKEN ortam değişkeni gereklidir
• Çalıştırma aşamaları build, recon, find, verify, dedupe, report ve patch olarak ayrılır; find ajanı izole bir konteyner içinde malformed input üretir ve ASAN ikili dosyası 3 denemenin 3'ünde de çökene kadar arama yapar
• verify aşamasında ayrı bir grader ajanı yalnızca proof of concept'i alarak yeni bir konteynerde çöküşü yeniden üretir; dedupe aşaması ise bunun yeni bir hata mı, mevcut bir hatanın daha iyi bir örneği mi, yoksa bir tekrar mı olduğunu belirler
• report aşaması, primitive class, reachability, escalation path ve severity içeren yapılandırılmış bir exploitability analysis hazırlar; patch aşaması ise bir düzeltme üretir, ardından build işlemini, özgün proof of concept ile çökme olmamasını, testlerin geçmesini ve baypas olasılığının yeniden araştırılmasını doğrular
• İlk kullanım akışı, 1. günde threat model ile statik scan, triage ve candidate patch oluşturmak; 2. günde C/C++ kütüphanesinde çalıştırılarak doğrulanmış bulgular üretmek; 3-5. günlerde ise kendi hedefiniz için targets/<your-service>/ oluşturmaktır
• Kendi stack'inize taşırken finding sinyalini, proof of concept biçimini ve build/çalıştırma yöntemini tanımlamanız gerekir; C/C++ referansı, ASAN çökme imzasını, çökerten girdi dosyasını ve clang+ASAN tabanlı Dockerfile'ı temel alır
• Otonom triage ve patching hâlâ açık bir problemdir; /patch için kullanılan doğrulama stratejisi çıtayı yükseltse de severity ve öncelik ortam bazında değerlendirilir ve doğrulanmış bir yama her zaman upstream'e alınabilir olmayabilir

[GN⁺]

Hacker News yorumları

• Bu daha çok bir atölye aparatı/jig gibi. İstersen bir crosscut kızak satın alabilirsin ama çoğu marangoz bunu kendisi yapar
  2 yıl önce kendi harness'ını yapmanın maliyeti yüksekti, o yüzden durum farklıydı; ama şimdi bunu fikir almak için bakılan bir şey olarak görüp, kendi çalışma biçimine, arayüzüne, hedefine ve emek tanımına, bildirim şekline göre kendin yapman en iyi seçenek gibi görünüyor

  • Atölye aparatı/jig benzetmesi tam oturuyor. Pek çok yazılım, genel amaçlı kullanımdan aşırı derecede kişiselleştirilmiş kullanımlara kayıyor
    Yapay zeka öncesinde, kendi sorununu çözen yazılımı üretmek için ciddi insan emeği gerektiğinden, başkalarının da yeniden kullanabilmesi için onu genelleştirmeye ekstra uğraş harcanırdı. Şimdi ise bunun maliyeti neredeyse yok, bu yüzden yazılım genelleştirilmeden kalıyor
    Bugünlerde yaptığım şeyleri neredeyse hiç paylaşmıyorum[0]; çünkü başkalarına faydalı olma ihtimalleri düşük ve benzer bir şeye ihtiyaç duyan biri, benimkini genişletip düzeltmek yerine kendisine tam uyan bir şey yapabilir. Tıpkı jig gibi
    0: https://redfloatplane.lol/blog/17-why-share/ ve ilgili yazılar
  • Aynen bu. “Bilgisayar kullanmak, bilgisayarın senin yerine kod yazıp çalıştırmasını şeffaf biçimde içeren bir şey haline gelecek” dediğimi defalarca söyledim ve teknik biri değilsen bunun farkına bile varmayabilirsin. Şu an konuşulan yön de oraya gidiyor
    Hayatımızda amaca özel araçlar yapmanın daha iyi olduğu birçok an var ve her yeni model çıktığında bu araçların karmaşıklığı da artıyor
    Bunlar gerçekten kişisel araçlar. Başkalarının da yaşayabileceği sorunları çözüyorlar ama kişinin kendi çalışma tarzına o kadar sıkı bağlılar ki başkasına açıklamak ya da uyarlamak zor. Bu yüzden atölye aparatı/jig benzetmesi uygun
    Bende de böyle özelleştirilmiş script ve programlardan yaklaşık 10 tane var; üniversiteden beri ilk kez böyle hissediyorum. O zamanlar ayarları dilediğince özelleştirecek zaman vardı, şimdi ise ajanlar var
    Arkadaşlarıma göstermek istiyorum ama bunu nasıl anlatacağımı kafamda canlandırınca, onların çeşitli tuhaf yönleri anlamayacağını düşünüyorum. Çünkü bunlar benim kendime özgü tuhaflıklarım. Benim sorunlarımı çok iyi çözen, epey karmaşık teknik parçalar bunlar; bu sorunlar da daha geniş sorunların kişisel varyasyonları ve en azından şu an bunları destekleme niyetim yok
    Bu yöne gittiğimiz o kadar açık ki, buna rağmen birçok insan hâlâ kodun elitlere ait olduğuna inanıyor. Ürün kodu için bu doğru olabilir ama geri kalanında, yakında anne babanızın bilgisayarı bile kendisi için yazılmış kodu çalıştırıyor olacak gibi görünüyor. Güvenlik açısından ürkütücü ama düşününce ilginç
  • İsteyen herkes bir harness yapabilir ama çoğunda bunu yapacak istek yok
    Ayrıca kendin yapsan bile, benim aylarca rafine ettiğim yapay zeka iş akışları ultracode yüzünden bir anda demode oldu
  • Bu değişimi nasıl ifade edeceğimi arıyordum; bu benzetme tam isabet. Yazılım mühendisliğinde kütüphaneler ve altyapı bileşenlerinin değeri hızla düşüyor
    Birçok organizasyonda, bu işleri yapan takımlara gelen kullanıcıların giderek azaldığını tahmin ediyorum
  • Açık kaynağın geleceğini de büyük ölçüde böyle görüyorum. Açık kaynak kütüphaneleri alıp kullanmaktan çok, yaptığımız özel araçların tasarımı için ilham olarak yeniden kullanılacaklar
    Kendi çözümünü üretmenin maliyeti fazla düştü, başkasının temel yapı taşlarına sıkışıp kalmanın maliyeti ise fazla yükseldi
    Ama yapay zeka ile kodlamayı mevcut araçlara bağlamak inanılmaz güçlü

• Bunu çalıştırmanın maliyetini merak ediyorum
  https://github.com/anthropics/defending-code-reference-harne... kaynağına göre:

  Kabaca bir ölçüt olarak, ajan başına dakikada yaklaşık 10K önbelleğe alınmamış giriş token'ı ve yaklaşık 2K çıkış token'ı bekleyin. Paralelliği hesabınızın ITPM sınırına kadar artırabilirsiniz (yaklaşık her 100K ITPM için 10 ajan).
  Tahminimce Opus için yüzlerce dolar, Mythos içinse binlerce dolar tutar

  • Kod yazmaktan çok, kodu güvenli hale getirmek için daha fazla token gerektiği giderek daha net hale geliyor
    Hatta bu fark tek haneli katlar düzeyine ulaşabilir
  • Bana göre Opus maliyeti bile zaten karşılanması zor olacak kadar yüksek; Mythos'la kıyasının nasıl olacağını ise bilmiyorum
    Bu hesaplayıcıya bakınca, 100 geliştiricili bir şirket için yıllık token maliyetinin yaklaşık 2,5 milyon dolar seviyesine çıkabilmesi oldukça sarsıcı
    https://ai-cost-calculator.arnica.io
  • Claude'un ultra code modu iş akışı da çok benzer şekilde çalışıyor ve görevin karmaşıklığına göre oturum kullanım kotasını makul ölçüde tüketiyor
    Ama API üzerinden çalıştırılırsa maliyetin hızla artacağını düşünüyorum
  • Ben de tarama maliyetini tahmin eden bir hesaplayıcı yaptım; buna sürekli çalıştırılıp çalıştırılmadığı da dahil: https://ai-cost-calculator.arnica.io
    Tahmin olduğu için hatalı olabilir ama bizim deneyimimize göre kabaca bir aralık sunuyor. Geri bildirim duymak isterim
  • Onların yönetilen hizmetiyle karşılaştırıldığında, bu tahmin kod tabanına bağlı olarak beklenen maliyetin onda biri olabilir
    Ama daha yüksek rakamlarla hesaplasanız bile, bu tür araçların hedeflediği türden bulgular için yapılan resmi güvenlik sözleşmelerinin yaklaşık onda biri maliyette olabilir. PR incelemesi ya da yalnızca /security-review ile çıkmayacak, ancak bir uzmanın açık kaynak çerçevenin ön çalışmasını yönlendirmesiyle elde edilebilecek sonuçlardan söz ediyoruz. Böyle bir sözleşmenin nasıl yürütüleceğini çözmek için gereken zaman ve gecikmeyi hesaba bile katmadım
    Açık konuşmak gerekirse, eğer önemliyse, tek bir taramanın maliyeti bir aylık vibe coding bütçesi kadar olsa bile “dolar başına birkaç sent” seviyesinde, son derece ucuz kalır
    Aynı zamanda bu çıktılar için hâlâ uzmana ihtiyaç var. Öneriler faydalı da olabilir, aktif olarak zararlı da olabilir; her şey ön çalışmanın kalitesine bağlı
    BT yöneticisine tavsiyem, birkaç bin dolar harcayıp bunu çalıştırması, korkutucu sonuç sayfalarıyla bütçe çıkarması ve ardından açıkları bulup sınıflandırmaya, gerekirse düzeltmeye yardımcı olacak ve şirket içi ekibi güvenlik odaklı biçimde eğitebilecek bir red team ile ilişki kurması olur

• “Bu depo artık bakım almıyor ve katkı kabul etmiyor.”
  Hımm :)

  • Claude neden bakım yapmıyor ki?
  • Bunun bakımı yapılıyor ve mümkün olduğunca hızlı şekilde tüm sabitlenmiş modellere uyarlanmalı
    https://github.com/space-bacon/SRT
    Bir gecede tüm sabitlenmiş modelleri büyük ölçüde iyileştirebilir. Haydi

• İyi bir harness olmadan codex/claude’dan çok şey elde edemediğimiz bizim deneyimimiz. Bir de kodlama ajanlarının insanların bulduğu hataları neden bulamadığını anlamaya zaman ve enerji harcamak gerekiyor
  Denetçi olarak her hafta bizim harness’imizin(https://zkao.io/) yakalayamadığı hataları görüyorum ve aracın o hataları bulmasını sağlamak için epey ilginç teknikler keşfetmek zorunda kalıyorum. Burada sözünü ettiğim şey çoğunlukla basit web uygulaması hataları değil, kriptografik zafiyetler
  Bu yüzden şirketlerin kendi harness’lerine sahip olması ve deneyime dayanarak iyi harness’ler oluşturmaya odaklanan hizmetlere para ödemesi mantıklı hale gelecek gibi görünüyor. Çok sayıda hata görüp bu hataları harness’e “öğretmeye” zaman ayırabilen denetim firmaları bu işte en iyi olanlar olabilir
  Ters tarafta sınıflandırma için de aynı derecede iyi teknikler gerekiyor. Aksi halde benim vibe denetimi dediğim bir makine ortaya çıkıyor; geliştiricileri, zaten hata ödül programlarındaki kalitesiz AI başvurularından ve tüm PR’ları inceleyen AI araçlarından bıkmışken, bir de tonla yanlış pozitif üreterek daha da yoruyor
  Sonuçta harness hiçbir hata döndürmediğinde “O zaman gerçekten hata yok mu?” diye düşünmeye başlıyorsunuz. İş yine en iyi aracı ya da en iyi ekibi, yani en iyi aracın hangisi olduğunu bilen ekibi seçme meselesine dönüyor; kimin o ekip olduğunu anlamaya yönelik bir itibar oyunu yani

• Güvenlik kesinlikle AI/LLM kullanım alanı olarak çok güçlü. Çünkü işin büyük bir kısmı, bilinen güvenlik sorun kalıplarını analiz edilen çok hassas programlama dili metniyle eşleştirmekten ibaret
  Dikkat çekici olan şu: en güçlü kullanım alanlarında AI şirketleri ham çıktıyı satmak yerine yöntemi bir hizmet olarak satmaya çalışıyor. Çıktının değeri düşük olduğunda ise token satıyorlar
  Eğer AI token’ları genel yazılım uygulaması geliştirmede yeni değer yaratma konusunda gerçekten sihirliyse, onları doğrudan satmazlardı. Token’ları biriktirip istedikleri tüm sektörlerdeki SaaS yazılımlarını ele geçirmek için kullanırlardı
  Bu biraz, borsada pahalı eğitim satan birinin, kendi bilgisiyle doğrudan borsadan para kazanmaktan ziyade eğitim satarak daha çok kazanılabildiğine işaret etmesi gibi

  • Ya da çeşitlendirme istiyor olabilirler
    AI token’larıyla ürün yapmak, deneyimlerinin daha az olduğu uçtan uca bir ürünü inşa edip satmalarını gerektirir ve kendi müşterileriyle rekabete sokar. Hâlâ konumunu sağlamlaştırmakta olan bir AI tedarikçisi için bu iyi bir pozisyon değil. Mevcut işleri zaten yeterince yoğun; bu büyük bir dikkat dağıtıcı olur ve stratejik olarak da çok değerli değildir
  • “Token’ları biriktirip istedikleri tüm sektörlerdeki SaaS yazılımlarını ele geçirmeliler” mantığını anlamıyorum
    Makul derecede başarılı SaaS ürünleri işletip satmış biri olarak söyleyeyim, insanı tüketen ve sinir bozan kısımlar LLM’lerin yardımcı olamayacağı şeyler. Ürünü kodlamak ne darboğaz ne de başarı garantisi
  • O sonuca hiç varılamaz. Anthropic, token satışından elde ettiği gelirde yıllık bazda 10 kat büyüme yaşıyor
    Token’ları gerçekten sihirli olsa ve mevcut sektörlere girip yerleşik oyuncuları saf dışı bırakarak o sektörlerde yılda %100 büyüyebilse bile, yine de önce token satmayı tercih etmeleri daha mantıklı olurdu. Çünkü bu tek başına zaten mükemmel bir iş
    Bu mantığın gösterdiği şey ancak bir sınır olduğudur. Token’lar yazılımın her alanında anında sonsuz para üretecek kadar güçlü değil. Bu doğru gibi görünüyor
  • Bir başka yorum da uzun vadede daha değerli olan şeyin ekosistem kurmak olduğu olabilir
    Başlangıçta birçok şirket güvenlik kaygıları yüzünden çalışanlarının kaynak kodunu uzak LLM’lere yazmasını yasaklıyordu. Şimdi ise birçok şirket, yine güvenlik kaygıları nedeniyle tüm kaynak kodunun uzak LLM’lerle analiz edilmesi gerektiğine inanmaya başlıyor
    Anthropic’e güvenmek normalleşirse, kaynak koda erişim gerektiren daha fazla hizmet satabilirler
  • Şirket içindeki çok sayıda kişiyi arayıp mesaj atarak savunmasız görünen birini aramaya başladığında işi bir insan red team üyesine devreden ya da daha doğrudan yöneten entegre bir MetaSploit AI güncellemesinin hâlâ çıkmamış olması şaşırtıcı

• Biraz konu dışı ama sanki birisi bu yazıdaki iyi GitHub bağlantılarını dead/flag ile topluca öldürüyor; neden yaptığını anlamıyorum

• Tek bir açığı bulmak, her zaman tüm açıkları kapatmaktan daha kolaydır. Hacker’ların da aynı araçlara sahip olduğu düşünülürse, bu kazanılması imkânsız bir silahlanma yarışı

  • LLM’lerin tehdit modelinin hesabını ciddi biçimde değiştirdiği açık, ama bu gözlem tek başına bunun nasıl ya da neden değiştiğini açıklamıyor
    Söz konusu asimetri, LLM’lerden önce de yazılımda var olan bir özellikti
  • Savunmacının, saldırganın bilmediği bağlam vardır

• Oldukça ilginç. Bir süredir benzer bir araç geliştirip kullanıyordum:
  https://github.com/bobinson/vulture
  Yanlış pozitiflerle uğraştım ve Claude + MCP’yi yoksul işi bir denetim aracı gibi kullandım. Son birkaç günde Nvidia barındırmalı modellerle daha iyi sonuçlar aldım

• Claude’un bu harness ile token’ları verimli kullanıp kullanmadığını bilmeden, kulağa geldiği kadar faydalı olmayabilir

• Anthropic’in artık belirli kullanım senaryoları için harness geliştirip bunu ürünleştirdiği açık
  Bu, güvenlik için Claude Design karşılığı gibi
  Harness farklı, paketleme farklı ve hedef persona farklı; dolayısıyla dağıtım biçimi de doğal olarak farklı
  İlginç olan, Mythos hakkında yazan şirketlerin hepsinin kendi harness’lerini yapıyor olması. Cisco hatta bunlardan birinin spesifikasyonunu yayımladı
  Ama bunu nasıl paketleyip dağıtacağını çözen taraf Anthropic olmuş. Harika bir go-to-market stratejisi

  • Bu yazı ve GitHub organizasyonu da kafa karıştırıyor. Anthropics ile Anthropic aynı şey değil