Yapay zekâ ile geliştirilen projelerde güvenlik testi nasıl yapılır?

Yapay zekâ ile geliştirilen projelerde güvenlik testi, modelin ürettiği kodu doğrudan yayımlamak yerine gereksinimden dağıtıma kadar katmanlı bir kontrol süreciyle yapılır. Güvenlik koşulları prompt'a yazılır, çıktı elle incelenir, statik ve dinamik testlerle sınanır, yapılandırma ve bağımlılıklar denetlenir, ardından CI/CD içinde yeniden kontrol edilir. Buradaki odak, yapay zekâ modelinin güvenliği ya da adversarial attack analizi değil, yapay zekâ araçlarının ürettiği uygulama kodunun güvenliğidir.

Yapay zekâ ile geliştirilen projelerde güvenlik testi nasıl planlanır?

Planın amacı yalnızca otomatik araçlardan uyarı toplamak değil, her kontrolün bir sonraki adıma taşınabilecek kanıt üretmesini sağlamaktır. Aşağıdaki akış, yapay zekâ tarafından oluşturulan kodu geliştirme sürecinin doğal bir parçası hâline getirir.

1. Gereksinimleri tanımla: Kimlik doğrulama ve yetkilendirme, veri sınıfları, girdi sınırları, dosya erişimi, hata ve log politikası ile kabul testlerini yaz. Kanıt: Veri akışı ve test maddeleri.
2. Güvenlik kısıtlarını prompt'a ekle: Parametreli sorgu, bağlama uygun çıktı kodlama, sırların ortamdan alınması, erişim kontrolü ve izin verilen değerler açıkça belirtilsin. Kanıt: Prompt ve varsayımlar kaydı.
3. Kodu küçük değişiklikler hâlinde üret: Yapay zekâdan tüm uygulamayı tek seferde değil, sınırları belli modül ve testlerle istemek incelemeyi kolaylaştırır. Kanıt: Kod farkı, bağımlılık listesi ve test dosyaları.
4. Elle incele: Kullanıcı kontrollü veriyi tehlikeli işlemlere kadar izle; kimlik doğrulama ile yetkilendirme ayrımını, sırları, dosya yollarını, kripto kullanımını ve logları kontrol et. Kanıt: İşaretlenmiş inceleme listesi.
5. Statik tarama yap: SonarQube, Bandit veya ESLint güvenlik eklentileriyle kaynak kodu tarat. Kanıt: Dosya, satır, akış, önem ve düzeltme bilgisi bulunan rapor.
6. Çalışan endpoint'i test et: Yalnızca yetkili yerel ya da test ortamında normal, sınır ve reddedilmesi gereken istekleri gönder. Kanıt: İstek, yanıt, beklenen ve gerçek davranış.
7. Düzelt ve yeniden test et: Kod değişikliğinin yanında yapılandırma ve bağımlılıkları da gözden geçir; regresyon testlerini çalıştır. Kanıt: Aynı bulgunun kapanması ve test sonucu.
8. Pipeline kararı ver: Çözülmemiş önemli güvenlik akışları için kapı koy, istisnaları gerekçe ve onayla kaydet. Kanıt: CI/CD çıktısı ve sürümleme kararı.

Yapay zekâ üretimi kodda hangi açık belirtilerine bakılır?

Yapay zekâ üretimi kodu değerlendirirken yalnızca belirli fonksiyon adlarını arama. Verinin kaynağını, işlendiği bağlamı, erişim kararını ve çıktının gerçek çalışma ortamındaki etkisini birlikte incele.

SQL injection

Kod kokusu: Kullanıcı girdisi sorgu metnine + veya şablon ifadeleriyle ekleniyor. Doğrulama sorusu: Bu değer sorgunun yapısını değiştirebiliyor mu? Düzeltme ilkesi: Parametreli sorgu ve ayrı veri bağlama kullan.

XSS

Kod kokusu: Doğrulanmamış veri innerHTML ya da ham HTML şablonuna yazılıyor. Doğrulama sorusu: Veri HTML, öznitelik veya JavaScript bağlamında nasıl kodlanıyor? Düzeltme ilkesi: Bağlama uygun çıktı kodlama ve güvenli DOM API'leri kullan.

Hardcoded secrets, kaynak koda gömülü sırlar

Kod kokusu: Anahtar, parola veya token doğrudan kaynak dosyada tutuluyor. Doğrulama sorusu: Bu değer depo geçmişinde, CI/CD günlüklerinde veya paketlenmiş dosyada görülebilir mi? Düzeltme ilkesi: Sırları çalışma ortamından al ve açığa çıkan değerleri yenile.

Yetkilendirme hataları

Kod kokusu: Kimlik doğrulama yapılmasına rağmen istenen kaynağın kullanıcıya ait olup olmadığı kontrol edilmiyor. Doğrulama sorusu: Başka bir hesabın kaynak kimliği gönderildiğinde erişim sürüyor mu? Düzeltme ilkesi: Yetki kontrolünü sunucu tarafında ve kaynak düzeyinde uygula.

Güvensiz dosya işlemleri

Kod kokusu: Kullanıcıdan gelen dosya adı veya yol doğrudan open, okuma ya da yazma işlemine aktarılıyor. Doğrulama sorusu: İzin verilen klasörün dışına çıkılabiliyor mu? Düzeltme ilkesi: İzin listesi kullan, yolu sınırla ve taban klasörü sunucuda belirle.

Zayıf şifreleme

Kod kokusu: Özel tasarım algoritma, yanlış amaçla kullanılan özet fonksiyonu veya sabit anahtar bulunuyor. Doğrulama sorusu: Kullanılan yöntem parola, bütünlük ya da gizlilik amacına uygun mu? Düzeltme ilkesi: Amaca uygun, denetlenmiş kütüphane ve anahtar yönetimi kullan.

Girdi doğrulama

Kod kokusu: Tür, uzunluk, aralık veya izin verilen değerler yalnızca istemciye bırakılıyor. Doğrulama sorusu: Beklenmeyen tür ve uzunlukta veri geldiğinde ne oluyor? Düzeltme ilkesi: Girdiyi güven sınırında, izin listesiyle ve sunucu tarafında doğrula.

Hata yönetimi

Kod kokusu: İstemciye stack trace, SQL metni, dosya yolu veya iç servis ayrıntısı dönüyor. Doğrulama sorusu: Hatalı istek uygulamanın iç yapısını açıklıyor mu? Düzeltme ilkesi: İstemciye genel hata, iç loglara ise kontrollü ayrıntı gönder.

Log güvenliği

Kod kokusu: Parola, token, kişisel veri veya ham kullanıcı girdisi loglanıyor. Doğrulama sorusu: Log akışını gören biri hassas veriye ulaşabilir mi? Düzeltme ilkesi: Maskeleme, veri minimizasyonu ve erişim kontrolü uygula.

Statik analiz sonuçları nasıl okunur ve önceliklendirilir?

Statik analiz, kodu çalıştırmadan riskli kalıpları ve veri akışlarını bulmaya yardım eder. Ancak tarama çıktısı tek başına açık kararı değildir. Her bulgu, kaynak, kullanıcı kontrollü veri, tehlikeli işlem, erişilebilirlik, veri hassasiyeti ve düzeltme bağlamıyla elle doğrulanmalıdır.

SonarQube: Kaynak kodu kurallarla tarayarak bulgular üretir. Güvenlik kuralları, kullanıcı kontrollü veriden hassas işlemlere uzanan enjeksiyon akışlarını ve yanlış parametre ya da eksik erişim kontrolü gibi yapılandırma sorunlarını gösterebilir. Bulgular kullanılan sınıflandırmaya göre güvenlik açığı veya Security Hotspot olarak görünebilir.

Bandit: Python dosyalarını AST'ye dönüştürür ve eklentilerle tarar. Basit bir JSON raporu almak için şu komut kullanılabilir:

bandit -r . -f json -o bandit.json

Bandit çıktısında dosya adı, satır numarası, bulgu metni, önem seviyesi, güven düzeyi ve test bilgisi gibi alanlar bulunabilir. Önem seviyesi ile güven düzeyini birlikte okumak, otomatik uyarıyı elle doğrulamak için başlangıç noktası sağlar.

ESLint güvenlik eklentileri: ESLint'in eklenti sistemiyle güvenlik kuralları yapılandırmaya eklenebilir. eslint-plugin-security gibi eklentiler, dinamik eval, çocuk süreçleri, değişken dosya adları ve riskli düzenli ifadeler gibi kalıpları işaretleyebilir. Bu uyarılar potansiyel güvenlik kokularıdır ve insan incelemesi gerektirebilir.

Aşağıdaki çıktı, canlı bir araç raporu değil, statik bulgunun nasıl okunacağını gösteren temsilî bir şablondur:

Temsilî statik tarama bulgusu
Dosya: app/routes.py
Satır: 18
Bulgu açıklaması: Kullanıcı kontrollü veri sorgu metnine ekleniyor
Önem seviyesi: yüksek
Kanıt: request.args["name"] -> query -> db.execute
Önerilen düzeltme: Parametreli sorgu kullan ve endpoint testini tekrarla

Önceliklendirmeyi yalnızca aracın verdiği önem etiketine bırakma. Şu dört soruyu sırayla sor:

1. Dışarıdan erişilebilir mi? İnternet veya kullanıcı kontrollü bir akışa açık bulgular önce incelenir.
2. Hassas veriye ulaşıyor mu? Kimlik bilgileri, kişisel veriler ve kritik işlevler önceliği artırır.
3. Gerçekten çalışabilir mi? Kaynaktan tehlikeli işleme uzanan yolun koşullarını elle doğrula.
4. Düzeltme etkili mi? Değişikliğin regresyon oluşturmadığını ve aynı akışın yeniden kurulamadığını test et.

Bir API endpoint'inde SQL injection açığı dinamik testle nasıl yakalanır?

Dinamik testte endpoint'e önce normal bir veri, ardından sorgu davranışını kontrollü biçimde değiştirmeyi amaçlayan test girdileri gönderilir. Beklenmeyen kayıtların dönmesi, veritabanı hatası veya yanıt davranışındaki tutarsızlıklar incelenir. Bu çalışma yalnızca kendi yerel uygulamanda ya da açıkça yetki verilmiş bir test ortamında yapılmalıdır.

Aşağıdaki Flask uygulaması, test veritabanını oluşturur ve kullanıcı adını sorgu metnine doğrudan ekleyen güvensiz bir endpoint içerir. Flask'ta rota tanımlama, istek parametresini okuma ve JSON yanıtı döndürme bu yapıyla gerçekleştirilebilir.

Güvensiz sürüm:

from flask import Flask, jsonify, request
import sqlite3

app = Flask(__name__)
DB = "test.db"

def connection():
    db = sqlite3.connect(DB)
    db.row_factory = sqlite3.Row
    return db

def init_db():
    with connection() as db:
        db.execute(
            "CREATE TABLE IF NOT EXISTS users "
            "(id INTEGER PRIMARY KEY, username TEXT UNIQUE)"
        )
        db.executemany(
            "INSERT OR IGNORE INTO users(username) VALUES (?)",
            [("alice",), ("bob",)]
        )

@app.get("/users")
def users():
    username = request.args.get("username", "")
    sql = "SELECT id, username FROM users WHERE username = '" + username + "'"
    with connection() as db:
        rows = db.execute(sql).fetchall()
    return jsonify([dict(row) for row in rows])

if __name__ == "__main__":
    init_db()
    app.run(debug=False)

/users?username=alice isteği yalnızca alice kaydını döndürmelidir. Buna karşılık username=alice%27 gibi tek tırnak içeren bir değer veritabanı hatasına yol açabilir. username=alice%27%20OR%20%271%27=%271 gibi kontrollü bir boolean koşulu ise sorgunun koşulunu değiştirerek birden fazla kaydın dönmesine neden olabilir. Bu sonuçlar, girdinin sorgu yapısına karıştığını gösteren güçlü işaretlerdir.

Düzeltilmiş endpoint: Aşağıdaki route, üstteki uygulamadaki users fonksiyonunun yerine kullanılabilir.

@app.get("/users")
def users():
    username = request.args.get("username", "").strip()

    if not username or len(username) > 64 or not username.isprintable():
        return jsonify({"error": "invalid username"}), 400

    try:
        with connection() as db:
            rows = db.execute(
                "SELECT id, username FROM users WHERE username = ?",
                (username,)
            ).fetchall()

        return jsonify([dict(row) for row in rows])

    except sqlite3.Error:
        app.logger.exception("user lookup failed")
        return jsonify({"error": "request could not be completed"}), 500

Burada girdi doğrulaması boş, aşırı uzun veya yazdırılamayan değerleri sınırlar. Asıl güvenlik düzeltmesi ise ? yer tutucusu ve ayrı parametre tuple'ı kullanan parametreli sorgudur. Aynı test girdileri artık sorgunun yapısını değiştirmez, yalnızca aranacak kullanıcı adı olarak değerlendirilir. İstemciye SQL ayrıntısı ya da yığın izleme bilgisi döndürülmez.

Yetkili bir yerel veya test hedefinde dinamik tarama akışı şu sırayla kurulabilir. ZAP'ın Quick Start bölümündeki Automated Scan akışı, hedef URL üzerinden keşif ve tarama adımlarını başlatabilir.

1. Hedefi tanımla: Yerel adresi veya test ortamı adresini belirle, kapsam dışındaki alanları taramaya dâhil etme.
2. Endpoint'i keşfet: Endpoint bir sayfada bağlantılı değilse yetkili tarayıcı trafiğini ZAP üzerinden geçirerek veya test isteğini kontrollü biçimde göndererek Sites ve History kayıtlarını oluştur.
3. Kontrollü tarama çalıştır: Yalnızca test verileriyle, seçilen hedef ve uygun tarama kapsamı üzerinde taramayı başlat.
4. Kanıtı incele: Alerts bölümünde uyarının URL'sini, etkilenen parametreyi, risk ve güven düzeyini, kullanılan test girdisini ve ilgili istek yanıtı karşılaştırmasını incele.
5. Elle yeniden üret: Uyarıdaki isteği, önce normal kullanıcı adıyla sonra kontrollü test girdisiyle tekrarla. Bulguyu yalnızca uygulama davranışı ve sunucu kayıtları birlikte destekliyorsa doğrulanmış kabul et.
6. Düzelt ve yeniden tara: Parametreli sorguya geç, genel hata yanıtını koru, aynı negatif testleri çalıştır ve ardından taramayı tekrarla.

Aktif tarama belirli açık türlerini bulmaya yardımcı olur, ancak yetkilendirme mantığı gibi iş kurallarına bağlı sorunların ayrıca manuel incelenmesi gerekir. Üretim sistemlerinde izinsiz tarama yapılmaz.

Güvenli prompt yazımı ve yapay zekâ çıktısının elle incelenmesi

Claude, Codex, Cursor ve GitHub Copilot gibi araçlar kod açıklama, kod önerme, düzenleme veya kod tabanı üzerinde çalışma süreçlerinde kullanılabilir. Ancak bu araçlardan gelen çıktı otomatik olarak güvenli kabul edilmemelidir.

Güvensiz prompt:

Flask ve SQLite ile username alan bir /users endpoint'i yaz.
Kullanıcı adına göre veritabanından kayıt getir.

Bu istek işlevi tarif eder, fakat güven sınırlarını ve kabul kriterlerini belirtmez. Daha güvenli bir prompt, modelden yalnızca kod değil, varsayımlarını ve negatif testlerini de açıklamasını ister.

Güvenli prompt:

Flask ve SQLite ile /users endpoint'i oluştur.

Güven sınırı: username dış girdidir ve güvenilmez kabul edilmelidir.
Authentication gereksinimini ve endpoint için gerekli authorization
kontrolünü açıkça belirt.
SQL sorgusunda yalnızca parametreli sorgu kullan.
Girdiyi tip, uzunluk ve izin verilen biçim açısından doğrula.
Sırları kaynak kodda veya prompt içinde tutma.
Hata yanıtları SQL ayrıntısı ve stack trace sızdırmasın.
Loglarda parola, token veya hassas kullanıcı verisi bulunmasın.
Her bağımlılığın adını, amacını ve neden gerekli olduğunu açıkla.
Negatif testler ekle: tek tırnak, boolean koşulu, boş değer,
aşırı uzun değer, yetkisiz kullanıcı ve hatalı kimlik doğrulama.
Varsayımlarını ve belirsiz kalan noktaları ayrı bir bölümde belirt.

Elle incelemede yalnızca kodun çalışmasına değil, güvenlik gereksinimlerinin gerçekten karşılanıp karşılanmadığına bakılır.

Güvenli yapılandırma: sırlar, bağımlılıklar ve çalışma ortamı

Gerçek API anahtarları, parolalar ve bağlantı bilgileri kaynak koda ya da yapay zekâ prompt'larına eklenmemelidir. Yapılandırma değerleri çalışma ortamından alınabilir, fakat ortam değişkeni tek başına eksiksiz bir sır yönetimi çözümü değildir. Erişim yetkileri, rotasyon, denetim, dağıtım ve sızıntı sonrası iptal süreçleri ayrıca yönetilmelidir. Bir sır açığa çıktıysa yalnızca dosyadan silmek yeterli değildir, ilgili değer yenilenmeli veya iptal edilmelidir.

Geliştirme, test ve üretim ortamlarının ayarları ayrıştırılmalı; testlerde üretim veritabanı ve üretim kimlik bilgileri kullanılmamalıdır. Hata ayıklama çıktıları dışarıya açılmamalı, istemciye genel hata mesajı döndürülürken ayrıntı yalnızca yetkili sunucu loglarında tutulmalıdır.

Yapay zekânın önerdiği her bağımlılık için kütüphanenin adı, amacı, resmî belgeleri, kaynak güvenilirliği, bilinen güvenlik uyarıları ve gereksiz transitif bağımlılıkları kontrol edilmelidir. Gereksiz bir paket eklenmemeli, kullanılan sürümler kilit dosyasıyla izlenmeli ve güncellemeler kontrollü test sürecinden geçirilmelidir.

• Sır yok: Kaynak kodda, prompt'ta ve sürüm geçmişinde gerçek gizli bilgi bulunmuyor.
• En az yetki var: Uygulama ve test hesapları yalnızca gerekli kaynaklara erişiyor.
• Hata yanıtı sınırlı: SQL ayrıntısı, stack trace ve hassas yapılandırma dışarı sızmıyor.
• Bağımlılık kaynağı incelenmiş: Amaç, belge, güvenlik uyarıları ve transitif zincir kontrol edilmiş.
• Kilit dosyası güncel: Kullanılan bağımlılık seti tekrarlanabilir biçimde kaydedilmiş.
• Test ortamında doğrulanmış: Yapılandırma, sırların yokluğu ve negatif senaryolar test edilerek kontrol edilmiş.

CI/CD pipeline'ında güvenlik testleri nasıl otomatikleştirilir?

CI/CD içinde güvenlik, tek bir tarama komutundan ibaret olmamalıdır. Kodun değişiklikten terfiye kadar geçtiği akışta bağımlılıklar, testler, kaynak kod, çalışma ortamı ve uygulama davranışı birlikte kontrol edilmelidir.

1. Kilitlenmiş bağımlılıkları kur
2. Birim ve entegrasyon testlerini çalıştır
3. Statik analiz ve sır taraması yap
4. Derle
5. İzole test ortamına dağıt
6. Dinamik tarama ve kontrollü istekler çalıştır
7. Raporları birleştir
8. Güvenlik kapısını değerlendir
9. Başarılıysa terfi et, değilse düzelt ve yeniden çalıştır

Güvenlik politikası pipeline çalışmadan önce tanımlanmalıdır. Örneğin doğrulanmış SQL injection, üretim sırrının kaynak koda yazılması veya yetkilendirme atlatma gibi yüksek etkili bulgular build ya da terfi adımını durdurabilir. Düşük güvenilirlikteki bir uyarı ise doğrudan engellemek yerine inceleme kaydı açılarak takip edilebilir.

• Önem: Açığın oluşturabileceği etki değerlendirilir.
• Güvenilirlik: Tarama sonucunun gerçek bir bulgu olma ihtimali incelenir.
• Erişilebilirlik ve veri hassasiyeti: Riskin dışarıdan ulaşılabilir olup olmadığı ve işlenen verinin niteliği dikkate alınır.

İstisnalar gerekçesi, sorumlusu ve yeniden değerlendirme tarihiyle kaydedilmelidir. Tarama raporları geliştiriciye ulaşmalı, düzeltme yapıldığında aynı kontrol yeniden çalıştırılmalı ve kapı yalnızca yeni sonuçlar incelendikten sonra geçilmelidir.

Uçtan uca örnek: yapay zekâ ile üretilen endpoint'i güvenlik kapısından geçirmek

Aşağıdaki temsili senaryoda bir endpoint, istekten aldığı kimlikle veritabanından kayıt döndürür. Amaç, yapay zekâ tarafından üretilen kodu tek bir taramayla değil, birbirini tamamlayan kontrollerle değerlendirmektir.

Yayın öncesi kontrol listesi

1. Prompt'taki güvenlik gereksinimlerini ve kabul ölçütlerini kaydet.
2. Kaynak, veritabanı işlemi ve yetkilendirme arasındaki akışı elle incele.
3. Statik analiz, sır taraması ve bağımlılık kontrollerini tamamla.
4. Dinamik testi yalnızca yetkili, izole ve veri kaybı oluşturmayacak ortamda yap.
5. Yüksek etkili ve doğrulanmış bulgular kapanmadan terfi ettirme.
6. İstisnaları gerekçe, sorumlu ve yeniden değerlendirme tarihiyle kaydet.
7. Düzeltmeden sonra aynı testleri yeniden çalıştır.

Güvenlik testleri belirli bir açığın bulunmasını ve bilinen risklerin görünür hâle gelmesini destekler. Hiçbir otomasyon, uygulamadaki tüm açıkların yokluğunu garanti etmez.

Sık Sorulan Sorular

Yapay zekâ tarafından üretilen kod güvenli kabul edilebilir mi?

Tek başına güvenli kabul edilmemelidir. Kod, manuel inceleme, testler, statik analiz, sır taraması, yapılandırma kontrolü ve mümkünse yetkili dinamik testlerle değerlendirilmelidir.

Statik analiz ile dinamik güvenlik testi arasındaki fark nedir?

Statik analiz, uygulamayı çalıştırmadan kaynak kodu ve veri akışlarını inceler. Dinamik test ise çalışan uygulamaya kontrollü istekler göndererek gerçek davranışı gözlemler. İki yöntem birbirini tamamlar.

Güvenlik taraması doğrudan üretim ortamında çalıştırılabilir mi?

Varsayılan yaklaşım, taramayı yerel veya izole test ortamında yapmaktır. Üretim incelemesi gerekiyorsa önceden yetkilendirme, düşük etkili istekler, hız sınırı, izleme ve geri dönüş planı bulunmalıdır.

Ortam değişkeni kullanmak gerçek sırları korumak için tek başına yeterli midir?

Hayır. Ortam değişkenleri sırları kaynak koddan ayırır, ancak loglar, CI çıktıları, yedekler, süreç izinleri ve hatalı yapılandırmalar üzerinden sızıntı yaşanabilir. Erişim kontrolü, maskeleme, tarama ve yenileme süreçleri de gerekir.

Kod üretim aracına gerçek API anahtarı veya kişisel veri göndermeden önce hangi kontroller yapılmalıdır?

Gerçek sırlar ve gereksiz kişisel veriler gönderilmemelidir. Değerler yer tutucularla değiştirilmeli, veri sınıfı ve kurum politikası incelenmeli, aracın erişim ve saklama koşulları onaylanmadan hassas içerik paylaşılmamalıdır.

Güvenliği, yapay zekâ çıktısının son kontrolü değil, geliştirme sürecinin her aşamasına yayılan bir çalışma olarak ele aldığında daha izlenebilir ve düzeltilebilir bir akış kurabilirsin.