Kazanimlar:
- AI çıktısını doğruluk, güvenlik ve kaynak/lisans olarak üç katmanda doğrulayabilme
- Enjeksiyon, halüsinasyon paket ve gömülü sır gibi riskleri güvenli kalıp ve araçlarla kapatabilme
- Güvenlik-kritik kodu yetkin mühendis onayına sunup sorumluluğun devredilemezliğini kavrayabilme
AI kodu üretmek kolaydır; ona güvenmek pahalıya patlar. Bu ünitenin tek amacı, önceki tüm ünitelerde tekrarladığımız "doğrula" ilkesini sistemli bir mühendislik disiplinine dönüştürmektir. Çünkü AI'nın ürettiği kod, ilk bakışta doğru görünse bile üç ayrı tehlike taşır: çalışmayan/yanlış olmak (halüsinasyon), güvensiz olmak (güvenlik açığı) ve hukuki/lisans riski taşımak. Bu üçünü tanımak ve her biri için bir kapı kurmak, sizi profesyonel yapar.
Burada "doğrulama"yı üç katmanda ele alıyoruz: doğruluk (kod gerçekten işi yapıyor mu?), güvenlik (kötü niyetli girdiye dayanıyor mu?) ve kaynak/lisans (bu kodu kullanmaya hakkım var mı?). Her katmanın kendi kontrol araçları vardır ve hiçbiri "AI böyle dedi" ile geçilemez.
Üç Risk Katmanı
1. Doğruluk riski (halüsinasyon). Model, var olmayan bir fonksiyon çağırabilir, bir API'yi yanlış kullanabilir, bir kenar durumu sessizce atlayabilir. Kod "makul" görünür ama yanlıştır. Panzehir: derleme, test, statik analiz ve gözle inceleme.
2. Güvenlik riski. AI, eğitim verisindeki güvensiz kalıpları tekrar edebilir: SQL enjeksiyonuna açık sorgu, doğrulanmamış kullanıcı girdisi, zayıf şifreleme, güvensiz deserialize, açık yönlendirme. Kod çalışır ama saldırıya açıktır. Panzehir: güvenlik odaklı inceleme, otomatik tarayıcılar (SAST), ve bilinen güvenli kalıpları dayatmak.
3. Kaynak/lisans riski. AI, telifli veya kısıtlayıcı lisanslı koda çok benzeyen bir çıktı üretebilir ya da uygunsuz lisanslı bir bağımlılık önerebilir. Panzehir: bağımlılık ve lisans denetimi, özgünlük kontrolü, kurumsal politika.
Dikkat: Bu üç riskten en sinsisi güvenliktir; çünkü kod testten geçebilir, üretimde sorunsuz çalışabilir ve açık yalnızca bir saldırgan onu bulunca ortaya çıkar. "Çalışıyor" ile "güvenli" aynı şey değildir.
Adım Adım: Katmanlı Doğrulama Kapısı
- Anlayarak oku. Kabul etmeden önce kodu gerçekten anlayın; anlamadığınız kodu birleştirmeyin. "Neden çalıştığını" açıklayamıyorsanız, henüz doğrulanmamıştır.
- Var olduğunu doğrula. Kullanılan her fonksiyon, API ve paketin gerçekten var olduğunu ve doğru kullanıldığını teyit edin (halüsinasyon kapısı).
- Otomatik araçları çalıştır. Derleyici, linter (stil/hata tarayıcı), tip denetleyici, birim testleri ve mümkünse bir SAST (Static Application Security Testing — kaynak kodunu güvenlik açığı için tarayan araç).
- Güvenlik gözüyle bak. Girdi doğrulanıyor mu? Sorgu parametreli mi? Sır gömülü mü? Yetki kontrolü var mı?
- Kaynak ve lisansı denetle. Yeni bağımlılıkların lisansı uygun mu? Çıktı bilinen bir kod tabanına aşırı benziyor mu?
- Güvenlik-kritik ise uzman onayı iste. Kimlik doğrulama, ödeme, kriptografi, erişim kontrolü gibi alanlarda yetkin bir mühendisin bağımsız incelemesi zorunludur.
Üç Mini Vaka
Vaka 1 — SQL enjeksiyonu inceleme kapısında yakalandı. AI, bir arama uç noktası için kullanıcı girdisini doğrudan SQL sorgusuna birleştiren bir kod üretti ("... WHERE name = '" + q + "'"). Kod çalışıyordu ve testten geçmişti. Güvenlik odaklı inceleme ve SAST taraması bunu yakaladı; parametreli sorguya (prepared statement) çevrildi. Yakalanmasa, klasik bir veri sızıntısı açığıydı.
Vaka 2 — Halüsinasyon paketi. AI, bir görev için var olmayan bir npm paketi (fast-safe-parse) önerdi. Geliştirici kurmaya çalışınca paket bulunamadı. Daha kötüsü: bazı durumlarda saldırganlar bu tür "hayalet" paket adlarını gerçek ve zararlı paketlerle doldurabilir (dependency confusion). Ders: önerilen her paketi resmî kayıttan ve indirilme/bakım geçmişinden doğrulayın.
Vaka 3 — Lisans uyumsuzluğu. AI'nın önerdiği şık bir yardımcı kütüphane, kurumun ürün lisansıyla bağdaşmayan güçlü kopyleft bir lisansa sahipti. Bağımlılık lisans taraması bunu bildirdi; ekip lisansı uygun bir alternatifle değiştirdi. Doğrulama olmasa, ürün dağıtımında hukuki bir yük doğacaktı.
Dört Kopyalanabilir Şablon
Kabul öncesi öz-denetim:
Aşağıdaki AI üretimi kodu kabul etmeden önce kontrol et:1) Kullandığı her fonksiyon/API/paket gerçekten var mı? Şüphelileri işaretle.2) Doğrulanmamış girdi, SQL/komut birleştirme, gömülü sır, zayıf kripto var mı?3) Ele alınmamış hata/kenar durum hangileri?Her bulguyu "kesin / olası" olarak etiketle ve düzeltme öner.{{kod}}
Güvenlik odaklı inceleme:
Bu kodu güvenlik gözüyle incele. OWASP tarzı yaygın açıkları ara: enjeksiyon,kırık kimlik doğrulama/yetki, hassas veri ifşası, güvensiz deserialize,doğrulanmamış yönlendirme. Her bulgu için: risk, sömürü senaryosu, düzeltme.Bu bir ön tarama; kritik bulguları insan güvenlik incelemesine yönlendir.{{kod}}
Bağımlılık ve lisans denetimi:
Bu kodun eklediği/önerdiği bağımlılıkları listele. Her biri için: paket gerçektenvar mı, bakımlı mı, tipik lisansı ne olabilir (DOĞRULANMALI), ve projeye gerçektengerekli mi yoksa mevcut bir araçla yapılabilir mi?{{kod veya bağımlılık listesi}}
Güvenli kalıp dayatma (üretim aşamasında):
{{görev}} için kod yaz. ZORUNLU güvenlik kuralları:- Tüm dış girdiyi doğrula/temizle.- Veritabanı erişiminde yalnızca parametreli sorgu kullan.- Sırları koda gömme; ortam değişkeni/sır yöneticisi varsay.- Hataları yut ma; anlamlı şekilde ele al.Kodun bu kurallara nasıl uyduğunu 3 maddeyle açıkla.
Zayıf prompt / Güçlü prompt
Zayıf: "Kullanıcı adına göre arama yapan bir sorgu yaz." (Enjeksiyona açık kod gelebilir.)
Güçlü: "Kullanıcı adına göre arama yapan bir fonksiyon yaz. Kullanıcı girdisini asla string olarak sorguya birleştirme; parametreli sorgu (prepared statement) kullan. Girdiyi uzunluk ve karakter açısından doğrula. Kodun enjeksiyona neden kapalı olduğunu 2 cümleyle açıkla."
Güçlü sürüm güvenli kalıbı baştan dayatır; böylece açığı sonradan yakalamak yerine hiç oluşmamasını sağlar. Yine de üretilen kodu doğrulama kapılarından geçirmek şarttır.
Doğrulama katmanı
Araç/yöntem
"AI dedi" yeterli mi?
Doğruluk
Derleme, test, gözle inceleme
Hayır
API/paket gerçekliği
Resmî doküman/kayıt kontrolü
Hayır
Güvenlik
SAST, güvenlik incelemesi
Hayır
Lisans/kaynak
Bağımlılık & lisans denetimi
Hayır
Güvenlik-kritik mantık
Uzman mühendis onayı
Kesinlikle hayır
Sorumluluk Devredilemez
Bir AI aracının ürettiği koddan doğan hata, açık veya ihlal karşısında sorumluluk araç sağlayıcısına değil, o kodu birleştiren ve dağıtan ekibe aittir. Bu, hukuki olduğu kadar mesleki bir gerçektir: imzayı siz atarsınız. Bu yüzden "AI üretti" bir mazeret değil, ekstra bir dikkat gerekçesidir. Özellikle güvenlik-kritik sistemlerde AI çıktısı, yetkin bir mühendisin incelemesi ve onayının yerine hiçbir koşulda geçmez; AI en fazla o mühendisin hızını artıran bir taslak sağlar.
İpucu: Ekibinizde "AI üretimi kod için doğrulama kapısı" adını verdiğiniz kısa bir kontrol listesi oluşturun (derleme + test + güvenlik taraması + gözle inceleme). Bu kapı bir kez alışkanlık hâline geldiğinde, hız kaybı minimum, risk azalması maksimum olur.
Sık yapılan hatalar
- "Çalışıyor" ile "güvenli"yi karıştırmak. Testten geçen kod, saldırıya açık olabilir.
- Paket/API'yi doğrulamadan kullanmak. Halüsinasyon paketler hem bozar hem güvenlik riski taşır.
- Otomatik araçları atlamak. Linter, tip denetleyici ve SAST, insanın kaçırdığını ucuza yakalar.
- Lisansı görmezden gelmek. Uygunsuz lisanslı bağımlılık, dağıtımda hukuki yük doğurur.
- Sorumluluğu araca yıkmak. Üretimdeki koddan ekip sorumludur; "AI yaptı" mazeret değildir.
Özetle
AI çıktısını kabul etmek üç katmanlı bir doğrulama gerektirir: doğruluk (derleme, test, gözle inceleme), güvenlik (SAST ve güvenlik odaklı inceleme), ve kaynak/lisans (bağımlılık denetimi). Kullanılan her paket ve API'nin gerçekten var olduğunu teyit edin, güvenli kalıpları baştan dayatın ve güvenlik-kritik kodu yetkin bir mühendisin onayına sunun. "Çalışıyor" güvenli demek değildir ve "AI üretti" sorumluluğu kaldırmaz. Doğrulama kapısı, hızın değil, profesyonelliğin bedelidir.
Uygulama görevi
Bir AI'ya kasıtlı olarak güvenlik-hassas bir görev verin (ör. "kullanıcı girdisiyle veritabanında arama yapan bir fonksiyon"), bu kez güvenli kalıp dayatmadan. Gelen kodu "kabul öncesi öz-denetim" ve "güvenlik odaklı inceleme" şablonlarından geçirin: enjeksiyon, gömülü sır, halüsinasyon paket veya doğrulanmamış girdi var mı? Sonra aynı görevi "güvenli kalıp dayatma" şablonuyla tekrar isteyin ve iki çıktıyı karşılaştırın. Mümkünse bir linter/SAST aracı çalıştırıp bulgularla AI'nın öz-denetimini kıyaslayın.
Kontrol listesi
- [ ] AI çıktısını doğruluk, güvenlik ve lisans olarak üç katmanda doğruluyorum.
- [ ] Kullanılan her fonksiyon, API ve paketin gerçekten var olduğunu teyit ediyorum.
- [ ] Derleme, test, linter ve mümkünse SAST araçlarını çalıştırıyorum.
- [ ] Güvenli kalıpları (parametreli sorgu, girdi doğrulama, sır yönetimi) baştan dayatıyorum.
- [ ] Yeni bağımlılıkların lisansını ve gerekliliğini denetliyorum.
- [ ] Güvenlik-kritik kodu yetkin bir mühendisin onayına sunuyorum ve sorumluluğun bende olduğunu biliyorum.