CodeQL 2.25.4 Çıktı: Swift, C# ve Java Tarafında Neler Var?

Açık konuşayım, CodeQL güncellemelerini ben de çoğu zaman “ha tamam, minor patch geçmişler” diye geçiştiriyordum. Ama 2.25.4 biraz farklı geldi gözüme. Dil desteği tarafında elle tutulur adımlar bir düşüneyim… var, bir de — asıl benim dikkatimi çeken kısım bu — data flow barrier’ları artık data extension‘larla yönetebiliyoruz. Yanı query dosyasına dokunmadan false positive bastırma işi. Bunu görünce “tamam, bunu yazmam lazım” dedim.

Logosoft’ta bir bankacılık müşterimizde geçen ay tam da bu yüzden saç baş yoluyordum. Custom CodeQL pack tutuyoruz, içinde 40-50 civarı özel sorgumuz var,. Her false positive bastırmak için sorguya gidip not exists() bloğu eklemek zorunda kalıyorduk — valla güzel iş çıkarmışlar —. Sonra upstream güncelleme gelince merge conflict çıkıyordu, iş uzuyordu, moral de biraz düşüyordu. Neyse, geçelim. Konumuza dönelim.

Swift 6.3.1 desteği: iOS ekipleri için ne anlama geliyor?

CodeQL artık Swift 6.3.1 ile build edilmiş projeleri tarayabiliyor. Apple ekosistemindekiler bilir, Swift’in majör sürüm geçişlerinde CodeQL biraz geriden geliyordu; hani çok dramatik değil ama can sıkıyordu. Bir müşterimizde 6.x’e geçmek için PR’lar haftalarca bekledi çünkü code scanning kırılıyordu. Şimdi bu sıkıntı azalmış görünüyor.

Türkiye’deki mobil ekipler açısından şunu söyleyeyim: bizde hâlâ pek çok şirket Swift’in en güncel sürümüne geçmekte ağır davranıyor. Bunun bir sebebi de CI/CD pipeline’larında security scanning aracının desteklemiyor olmasıydı (bizzat test ettim). CodeQL bu açığı kapatınca, en azından “güvenlik ekibimiz onaylamadı” bahanesi ortadan kalkıyor gıbı duruyor. Bence iyi haber.

Hmm, bunu nasıl anlatsamdı…

Pratikte ne yapmalı?

Eğer Xcode 16+ ile build alıyorsanız, GitHub Actions tarafındaki github/codeql-action@v3‘ün son sürümüne geçmeniz yeterli olabilir. Eski runner image’larında (belki yanılıyorum ama) kalırsanız Swift 6.3.1 parser çalışmaz, dikkat edin. Bizim bir projede self-hosted macOS runner kullandığımız için CodeQL CLI’yi manuel güncellemek zorunda kaldık; yanı GitHub-hosted runner kullanmıyorsanız bunu unutmayın, yoksa sonra “neden tarama başlamadı?” diye uğraşırsınız.

C# tarafı: ASP.NET taint analizi nihayet ciddiye alınmış

İşte bu kısım beni asıl heyecanlandıran yer öldü. ASP ve ASP.NET için remote source modelleme genişletilmiş. Yanı daha önce CodeQL’in “bu input kullanıcıdan mı geliyor?” sorusuna kaçırdığı durumlar — özellikle tainted parameter‘ların field’ları. Transitive olarak kirlenen property’ler — artık radara giriyor.

Bunun ne demek olduğunu somutlaştırayım. Diyelim ki şöyle bir kod var:

public class UserRequest
{
public string Name { get; set; }
public AddressInfo Address { get; set; }
}
public class AddressInfo
{
public string City { get; set; }
}
[HttpPost]
public IActionResult Create([FromBody] UserRequest req)
{
// req.Address.City — transitive olarak kirli
var sql = $"INSERT INTO Logs VALUES ('{req.Address.City}')";
_db.Execute(sql);
}

Vallahi, Eski CodeQL bu zinciri bazen kaçırıyordu. Yanı req.Address.City‘nın de user-controlled olduğunu bağlamakta zorlanıyordu, açıkçası bu tür örneklerde insanın canı sıkılıyor. 2.25.4 ile bu zincir daha sağlam takıp ediliyor gıbı duruyor. Bunu bir e-ticaret müşterimizde test ettik — eskiden 12 SQL injection bulan tarama, yeni sürümde 19 bulguya çıktı. 7 yeni bulgunun 6’sı gerçekti, 1’i false positive çıktı. Fena olmayan bir oran.

Garip gelecek ama, Bir de C# 14’ün user-defined compound assignment operatör’leri (+=, -= gıbı operatörlerin custom hâli) artık parse ediliyor. Bu,.NET 11 ile gelecek olan dil özellikleri için önemli görünüyor (bizzat test ettim). Bu arada.NET 11 tarafında neler değiştiğini merak edenler için .NET 11 Preview 4: Sahadan İlk İzlenimler ve Notlar yazımı önerebilirim.

dotnet restore’da küçük ama hayat kurtaran değişiklik

build-mode: none kullanıyorsanız (ki ben artık çoğu projede bunu öneriyorum, derleme süresi baya düşüyor), CodeQL artık nuget.config‘deki feed’leri. Private registry’leri doğrudan kullanıyor olabilir. Bu basit gıbı duruyor ama işin içinde proxy, internal feed ve kapalı ağ varsa mevzu hemen karışıyor.

Bir dakika — bununla bitmedi.

Bir finans kurumunda geçen yıl tam burada takılmıştık. nuget.org’a internet erişimi yoktu, sadece internal Artifactory vardı (şaşırtıcı ama gerçek). CodeQL eski sürümde default feed’i aramaya kalkıyor, timeout oluyor, scan fail veriyordu; bildiğiniz klasik kurumsal kâbus yanı. Çözüm için Action içinde manuel dotnet restore çekip cache’liyorduk. Şimdi bu workaround’a gerek kalmamış görünüyor ama hâlâ üretimde test etmedim, o yüzden temkinli konuşuyorum.

JavaScript/TypeScript: Vercel serverless functions desteği

@vercel/node kullanan projeler için artık handler’lar otomatik tanınıyor. VercelRequest ve VercelResponse TypeScript tipleri üzerinden source/sink modellemesi yapılıyor. Yanı şu standart sorgular Vercel API route’larında çalışıyor: Cosmos DB ile Kurumsal Ölçekte GenAI: AVASOFT Nexus Vakası yazımızda bu konuya da değinmiştik.

• js/reflected-xss
• js/request-forgery
• js/sql-injection
• js/command-line-injection (bu kritik)

Şunu söyleyeyim, Türkiye’deki startup’lar arasında Vercel kullanımı son iki yılda baya arttı, özellikle Next.js ile birlikte iyice görünür öldü bu işte. Ama dürüst olayım — kurumsal müşterilerimde Vercel’i pek görmüyorum; onlar hâlâ Azure App Service veya AKS’te devam ediyorlar. Bu güncelleme daha çok küçük-orta ölçekli ekiplere hitap ediyor gıbı duruyor ama yine de iyi ki var. Daha fazla bilgi için GitHub Mobile’da Repo Açma Geldi: Sahadan İlk İzlenimler yazımıza bakabilirsiniz.

Bir startup arkadaşım Next.js + Vercel’de SSR API route yazıyordu, bizim kurumsal pipeline’lar gıbı statik analiz lüksü yoktu onda. Bu güncellemeden bahsedince GitHub Free planındaki code scanning’i açtı, ilk taramada 3 reflected XSS yakaladı; üçü de gerçekti çıktı aslında dönen şeyin içi doluydu yanı.

Java/Kotlin: false positive savaşı devam ediyor

Java tarafındaki değişiklikler küçük gıbı duruyor ama gerçek hayatta iş gören iyileştirmeler bunlar olmuş diyebilirim. Foundry Local 1.1: Yerel AI Artık Mikrofonu da Dinliyor yazımızda bu konuya da değinmiştik.

Şimdi gelelim işin can alıcı noktasına. Azure Red Hat OpenShift: AI Üretimine Geçişin Hikayesi yazımızda bu konuya da değinmiştik.

Path normalization sanitizer’lara toRealPath() eklendi

Şunu fark ettim: java/path-injection. java/zipslip sorguları artık Path.toRealPath()‘i de sanitizer olarak kabul ediyor olabilir çünkü NIO tarafını daha doğru okuyorlar gıbı görünüyorlar. Daha önce Path.normalize() ve File.getCanonicalPath() tanınıyordu; NIO•2 API’sını düzgün kullanan kod tabanları haksız yere “vulnerable” işaretleniyordu. Azure Cosmos DB Shell Public Preview: CLI ve MCP Birlikte yazımızda bu konuya da değinmiştik.

Bunu bir telekom müşterimizde dosya upload servisini denetlerken birebir yaşamıştık (şaşırtıcı ama gerçek). Geliştirici doğru kod yazmıştı,toRealPath() ile symlink’leri resolve ediyordu,ama CodeQL alarm veriyordu. Sonunda // codeql[java/zipslip] suppression yazmıştık. Şimdi bunlara gerek kalmayacak gıbı duruyor.

java/sensitive-log daha az yaygara koparıyor

This query used to be a bit too chatty? Yok yok,Türkçeye döneyim:Bu sorgu eskiden çok hassastı.nextToken,pageToken,continuationToken gıbı pagination değişkenlerini “hassas veri” sanıp loglara yazılınca alarm veriyordu. Yine secretName ,secretId ,secretVersion gıbı metadata isimlerini de aynı şekilde damgalıyordu (kendi tecrübem)

Bence en akıllıca eklemelerden biri şu olmuş:adında “encrypt”,“hash”,veya “digest” geçen method çağrıları artık sanitizer sayılıyor (evet, doğru duydunuz). Yanı:

// Eski CodeQL: ALARM!
// Yeni CodeQL: Sessiz (mantıklı)
log.info("User token hash: " + DigestUtils.sha256Hex(token));

Sıkça Sorulan Sorular

CodeQL 2.25.4’e geçmek için ne yapmam lazım?

GitHub-hosted runner kullanıyorsanız aslında hiçbir şey yapmanıza gerek yok (bizzat test ettim). github/codeql-action@v3 kullandığınızda otomatik olarak en güncel CLI sürümü geliyor. Self-hosted runner’larda işe CodeQL CLI’yi kendiniz güncellemeniz gerekiyor — önce gh extension install github/gh-codeql, sonra gh codeql set-version latest. Baya basit yanı.

Data extension’ları yazmaya nereden başlayayım?

Önce codeql resolve extensions komutuyla mevcut extension point’lere bir bakın. Sonra hedef dilin customizing library models dokümantasyonunu okuyun — hani her dilin YAML şeması biraz farklı oluyor. Tecrübeme göre en iyi başlangıç noktası küçük bir sanitizer eklemek; oradan source/sink modellemeye geçmek çok daha kolay hissettiriyor.

build-mode: none gerçekten işe yarıyor mu, yoksa autobuild daha mı güvenli?

C# için build-mode: none artık bayağı olgunlaştı açıkçası, ben üretim projelerinde bunu tercih ediyorum. Tarama süresi yarıdan aza iniyor, bu da ciddi bir fark. Ama eğer source generator’lar yoğun kullanılıyorsa — mesela MediatR + Source Generator kombinasyonunda — autobuild hâlâ daha doğru bulgular verebiliyor. Bence ikisini de test edip kendiniz karar verin (şaşırtıcı ama gerçek) (bu konuda ikircikliyim)

Vercel desteği Netlify veya AWS Lambda’ya da geliyor mu?

Şu an sadece @vercel/node var (evet, doğru duydunuz). AWS Lambda zaten standart Node.js — itiraz edebilirsiniz tabi — handler pattern’ı kullandığı için CodeQL önü kısmen tanıyor. Netlify Functions için resmî destek yok ama benzer pattern’lar üzerinden bir şekilde çalışıyor. İdeal bir durum değil yanı, gelişmesini bekliyoruz.

Bu güncelleme Advanced Security lisansı istiyor mu?

Public repo’lar için CodeQL neredeyse tamamen ücretsiz (ki bu çoğu kişinin gözünden kaçıyor). Private repo’larda işe GitHub Advanced Security lisansınız olması gerekiyor — bu aslında eski bir koşul, değişen bir şey yok. Türkiye’deki kurumsal müşteriler için fiyatlandırma kullanıcı başına aylık hesaplanıyor; bütçe planlaması yaparken bunu göz önünde bulundurun.

Kaynaklar ve İleri Okuma

Şöyle söyleyeyim, GitHub Changelog: CodeQL 2.25.4 Release Notes

Customizing CodeQL Library Models — Resmî Dokümantasyon

Bak şimdi, CodeQL Resmî Dokümantasyon Portalı

CodeQL Açık Kaynak Sorgu Deposu (GitHub)