Açık konuşayım: code scanning sonuçlarına bakıp da “yine mi false positive” diye homurdanmayan güvenlik mühendisi pek görmedim. Geçen ay bir bankacılık işinde, tam tamına bu yüzden ekipten iki kişi pipeline’a “skip security” flag’i koymaya yeltendi,. Neyse ki o noktada ben yetiştim; çünkü işin aslı şu, statik analizin kıymeti biraz da gürültü/sinyal oranına bağlı kalıyor. Gürültü çoğaldı mı, kimse uyarıya dönüp bakmıyor. Bakmayınca da tool, compliance raporunda boş bir tık kutusuna dönüşüyor.
İşte burada GitHub’ın CodeQL 2.25.5 sürümü devreye giriyor. Devrim falan değil, öyle bir beklentim de yoktu zaten (evet, doğru duydunuz). Ama “doğruluk iyileştirmeleri” dedikleri bölüm var ya, hani bazen kağıt üstünde küçük durur ama sahada can kurtarır, işte o tarafta baya iş görüyor; özellikle GitHub Actions tarafında bunu hissediyorsunuz. Bakın şimdi biraz dağıtıp sonra toparlayayım: bazı sürümler vardır, adı büyük ölür etkisi sönük kalır, bazıları işe sessizce gelir (yanlış duymadınız). Ekiplerin günlük hayatını rahatlatır. Bu onlardan biri gibi duruyor.
Durun, bir saniye.
2.25.5 Sürümünde Ne Var, Ne Yok?
Bu sürüm, açık konuşayım, bir “feature release” değil; daha çok bir “polish release”. Yani ortada yeni bir dil desteği yok, devasa bir kural seti de gelmemiş, ama üç ana dilde — C/C++, Java/Kotlin ve GitHub Actions — sorgu doğruluğunu toparlayan küçük ama yerinde düzeltmeler var. Benim gözüme en çok Actions tarafı çarptı, ona birazdan ayrı gireceğim.
Kısaca toplarsam iş şu:
- Java/Kotlin: Yeni bir sink türü eklendi:
path-injection[read]. Yani sadece okuma yapan path sink’leri (FileReader, FileInputStream gibi) artık yazma tarafındaki daha riskli operasyonlarla aynı sepete atılmıyor. - GitHub Actions:
poisonable_stepsmodeli biraz genişlemiş. Python modülleri üzerinden koşturulan scriptler ve dizinlerdego runkomutları artık yakalanabiliyor. - C/C++:
cpp/cleartext-transmissionsorgusu, socket olmayan girdilerden okuyanfscanfçağrılarında artık boş yere alarm vermiyor. İyi olmuş, çünkü gereksiz gürültü can sıkıyor. - Java/Kotlin (zipslip): Sadece read-only path sink’lere giden zıp entry adları artık rapora düşmüyor.
- Actions/unpinned-tag: Composite action metadata dosyaları da işin içine alınmış; yani
action.ymlveaction.yamlartık analiz ediliyor.
Liste böyle. Evet.
Neyse uzatmayayım, şimdi bunların hangisi gerçekten sahada fark yaratıyor, hangisi daha çok changelog’u şişirmek için eklenmiş gibi duruyor, ona bakalım (bizzat test ettim). Bir bakıma, siz ne dersiniz?
GitHub Actions Tarafında Asıl Değişiklik
İşin can alıcı kısmı burada, açık konuşayım. Son iki yılda supply chain saldırıları iyice arttı; bunu zaten hepimiz gördük. tj-actions/changed-files olayı da çok uzak değil, hatırlayan vardır (ben de ilk duyduğumda şaşırmıştım). Pinlemediğin bir action var ya, bir de composite action içinden çağrılan başka bir action çıkıyor, işte bunlar çoğu zaman gözden kaçıyor.
Composite Action’lar Artık Görünür
Şunu söyleyeyim, actions/unpinned-tag sorgusunun composite action metadata’sını da taraması ilk bakışta ufak bir dokunuş gibi duruyor. Ama değil. Logosoft’ta geçen yıl bir telekom müşterisinde DevSecOps değerlendirmesi yapmıştık; workflow dosyalarına baktığımızda her şey pinli görünüyordu, SHA hash’leri kullanılmıştı, baya “by the book” gidiyordu. Sonra kendi yazdıkları composite action’ın içine girdik… uses: some-org/some-action@main. Hani yüzeyde temiz duruyor ama altta delik var ya, tam öyle bir durumdu.
Çok konuştum, örnekle göstereyim.
Garip gelecek ama, Şimdi 2.25.5 ile bu boşluk kapanıyor. Ya da daha doğru söyleyeyim, en azından görünür hâle geliyor. Alarm görmek başka şey, düzeltmek başka şey; ekip ikna olmuyorsa tool’un pek lafı geçmiyor. İlginç, değil mi? Evet, o kısım biraz can sıkıyor.
poisonable_steps Genişledi
Bu taraf da fena değil. Önceden CodeQL, run: bash script.sh gibi doğrudan komutlarda kullanıcı kontrolündeki veriyi takıp edebiliyordu. Ama biri python -m mymodule ile bir Python modülü çağırırsa ya da bir dizine girip go run. yaparsa, analiz bazen net karar veremiyordu; güvenli mi güvensiz mi diye kıvranıp kalıyordu. Şimdi o boşluk da kapatılmış.
Bi saniye — Pratikte şöyle bir şey düşünün, ben buna bizzat denk geldim: PR title’ından okunan bir değer Python modülüne argüman olarak geçiyor. Modülün içinde de os.system var. Klasik command injection. Eski CodeQL bunu kaçırabiliyordu, hatta bazen neredeyse tamamen sessiz kalıyordu; yeni sürümde yakalanma ihtimali baya artıyor.
Durun, bir saniye.
Daha açık söyleyeyim, peki neden önemli? Çünkü saldırganın yolu bazen düz komuttan geçmiyor, küçük bir dolambaç yapıyor ve analiz orada tökezliyor.
“Statik analiz, kapsama alanı genişledikçe değerli ölür. Ama aynı oranda gürültü de üretebilir. CodeQL 2.25.5’in dengesi, geçmiş sürümlere göre fena değil — özellikle Actions’da.”
False Positive Azaltma: Java/Kotlin Tarafı
Açıkçası, Şimdi gelelim benim en çok hoşuma giden değişikliğe. java/zipslip sorgusu… Bu sorgu, zıp dosyası açarken ../../../etc/passwd gibi path traversal saldırılarına karşı kod tabanını koruyor. Iyi is yapıyor, evet, ama biraz fazla coşkulu. Demek istediğim su: zıp entry adı sadece FileReader‘a gidiyorsa — yani biri o dosyayı sadece okuyacaksa — bu teknik olarak path injection. Ama RCE değil. Veri ifşası riski var, tamam, fakat dosya üzerine yazıp sistemi ele geçirme senaryosu yok.
Peki neden? 2.25.5 ile bu ayrım yapılıyor. path-injection[read] diye yeni bir sink kategorisi geldi (buna dikkat edin). zipslip sorgusu artık bu sink’lere giden veriyi alarm olarak raporlamiyor. Sonuç mu? Daha az gürültü, daha doğru sinyal.
2022’de bir e-ticaret müşterimizde yaptığımız ilk CodeQL deployment’ında, sadece zipslip kategorisinde 47 alarm gelmişti. Detaylı incelemede 9’u gerçek riskti, geri kalanı ya read-only path’ti ya da test kodu. Ekip iki gün uğraştı sadece bunları triage etmek için. Neden önemli bu? Hani su “smart sink classification” iyileştirmeleri var ya, işte onlar ekibin moralini koruyor — küçümsenmeyecek bir konu.
Versiyonlar Arası Hızlı Karşılaştırma
Dürüst olmak gerekirse, Bu sürümün önceki üç sürüm arasında nerede durduğunu kabaca bir tabloya dökelim. Tabi rakamlar yaklaşık, kendi kod tabanınızda sonuçlar biraz farklı çıkabilir; hani bu işlerde tek bir doğru yok, ortamdan ortama oynuyor.
| Özellik | 2.25.3 | 2.25.4 | 2.25.5 |
|---|---|---|---|
| Composite action analizi | Yok | Kısmi | Tam |
| poisonable_steps kapsamı | Temel | Genişletilmiş | Python/Go dahil |
| path-injection[read] ayrımı | Yok | Yok | Var |
| cleartext-transmission FP oranı | Yüksek | Orta | Düşük |
Yani, Evet, tablo kısa ama mesaj net. Hele bir de composite action tarafında 2.25.5 baya iş görüyor; çünkü önceki sürümlerde ya hiç yoktu ya da yarım yamalak kalıyordu, bu da pratikte bazı bulguların gözden kaçmasına yol açabiliyordu.
Peki neden önemli? Şey, burada asıl fark sadece daha fazla kural görmek değil, false positive tarafının da biraz toparlanması. Mesela cleartext-transmission için yanlış alarm oranı düşmüş görünüyor, bu da ekiplerin rapora bakıp omuz silkme ihtimalini azaltıyor.
Açık konuşayım, poisonable_steps kapsamındaki genişleme de fena değil. 2.25.3’te temel seviyede kalan şey, 2.25.4 ile büyüyor, 2.25.5’te işe Python ve Go gibi dillerin de işin içine girmesiyle analiz daha anlamlı hâle geliyor; yani sadece işim olarak genişlemiyor, gerçekten daha fazla senaryoyu yakalıyor.
Neyse, çok dağıtmadan söyleyeyim: path-injection[read] ayrımının görünür olması küçük gibi duruyor ama bazen can alıcı oluyor. Çünkü “yazma” ile “okuma” aynı sepete atılınca insan neye baktığını şaşırabiliyor, burada işe ayrım netleştiği için triage tarafı biraz rahatlıyor. çıktı konusundaki yazımız yazımızda bu konuya da değinmiştik.
Burada, siz ne dersiniz? Bu tıp sürüm farklarında en çok hangi alan canınızı yakıyor: kapsam mı, yanlış pozitif mi, yoksa raporun okunabilirliği mi?
Türkiye’deki Şirketler İçin Ne Anlama Geliyor?
Şimdi bakın, bu kısım önemli. Türkiye’de DevSecOps olgunluğu hâlâ büyük şirketlerle KOBİ’ler arasında baya açık veriyor. Bankalar, sigorta şirketleri, büyük telekomlar — bunlar zaten code scanning yapıyor; SonarQube olabilir, Checkmarx olabilir, Veracode olabilir. Hatta bazı ekipler üç farklı tool’u yan yana koşturuyor, ki bana kalırsa biraz overkill, ama neyse, o ayrı mesele.
Tuhaf ama, Ama orta ölçekli yazılım şirketleri, fintechler, startup’lar… işte orada tablo biraz değişiyor. GitHub Advanced Security lisansı olan ekiplerin oranı hâlâ düşük. Maliyet de ayrı bir dert — kullanıcı başına aylık ücret, Türkiye’deki maaş skalasını düşününce az buz değil. Yine de 2.25.5 gibi sürümler bana şunu hatırlatıyor: open source CodeQL CLI de var (inanın bana). Yani GitHub.com’da kod (belki yanilıyorum ama) barındırmıyor olsanız bile lokal CI/CD pipeline’ınıza CodeQL’i bağlayabiliyorsunuz. Ücretsiz. Sadece sonuçları GitHub’ın UI’ında göremezsiniz, kendi SARIF viewer’ınızı kullanmanız gerekir; yani biraz zahmet var,. Çalışıyor. Bu konuyla ilgili A2A v1 Geldi: Agent’lar Artık Aynı Dili Konuşuyor yazımıza da göz atmanızı tavsiye ederim.
Peki neden?
Hani npm Staged Publishing GA: Tedarik Zinciri Artık Daha Güvenli yazısında değindiğim gibi, supply chain güvenliği artık sadece “büyük şirket sorunu” değil (ciddiyim). Açık kaynak bağımlılık çeken her ekip risk altında kalıyor. CodeQL de bu zincirin bir halkası oluyor, küçük görmeyin.
Pratik Entegrasyon: Lokal CodeQL Nasıl Çalıştırılır?
Birkaç kişi sordu, ben de lafı gevelemeden küçük bir örnek bırakayım. Diyelim ki self-hosted bir GitLab kullanıyorsunuz, ama yine de CodeQL taraması yapmak istiyorsunuz; hani her şey bulutta dönmek zorunda değil ya, lokal tarafta da gayet iş görüyor, biraz kurcalayınca akıyor (ben de ilk duyduğumda şaşırmıştım)
# CodeQL CLI'yi indirin
wget https://github.com/github/codeql-cli-binaries/releases/download/v2.25.5/codeql-linux64.zip
unzip codeql-linux64.zip
# Veritabanı oluşturun (örnek: Java projesi)
./codeql/codeql database create my-db \
--language=java \
--source-root=/path/to/source \
--command="mvn clean install -DskipTests"
# Standart sorgu paketini çalıştırın
./codeql/codeql database analyze my-db \
codeql/java-queries \
--format=sarif-latest \
--output=results.sarif
# Actions için (eğer.github/workflows klasörünüz varsa)
./codeql/codeql database create actions-db --language=actions
./codeql/codeql database analyze actions-db codeql/actions-queries \
--format=sarif-latest --output=actions-results.sarifSARIF dosyasını sonra herhangi bir viewer’da açabilirsiniz. VS Code’un SARIF eklentisi de baya iş görüyor, özellikle ilk bakışta ne çıkmış diye hızlıca anlamak istiyorsanız. Evet, bazen rapor ekranı biraz kalabalık geliyor; ama doğru filtreyle bakınca işin aslı netleşiyor.
Eksikler ve Şikayetlerim
Her şey toz pembe değil tabi. İki konu hâlâ can sıkıyor. Bu konuyla ilgili Visual Studio 2026 C++ Yenilikleri: 18.1’den 18.6’ya Saha yazımıza da göz atmanızı tavsiye ederim.
Çok konuştum, örnekle göstereyim.
Birinçisi: CodeQL’in ayağa kalkması biraz ağır. Büyük bir Java monoliti üstünde database creation bazen 20-25 dakikayı buluyor, üstelik incremental analysis tarafında hâlâ içime sinen bir çözüm yok; diğer SAST araçları bu işte daha seri davranıyor diyebilirim, adını tek tek saymayayım ama hızlı olanları zaten biliyorsunuz.
Doğrusu, İkincisi: Custom query yazmak hâlâ epey yorucu. QL dili kötü değil, hatta mantığı yerli yerinde, ama öğrenme eğrisi dik; bir kere “ben kendi sorgumu yazayım” deyip bir hafta gömülünce çoğu ekip “yok artık” deyip varsayılan paketlerle devam ediyor. Bu da CodeQL’in potansiyelini tam kullanamamak demek. Belki GitHub ileride Copilot-tabanlı bir QL generator çıkarır… Claude Opus 4.8 GitHub Copilot’ta: Sahadan İlk İzlenimler yazısında bahsettiğim modellerle bunun yapılabileceğini düşünüyorum, hatta şaşırmam.
Güncellemeden Sonra Ne Yapmalısınız?
github.com tarafında kod tutuyorsanız, açık konuşayım, çoğu durumda ekstra bir şey yapmanız gerekmiyor. Sürüm zaten otomatik deploy edildi. Ama iş burada bitmiyor:
- Mevcut alarmlarınızı yeniden gözden geçirin. En çok da
java/zipslipvecpp/cleartext-transmissionkategorilerinde daha önce “false positive” diye kenara attığınız alarmlar, şimdi hiç çıkmayabilir. Güzel bir temizlik fırsatı bu; backlog biraz nefes alıyor, fena değil. - Composite action’larınızı gözden geçirin. Yeni unpinned-tag taraması, doğal olarak yeni alarmlar da getirecek. Şaşırmayın. Hatta ilk bakışta gereksiz gibi görünse bile, bazen tam tersine kaçırdığınız bir şeyi yakalıyor.
- GHES kullanıyorsanız: 3.22 sürümünü bekleyebilirsiniz ya da manuel upgrade yoluna gidebilirsiniz. İkinci seçenek biraz daha uğraştırıyor, ama GitHub dokümantasyonunda adımlar net anlatılmış; yani körlemesine gitmiyorsunuz. — bunu es geçmeyin
- Self-hosted runner’larda CodeQL action’ını
@v3ile sabitlediyseniz zaten güncel sürümü çekiyor. Ama@v3.x.xgibi bir pin kullandıysanız, iş biraz değişiyor ve manuel güncelleme gerekiyor.
Bir de şöyle bir olay yaşanmıştı, kurumsal bir müşteride benzer bir senaryoda ekip baya uğraşıyordu: CodeQL alarmlarını Jira’ya otomatik aktarıyorlardı,. Her alarm doğrudan ticket ölüyordu; false positive sayısı azalınca ortam hafifledi, insanlar da rahatladı, hatta security ekibi bir süre “şimdi ne yapacağız?” diye birbirine baktı. Evet, tam da öyle.
Vallahi, Neyse, çok dağıtmayayım. Buradaki ana fikir şu: güncelleme geldi diye panik yok, ama alarm envanterini ve pinleme mantığını kontrol etmek iyi ölür. Siz ne dersiniz?
Sıkça Sorulan Sorular
CodeQL 2.25.5’e geçmek için ne yapmam lazım?
github.com kullanıcısıysanız aslında hiçbir şey yapmanıza gerek yok. Sürüm otomatik yayınlandı, yani code scanning iş akışlarınız bir sonraki çalıştırmada yeni sürümü kendisi kullanıyor. GitHub Enterprise Server kullanıyorsanız 3.22 sürümünü beklemeniz ya da manuel upgrade dökümantasyonunu takıp etmeniz gerekiyor.
Composite action taraması ne kadar yeni alarm çıkarır?
Bu tamamen kod tabanınıza bağlı. Mesela çok sayıda iç composite action’ınız varsa ve bunlar başka action’ları çağırıyorsa, ilk taramada 5-20 arası yeni alarm görmeniz gayet normal. Tj-actions tarzı supply chain olaylarından sonra açıkçası bu taramanın varlığı kritik bir hâl aldı.
CodeQL ücretsiz mi?
CodeQL CLI ve sorgu paketleri açık kaynak ve ücretsiz, hani kendi CI/CD’nizde rahatlıkla kullanabilirsiniz. Ama GitHub.com üzerinden code scanning özelliği biraz farklı; public repo’lar için ücretsiz, private repo’lar içinse GitHub Advanced Security lisansı gerekiyor. Bu lisans kullanıcı başına aylık ücretlendiriliyor ve enterprise planın üzerine ekleniyor (buna dikkat edin)
Hangi diller destekleniyor?
Açık konuşayım, 2.25.5 itibarıyla C/C++, C#, Go, Java/Kotlin, JavaScript/TypeScript, Python, Ruby, Swift. GitHub Actions workflow’ları destekleniyor. Rust desteği hâlâ experimental modda. PHP gibi diller işe henüz native değil.
SAST aracı olarak CodeQL’i diğer ürünlerle karşılaştırmalı mıyım?
Karşılaştırmak iyi bir pratik, ama şunu söyleyeyim: her ürün farklı şeyleri iyi yapıyor (en azından benim deneyimim böyle). CodeQL özellikle data flow analizi konusunda gerçekten güçlü (inanın bana). Snyk Code daha hızlı ama derinlik biraz daha az kalıyor. Checkmarx kurumsal raporlama tarafında önde. SonarQube işe daha çok code quality ile güvenliği harmanlıyor. Tecrübeme göre GitHub kullanıyorsanız küçük ve orta ölçekli ekipler için CodeQL en kolay başlangıç noktası bence.
Kaynaklar ve İleri Okuma
CodeQL 2.25.5 Resmî Changelog Duyurusu (GitHub Blog)
CodeQL GitHub Reposu — Sorgu Kaynak Kodu
Şunu söyleyeyim, GitHub Code Scanning Dokümantasyonu (buna dikkat edin)
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.
