AI Üretimi Kod Güvenliği: CI Hattında Güvenlik Kapısı

AI üretimi kod güvenliği hangi riskleri getirir?

Araştırmalar sorunun ölçeğini gösterir. Pearce ve arkadaşlarının IEEE S&P 2022'de yayımlanan çalışmasında GitHub Copilot'a 89 senaryo verildi, üretilen 1.689 programın yaklaşık yüzde 40'ında açık bulundu. Spracklen ve arkadaşlarının USENIX Security 2025 çalışması ise 16 modelden alınan 576 bin kod örneğinde 205.474 farklı uydurma paket adı tespit etti.

Kodu büyük ölçüde modele bırakan çalışma biçiminde bu riskler artar. En sık görülen desenler vibe coding güvenliği yazısında listelenir. Aşağıdaki kapılar bu desenlerin birleştirmeden önce yakalanması içindir.

Risk yalnız kodun kendisinde değildir. Kodlama yardımcısı yeni bir dosya, yeni bir CI adımı ya da yeni bir bulut izni ekleyebilir. İnceleme yükü arttıkça bu tür yan değişiklikler gözden kaçar. Bu yüzden kapı yalnız uygulama kodunu değil, yapılandırma dosyalarını, kilit dosyalarını ve iş akışı tanımlarını da kapsamalıdır.

CI güvenlik kapısı nedir ve neleri içerir?

CI güvenlik kapısı, kodun ana dala girmeden önce otomatik güvenlik kontrollerinden geçmesini zorunlu kılan denetim noktasıdır. Kontrol başarısız olursa birleştirme durur. Değeri, insan dikkatine bağlı olmamasıdır.

1. Statik analiz: kaynak kodu çalıştırmadan güvensiz desenleri arar.
2. Bağımlılık incelemesi: yeni eklenen paketlerdeki bilinen açıkları ve lisans sorunlarını bulur.
3. Sır taraması: koda gömülmüş anahtar, parola ve belirteçleri yakalar.
4. İzin denetimi: altyapı ve CI yapılandırmasındaki aşırı yetkiyi arar.

Kapının çalışması için depo kurallarında bu kontrollerin "zorunlu durum denetimi" olarak işaretlenmesi gerekir. Aksi halde başarısız bir tarama, birleştirmeyi engellemeyen bir kırmızı simgeden ibaret kalır. Kapıların sırası da önemlidir. Sır taraması gönderim anında, bağımlılık incelemesi ve statik analiz birleştirme isteğinde, geçmişe dönük sır taraması ve tam bağımlılık taraması ise zamanlanmış görev olarak çalışır. Böylece her kontrol en ucuz olduğu noktada devreye girer.

SAST ve bağımlılık incelemesi neyi yakalar?

SAST (statik uygulama güvenlik testi), sizin yazdığınız kodda güvensiz desenleri arar: girdi doğrulama eksikliği, birleştirilerek kurulan sorgu, zayıf kriptografi gibi. İş mantığı ve yetkilendirme hatalarını çoğunlukla göremez. SCA (yazılım bileşen analizi) ise dışarıdan aldığınız paketleri bilinen açıklarla eşleştirir. İkisi birbirinin yerini tutmaz.

Bağımlılık incelemesini birleştirme isteğine bağlamanın kolay yolu, GitHub'ın dependency-review-action eylemidir. Eylem, isteğin getirdiği yeni bağımlılıkları denetler. fail-on-severity ayarı low, moderate, high ya da critical değerlerini alır. allow-licenses izin verilen lisansları tanımlar.

name: bagimlilik-incelemesi
on: [pull_request]
permissions:
  contents: read
jobs:
  inceleme:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: actions/dependency-review-action@v5
        with:
          fail-on-severity: high
          allow-licenses: MIT, Apache-2.0, BSD-3-Clause

Örnekte okunabilirlik için sürüm etiketi kullanıldı. Üretimde her eylemi tam commit SHA değerine sabitleyin.

Önceliklendirmede CVSS bantları başlangıç noktasıdır. FIRST'ün tanımına göre 7.0-8.9 yüksek, 9.0-10.0 kritiktir. CISA'nın aktif sömürülen açıklar kataloğunda (KEV) yer alan bir bulgu, puanından bağımsız olarak öne alınmalıdır. Puanın ortam bağlamıyla nasıl tamamlanacağı LLM framework yama yönetimi yazısında anlatılır.

Sır taraması ve izin denetimi nasıl kurulur?

Yapay zekâ araçları örnek kodda yer tutucu anahtar kullanır. Geliştirici bunları gerçek değerle değiştirip depoya ekleyebilir. GitHub'ın push protection özelliği, sır içeren gönderimleri depoya ulaşmadan engeller. Varsayılan olarak yazma yetkisi olan kişi bir gerekçe belirterek engeli aşabilir. Her aşma bir uyarı oluşturur ve denetim kaydına düşer. Aşma taleplerini güvenlik ekibinin onayına bağlamayı değerlendirin.

Bulunan bir sır için depodan silmek yetmez, sır sağlayıcı tarafında iptal edilmelidir. Adımlar LLM API anahtarı sızdı yazısındadır.

İzin denetimi, modelin "çalışsın diye" verdiği geniş yetkileri yakalar. CI hattının kendisi de bu denetime girer. GitHub'ın Actions güvenlik belgesi, üçüncü taraf eylemleri tam commit SHA değerine sabitlemeyi ve GITHUB_TOKEN yetkilerini en aza indirmeyi önerir: varsayılan olarak salt okunur, gerektiğinde yalnız ilgili iş için yükseltilmiş.

Uydurma paket riski kapıya nasıl yansır?

Modelin önerdiği paket adı var olmayabilir. Saldırgan bu adı kaydedip içine zararlı kod koyarsa, öneriye güvenen geliştirici paketi kurar. Savunma bağımlılık kapısında yapılır:

• Yeni eklenen her paket bir kişinin onayından geçsin.
• Paketin yayımlanma tarihine, bakım geçmişine ve sahibine bakılsın.
• Onaylı paketlerin iç izin listesi tutulsun.
• Kilit dosyası ve sürüm sabitleme zorunlu olsun.
• Kurulum sırasında betik çalıştıran paketler ek incelemeye alınsın.

Saldırının mekanizması ve kurulum öncesi savunma adımları slopsquatting yazısında ayrıntılı anlatılır.

Yanlış pozitifler nasıl yönetilir?

Kapıların kalitesi, yakaladıkları kadar susturdukları gürültüyle de ölçülür. Başlangıçta sıkı olmaktan çok güvenilir olmak önemlidir.

1. Yalnız yüksek güvenilirlikli kuralları engelleyici yapın, diğerlerini uyarı olarak bırakın.
2. Her yanlış pozitifi gerekçeyle işaretleyin ve kural ayarına geri besleyin.
3. İstisnalara sahip ve bitiş tarihi atayın, süresiz istisna bırakmayın.
4. Tekrar eden kuralları ve ortalama çözüm süresini aylık izleyin.
5. Bulgunun neden önemli olduğunu ve nasıl düzeltileceğini geliştiriciye gösterin.

Ekip alıştıkça daha fazla kural engelleyici hale getirilir.

Birleştirme politikası nasıl yazılır?

Birleştirme politikası, kapıların sonucunu karar kuralına çevirir ve istisna sürecini tanımlar. Yapay zekâ ile üretilen kodda riskli alanlarda insan incelemesi korunur.

Kapıları atlayan bir acil düzeltme yolu tanımlıyorsanız kayıtlı ve sonradan incelenen bir istisna olmalıdır.

Kodlama yardımcısının kendisi nasıl yapılandırılır?

Kapılar sorunu birleştirmeden önce yakalar. Daha iyisi sorunun hiç üretilmemesidir. Yardımcının proje kural dosyasında güvenli kodlama ilkeleri tanımlanabilir: parametreli sorgu, sırların ortam yapılandırmasından okunması, yeni bağımlılığın açıkça bildirilmesi.

• Yardımcıya üretim sırlarına ve gerçek veriye erişim vermeyin.
• Çalıştırabileceği komutları ve ağ erişimini sınırlayın.
• Önerdiği her yeni paketi geliştiricinin doğrulamasını zorunlu kılın.
• Ürettiği değişiklikleri küçük parçalar halinde inceleyin.

Kapıların etkisini üç ölçütle izleyin: yakalanan gerçek bulgu sayısı, yanlış pozitif oranı ve düzeltme süresi. Bulgu sayısı hep sıfırsa kapı çalışmıyor olabilir. Ajan olarak çalışan kodlama araçlarının yetki ve yalıtım farkları için kodlama ajanı güvenliği karşılaştırması yazısına bakın.

Sık Sorulan Sorular

Yapay zekâ kodu için ayrı bir CI hattı gerekir mi?

Ayrı hat gerekmez, mevcut hattın sıkılaştırılması gerekir. Kod üretimi hızlandıkça gözden geçirme yükü büyür ve insan dikkati tek başına yetmez. Statik analiz, bağımlılık incelemesi, sır taraması ve izin denetimi tüm kod için zorunlu olmalıdır. Kodu kimin ya da hangi aracın yazdığına bakılmaz, her değişiklik aynı standarttan geçer.

Yanlış pozitifler hattı nasıl bozar?

Çok fazla yanlış uyarı geliştiricileri uyarıları yok saymaya iter ve gerçek bulgu kaybolur. Başlangıçta yalnız yüksek güvenilirlikli kuralları engelleyici yapın, diğerlerini uyarı olarak bırakın. Yanlış pozitifleri gerekçeyle işaretleyin, kuralları düzenli ayarlayın ve her istisnaya sahip ile bitiş tarihi atayın. Böylece ekip kapıya güvenmeye devam eder.

Yapay zekânın önerdiği paketler neden riskli?

Modeller bazen var olmayan paket adları önerir. USENIX Security 2025'te yayımlanan bir çalışma, 576 bin kod örneğinde uydurma paket oranının ticari modellerde ortalama en az yüzde 5,2, açık kaynak modellerde yüzde 21,7 olduğunu buldu. Saldırgan bu adı kaydedip zararlı kod koyabilir. Bağımlılık kapısı yeni her paketi onaya bağlamalıdır.

Kapılar kodu tamamen güvenli yapar mı?

Yapmaz. Otomatik araçlar yaygın hata desenlerini, bilinen açıklı paketleri ve sızan sırları yakalar. İş mantığı hatalarını ve yetkilendirme kusurlarını çoğunlukla göremez. Bu yüzden kimlik, yetki ve ödeme koduna dokunan değişikliklerde insan incelemesi, tehdit modelleme ve güvenlik testi ayrıca gerekir. Kapılar temel güvenceyi sağlar, katmanlardan yalnız biridir.

Kaynaklar

• arXiv: Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions
• arXiv: Spracklen ve diğerleri, Package Hallucinations by Code Generating LLMs (USENIX Security 2025)
• GitHub Docs: Push protection
• GitHub: actions/dependency-review-action
• GitHub Docs: Secure use reference for GitHub Actions
• FIRST: CVSS v4.0 Specification Document

İlgili Yazılar

• Vibe Coding Güvenliği: AI ile Yazılan Kodun Zafiyet Desenleri
• Slopsquatting LLM'in Uydurduğu Paket, Saldırganın Fırsatı (LLM07:2026)
• AI Kod Asistanı Güvenliği Karşılaştırması 2026 Claude Code, Cursor, Codex CLI, Gemini CLI ve Cline'ı izin modeli, sandbox ve CVE ekseninde ölçtük
• LLM Framework Güvenlik Güncellemesi: Yama Yönetimi Rehberi