Çalışanların yapay zekayla yazdığı uygulamaların güvenliği: yasaklamadan üç katmanlı denetim

Çalışanların yapay zekayla yazdığı uygulamalar güvenli mi?

Çalışanların yapay zekayla yazdığı uygulamaların güvenliği yasakla değil, katmanlı denetimle sağlanır. Bir analize göre bu tür projelerin %45'inde güvenlik açığı var [1]. En sık hatalar dört tane: koda gömülü şifreler, eksik kimlik doğrulama, korunmasız kullanıcı girdisi ve eski kütüphaneler [1]. İyi bir temel üç parçadan oluşur: sır taraması, otomatik kod taraması ve yayın öncesi denetim [1]. Hesap girişi ya da ödeme varsa saldırgan gözüyle inceleme eklenir [1].

Yapay zeka ajanları .env dosyasındaki değerleri sık sık doğrudan koda taşıyor [1]. Bu yüzden ilk kuracağınız kontrol sır taraması olmalı [1].

Çalışan kod, güvenli kod değildir

Yapay zeka çalışan kod yazar. Ama açıkları sessizce içine gömebilir [1].

Desen genelde aynıdır. Uygulama iyi görünür, yayına alınır. Sonra API anahtarı açıkta, veritabanı herkese açık çıkar [1].

Bir analize göre bu yöntemle yazılan projelerin %45'inde açık var [1]. Yöneticinin sorusu 'çalışıyor mu' değil, 'denetlendi mi' olmalı.

• Koda gömülü şifre ve anahtarlar [1]
• Yalnız tarayıcıda kalan ya da hiç olmayan kimlik doğrulama [1]
• Korunmasız kullanıcı girdisi, örneğin SQL enjeksiyonu [1]
• Bilinen açıkları olan eski kütüphaneler [1]

Bu araçlar tüm hataları bitirmez, sayıyı ciddi düşürür [1].

İlk katman: şifreler repoya hiç girmesin

En yaygın hata sırların koda sızması [1]. Yapay zeka ajanları .env değerlerini doğrudan koda çektiği için bu sık yaşanır [1].

Gitleaks bu iş için kullanılır. Kodda şifreye benzeyen bir şey görürse commit'i durdurur ve yerini gösterir [1].

Karar kuralı basit: ekipte kod üreten herkesin projesinde sır taraması açık olsun.

• Çalışan kodu kaydetmek ister
• Gitleaks commit'i tarar
• Şüpheli şifre varsa işlem durur
• Çalışan anahtarı koddan çıkarır
• Commit temiz hâliyle geçer

Ekip kuralı şablonu: - Yapay zekayla yazılan her projede: 1) Şifre, token ve API anahtarı koda yazılmaz. 2) Sır taraması kapalıyken commit yapılmaz. 3) Tarama uyarı verirse anahtar değiştirilir ve koddan çıkarılır. 4) Yayın öncesi kontrol listesi tamamlanmadan proje dışa açılmaz.

İkinci katman: her güncellemede otomatik tarama

Elle kontrol ölçeklenmez. Bir tarayıcı bağlayın, arka planda çalışsın.

Üç seçenek farklı işler yapar. Birini seçmek temel için yeterli [1].

• Semgrep: her GitHub güncellemesinde kodu tarar, binlerce hazır kuralı var, elle ayar istemez [1].
• Snyk Code: yalnız sizin kodunuzu değil, kullandığınız kütüphaneleri de bilinen açıklar için tarar [1].
• CodeRabbit: değişiklikleri okuyup pull request'e yorum bırakır, ilk gözden geçiren gibi çalışır [1].

Bu yazının hazırlandığı tarihte üç aracın da ücretsiz katmanı ve hacme göre ücretli planları vardı [1].

Üçüncü katman: yayına çıkmadan son denetim

Bazı hatalar ancak sunucuya çıkınca patlar. Production Audit Skill bunları yayından önce arar [1].

Ortam değişkenlerini, hata yönetimini, unutulmuş debug kodunu ve aşırı yük korumasını kontrol eder [1].

Uygulama form, kayıt ya da kişisel veri topluyorsa Bearer CLI ekleyin. E-posta, telefon gibi verinin loglara ya da üçüncü taraf servislere düşüp düşmediğini gösterir [1].

İK ve müşteri verisiyle çalışan araçlarda kişisel veri akışı kontrolü atlanmamalı [1].

Hesap ve ödeme varsa saldırgan gözü ekleyin

Her proje aynı riski taşımaz. Hesap girişi, ödeme ya da dış servis bağlantısı olan araçlar ek inceleme ister [1].

Security Review Skill kodu saldırgan gözüyle okur. Yetkisiz erişim ve veri çalınabilecek yerleri arar [1].

Santa Method aynı kodu birkaç bağımsız ajanla kontrol eder. Birinin kaçırdığını diğeri yakalayabilir [1].

Kriptografi, ödeme sistemi ya da karmaşık sunucu mantığı varsa Trail of Bits Skills kontrol setine bakın [1].

Claude kullanan ekipler için komutlar: - /codex:review - /codex:adversarial-review

İlk komut her değişiklikten sonra hızlı kontrol içindir. İkincisi önemli sürüm öncesi mimarideki zayıf noktaları da arar [1].

Adım adım nasıl yapılır?

• Ekipte yapay zekayla araç yazan kişileri ve projeleri listeleyin.
• Her projede sır taraması (Gitleaks) zorunlu olsun [1].
• Bir kod tarayıcı seçip GitHub'a bağlayın: Semgrep ya da Snyk Code [1].
• Yayın öncesi denetimi kurala bağlayın: Production Audit [1].
• Kişisel veri toplayan araçlara Bearer CLI ekleyin [1].
• Hesap veya ödeme içeren projelere saldırgan gözüyle inceleme ekleyin [1].
• Projeler büyüdükçe çoklu ajan denetimini devreye alın [1].

Örnek: Tipik senaryo: 'iyi görünüyor, yayınla gitsin'

• Çalışan yapay zekayla küçük bir araç yazar, araç çalışır [1].
• Ajan .env içindeki API anahtarını koda taşımıştır [1].
• Kimse denetlemeden araç yayına alınır [1].
• Canlıda anahtar açıkta, veritabanı herkese açık kalır [1].
• Sır taraması olsaydı commit bu aşamada dururdu [1].

Sık yapılan hatalar neler?

• Kod çalıştığı için işi bitmiş saymak. Yayından önce otomatik tarama ve denetimden geçmesini şart koşun [1].
• Şifre ve anahtarları doğrudan koda yazmak. Gitleaks ile commit aşamasında sızıntıyı durdurun [1].
• Kimlik doğrulamayı yalnız tarayıcı tarafında bırakmak. Hesap girişi olan projelerde Security Review ile saldırgan gözüyle kontrol yaptırın [1].
• Eski kütüphanelerdeki bilinen açıkları gözden kaçırmak. Kütüphaneleri de tarayan Snyk Code gibi bir araç kullanın [1].
• Bütün araçları aynı anda kurmaya çalışmak. Sır taraması, kod tarayıcı ve yayın öncesi denetimle başlayıp gerektikçe ekleyin [1].

Kontrol listesi

• Projede koda gömülü şifre ya da anahtar yok [1].
• Kimlik doğrulama yalnız tarayıcıda kalmıyor [1].
• Kullanıcı girdisi korunuyor [1].
• Kütüphaneler bilinen açıklar için tarandı [1].
• Debug kodu temizlendi, hata yönetimi var [1].
• Kişisel veri loglara ya da üçüncü taraflara düşmüyor [1].

Bugün ne yapmalı?

• Ekipte yapay zekayla yazılmış ve yayında olan araçları listeleyin.
• Bu araçlarda koda gömülü anahtar olup olmadığını sorun [1].
• Ekip kuralı şablonunu kopyalayıp ilgili kanala paylaşın.
• Bir kod tarayıcı seçip ilk projeye bağlatın [1].
• Kişisel veri toplayan araçları ayrı işaretleyin [1].

Yapay zekayla yazılan uygulamalar gerçekten bu kadar riskli mi?

Bir analize göre bu projelerin %45'inde açık var [1]. En sık görülenler koda gömülü sırlar, eksik kimlik doğrulama, korunmasız girdi ve eski kütüphaneler [1].

Hangi kontrolle başlamalıyız?

Gitleaks ile sır taramasıyla başlayın ve bir kod tarayıcı ekleyin: Semgrep ya da Snyk Code [1]. Hesap veya ödeme varsa Security Review ekleyin [1].

Bu araçlar ücretli mi?

Bu yazının hazırlandığı tarihte çoğu açık kaynak ve GitHub tabanlıydı [1]. Semgrep, CodeRabbit ve Snyk Code'un ücretsiz katmanları ve ücretli planları vardı [1].

Hepsini birden kurmak gerekir mi?

Hayır. Sır taraması, bir kod tarayıcı ve yayın öncesi denetim iyi bir temeldir; proje büyüdükçe diğerleri eklenir [1].

Ekibimiz Claude kullanıyor, ne önerilir?

Claude'a Codex ekleyen eklenti iki modelle çapraz kontrol sağlar [1]. /codex:review hızlı kontrol, /codex:adversarial-review sürüm öncesi derin analiz içindir [1].

Ekibinize eğitim mi gerekiyor?

LeftFlow'un kurumsal yapay zeka eğitimi programı 2 ya da 4 ay sürer; ekipler kendi gerçek işleri üzerinde çalışır ve her hafta somut bir çıktıyla kapanır.

Bu yazıdaki işi hemen denemek isterseniz yapay zeka kullanım politikası oluşturucu tarayıcınızda çalışır, yazdığınız metin siz istemedikçe hiçbir yere gönderilmez.

Kaynaklar

• Vibe coding'in kör noktası: güvenlik

Bu yazı nasıl hazırlandı?

Yukarıdaki kaynaklardan derlendi ve her somut bilgi kaynağıyla karşılaştırılarak denetlendi. Derleme tarihi 2026-11-02. Fiyat, sürüm ve takvim gibi bilgiler değişebilir; güncelini kaynağından doğrulayın.