Güncel bir araştırmada, Grok Build adlı yapay zeka destekli kod asistanının yalnızca işlem yaptığı dosyaları değil, tüm git deposunu xAI’nin bulut depolama alanına yüklediği ortaya çıktı. Söz konusu durum, özellikle kod gizliliği ve veri güvenliği açısından yeni soruları gündeme getirdi.
Depo Büyüklüğü ve Veri Transferi Arasındaki Uçurum
cereblab rumuzlu bir araştırmacı, Grok Build 0.2.93 sürümünü incelerken, modelin hiç okumadığı 12 GB büyüklüğündeki bir git deposundan sadece 192 KB veri talep ettiği halde, /v1/storage kanalından 5.10 GiB verinin yüklendiğini tespit etti. Bu, modelin ihtiyaç duyduğu veri ile dışarıya gönderilen veri arasında yaklaşık 27.800 kat fark olduğunu gösteriyor. Yüklenen veri, 75 MB’lık 73 parça halinde başarılı şekilde (HTTP 200) sunucuya iletildi ve tüm dosya yolu bilgileri gs://grok-code-session-traces/ depolama alanına işaret ediyordu.
Okunmayan Dosyalar ve Git Geçmişi
Özellikle src/_probe/never_read_canary.txt isimli, modele kesinlikle açılmaması söylenen özel işaretli bir dosya da bu paket içinde yer aldı. Dosyanın birebir kopyası ve tüm commit geçmişi, yakalanan git paketi üzerinden geri getirildi. Aynı test başka bir farklı depoda da benzer sonuç verdi. Bu durum, dosyaların eğitimde kullanıldığından değil, iletim, kabul ve depolama sürecinde tam olarak aktarıldığından emin olunmasını sağladı.
Gizli Anahtarlar ve Kredi Bilgileri Risk Altında
Grok Build’in dosya içeriklerini okuduğunda, bu veriler model dönüşü sırasında ve ayrıca depolama amaçlı session_state arşivlerinde şifrelenmeden yer aldı. Üstelik .env gibi gizlilik içeren ortam dosyalarında bulunan API anahtarları ve veri tabanı şifreleri de bu paketlerin içinde bulunuyordu. Testte kullanılan gizli bilgiler sahteydi, ancak bu durum gerçek dünyada kritik veri sızıntısı riskini gösteriyor.
Kullanıcı Ayarları ve Kontrol Eksikliği
Model eğitimi için izin vermeyi kapatan kullanıcı ayarları bile bu veri yüklemesini engellemedi. Sunucudan gelen /v1/settings yanıtı hâlâ trace_upload_enabled: true değerini döndürüyordu. Bu, model eğitimi ile kodun dışarı gönderilmesi arasında iki farklı kontrolün olduğunu, ancak kullanıcıların sadece eğitim seçeneğine müdahale edebildiğini ortaya koyuyor. Bu durum, özellikle hassas kod ve verilerin güvenliği açısından kritik bir zafiyet oluşturuyor.
Bulut Kod Asistanları Arasında Benzersiz Bir Durum
Çeşitli kod asistanları incelendiğinde, Claude Code ve Codex gibi araçların hiç depo paketi göndermediği, Gemini’nin ise sadece görev sırasında veri gönderdiği, boşta kaldığında depo yüklemediği belirlendi. Grok Build ise tüm çalışma alanını ve geçmişini topluca sunucuya yollayan tek araç olarak öne çıktı. Bu yaklaşım, bulut güvenliği ve kaynak kontrolü açısından ciddi sorgulamalar gerektiriyor.
xAI’nin Müdahalesi ve Durumun Güncel Hali
13 Temmuz itibarıyla Grok Build 0.2.93 sürümü artık /v1/storage üzerinden yükleme yapmıyor. Yapılan tekrar testlerde sıfır yükleme tespit edildi, sunucu ayarları ise disable_codebase_upload: true ve trace_upload_enabled: false şeklinde değişti. Bu değişiklik, sadece tek bir kullanıcıya özgü değil, başka hesaplarda da görüldü. xAI tarafından henüz resmi bir açıklama yapılmadı; bu değişikliğin kalıcı mı yoksa geçici bir önlem mi olduğu bilinmiyor.
Güvenlik Uzmanlarına Tavsiyeler
Yukarıdaki gelişmeler ışığında, Grok Build ya da benzeri araçları kullanan geliştiricilerin, daha önce gönderilmiş olabilecek tüm gizli anahtarları ve kimlik bilgilerini derhal yenilemesi gerekiyor. Özellikle commit edilmiş ve sonradan silinmiş dosyaların bile geçmişte paketlere dahil edildiği unutulmamalı. Ayrıca, kurumsal ortamlar için IAM politikaları, ağ segmentasyonu ve olay müdahale süreçlerinin gözden geçirilmesi kritik önem taşıyor.
Teknik Özet ve Risk Yönetimi
Grok Build’in tüm git deposunu yüklemesi, sadece o an kullanılan dosyaların değil, geçmişte var olmuş tüm kod ve gizli verilerin dışarı sızması anlamına geliyor. Bu durum, özellikle fidye yazılımı saldırıları ya da iç tehditler açısından risk teşkil ediyor. E-posta güvenliği ve konteyner güvenliği ile entegre çalışan SIEM ve EDR sistemlerinin, bu tür veri sızıntılarını tespit etmek için yapılandırılması faydalı olacaktır.
Sonuç olarak, bu olay kod asistanlarının veri işleme politikaları ve kullanıcı farkındalığı açısından ders alınması gereken bir vaka olarak değerlendirilmeli. Model eğitimi için izin kapatılsa bile, kodun dışarı gönderilmesini engelleyen mekanizmaların eksikliği şirketleri ve bireysel geliştiricileri hassas duruma düşürebilir.