Yapay zekâ kod yazdıysa bu 9 güvenlik kapısını atlamayın

Yapay zekâ tarafından üretilen kodu doğrudan birleştirmeyin. Değişikliği önce görev kapsamı, hassas veri, bağımlılıklar, insan incelemesi, davranış testleri, otomatik taramalar, ajan yetkileri, build bütünlüğü ve kontrollü yayın olmak üzere dokuz güvenlik kapısından geçirin.

Bunun için ayrı bir “AI güvenlik hattı” kurmak gerekmez. Kapıları yerel geliştirme, pull request, CI/CD ve üretim sonrası izleme aşamalarına yerleştirin; herhangi bir kapının denetlenebilir kanıtı eksikse değişikliği birleştirmeyin.

1. Üretim başlamadan kapsamı ve güven sınırını yazın

Kapı 1 — görev sınırı ve tehdit modeli: Aracın okuyabileceği ve değiştirebileceği dosyaları, çalıştırabileceği komutları, ağ ve harici araç erişimini görev başlamadan belirleyin. Kimlik doğrulama, yetkilendirme, ödeme, şifreleme, CI yapılandırması ve altyapı kodu gibi kritik alanları ayrıca işaretleyin; bu alanlarda daha güçlü insan onayı isteyin.

OWASP AISVS Ek C, AI araçlarının tasarımdan üretim sonrası izlemeye kadar mevcut güvenli yazılım yaşam döngüsüne yerleştirilmesini ve AI kullanılsa da zorunlu güvenlik kapılarının korunmasını öngörüyor. Aynı yaklaşım; onaylı araçların, yasak kullanımların, izin verilen veri sınıflarının ve araca özgü tehdit senaryolarının yazılı olmasını gerektiriyor.

Pull request açıklamasında AI kullanımını, değiştirilen bileşenleri ve insanın doğruladığı bölümleri kaydedin. Bu kayıt, AI çıktısının güvenli olduğunu kanıtlamaz; inceleyenin hangi yüzeylere özellikle bakacağını görünür kılar.

2. Yerel geliştirmede bağlamı, farkı ve paketleri denetleyin

Kapı 2 — hassas bağlam ve gizli bilgi: Prompt’a erişim anahtarı, parola, kişisel veri, üretim günlüğü veya paylaşılması yasak müşteri kodu koymayın. Aracın bağlam kaynaklarını sınırlandırın; prompt girdisini ve oluşan dosyaları IDE ya da pre-commit aşamasında gizli bilgi taramasından geçirin. Açığa çıkan kimlik bilgisini yalnızca koddan silmeyin, geçersiz kılıp yenileyin.

Kapı 3 — kapsam dışı değişiklik: Üretilen farkı görev tanımıyla dosya dosya karşılaştırın. Test silme, doğrulamayı atlama, güvenlik denetimini gevşetme, hatayı sessizce yutma veya CI iş akışını değiştirme açıkça istenmediyse bu değişiklikleri ayırın. Büyük farkları, amacı tek başına incelenebilen küçük commit’lere bölün.

Kapı 4 — paket ve sürüm doğrulaması: AI’ın önerdiği paket adını otomatik kurmayın. Kayıt sayfasını, adın doğru yazıldığını, oluşturulma tarihini, bakım geçmişini, sahiplerini ve seçilen sürümün bilinen açıklarını kontrol edin. OWASP Secure Coding with AI kontrol listesi, her AI önerisi paketin kurulumdan önce gerçek kayıt bilgileriyle doğrulanmasını ve AI üretimi bağımlılık listelerinin güvenlik denetiminden geçirilmesini öneriyor. Kurum içi izin listesi varsa listede bulunmayan bağımlılığı inceleme tamamlanana kadar engelleyin.

3. Pull request’te insan incelemesini davranış testleriyle birleştirin

Kapı 5 — nitelikli insan incelemesi: İnceleyen kişi yalnızca sözdizimine değil, veri akışına, güven sınırlarına, yetkilendirme kararlarına, dış girdi doğrulamasına ve hata yollarına bakmalıdır. Uydurulmuş API’leri, gereğinden geniş izinleri, güvensiz varsayılanları ve kullanılmayan kodu özellikle arayın. Kritik dosyalarda kod sahibi veya ikinci bir yetkili onayı zorunlu tutulabilir.

GitHub’ın güvenlik ve kalite AI özelliklerine ilişkin uygulama kartı, önerilen düzeltmelerin kabulden önce insan tarafından değerlendirilmesini, birleştirmeden önce CI testlerinin geçmesini ve bağımlılık değişikliklerinin güvenlik ile destek durumu açısından incelenmesini istiyor. Bu nedenle başka bir modelin “güvenli” değerlendirmesi, sorumlu insanın onayı yerine geçmez.

Kapı 6 — gereksinim ve kötüye kullanım testleri: Mevcut birim ve entegrasyon testlerine, değişen güven sınırını hedefleyen negatif testler ekleyin. Yetkisiz kullanıcı, bozuk ya da aşırı büyük girdi, beklenmeyen tür, zaman aşımı ve bağımlılık hatasında sistemin güvenli biçimde başarısız olduğunu doğrulayın. Testleri de AI yazdıysa, testlerin gerçek gereksinimi ölçtüğünü ve yalnızca üretilen uygulamayı onaylayacak biçimde kurulmadığını insan incelemesiyle kontrol edin.

4. CI/CD bulgularını bağlayıcı kapılara dönüştürün

Kapı 7 — otomatik güvenlik taramaları: Her pull request’te statik uygulama güvenliği testi, bağımlılık analizi ve gizli bilgi taraması çalıştırın. Projeye göre altyapı kodu, container veya dinamik uygulama taraması ekleyin. Birleştirmeyi hangi önem düzeyindeki bulgunun durduracağını önceden tanımlayın; istisnaları gerekçeli, süreli ve yetkili insan onayına bağlı tutun.

Kapı 8 — ajan yetkileri ve görev ayrılığı: Kodlama ajanını izole bir ortamda, işe özel kısa ömürlü kimlikle ve gereken en düşük dosya, araç ve ağ erişimiyle çalıştırın. Üretim sırlarını ve kalıcı geliştirici kimlik bilgilerini vermeyin. Kodu üreten ajan kendi değişikliğini onaylayamamalı, ana dala birleştirememeli veya üretime dağıtamamalıdır; dış fork’lardan gelen kodu sır taşıyan ayrıcalıklı CI işlerinden ayırın.

Kapı 9 — build bütünlüğü, kontrollü yayın ve izleme: Dağıtılacak çıktıyı incelenen commit ve CI build kaydıyla ilişkilendirin. Üretimde çalışacak paketin test edilen kaynaktan aynı denetimli süreçle üretildiği doğrulanamıyorsa dağıtımı durdurun. Yayından önce geri alma adımını hazırlayın; mümkünse aşamalı dağıtım yaparak hata oranı, yetkilendirme reddi, olağandışı dış bağlantı ve beklenmeyen kaynak tüketimi gibi değişikliğe özgü sinyalleri izleyin.

Dokuz kapıyı aşamalara dağıtın

Kontrollerin sahibi ve kanıtı belli olmalıdır. Yerel geliştirmede kapsam, bağlam, fark ve paket doğrulaması; pull request’te insan incelemesi ile negatif testler; CI/CD’de tarama eşikleri, yetki ayrılığı ve build kaydı; üretimde ise aşamalı yayın, izleme ve geri alma uygulanır.

1. Yerel geliştirme: Kapı 1–4 tamamlanır; hassas bağlam temizlenir ve yeni paket kurulmadan doğrulanır.
2. Pull request: Kapı 5–6 için sorumlu inceleyen, kritik veri akışları ve olumsuz test sonuçları üzerinden karar verir.
3. CI/CD: Kapı 7–9 için taramalar ve politika eşikleri birleştirmeyi otomatik olarak durdurabilir; ajan ile onaylayan kişi ayrılır ve çıktı commit’e bağlanır.
4. Üretim sonrası: Kapı 9’un yayın sinyalleri izlenir; belirlenen eşik aşılırsa hazır geri alma işlemi uygulanır.

Küçük ve kurumsal ekipler için iki seviye

Küçük ekip seviyesi: Pull request şablonuna AI kullanımı, paket değişikliği ve insan doğrulaması alanlarını ekleyin. Pre-commit gizli bilgi taraması; CI’da birim testleri, statik analiz ve bağımlılık denetimi; korunan ana dalda en az bir insan onayı; sürüm öncesinde çalışır geri alma adımı temel çizgiyi oluşturur.

Kurumsal seviye: Temel çizgiye onaylı araç ve paket listeleri, araç başına tehdit modeli, kritik yollar için iki kişilik onay, merkezi tarama eşikleri, izole ajan çalıştırıcıları, kısa ömürlü kimlikler, doğrulanabilir build kayıtları ve üretim anomali uyarıları ekleyin. Dokuz kapıdan herhangi birinin kanıtı yoksa değişiklik hazır değildir; eksik kontrol aynı pull request üzerinde tamamlanmalıdır.