Security Blog

Yapay Zekâ Kodlama Asistanınız Az Önce Cüzdanınızı Okudu

#144

October 2, 2026 · By Marketing team

← All posts

Yapay zekâ kodlama araçları siz tek bir tuşa basmadan .env dosyalarını okur. API anahtarlarınız — her biri harcama limiti olmayan birer kredi kartı — ilk isteğinizi yazmadan önce başkasının bağlam penceresine girmiş olur. Sorun yapay zekâda değil. Sorun, gizli bilgilerin birer dosya olması.

Yapay zekâ kodlama asistanınızı açın. Tek bir karakter yazmadan önce proje dizininizi çoktan okumuş olur. .env dosyanızı. API anahtarlarınızı. Veritabanı parolanızı. Stripe gizli anahtarınızı.

Siz ondan bunu istemediniz. Onay vermediniz. Bu bir hata değil, bir özellik — aracın işe yaraması için proje bağlamına ihtiyacı var. Bu yüzden bir geliştiricinin okuyabildiği her şeyi okur.

Bir geliştirici ise her şeyi okuyabilir.

Greentext versiyonu

Bu hafta bir gönderi dolaşıma girdi; bir geliştiricinin iç monologu olarak yazılmıştı:

> Claude Code'u aç. Daha bir şey yazmadan .env okunuyor. API anahtarların artık sohbetin içinde. CLAUDE.md'ye "env okuma" yazıyorsun. İşe yaramıyor.

380.000 kişi o gönderiyi gördü. 2.700 kişi yer imlerine ekledi. Yeni bir haber olduğu için değil — bir ayna olduğu için.

Onu okuyan her geliştiricinin aklından aynı düşünce geçti: benim kurulumum bu.

Talimatlar işe yaramıyor

İnsanların ilk denediği şey kural yazmak oldu. ".env dosyalarını okumayın." CLAUDE.md'ye, AGENTS.md'ye, sistem istemlerine. Doğrudan, açık yasaklar.

Araç yine de dosyaları okudu.

Biraz düşününce bu mantıklı. Dosya, proje bağlamı oluşturulurken okunuyor — talimatlar henüz işlenmeden. Modele zaten okumuş olduğu bir dosyayı okumamasını söylemek, birine az önce gördüğünü unutmasını söylemek gibidir. Bilgi bağlam penceresinde. Aktarılmış durumda. Talimat, zarar gerçekleştikten sonra ulaşıyor.

Bir araştırmacı, dosya düzeyindeki ret kurallarının bile özel betikler veya boru zincirleriyle atlatılabildiğini tespit etti. Bir başkası, HTTP_PROXY kimlik bilgileri otomatik olarak yüklenip kullanıldığı için proxy faturalarının şiştiğini fark etti.

.env dosyanızdaki para

İnsanlar bunu bir gizlilik sorunu olarak çerçevelendiriyor. Oysa bu bir finans sorunu.

Üretime alınmış bir projedeki tipik bir .env dosyasını açın:

OPENAI_API_KEY=sk-...
STRIPE_SECRET_KEY=sk_live_...
AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=...
DATABASE_URL=postgresql://user:pass@...

O OpenAI anahtarı, harcama limiti de PIN'i de olmayan bir kredi kartıdır. Bu diziye sahip biri bir gecede 40.000 dolarlık API çağrısı çalıştırabilir. Stripe anahtarı iade oluşturabilir, tahsilat yapabilir, müşteri ödeme verilerine erişebilir. AWS kimlik bilgileri — IAM politikasına bağlı olarak ki neredeyse kesinlikle fazlasıyla geniştir — GPU örnekleri açabilir, S3 kovalarına erişebilir veya altyapıyı silebilir.

Bu bir parola listesi değil. Her birinde farklı bakiye olan ve hiçbiri kilitli olmayan bir cüzdan listesi.

Kaldırımda 29 milyon cüzdan

GitGuardian'ın son raporu, 2025 yılında herkese açık GitHub commit'lerinde 28,6 milyon gizli bilginin ifşa olduğunu saydı. Bir önceki yıla göre %34 artış ve bugüne kadar ölçtükleri en büyük yıllık yükseliş.

Yapay zekâya özgü sayılar daha kötü. 1,2 milyon yapay zekâ hizmeti gizli bilgisi ifşa oldu — yıldan yıla %81 sıçrama. Yapay zekâ kodlama araçlarının ortak yazar olduğu commit'ler, temel oranın yaklaşık iki katı hızda gizli bilgi sızdırdı. Ayrıca MCP yapılandırma dosyalarında — yapay zekâ ajanlarını dış hizmetlere bağlayan boru hattında — 24.000 benzersiz gizli bilgi bulundu.

En hızlı artan ilk on beş sızıntı türünün on ikisi yapay zekâ hizmetleriydi. Veritabanları değil. Bulut sağlayıcıları değil. Yapay zekâ hizmetleri.

Kodu daha hızlı yazmak için kullandığımız araçlar, o kodun bağlandığı sistemlerin anahtarlarını sızdırıyor.

Gerçek sorun

Greentext başlığını açan geliştirici, pratik bir çözümle bitirdi — dosya okumalarını engelleyen bir settings.json yapılandırması. Bu işe yarıyor. Şimdilik, o araç için.

Ama gerçek sorun Claude Code ya da Cursor ya da Copilot değil. Gerçek sorun, gizli bilgilerin birer dosya olması.

.env dosyası, diskte duran, sizin kullanıcı hesabınızla çalışan herhangi bir sürecin okuyabileceği düz metin bir belgedir. Yapay zekâ kodlama araçlarından önce projenizi okuyan süreçler git, npm, node, editörünüzdü. Bunlara örtük olarak güveniyordunuz. Gizli bilgilerinizin bir cat komutuyla açığa çıkmak arasında olduğunu düşünmüyordunuz.

Yapay zekâ kodlama araçları yalnızca örtük olanı açık hale getirdi. Projenizi diğer her araçla aynı şekilde okuyorlar — yalnızca bağlamı sizin görebileceğiniz bir yere gönderiyorlar.

CI hattınız da .env dosyalarını okur. Test çalıştırıcınız okur. Linter'ınız okur. Docker derlemeniz okur. Hiçbiri de izin sormadı. Siz yalnızca, bulduklarının sohbet dökümünü göstermedikleri için fark etmediniz.

Altındaki örüntü

2022'de sızan gizli bilgilerin %70'i hâlâ bugün aktif. Değiştirilmemiş. İptal edilmemiş. Üç yıl sonra hâlâ çalışıyor, hâlâ erişim veriyor.

Asıl sayı bu. 29 milyon sızıntı değil — %70'i hiç düzeltilmemiş. Çünkü bir anahtarı değiştirmek, onu kullanan her sistemi bulmak, her dağıtımı güncellemek, her entegrasyonu sınamak anlamına gelir. Anahtar bir kez oluşturuldu, bir .env dosyasına yapıştırıldı ve bir daha hiç düşünülmedi. Sızdırmanın maliyeti anlıktır. Sızıntıyı düzeltmenin maliyeti sınırsızdır.

Bu yüzden çoğu kuruluş düzeltmez. Düzeltilemez. Hangi anahtarın nerede olduğunu, hangilerinin hâlâ aktif olduğunu, hangilerinin cuma öğleden sonra bir özelliği çalışır hale getirmeye çalışan başka geliştiriciler tarafından başka makinelerdeki başka .env dosyalarına kopyalandığını bilmiyorlar.

Bu aslında ne anlama geliyor

Her .env dosyası bir bahistir. Hiçbir sürecin onu okumayacağı bahsi. Hiçbir aracın onu beklemediğiniz bir yere göndermeyeceği bahsi. Hiçbir geliştiricinin onu yanlışlıkla commit'lemeyeceği bahsi.

Geçen yıl bu bahsi 29 milyon kez kaybedildi. Yalnızca herkese açık GitHub'da. GitGuardian'ın depoların %35'inde gizli bilgi bulduğu özel depolar — hesaba bile katılmıyor.

Çözüm bir settings.json kuralı değil. Çözüm bir .gitignore girdisi değil. Çözüm talimat dosyanıza "DO NOT READ .ENV" diye büyük harflerle yazmak değil.

Çözüm, gizli bilginin orada hiç bulunmaması gerektiği. Bir dosyada değil. Dosyadan yüklenen bir ortam değişkeninde değil. Sizin yetkilerinizle çalışan bir sürecin süreçlerin yaptığı şeyi yaparak — projenizdeki dosyaları okuyarak — okuyabileceği hiçbir biçimde değil.

Gizli bilgi diskteyse okunacaktır. Tek soru, ne zaman ve ne tarafından olduğu.

---

Kaynaklar