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.
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 |
| 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) Daha fazla bilgi için
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.
3 comments