AI ile Yazılan Kodun İnsan Kontrolüne İhtiyacı Var (Ve Bu Normal)

AI ile Yazılan Kodun İnsan Kontrolüne İhtiyacı Var (Ve Bu Normal)

May 11, 2026 ai development application security code review best practices owasp vulnerabilities vibe coding authorization bugs secure coding devops technical debt

AI ile Yazılan Kodunuz İnsan İncelemesine İhtiyaç Duyuyor (Ve Bu Tamamen Normal)

Yazılım geliştirme dünyasında ilginç bir dönemdeyiz. Claude, ChatGPT gibi araçlar ve yapay zeka destekli geliştirme ortamları sayesinde bir fikri çalışan koda dönüştürmek artık haftalarca değil, günler içinde olabiliyor. Özelliği anlatıyorsunuz, değişiklikleri onaylıyorsunuz, geliştiriyorsunuz ve yayına alıyorsunuz. Hız açısından gerçekten devrim niteliği.

Ama tabii bir sorun var.

Geçenlerde tam da bu şekilde yazılan bir kodun incelemesini yaptım—basit bir iç araç, kritik değil, ama 2024'ün sonuna kadar nasıl kod yayına alınacağını gösteren tipik bir örnek. Bulduklarım endişe verici olmakla birlikte, endişe verici bir şekilde. Kod yaklaşık 28 farklı sorun içeriyordu. Çoğu güvenlik açığı içeriyordu. Hemen hemen tamamı, 2000'li yıllardan beri OWASP Top 10 listesinde olan açıklıklardan biriydi.

Bu hikaye yapay zekanın tehlikeli olduğu hakkında değil. Bu hikaye, özellikleri geliştirmedeki şaşırtıcı hız ile bu özelliklerin sorunlara dönüşmesini önleyen yapısal düşüncenin dengesizliği hakkında.

Sorun Yapay Zeka Değil, Sormanız Gereken Soruyu Sormamak

İşte mesele şu: incelediğim kod iyiydi. Yapısı mantıklıydı. Bileşenleri iyi organize edilmişti. Kütüphane seçimleri makuldü. Eğer ben benzer bir şey bir hafta sonu içinde yazsaydım, ilk bakışta fark etmek zor olurdu.

Fark, üst seviye bir yerde gizli. Kodun ilk satırını yazmadan önce olması gereken şeyler.

Yapay zeka araçları istediğiniz şeyi yapmakta müthiş. "Bana bir kullanıcı yönetim sistemi yap" dersiniz, kullanıcı yönetim sistemi elde edersiniz. Ama başlamadan önce sorulması gereken soruları gönüllü olarak ortaya çıkarmaz: Bunu kim kullanabilir? Hangi veriler gerçekten hassas? Kimlik doğrulama nerede yapılır? Biri ön yüzü atlatırsa ne olur?

Araç, özellikler üretir. Gece rahat uyumanızı sağlayan düşünceli güvenlik mimarisi üretmez.

Gerçek Bir Örnek: Korumasız Admin Fonksiyonu

Şöyle bir senaryoyu düşünün: uygulamanızda sunucusuz bir fonksiyon var—kullanıcı oluşturma, şifre sıfırlama, hesap silme gibi işlemler. Standart işlemler. Geliştirme ekibi doğru karar aldı: güçlü kimlik bilgilerini sunucu tarafında tutsun, hiçbir zaman tarayıcıya açığa çıkarmasın.

Fonksiyonun hiçbir kimlik doğrulama kontrolü yoktu.

Zayıf kimlik doğrulamadan bahsetmiyorum. Yanlış kimlik doğrulama da değil. Hiç yoktu. Biri Geliştirici Araçlarını açıp endpoint URL'sini keşfetseydi ve POST isteği gönderseyde, admin hesapları oluşturabilir, şifreleri sıfırlayabilir, veya tüm kullanıcı veritabanını silebilirdi.

Ön yüzün mükemmel bir izin kontrolü vardı. Admin olmayan kullanıcılardan admin düğmesini gizlerdi. Gerçekten güvenli tasarlanmıştı. Ve tamamen işe yaramaz olmuş. Kullanıcı arayüzü üzerinden güvenlik bir sahtekarlık.

Bu klasik bir yetkilendirme atlatması—2003'ten beri açıklık listesinde var. Yapay zekanın bunu hiç neden işaretlemedili: istem "bana adminin kullanıcı oluşturmasını sağlayan bir fonksiyon yaz" idi. Fonksiyon bunu yapıyor. Ayrıca—teknik olarak—admin olmayanlar için de kullanıcı oluşturmaya izin veriyor. Çünkü istem asla açıkça bunun olmaması gerektiğini söylemedi.

İşin özü: yapay zeka sormanız gereken soruyu sormadığınızı bilmiyor.

Kağıtta Güvenli Olan Veritabanı

İşte başka bir faydalı örnek. Veritabanınız satır düzeyinde güvenlik ilkelerine destek veriyor—bir kullanıcının hangi satırları okuup değiştirebileceğini kimliğe göre sınırlayan türden. İyi bir güvenlik modeli. Hele de ön yüzünüz JavaScript'e API anahtarı gönderme mimarisini seçtiyse.

İyi niyetli bir mühendis yapay zekaya çok kullanıcılı desteği eklemeyi istedi. Yapay zeka, uygun RLS ilkeleri uygulanmış yeni tablolar oluşturan göçler yazıyor. Harika iş.

Ama beş tane varolan tablo—gerçek ticari verileriniz—olduğu gibi kaldı. Belki RLS etkinleştirilmişti. Belki değildi. Göç kontrol etmedi, etkinleştirmedi, bahsetmedi.

Yeni altyapıda npm run db:push çalıştırsaydınız, yeni tablolar sıkıca kilitliyken, eski tablolar API endpoint'inizi bilen herhangi birine açık olurdu.

Yapay zeka burada yanlış değildi. Sadece eksikti. Dar problemin çözümünü buldu (yeni auth tablolarına RLS ekle) ama içinde gizli bir varsayım vardı (her şeyi güvenli hale getirmek ister misiniz?).

Bunu Geliştirme Pratiğinize Nasıl Uyarlayabilirsiniz

Bütün bunlar yapay zeka destekli geliştirmeye karşı bir argüman değil. Hız önemli. Hızla özellik yayına alabilme yeteneği gerçekten değerli. Ama bununla birlikte bir sorumluluk geliyor: kod satır satır incelemesi değil, mimarî kararları inceleyen deneyimli mühendislere ihtiyacınız var.

İşe yaramış olan şey:

İnşa etmeden önce güvenlik kontrol listesi hazırlayın. "Bu endpoint'i kim çağırabilir? Birisi bunu izinsiz çağırırsa ne olur? Bu veriler herkese açık mı olmalı? Her tabloya RLS gerekli mi?" gibi sorular. Bunlar belgelenmiş varsayımlar olmalı, kod incelemesinde keşfedilecek şeyler değil.

Kıdemli mühendislerin satır satır inceleme değil, tehdit modelleme yapmasını sağlayın. Bulduğum 28 sorun yazım hatası veya stil sorunu değildi. Mimarî gözden kaçışlardı. Yapay zekaya kod üret deyin. Güvenlik hakkında düşünen işleri insana bırakın.

İstemlerde kimlik doğrulama ve yetkilendirmeyi açık hale getirin. "Bana bir kullanıcı yönetim endpoint'i yaz" yerine, "bana sadece o anda giriş yapan admin'in erişebileceği bir kullanıcı yönetim endpoint'i yaz ve kimlik doğrulama varsayımlarını belgetle" deneyin. Bu, aracı mantığını ortaya çıkarmaya teşvik eder.

Yetkilendirmeyi işlevsellikten ayrı test edin. İlişkisiz kullanıcıların işlem yapamadığını doğrulayan testler yazın. Sadece yetkili kullanıcıların yapabileceğini değil.

Önemli Olan Desen

Asıl sorun yapay zekanın güvensiz kod üretmesi değil. Yapay zeka, istediğiniz şeyi yapmakta son derece başarılıyken, unuttuğunuz şeyleri işaretlemekte son derece başarısız.

Aslında bu özellik, değil kusur—araçlarınızın istemlerinize duyarlı olmasını ve bahsetmediğiniz gereksinimleri tahmin etmemesini istiyorsunuz. Ama bu, sorumluluğu değiştiriyor. Yapay zekayı güvenlik hakkında düşünmesi için işe almıyorsunuz. Güvenlik tasarım kararlarını ölçekte yürütmek için işe alıyorsunuz.

İncelediğim kod, birisinin "dur, bu endpoint'in kimlik doğrulaması gerekli" demesini bekliyordu. Birisi bunu söyledikten sonra, düzeltmek dakikalar sürdü. 20 yıllık açıklık deseni 2024 geliştirme iş akışıyla buluştu ve iş akışı kazandı—ama sadece deneyimli biri dikkat ettiği için.

Önümüzdeki birkaç yıl için bu sürdürülebilir model: hız için yapay zeka, mimari için insanlar. Her iki bileşen de gerekli.

Read in other languages:

RU BG EL CS UZ SV FI RO PT PL NB NL HU IT FR ES DE DA ZH-HANS EN