CodeQL 2.25.6 ile Sessiz Ama Güçlü Güvenlik Sıçraması
Bir güvenlik aracını sevdiren şey çoğu zaman gürültülü özellikler değil, tam tersine sessizce daha çok şeyi görmeye başlamasıdır. CodeQL 2.25.6 de biraz böyle bir sürüm olmuş; Swift 6.3.2 desteği gelmiş, C# 14 ve.NET 10 tarafında kapsam tamamlanmış, üstüne bir de hassas veri tespiti birkaç dilde toparlanmış. Kâğıt üstünde “küçük güncelleme” gibi dürüyor ama pratikte, özellikle kurumsal kod tabanlarında bayağı fark yaratır.
Ben bu tip değişikliklere ilk bakışta hep aynı yerden bakarım: “Bu sürüm bana daha az yanlış pozitif mi verecek, yoksa yeni açıkları daha erken mi yakalayacak?” Çünkü işin aslı şu ki, güvenlik taraması iyi görünmek için değil, gerçekten işe yaradığı için değerli. Geçen yıl İzmir’de bir finans müşterisinde buna benzer bir güncelleme geçişi yaparken gördüm; tarayıcı sürümü değişince ilk hafta alarm sayısı arttı diye herkes biraz gerildi ama iki hafta sonra çıkan gerçek bulguların değeri, o kısa rahatsızlığı fazlasıyla unutturdu.
Neden bu sürüm dikkat çekiyor?
Bakın şimdi, çoğu ekip güvenlik araçlarını ancak bir şey patlayınca konuşuyor (en azından benim deneyimim böyle). Oysa statik analizde asıl kazanç erken uyarıdan geliyor; üretime çıkmadan önce hatayı görmek bazen aylarca sürecek dertten kurtarıyor sizi. CodeQL 2.25.6’nın olayı da biraz burada: yeni dil sürümlerini yakalarken eski sorguları da daha akıllı hâle getiriyor.
Bir dakika — bununla bitmedi.
Swift tarafı önemli çünkü mobil ekipler artık iOS uygulamalarını sadece “uygulama” diye görmüyor; veri sızıntısı riski olan ciddi kurumsal uç noktalar olarak görüyor. Ben 2024’ün son çeyreğinde İstanbul’da bir sağlık yazılımı ekibiyle çalışırken şunu net gördüm: Swift güncellemeleri geldikçe araç zinciri geri kalıyor. Güvenlik ekibi körleşiyor. İşte bu tür destekler o körlüğü azaltıyor.
C# tarafında işe hikâye biraz daha geniş..NET 10 ve C# 14 desteğinin tamamlanması, extractor’ın yeni dil özelliklerini kaçırmaması demek. Az önce X dedim. Aslında Y daha doğru olabilir: burada en hayatı nokta sadece syntax desteği değil, data flow modelinin runtime tarafıyla uyumu. Çünkü modern.NET uygulamalarında asıl mesele yazdığınız koddan çok framework’ün sizin yerinize ürettiği davranışlar oluyor.
Durun, bir saniye.
Swift ve C#: Kurumsalda neden farklı hissediliyor?
Küçük bir startup iseniz Swift desteği size şöyle görünür: “Tamam güzel, devam.” Ama enterprise tarafta bu bambaşka bir şeydir; çünkü mobil uygulamanın arkasında IAM entegrasyonu, cihaz politikaları, loglama katmanı ve bazen de regülasyon baskısı vardır. Bir bankacılık projesinde Ankara’daki ekip arkadaşlarıyla yaptığımız değerlendirmede şunu konuşmuştuk: geliştirici deneyimi iyi olsa bile güvenlik taraması eski dil sürümünü tanımıyorsa risk raporu eksik kalıyor.
C# ve.NET dünyasında durum daha da hassas. Ben AZ-305 sınavına hazırlanırken bile mimarı kararların ne kadar küçük detaylara bağlı olduğunu tekrar görmüştüm; aynı mantık burada da geçerli. Yeni language feature’lar geldiğinde CodeQL’in onları doğru yorumlaması gerekiyor, yoksa ya kaçırıyor ya da saçma alarm üretiyor. İkisi de kötü.
Bir de şu var: kurumsalda kodun büyük kısmı sıfırdan yazılmıyor artık, çoğu yerde generated code var, SDK var, template var… İşte bu yüzden extractor’ın kapsama alanı tamamlandığında fayda hemen hissediliyor. Geliştirici “ben zaten bunu elle yazmadım” dese bile saldırgan umursamaz; açık oradaysa açık odur.
| Alan | Ne değişti? | Bence etkisi |
|---|---|---|
| Swift 6.3.2 | Yeni sürüm analizi eklendi | Mobil güvenlikte kör nokta azalır |
| C# 14 /.NET 10 | Tam kapsam sağlandı | Modern.NET projelerinde daha tutarlı sonuç verir |
| Sensitive data heuristics | Daha iyi desen tanıma geldi | Daha az yanlış pozitif, daha iyi önceliklendirme |
| Actions" data-glossary-term="GitHub Actions">GitHub Actions sorguları | Açıkların konumu güncellendi | Sahiplenme ve triage işi kolaylaşır |
Sorgu tarafındaki değişiklikler niye önemli?
Açık nerede görünüyorsa orada çözülür
Aslında, actions/untrusted-checkout/critical sorgusunun checkout noktasına taşınması bence doğru hamle olmuş. Çünkü sorun kaynakta görünmüyorsa triage yapan kişi gereksiz yere bağlam arıyor demektir — vakit gidiyor, heves gidiyor, sonra kimse bakmıyor bile. Bu değişiklik closed alert’lerin yeniden açılmasına yol açabilir; evet bu biraz can sıkıcı ama dürüst olayım, bazen rahatsız edici olan şey doğrudur (en azından benim deneyimim böyle)
Pinned reference meselesi biraz ince iş
Tuhaf ama, actions/unpinned-tag sorgusunun SHA-256 commit hash’lerini düzgün pinlenmiş saymaya başlaması güzel haber gibi dürüyor ama burada pratik fayda önemli: false positive azalınca ekipler uyarıya daha çok güveniyor. Geçen ay Rotterdam’da çalışan bir SaaS ekibinde tam bunu konuştuk; her yanlış alarm triage kuyruğunu şişiriyordu. Sonunda insanlar uyarıları ciddiye almamaya başlıyordu.
CodeQL’de benim en çok önem verdiğim şey şu: yalnızca daha fazla bulgu üretmesi değil, doğru bulguyu doğru yerde göstermesi.
Yanlış yerden gelen alarm bazen hiç alarmdan daha zararlı oluyor.
Evet!
Bash regex iyileştirmesi küçük ama etkili
Bash regex kontrollerinin alfanumerik kısıtları daha iyi anlaması da sessiz kahramanlardan biri gibi dürüyor.
Mesela komut çıktısını kullanmadan önce doğrulayan script’lerde eskiden yakalanan bazı senaryolar şimdi false positive olmaktan çıkabilir.
Bu tarz iyileştirmeler kullanıcıya gösterişli gelmez. Günlük iş yükünde fark yaratır.
Neyse uzatmayayım; güvenlik mühendisliği biraz da böyledir zaten — az konuşur, çok hata ayıklar.
Sensitive data tespiti neden ayrı bir başlık?
Password veya private data içeren akışları tanımak dışarıdan kolay görünür ama pratikte bayağı kaypak bir iştir.
Kodda “password” kelimesi geçiyor diye alarm vermek yetmez; log’a mı basılıyor, exception’a mı düşüyor, test datası mı yoksa canlı veri mi… bunların ayrımı lazım.
CodeQL’in JS/TS, Python, Swift. Rust için heuristics geliştirmesi tam bu yüzden değerli.
Kendi deneyimimde en zorlanan ekipler genelde ürün ekipleri olmuyor; platform ekipleri oluyor.
Çünkü onlar hem altyapıyı yönetiyor hem standart koyuyor hem de yüzlerce repoya aynı anda söz geçirmek zorunda kalıyor.
2025’in başında Berlin’de görüştüğüm bir platform takım lideri bana aynen şunu söylemişti:
“Bizde sorun açık bulmak değil hocam, açıkların hangisinin gerçekten acil olduğunu anlatmak.”
İşte heuristic iyileştirmeleri bu iletişimi rahatlatıyor.
- Daha az gürültü = daha hızlı triage (bu kritik)
- Daha iyi örüntü tanıma = gerçek riskleri öne alma
- Daha temiz sinyal = geliştirici yorgunluğunu azaltma
- Daha sağlam kapsam = denetim raporlarında boşluk bırakmama
Her şeyi açmak yerine seçerek ilerlemek çoğu zaman daha sağlıklı oluyor.
Bunu Türkiye’deki şirketler açısından nasıl okumalıyız?
Bence Türkiye’deki şirketlerin en büyük avantajı çeviklikleri; en büyük handikapları işe çoğu zaman teknik borcu uzun süre taşıyabilmeleri.
Bu ikisi birleşince statik analiz araçlarına yaklaşım da garipleşiyor:
“Şimdilik geçelim”, “sonra bakarız”, “önce release çıksın”…
Sonra bir bakıyorsunuz ki üç sprint boyunca kimse security scan’e dönmemiş.
Aslında sorun araçta değil kültürde.
İşin garibi, Kurumlarda sık gördüğüm tablo şu:
Enterprise yapıdaysanız CodeQL’i policy ile bağlamak mantıklı,
küçük ekipseniz önce birkaç kritik repo ile başlayıp değerini göstermek daha akıllıca olur.
Mesela fintech tarafında çalışan ekiplerde secrets detection ile başlanabilir;
oyun stüdyosu veya startup tarafında işe public repo hijyeni ve GitHub Actions güvenliği öne çıkar.
Yanı herkese tek reçete yok…
İnanın, Maliyet tarafına gelirsek — TL bazlı düşününce işin rengi değişiyor tabi.
Bugün birçok yönetici lisans maliyetinden çok operasyonel verimlilikle ilgileniyor;
bir saatlik gereksiz triage toplantısı bile can sıkabiliyor.
CodeQL gibi araçlarda yanlış pozitifi düşürmek dolaylı maliyet tasarrufu sağlar,
bunu bütçe dosyasına yazmazsınız belki. Kasa hisseder.
Açık konuşayım:
kurum içi güvenliği ucuzlatmanın yolu her zaman yeni ürün almak değil,
var olan aracı doğru ayarlamak oluyor.
# Örnek yaklaşım
name: CodeQL Security Scan
on:
push:
branches: [ "main" ]
pull_request:
jobs:
analyze:
runs-on: ubuntu-latest
permissions:
security-events: write
contents: read
actions: read
steps:
— name: Checkout
uses: actions/checkout@v4
— name: Initialize CodeQL
uses: github/codeql-action/init@v3
with:
languages: csharp,javascript
— name: Autobuild
uses: github/codeql-action/autobuild@v3
— name: Perform analysis
uses: github/codeql-action/analyze@v3
Ben olsam nasıl ilerlerdim?
Denemek istiyorsanız ilk iş mevcut workflow’unuzu gözden geçirin.
Mesela untrusted checkout ve pinned reference konularına bakın;
sonra sensitive data sorgularını hangi repolarda gerçekten ihtiyacınız varsa oralara açın.
Her repoda her kural aktif olsun demek kulağa disiplin gibi geliyor ama pratikte karmaşa yaratabiliyor.
Eğer GHES kullanıyorsanız eski sürümlerde manuel upgrade ihtimali olduğunu unutmayın;
bu detay bazen gözden kaçıyor. Sonra “github.com’da vardı bizde niye yok?” sorusu geliyor.
Bir müşteride Gebze’de yaşadığımız problem tam buydu,
ekip changelog’u okumuştu ama GHES release planını atlamıştı…
ufak detay dediğiniz şey bazen bütün haftayı yiyebiliyor!
Şahsen, Bence burada asıl kazanım şu:
CodeQL artık sadece “bulgu üreten araç” olmaktan çıkıp,
kod tabanının davranışını biraz daha iyi anlayan bir analiz katmanına dönüşüyor.
Mükemmel mi?
Hayır.
Hâlâ bazı alanlarda ham kalıyor mu?
Net bir şekilde evet.
Ama yön doğru yönde ilerliyor; ben buna not versem geçer not veririm,
hatta güçlü geçer not veririm diyebilirim.
Sıkça Sorulan Sorular
CodeQL 2.25.6 hangi dilleri etkiliyor?
Aslında bu sürüm en çok Swift 6.3.2 ve C# 14 /.NET 10 tarafında işe yarıyor, yanı o cephede ciddi yenilikler var (inanın bana). Bunun yanında Java/Kotlin ile C/C++ için de bazı modelleme iyileştirmeleri geliyor.
false positive sayısı azalır mı?
Evet, azalabilir. Bilhassa hassas veri heuristics’i ve bazı GitHub Actions sorguları bu konuda gerçekten yardımcı oluyor. Ama açıkçası, kullandığınız repo yapısına göre sonuç değişiyor; bence tek seferde mucize beklememek lazım.
GHES kullananlar ne yapmalı?
Eğer GHES’inizde eski bir CodeQL paketi varsa manuel yükseltme gerekebilir. Tecrübeme göre en doğrusu önce mevcut sürümü kontrol edip sonra planlı bir geçiş yapmak; hani aceleye getirince işler sarpa sarıyor.
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