CodeQL 2.26.0: Kotlin 2.4 Desteği ve AI Prompt Injection Taraması
Uzun zamandır CodeQL’i takip edenler bilir: bu araç sessiz sedasız işini yapıyor, ama ortada yoksa insanın başını ağrıtıyor. GitHub’ın code scanning tarafının kalbi gibi düşünebilirsiniz. Geçen hafta 2.26.0 çıktı ve bu kez içinde göze çarpan birkaç şey var. Bir tanesi var ki, AI prompt injection tespiti, bana kalırsa 2026’nın en anlamlı güvenlik adımlarından biri.
Lafı dolandırmadan gireyim. Bu sürümde üç ana konu var: Kotlin 2.4.0 desteği, JavaScript/TypeScript tarafında sistem prompt injection sorgusu, bir de birkaç dilde false positive azaltan dokunuşlar. Ama işin asıl tarafı, listelenen maddelerin biraz ötesinde; bu sürüm SAST’in (Static Application Security Testing) AI çağına nasıl ayak uydurduğunu gösteriyor (şaşırtıcı ama gerçek)
Şimdi gelelim işin can alıcı noktasına.
Neden Bu Sürüm Farklı: AI Kodu Artık Bir Saldırı Yüzeyi
Dürüst olmak gerekirse, Şunu açıkça söyleyeyim: klasik SAST araçları uzun süre aynı dertlerle uğraştı. SQL injection, XSS, path traversal, deserialization… Liste neredeyse yıllardır aynı yerde dönüp dürüyor. Sonra LLM’ler geldi. Bir anda fark ettik ki kodumuz artık sadece veritabanına değil, bir dil modeline de sorgu gönderiyor. Üstelik o sorgunun içine kullanıcı verisi de karışabiliyor.
Bak şimdi, İşin garip yanı şu: prompt injection hâlâ birçok ekip için soyut kalıyor. “Ya kullanıcı sistem prompt’u ele geçirirse ne olur?” sorusunun cevabı çoğu zaman “model biraz saçmalar” seviyesinde bırakılıyor. Ama bir e-ticaret asistanının — en azından ben öyle düşünüyorum — fiyat hesaplama akışı ya da müşteri hizmetleri botunun iade politikası manipüle edilirse, olay teoriden çıkıp sahaya iniyor. Evet, baya sahaya.
CodeQL’in js/system-prompt-injection sorgusu, kullanıcıdan gelen güvenilmez verinin bir AI modelinin sistem prompt’una aktığı yerleri yakalıyor. Bu, taint analizinin AI SDK’larına genişletilmiş hali — yanı mantık aynı, hedef farklı.
Hangi SDK’lar Kapsamda?
Burada küçük ama önemli bir detay var; çünkü kapsama sadece OpenAI girmiyor. Sürüm notlarına bakınca yüzey şöyle genişliyor: (inanın bana)
- OpenAI: Sora prompt’ları ve Realtime session instructions dahil
- Anthropic: Legacy completion prompt’ları da modellenmiş
- Google GenAI: Cached content ve system instructions sink’leri eklenmiş
Yanı ekibiniz Anthropic’ten OpenAI’a geçtiyse (2026’da bunu sık görüyorum), eski kodunuz da taranıyor. Güzel tarafı bu. Çünkü kurumlarda “geçici” diye yazılan entegrasyonlar bazen production’da yıllarca kalıyor; legacy completion API’si de köşede unutulmuş olabiliyor.
Hmm, bunu nasıl anlatsamdı…
Kotlin 2.4.0 Desteği: Android ve Backend Tarafında Rahat Bir Nefes
Kotlin tarafındaki güncelleme biraz sessiz ama etkisi var. CodeQL artık Kotlin 2.4.0’a kadar destek veriyor. K2 derleyicisiyle gelen değişikliklerden sonra SAST tarafının uyumlu kalması demek bu.
Türkiye’deki tabloyu da söyleyeyim biraz. Kurumsal Android geliştiren ekiplerin çoğu Kotlin sürüm yükseltirken temkinli davranıyor; haklılar da aslında, çünkü her yükseltme yeni bir sürpriz getirebiliyor. Ama sorun şu oluyor: SAST aracınız yeni Kotlin sürümünü desteklemiyorsa ekipler ya Kotlin’i yükseltemiyor ya da yükseltip taramayı kapatıyor. İkincisi daha tatsız bir senaryo. Bu yüzden Kotlin 2.4 desteği sadece yeni özellik değil, upgrade debt için de bir nefes alanı gibi dürüyor.
Kimin İçin Kritik?
Küçük bir mobil ekipseniz ve tek uygulama geliştiriyorsanız, bu sürüm size “iyi öldü” dedirtir geçer. Ama bankacılık, fintech veya sağlık gibi regülasyonlu sektörlerdeyseniz — ki backend tarafında Kotlin kullanımı oralarda da arttı — durum değişiyor. Regülatörler bazen çok basit görünen. Can sıkıcı sorular soruyor: hangi statik analiz aracını kullanıyorsunuz, hangi dilleri destekliyor? Eski sürüm varsa işte orada uyumsuzluk riski başlıyor.
C#, Go, Python, Swift: Sessiz İyileştirmeler
Burada birkaç teknik detay var; biraz sabredin.
C# Razor Pages Artık İzleniyor
C# tarafında ilginç bir ekleme yapılmış: Razor Page handler metodlarının parametreleri (OnGet, OnPost, OnPostAsync gibi) artık remote flow source olarak modelleniyor. Yanı ne oluyor? ASP.NET projenizde Razor Pages kullanıyorsanız PageModel metod parametrelerine gelen kullanıcı verisi artık CodeQL tarafından güvenilmez kabul ediliyor ve SQL injection gibi zafiyetler için izlenebiliyor.
Bence bu çoktan olması gereken bir şeydi. Sahada şunu çok gördüm: ASP.NET MVC projelerinde controller action parametreleri az çok izleniyordu ama Razor Pages’e geçen ekiplerde SAST kapsamı sessizce daralıyordu. Kimse fark etmiyordu bile; çünkü raporda “temiz” görünüyordu. Oysa bu bazen dümdüz yanıltıcı güven yaratıyor (ki bu çoğu kişinin gözünden kaçıyor)
Go — slog Paketi Desteği
Go 1.21 ile gelen log/slog paketi artık modellenmiş durumda. go/log-injection. go/clear-text-logging sorguları slog fonksiyonlarını ve slog.Logger metodlarını tanıyor.
// Bu tür bir kod artık taranabilir hale geldi
logger := slog.New(slog.NewJSONHandler(os.Stdout, nil))
logger.Info("user login attempt",
"username", userInput, // log injection riski
"password", plainPassword) // clear-text loggingBi saniye — Go 1.21 önemliydi çünkü slog standart kütüphaneye girdi ve birçok ekip logrus/zap’ten göç etti. Eğer sız de o göçü yaptıysanız ama SAST’ınızın bu alanı gerçekten tarayıp taramadığını hiç kontrol etmediyseniz (ki bu çoğu kişinin gözünden kaçıyor). hani şimdi iki dakika ayırıp bakmak fena olmaz.
Go’da False Positive Azalması
Bir de şu var: go/unhandled-writable-file-close sorgusu daha akıllı davranıyor artık. Sync çağrısından sonraki deferred Close’u uyarı olarak saymıyor. Peki bunu neden söylüyorum? Küçük gibi dürüyor ama moral bozucu false positive’leri azaltması açısından iyi olmuş doğrusu. Node Readiness Controller: Kubernetes’te Ready’nin Ötesi yazımızda bu konuya da değinmiştik.
Python ve Swift Ayrıntıları
Python tarafında py/modification-of-locals, scope dışına çıkmış locals() sözlüğünün değişikliklerini artık gürültü diye işaretlemiyor. Swift’te işe CryptoKit modellemesi elden geçirilmiş; swift/weak-sensitive-data-hashing ve swift/weak-password-hashing sorguları daha fazla sonuç yakalayabiliyor.
SSRF ve IPv6 Geçiş Adresleri: Deneysel Ama Kritik
Denenmiş başka bir sorgu daha var: javascript/ssrf-ipv6-transition-incomplete-guard. Konu şu; SSRF önlemi koyarken “private IPv4 aralıklarını engelliyorum” diyorsunuz ya (10.x, 192.168.x, 172.16-31.x gibi), işte IPv6 transition adresleriyle aynı hedefe yine ulaşılabiliyor olabilir.
::ffff:10.0.0.1
Evet.
Aslında, Eğer guard bunu görmüyorsa bypass olur. Agent Skills for .NET Kararlı Sürümde: Uzmanlık Artık Paketli yazımızda bu konuya da değinmiştik.
Yeni bir servis yazıyorsanız mümkünse baştan allowlist tarafına geçin.
GitHub Actions Sorgularında Ince Ayarlar
actions/pr-on-self-hosted-runner sorgusu güncel standard runner label’larını tanıyacak şekilde güncellenmiş.actions/untrusted-checkout/medium sorgusunun adı ve açıklaması da düzeltilmiş ; nonprivileged context için geçerli olduğu daha net anlatılıyor.
Bu tip değişiklikler dışarıdan bakınca önemsiz gibi dürüyor, ama değil. Aksine, DevSecOps ekiplerinin en çok zaman yediği konu “bu alert doğru mu yanlış mı” tartışması. False positive azalınca, ekibin alert’lere olan güveni artıyor. Ben bunu Innersource Security Advisories GA: Kurum Içi Zafiyet Yönetimi yazımda da uzunca anlatmıştım.
Türkiye Perspektifi : Kurumlarda CodeQL Ne Durumda?
Açık konuşayım : Türkiye’de CodeQL kullanımı hâlâ nispeten dar bir kitlede. Bankalar Fortify veya Checkmarx’a yatırım yaptığı için oralara bağlı kalıyor. Küçük startup’lar işe GitHub Advanced Security lisansını ödemek istemiyor. Ortada kalan orta ölçekli teknoloji şirketleri, yazılım evleri ve GitHub Enterprise Cloud’a geçmiş bazı kurumlar CodeQL’i aktif kullanıyor. vcpkg Haziran 2026: Cache Atlama, OHOS ve 2.849 Port Hazır yazımızda bu konuya da değinmiştik. Daha fazla bilgi için Deutsche Telekom OpenAI ile Telekomu Baştan Kuruyor yazımıza bakabilirsiniz.
Peki bu sürümün Türkiye açısından pratik değeri ne ? Bence şu : AI entegrasyonu yapan her ekibin artık prompt injection için otomatik bir kontrol katmanı var. Bir bankanın müşteri hizmetleri botu, bir e-ticaret sitesinin ürün öneri motoru, bir sağlık uygulamasının semptom sorgulama arayüzü… hepsi risk altında. Şu an sahada gördüğüm kadarıyla bu ekiplerin çoğu prompt injection için ne düzgün bir threat model çıkarmış ne de buna özel bir kontrol yazmış (şaşırtıcı ama gerçek). En azından statik tarama tarafında bir başlangıç noktası olması, sıfırdan iyidir. Daha fazla bilgi için Visual Studio Haziran Güncellemesi: Kullanım, Güven ve C++ Ajanı yazımıza bakabilirsiniz.
Bütçe Kısıtlıysa Ne Yapmalı?
Şöyle söyleyeyim, GHAS lisansı Türk lirası bazında ciddi bir kalem ; bunu inkâr etmeye gerek yok. Küçük bir ekipseniz ve GHAS almadan CodeQL kullanmak istiyorsanız :
- Public repository işe CodeQL zaten ücretsiz. Açık kaynak projelerinizde hemen açabilirsiniz. — ciddi fark yaratıyor
- CodeQL CLI’yi lokal olarak çalıştırıp haftalık rapor üretebilirsiniz ; GitHub Actions olmadan da olur. — bunu es geçmeyin
- Sadece kritik pathleri tarayın — bütün repo yerine AI SDK’larıyla konuşan modülleri seçin.
Açıkçası, Bu üçüncü madde önemli. Tüm monorepo’yu her PR’da taramak CI dakikası yer bitirir. Konfigürasyonda paths . paths-ignore kullanarak taramayı daraltmak hem hız hem maliyet açısından işe yarar. FinOps tarafından bakınca, böyle ince ayarlar bazen ay sonunda şaşırtıcı tasarruf çıkarabiliyor. Detaylı bakış isterseniz Azure IaaS Maliyet Optimizasyonu: Sahadan FinOps Notları yazıma göz atabilirsiniz — orada CI maliyetlerine de değinmiştim.
Karşılaştırma : Klasik SAST vs AI-Aware SAST
| Kriter | Klasik SAST | AI-Aware SAST (CodeQL 2.26+) |
|---|---|---|
| SQL Injection | ✅ Yakalıyor | ✅ Yakalıyor |
| PROMPT Injection) | ||
| PROMPT Injection} |
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder