Claude Kod Sızdı, Yerel Kopyalar Türedi: Kurumsal Risk Ne?

Anthropic’in Claude Code aracının kaynak kodu 31 Mart 2026’da sızdı ve bu sızıntı beklenmedik bir domino etkisi başlattı: Günler içinde birden fazla açık kaynaklı klon ortaya çıktı. Hacker News’te yankı bulan bir tartışma, yazılımcıların artık “ücretli bulut modeli yerine tamamen yerel çalışan kodlama ajanı” arayışına girdiğini gözler önüne seriyor. Peki bu tablo, kurumsal güvenlik açısından ne anlama geliyor ve sizin geliştirme ortamınız bu dalgadan nasıl etkilenebilir?

🔍 Ne Oldu? Sızıntının Anatomisi

Claude Code, Anthropic’in geliştirdiği ve Claude modellerini doğrudan terminal üzerinden ajansal kodlama görevleri için kullanan bir araçtır. 31 Mart 2026 tarihinde bu aracın iç yapısı —kullandığı sistem komutları, araç tanımları ve harness (çalışma iskeleti) mimarisi— kamuya açık hale geldi. Sızıntının tam olarak nasıl gerçekleştiği henüz doğrulanmış değil; ancak sonuç net: GitHub’da claw-code ve openclaude gibi repolar hızla yıldız topladı.

Hacker News tartışmasındaki asıl soru şu: “Anthropic’in hız sınırlamalarından bıktım, aynı performansı veren tamamen yerel bir kurulum var mı?” Bu soru masum görünüyor. Oysa bu soruyu soran kişinin kurumsal bir geliştirme ortamında çalışıyor olması, güvenlik ekipleri için ciddi bir sinyal.

⚠️ Asıl Tehdit: Doğrulanmamış Klonların Kurumsal Ortama Girişi

Sızıntının kendisi bir zafiyet değil; ama doğurduğu ekosistem bir saldırı yüzeyi (attack surface) oluşturuyor. Şöyle açıklayayım:

Bir geliştirici, Anthropic’e aylık ücret ödemek yerine GitHub’da bulduğu açık kaynaklı bir harness aracını indiriyor. Bu aracı kendi MacBook’una ya da şirket dizüstüne kuruyor. Araca yerel bir model bağlıyor —Ollama ile çektiği Llama 3, Mistral ya da Qwen serisi bir şey— ve çalışmaya başlıyor. Güvenlik ekibi bundan haberdar değil.

Buradaki riskler katmanlı:

Tedarik zinciri riski: Sızıntıdan türeyen repolar, kötü amaçlı kod içerebilir. Orijinal sızıntıya “sadık” görünen bir klon, içinde ek bir araç çağrısı (tool call) tanımıyla dosya sistemini tarayabilir veya ağ çıkışı yapabilir.
Görünmez veri çıkışı: Ajansal kodlama araçları doğası gereği kaynak kodunu okur, dosyaları düzenler, komut çalıştırır. Eğer modelin arkasında bir bulut uç noktası varsa —”yerel” zannedilen ama aslında API çağrısı yapan kurulumlar oldukça yaygın— kurumsal kaynak kodu dışarı sızıyor olabilir.
Gölge yapay zeka (shadow AI): BT ve güvenlik ekiplerinin onaylamadığı, envanterine almadığı yapay zeka araçlarının kurum içinde kullanımı. Bu, klasik gölge BT sorunununun 2026 versiyonu.
Model doğrulama eksikliği: GGUF formatında indirilen modeller, hash doğrulaması yapılmadan kullanıldığında değiştirilmiş (trojanlanmış) model ağırlıkları içerebilir. Bu konu, benim özellikle dikkat çekmek istediğim noktalardan biri.

🎯 MITRE ATT&CK Eşlemesi

Bu senaryoyu MITRE ATT&CK çerçevesine oturtursak:

T1195.001 — Tedarik Zinciri Güvenlik Açığı (Yazılım Bağımlılıkları): Doğrulanmamış açık kaynak harness araçlarının kurulumu.
T1059 — Komut ve Betik Yorumlayıcısı: Ajansal yapay zeka araçlarının terminal üzerinden rastgele komut çalıştırma yeteneği.
T1567.002 — Web Servisi Üzerinden Veri Sızdırma: “Yerel” görünen ama arka planda bulut API’si kullanan modellerin kod içeriğini dışarı göndermesi.
T1078 — Geçerli Hesaplar: Geliştirici kimlik bilgileriyle API anahtarları harness yapılandırma dosyalarında düz metin olarak saklanıyorsa.

🔧 Teknik Örnek: Yerel Model Kurulumu için Güvenli Doğrulama

Bir geliştirici GGUF formatında model indirdiğinde, güvenlik ekibinin beklentisi en azından SHA-256 hash doğrulamasıdır. Bunun yanı sıra modelin ağ çıkışı yapıp yapmadığını izlemek için basit bir Wazuh FIM (dosya bütünlüğü izleme) kuralı ve ağ izleme kombinasyonu kullanabilirsiniz.

Aşağıdaki Bash betiği, bir GGUF model dosyasını indirdikten sonra hash doğrulaması yaparak kuruma güvenli bir onay mekanizması sağlar:

#!/bin/bash
# Güvenli yerel model indirme ve doğrulama betiği
# Kullanım: ./verify_model.sh  

MODEL_DOSYASI="$1"
BEKLENEN_HASH="$2"
LOG_DOSYASI="/var/log/ai_model_audit.log"

if [[ -z "$MODEL_DOSYASI" || -z "$BEKLENEN_HASH" ]]; then
  echo "Kullanim: $0  "
  exit 1
fi

echo "[$(date '+%Y-%m-%d %H:%M:%S')] Model dogrulama basliyor: $MODEL_DOSYASI" >> "$LOG_DOSYASI"

# SHA-256 hesapla
GERCEK_HASH=$(sha256sum "$MODEL_DOSYASI" | awk '{print $1}')

if [[ "$GERCEK_HASH" == "$BEKLENEN_HASH" ]]; then
  echo "[BASARILI] Hash dogrulandi: $GERCEK_HASH" | tee -a "$LOG_DOSYASI"
  exit 0
else
  echo "[UYARI] Hash UYUSMAZLIGI!" | tee -a "$LOG_DOSYASI"
  echo "  Beklenen : $BEKLENEN_HASH" | tee -a "$LOG_DOSYASI"
  echo "  Bulunan  : $GERCEK_HASH" | tee -a "$LOG_DOSYASI"
  echo "[AKSIYON] Model karantinaya aliniyor..."
  mv "$MODEL_DOSYASI" "/tmp/karantina_$(basename $MODEL_DOSYASI)"
  exit 1
fi

Wazuh tarafında ise ajansal yapay zeka araçlarının beklenmedik ağ bağlantısı kurmasını tespit etmek için aşağıdaki özel kuralı /var/ossec/etc/rules/local_rules.xml dosyanıza ekleyebilirsiniz:

<!-- Wazuh: Yerel AI aracinin dis ag baglantisi uyarisi -->
<group name="ai_shadow,network,">

  <rule id="100500" level="10">
    <if_group>syscheck</if_group>
    <match>\.gguf</match>
    <description>GGUF model dosyasi degistirildi veya yeni model eklendi</description>
    <mitre>
      <id>T1195.001</id>
    </mitre>
  </rule>

  <rule id="100501" level="12">
    <if_group>firewall</if_group>
    <program_name>ollama|llamafile|llama.cpp</program_name>
    <match>dst_port=443</match>
    <description>Yerel AI sureci dis HTTPS baglantisi kurdu - golgede API kullanimi?</description>
    <mitre>
      <id>T1567.002</id>
    </mitre>
  </rule>

</group>

Bu kurallar %100 eksiksiz değil; ancak güvenlik ekibine “bu kurumda yerel yapay zeka aracı var ve beklenmedik davranış gösteriyor” sinyalini verecek ilk katman olarak çalışır.

📊 Kurumsal Perspektif: Bu Size Neden Önemli?

Hacker News tartışmasındaki kişi muhtemelen bireysel bir geliştirici. Ama aynı motivasyonu taşıyan —”bulut sınırlamalarına takılmadan daha hızlı çalışmak istiyorum”— kurumsal geliştiriciler de var. Ve bu kişiler çoğunlukla iyi niyetli; güvenlik politikasını kasıtlı ihlal etmiyorlar, sadece verimliliği arttırmak istiyorlar.

Biz kurumda Wazuh ile bu tür gölge yazılım kurulumlarını izlediğimizde, en sık karşılaştığımız senaryo şu: Geliştirici, onaylı araçlar listesinde olmayan bir şeyi kuruyor. BT’ye sormak zaman alıyor, işi bekliyor, internetten bulduğu alternatifi kuruyor. Bu çoğunlukla bir güvenlik olayına dönüşmüyor —ama dönüşebildiği zamanlar, hasarı büyük oluyor.

Claude Code sızıntısından türeyen klonlar için ek bir risk daha var: Bu klonları kim geliştiriyor, ne motivasyonla? Bir harness aracına eklenen tek bir kötü amaçlı araç tanımı (tool definition), çalıştırıldığı sistemdeki kaynak kod deposuna erişim sağlayabilir. Ajansal yapay zeka araçlarının dosya sistemi ve terminal erişimi olduğunu unutmayın.

OpenAI güvenlik platformu ve yapay zeka ajanlarının e-posta kimliği gibi yeni saldırı yüzeylerini ele aldığımız önceki yazılarımızda da vurguladık: AI ajanlarına verilen yetkiler, bu ajanların saldırı yüzeyini doğrudan büyütüyor. Yerel çalışan, denetlenmeyen bir kodlama ajanı bu riski daha da artırıyor.

🛡️ Ne Yapmalısınız? 5 Somut Adım

Yapay zeka araçlarını onay listesine alın: Hangi yapay zeka modellerinin ve harness araçlarının kurumsal cihazlarda kullanılabileceğini net bir politikayla belirleyin. “Yasak” değil, “onaylı liste” yaklaşımı daha sürdürülebilir —geliştiricilerin ihtiyacını karşılayan onaylı alternatifler sunun.
GGUF ve model dosyalarını Wazuh FIM ile izleyin: Geliştirici makinelerinde ~/.ollama/models, ~/Library/Application Support/ollama gibi dizinleri dosya bütünlüğü izlemeye ekleyin. Yeni model dosyası eklenmesi bir uyarı tetiklemeli.
Yerel yapay zeka süreçlerinin ağ çıkışını kısıtlayın: “Yerel” çalışması beklenen bir modelin dışarıya bağlantı kurmaması gerekir. Güvenlik duvarı kurallarıyla Ollama ve benzeri süreçlerin giden bağlantılarını kısıtlayın veya izleyin.
İndirilen model dosyalarını hash ile doğrulayın: Yukarıdaki betik gibi bir doğrulama mekanizması kurun. Model kaynağını resmi Hugging Face deposuyla karşılaştırın; forklardan ve tanımsız kaynaklardan kaçının.
Sızıntı kaynaklı araçlara mesafeyle yaklaşın: claw-code ve openclaude gibi repoları yasak olarak değil, “yeterli denetim yapılmadan kullanılmamalı” olarak sınıflandırın. Kod incelemesi yapılmadan kurumsal cihazda çalıştırılmamalı. Claude’un sistem komutu mimarisi hakkındaki analizimiz bu araçların nasıl çalıştığını daha iyi anlamanıza yardımcı olabilir.
Geliştiricileri eğitin, yasaklamayın: “Hız sınırlamasından bıktım, alternatif arıyorum” duygusu anlaşılır. Güvenlik ekibinin rolü bu ihtiyacı bastırmak değil, güvenli karşılamak. Onaylı yerel model seçenekleri ve kurulum rehberleri hazırlayın.

Sonuç: Sızıntı Kapandı, Risk Kapanmadı

Claude Code sızıntısı tek başına bir felaket değil. Ama doğurduğu ekosistem —doğrulama mekanizması olmayan klonlar, kurumsal denetim dışı yerel modeller, ajansal yapay zekaların geniş sistem erişimi— güvenlik ekipleri için yönetilmesi gereken gerçek bir risk alanı oluşturuyor.

Bu tartışmanın özünde yatan motivasyon —hız sınırlamalarından kurtulmak, maliyeti düşürmek— önümüzdeki yıllarda kurumsal yapay zeka politikalarının en zorlu boyutu haline gelecek. Yapay zekanın SOC süreçlerine entegrasyonunu tartıştığımız yazımızda da belirttiğimiz gibi: yapay zeka araçlarına verilen yetkiler, güvenlik denetimiyle orantılı olmalı. Yerel çalışıyor olması, denetimsiz çalışması anlamına gelmiyor.

Orijinal kaynak: https://news.ycombinator.com/item?id=47876210

Securtr