Yapay zeka kod güvenliği, Cursor, GitHub Copilot veya Claude Code gibi asistanlarla üretilen kodun bilinen güvenlik açıklarından arındırılması ve canlıya alınmadan önce sistematik biçimde denetlenmesidir. Bu yazıda, yapay zeka ile üretilen kodda en sık hangi açıkların ortaya çıktığını, bunların neden oluştuğunu ve pull request (PR) sürecine eklenebilecek 10 maddelik bir kontrol listesini paylaşıyoruz. Yazı yazılım geliştiriciler, takım liderleri ve uygulama güvenliği ekipleri için hazırlandı.
Yapay zeka ile yazılan kod ne kadar güvenli?
Veracode’un Temmuz 2025’te yayımladığı GenAI Code Security raporu bu soruya çarpıcı bir cevap verdi. Araştırmacılar 100’den fazla dil modelini, güvenlik açığı potansiyeli bilinen 80 kodlama görevinde test etti. Modeller, güvenli ve güvensiz bir yöntem arasında seçim yapabilecekleri durumların yüzde 45’inde güvensiz olanı seçti.
Dile göre fark da dikkat çekiciydi. Java’da güvenlik testlerinden kalma oranı yüzde 70’in üzerindeydi. Python, C# ve JavaScript’te bu oran yüzde 38 ile 45 arasında kaldı. Modeller, siteler arası betik çalıştırma (XSS) açıklarının yüzde 86’sında ve log enjeksiyonu açıklarının yüzde 88’inde kodu korumayı başaramadı.
Raporun belki de en önemli bulgusu şuydu: yeni ve daha büyük modeller sözdizimi açısından daha doğru kod üretiyor, ancak güvenlik başarısı zamanla belirgin biçimde iyileşmiyor. Yani “model güncellenince sorun kendiliğinden çözülür” beklentisi gerçekçi değil.
Yapay zeka neden güvensiz kod üretiyor?
Dil modelleri eğitim verisindeki en yaygın kalıbı tekrar etme eğilimindedir. İnternetteki kod örneklerinin büyük kısmı ise güvenlik değil, “çalışsın yeter” düşüncesiyle yazılmıştır. Stack Overflow cevaplarındaki hızlı çözümler, eğitim amaçlı basitleştirilmiş örnekler ve eski kütüphane kullanımları modelin öğrendiği varsayılan davranışı oluşturur.
İkinci neden bağlam eksikliğidir. Model, yazdığı fonksiyonun hangi kullanıcı girdisini işlediğini, hangi yetki seviyesinde çalıştığını ya da verinin daha sonra nereye gittiğini çoğu zaman bilmez. Geliştirici istemde güvenlik gereksinimini belirtmezse model bunu varsaymaz.
Üçüncü neden ise hızın getirdiği rehavettir. Vibe coding yaklaşımında geliştirici kodu satır satır okumak yerine sonucu test eder. Uygulama çalışıyorsa kod kabul edilir. Güvenlik açıkları ise genellikle uygulamanın çalışmasını engellemez, bu yüzden gözden kaçar.
En sık görülen 6 güvenlik açığı
Kod incelemelerinde yapay zeka kaynaklı kodda tekrar tekrar karşılaşılan açıklar şunlardır:
- Doğrulanmamış kullanıcı girdisi: Form verisi veya API parametresi, tip ve uzunluk kontrolü yapılmadan işleniyor.
- SQL enjeksiyonu: Sorgular, parametreli sorgu yerine string birleştirme ile oluşturuluyor.
- Koda gömülü gizli bilgiler: API anahtarları, veritabanı şifreleri veya token’lar doğrudan kaynak koda yazılıyor.
- Eksik yetki kontrolü: Uç nokta kimlik doğrulaması yapıyor ama kullanıcının o kayda erişim yetkisi olup olmadığını kontrol etmiyor.
- Güvensiz hata mesajları: Hata ayrıntıları, stack trace ve sistem bilgileri son kullanıcıya gösteriliyor.
- Uydurma paketler: Model, gerçekte var olmayan bir kütüphaneyi öneriyor.
Son madde yeni bir tedarik zinciri riskine dönüştü. 2025’te yayımlanan akademik bir çalışma, test edilen modellerin önerdiği paketlerin yaklaşık beşte birinin gerçekte var olmadığını ortaya koydu. Saldırganlar bu uydurma isimleri tespit edip aynı adla zararlı paket yayımlıyor. Bu saldırı türüne “slopsquatting” adı veriliyor. Geliştirici modelin önerisine güvenip paketi kurduğunda, zararlı kod projeye dahil oluyor.
PR sürecine eklenecek 10 maddelik kontrol listesi
Aşağıdaki listeyi PR şablonunuza ekleyebilirsiniz. Her madde, inceleyen kişinin evet ya da hayır diye cevaplayabileceği şekilde yazıldı.
- Bu PR’daki kodun hangi bölümleri yapay zeka ile üretildi ve PR açıklamasında belirtildi mi?
- Yeni eklenen her bağımlılık, resmi paket deposunda gerçekten var mı ve bakımı yapılıyor mu?
- Paket adı, bilinen bir paketin yazım hatası içeren bir kopyası olabilir mi?
- Tüm kullanıcı girdileri sunucu tarafında doğrulanıyor mu?
- Veritabanı sorguları parametreli mi, yoksa string birleştirme mi kullanılıyor?
- Kodda API anahtarı, şifre veya token var mı? Gizli bilgiler bir secret manager üzerinden mi okunuyor?
- Her uç noktada hem kimlik doğrulaması hem de kayıt bazlı yetki kontrolü yapılıyor mu?
- Hata mesajları son kullanıcıya sistem ayrıntısı sızdırıyor mu?
- Loglara yazılan veriler kişisel bilgi veya kullanıcıdan gelen ham girdi içeriyor mu?
- Statik analiz (SAST) ve bağımlılık taraması (SCA) bu PR üzerinde çalıştı ve bulgular çözüldü mü?
İlk madde tartışmalı görünebilir, ancak önemlidir. Yapay zeka ile üretilen bölümleri bilmek, inceleyen kişinin dikkatini doğru yere yönlendirmesini sağlar. Amaç geliştiriciyi yargılamak değil, inceleme eforunu akıllıca dağıtmaktır.
Asistanı en baştan güvenli kod yazmaya yönlendirmek
Kontrol listesi hataları yakalar, ama hatayı hiç yapmamak daha ucuzdur. Çoğu kodlama asistanı, proje kökünde tutulan bir kurallar dosyasını her istekte bağlam olarak okur. Bu dosyaya güvenlik kurallarını yazmak, asistanın varsayılan davranışını doğrudan değiştirir.
Örnek kurallar şöyle olabilir: “Veritabanı sorgularında her zaman parametreli sorgu kullan. Gizli bilgileri asla koda yazma, ortam değişkeninden oku. Yeni bir paket önermeden önce resmi depoda var olduğunu belirt.” Bu dosyanın ekip genelinde nasıl yapılandırılacağını CLAUDE.md nedir ve yazılım takımınız için nasıl yapılandırılır yazımızda adım adım anlattık.
Asistanın araç çağırma yetkisi varsa, yani terminal komutu çalıştırabiliyor veya dosya sistemine yazabiliyorsa, risk yüzeyi daha da genişler. Bu durumda istem enjeksiyonu ve araç kötüye kullanımı riskleri devreye girer. Bu konuyu MCP güvenliği yazımızda inceledik.
Ekip yetkinliği: araç tek başına yetmez
Kontrol listesinin işe yaraması için inceleyen kişinin açığı görebilmesi gerekir. SQL enjeksiyonunun neye benzediğini bilmeyen bir geliştirici, listedeki beşinci maddeye “evet” deyip geçebilir. Bu yüzden güvenli kodlama bilgisi, yapay zeka asistanlarının yaygınlaşmasıyla birlikte daha da kritik hale geldi.
Ekibinizde temel farkındalığı oluşturmak için güvenli yazılım geliştirme farkındalık eğitimi iyi bir başlangıç noktasıdır. Dil bazında derinleşmek isteyen ekipler için C ve web uygulama güvenliği ile Java security eğitimleri, Veracode raporunda en riskli çıkan dillerde uygulamalı içerik sunar. Güvenliğin tasarım aşamasından itibaren neden ele alınması gerektiğini tasarımdan itibaren güvenlik yazımızda ayrıca tartıştık.
Asistanları verimli ve kontrollü kullanmayı öğrenmek isteyen geliştiriciler için yapay zeka destekli kodlama eğitimi hem üretkenlik hem de güvenlik pratiklerini birlikte ele alır. Test tarafında ise yapay zeka ile test otomasyonu eğitimi, güvenlik testlerinin CI hattına nasıl entegre edileceğini gösterir.
Sonuç
Yapay zeka kodlama asistanları yazılım ekiplerini hızlandırıyor, ancak güvenlik kararlarını modele bırakmak ciddi risk taşıyor. Veracode’un bulguları, bu riskin model güncellemeleriyle kendiliğinden azalmadığını gösteriyor. Çözüm; asistanı güvenlik kurallarıyla yönlendirmek, PR sürecine net bir kontrol listesi eklemek ve inceleyen geliştiricilerin güvenli kodlama bilgisini güçlendirmekten geçiyor.
Sıkça sorulan sorular
Yapay zeka ile yazılan kod güvenli midir?
Otomatik olarak güvenli değildir. Veracode’un 2025 raporuna göre modeller, güvenli ve güvensiz yöntem arasında seçim yapabildikleri durumların yüzde 45’inde güvensiz yöntemi seçti. Yapay zeka ile üretilen kod, insan tarafından yazılan kod kadar titizlikle incelenmelidir.
Slopsquatting nedir?
Yapay zeka modellerinin uydurduğu, gerçekte var olmayan paket isimlerinin saldırganlar tarafından kaydedilip zararlı kodla yayımlanmasıdır. Geliştirici modelin önerisine güvenip paketi kurduğunda zararlı kod projeye girer. Her yeni bağımlılığın resmi depoda doğrulanması bu riski azaltır.
Yapay zeka ile üretilen kod PR’da belirtilmeli mi?
Belirtilmesi önerilir. Bu bilgi inceleyen kişinin dikkatini riskli bölümlere yoğunlaştırmasını sağlar. Amaç geliştiriciyi yargılamak değil, inceleme sürecini daha verimli hale getirmektir.
Hangi programlama dili yapay zeka ile üretildiğinde daha riskli?
Veracode’un araştırmasında Java, yüzde 70’in üzerinde güvenlik hatası oranıyla en riskli dil çıktı. Python, C# ve JavaScript’te bu oran yüzde 38 ile 45 arasındaydı. Ancak hiçbir dil tamamen güvenli sayılmamalıdır.