Uygulama Güvenliği

CodeQL 2.26.4: GitHub Actions Kontrolleri ve Yeni Bulgular Nasıl Değerlendirilmeli?

← Tüm yazılara dön

CodeQL 2.26.4: GitHub Actions Kontrolleri ve Yeni Bulgular Nasıl Değerlendirilmeli?

CodeQL 2.26.4 ile değişen Actions denetimleri, Rust bulgu konumları ve uygulama modelleri için güvenlik ekiplerine doğrulama rehberi.

Sürüm ve duyuru tarihi

GitHub, 3 Eylül 2026’da yayımladığı duyuruda CodeQL 2.26.4’ün güvenlik analizi iyileştirmelerini açıkladı. Ayrıntılı sürüm kaydı 26 Ağustos 2026 tarihini taşıyor; dolayısıyla ürünün sürüm tarihi ile duyurunun tarihi birbirinden ayrılmalıdır.

CodeQL, kaynak kodu ve veri akışını inceleyerek güvenlik bulguları üreten statik analiz motorudur. Yeni sürüm sonrasında değişen sonuçlar yalnızca kod değişikliğinden değil, analiz modelinin daha doğru hale gelmesinden de kaynaklanabilir.

Actions denetimlerinde ne değişti?

Olay yükünden okunan kullanıcı alanları üzerindeki kontroller, artık yalnızca ilgili alanı gerçekten dolduran olaylarda koruma olarak kabul ediliyor. Ayrıca actions/unpinned-tag sorgusu, yeniden kullanılabilir iş akışlarındaki değiştirilebilir referansları da saptıyor.

Bu değişiklikler bazı depolarda daha fazla uyarı görülmesine yol açabilir. Ekipler uyarıları topluca susturmak yerine tetikleyici olayın yapısını, yetki sınırlarını ve çağrılan iş akışının nasıl sabitlendiğini incelemelidir.

  • Olay türü ile kontrol edilen kullanıcı alanının uyumunu doğrulayın.
  • Yeniden kullanılabilir iş akışı referanslarını gözden geçirin.
  • Yüksek yetkili işlerde dış girdilerin hangi adımlara ulaştığını inceleyin.
  • Yeni bulguları mevcut istisna kayıtlarıyla eşleştirin.

Rust bulgularında görünen hareketlilik

Rust veri akışı sorgularında bulgu konumları gerçek kaynak ve hedef düğümlerine göre daha hassas gösteriliyor. GitHub, bazı eski uyarıların kapanıp yeni konumda tekrar ortaya çıkabileceğini özellikle belirtiyor.

Bu nedenle aynı gün görülen kapanış ve açılış artışını otomatik olarak güvenlik iyileşmesi veya yeni zafiyet dalgası diye yorumlamayın. Sorgu kimliği, veri akışı, dosya ve kod değişikliklerini birlikte karşılaştırarak yeniden konumlanan bulguları ayırın.

Dil ve çerçeve kapsamı

Sürüm Go 1.27 desteği ekliyor; Java ve Kotlin tarafında Spring R2DBC ve R2DBC SPI için SQL enjeksiyonu hedef modellerini genişletiyor. Python liste işlemlerinde veri akışı ve C# sorgularında doğruluk iyileştirmeleri de bulunuyor.

Bu yeniliklerin kuruluşunuza etkisi kullandığınız teknolojiye bağlıdır. Güvenlik ekibi, ilgili çerçeveleri kullanan depoları seçerek yeni analizin gerçekten çalıştığını ve beklenen dosyaları kapsadığını doğrulamalıdır.

Temiz tarama sonucu, uygulamanın bütünüyle güvenli olduğunu kanıtlamaz. Statik analiz; bağımlılık denetimi, yetkilendirme testleri, kod incelemesi ve çalışma zamanı kontrolleriyle birlikte değerlendirilmelidir.

Kontrollü değerlendirme planı

Önce temsili birkaç depoda önceki sonuçları kaydedin ve aynı kod revizyonunu yeni analizle karşılaştırın. Böylece kod değişiklikleriyle analiz motorunun etkisini ayırabilirsiniz.

GitHub.com üzerindeki code scanning kullanıcılarına yeni CodeQL sürümleri otomatik dağıtılıyor. GitHub Enterprise Server kullanıcıları ise kendi sürüm ve yapılandırmalarına uygun yükseltme yolunu ayrıca değerlendirmelidir.

  1. Analiz sürümünü ve sorgu paketlerini kaydedin.
  2. Aynı kod revizyonunda önceki ve yeni sonuçları karşılaştırın.
  3. Gerçek yeni riskleri yeniden konumlanan bulgulardan ayırın.
  4. Doğrulanmış sorunları sorumlu ekibe ve çözüm tarihine bağlayın.

Raporlama ve kapanış

Güvenlik panosunda bulgu sayısının yanına analiz sürümü değişikliğini not edin. Aksi halde yöneticiler yalnızca sayıdaki artışa bakarak yanlış bir risk değerlendirmesi yapabilir.

Kapanış için taramanın başarılı olması, kapsamın doğru bulunması ve önemli yeni bulguların incelenmesi gerekir. Gerçek düzeltme, yanlış pozitif ve kabul edilen risk kararları ayrı gerekçelerle belgelenmelidir.

Kaynaklar

OKUMAYA DEVAM EDİN

Uygulama Güvenliği kategorisi →