CodeQL 2.26.4 daha fazla Actions riski bulabilir; eski uyarılar taşınabilir

GitHub, 3 Eylül 2026’da CodeQL 2.26.4’ün GitHub Actions güvenlik analizini genişlettiğini ve Rust veri akışı uyarılarının konumlarını hassaslaştırdığını duyurdu. GitHub.com’daki code scanning kullanıcılarına otomatik dağıtılan değişiklikler, bazı depolarda yeni Actions bulguları üretirken mevcut Rust uyarılarının eski konumda kapanıp yeni konumda açılmış görünmesine yol açabilir; GitHub’ın ürün duyurusu iki sonucu da açıkça belirtiyor.

GitHub’ın 3 Eylül 2026 tarihli açıklamasının tarama kuyruğundaki karşılığı üç grupta görülebilir: daha önce saptanmayan bir Actions riski, konumu değişen bir Rust bulgusu veya sorgu doğruluğu arttığı için kapanan bir kayıt. Xebia Tech Hub özeti de güncellemeyi GitHub code scanning’de dil desteğini ve C#, Java/Kotlin ile GitHub Actions sorgularının doğruluğunu etkileyen bir değişiklik olarak kaydediyor.

Yeni bulgu: Actions analizinin kapsamı genişliyor

İlk önemli değişiklik, actions/unpinned-tag sorgusunun yeniden kullanılabilir workflow çağrılarını da incelemesi. Bir workflow başka bir workflow’u tam commit SHA’sı yerine hareket edebilen bir branch veya tag ile çağırıyorsa, aynı referans daha sonra farklı kod çalıştırabilir. Önceki taramada görünmeyen bu durum 2.26.4 sonrasında yeni bir bulgu olarak ortaya çıkabilir.

İkinci değişiklik, olay yükünden okunan aktör alanlarının koruyucu koşul sayılacağı bağlamı daraltıyor. Örneğin github.event.pull_request.user.login kontrolü yalnızca bu alanı gerçekten dolduran olaylarda koruma kabul ediliyor. Aynı koşul, pull request verisi taşımayan bir issues olayı için gerçekte etkisiz olduğundan artık güvenlik bariyeri gibi değerlendirilmiyor.

Bu düzeltme, ControlCheck sınıfını kullanan sorgularda daha fazla sonuç doğurabilir. EnvironmentCheck de models-as-data modeliyle tanımlanabiliyor; eklenen özel model bir ortamı yeterli temizleyici olmaktan çıkarırsa yeni sonuçlar oluşabiliyor. Özel model eklenmediğinde ise bu ikinci mekanizmanın varsayılan davranışı değişmiyor.

Konumu değişen bulgu: Rust kaydı neden yeniden açılmış görünebilir?

Rust tarafında açıklanan değişiklik yeni bir güvenlik sorgusu değil, veri akışı uyarısının gösterildiği yerin hassaslaştırılması. Uyarı konumları artık daha genel bir çağrı ifadesi yerine gerçek kaynak ve hedef düğümlerine dayanıyor. Bu nedenle alttaki veri akışı değişmemiş olsa bile satır veya ifade konumu değişebiliyor.

CodeQL 2.26.4 sürüm günlüğü, sürüm tarihini 26 Ağustos 2026 olarak veriyor ve konumu değişen bazı Rust uyarılarının eskisi kaybolurken yeni uyarı gibi görüneceğini belirtiyor. Günlük ayrıca Rust trait öğelerinin kanonik yolunu crate::Trait::item biçimine geçiriyor; bu öğelere başvuran özel veri uzantısı modellerinin yeni biçime uyarlanması gerekiyor.

Başlıktaki “uyarıların taşınması” bu davranışın operasyonel karşılığıdır: platform eski kaydı aynı kimlikle fiziksel olarak taşımak zorunda değildir; eski konumdaki kayıt kapanıp yeni konumda başka bir kayıt olarak görünebilir. Dolayısıyla yalnızca uyarı kimliğine veya satır numarasına dayanan karşılaştırma, değişmeyen bir veri akışını yeni güvenlik açığı sanabilir.

Daha az yanlış pozitif: kapanan kayıt her zaman giderilmiş açık değildir

2.26.4 bazı sorguların gereksiz sonuçlarını da azaltıyor. C# sorguları artık antiforgery middleware ile kullanılan etkin RequireAntiforgeryToken özniteliklerini tanıyor, nameof ifadelerindeki sanal üyeleri çağrı olarak raporlamıyor ve build-mode: none veritabanlarında iki sorgunun yanlış pozitiflerini azaltıyor. JavaScript/TypeScript tarafında ise TransformStream kurucusuna verilen geçerli ek argümanlar artık gereksiz argüman olarak işaretlenmiyor.

Bu sorgulara ait bir kayıt kod değişmeden kapanırsa, olası açıklama açığın giderilmesi değil analiz mantığının daha isabetli hale gelmesidir. Tersi yönde de yalnızca Actions değişiklikleri sonuç üretmeyebilir: Java/Kotlin için Spring R2DBC DatabaseClient ve R2DBC SPI SQL injection hedef modelleri, Python için list.extend ve list.insert üzerinden taint akışı eklendi. Toplam uyarı sayısındaki artış ya da düşüş bu nedenle tek başına güvenlik seviyesindeki değişimi göstermiyor.

İlk 2.26.4 taramasında temel çizgi nasıl ayrıştırılmalı?

Sürüm öncesi ve sonrası sonuçların sağlıklı karşılaştırılması, uyarıları tek bir toplam yerine değişikliğin nedenine göre ayırmayı gerektiriyor. Kısa kontrol sırası şöyle kurulabilir:

1. Taramada kullanılan CodeQL sürümünü ve sorgu paketlerini kaydedin; GitHub.com sonuçlarıyla sabitlenmiş yerel veya GHES kurulumlarının aynı sürümü kullandığını varsaymayın.
2. Yeni Actions kayıtlarını sorgu kimliğine göre ayırın. Yeniden kullanılabilir workflow çağrılarındaki branch ve tag referanslarını, ardından aktör alanlarının workflow’u tetikleyen olaylarda gerçekten bulunup bulunmadığını inceleyin.
3. Yeni görünen Rust kayıtlarını kapanan kayıtlarla sorgu, dosya, kaynak ve hedef düğümleri üzerinden eşleştirin. Satır numarasını tek eşleştirme ölçütü olarak kullanmayın.
4. Kapanan C# ve JavaScript/TypeScript kayıtlarında aynı aralıkta kod değişikliği bulunup bulunmadığını kontrol edin; yoksa sorgu doğruluğu düzeltmesini ayrı bir neden olarak işaretleyin.
5. Karşılaştırmayı “yeni bulgu”, “konumu değişen bulgu” ve “azalan yanlış pozitif” gruplarına bölün; toplam sayı değerlendirmesini bu ayrımdan sonra yapın.

Dağıtım kapsamı da sonuçları etkiliyor. CodeQL’in yeni sürümleri GitHub.com code scanning kullanıcılarına otomatik ulaşıyor; 2.26.4 işlevlerinin gelecekteki bir GitHub Enterprise Server sürümüne eklenmesi planlanıyor ve eski GHES sürümlerinde manuel yükseltme seçeneği bulunuyor. Kesin sonuç depo bazında değişecek: yeni bulgular workflow referanslarına, tetikleyici olaylara, kullanılan dillere ve özel modellere bağlı olacak.

Ayrıca okuyun:

• Bending Spoons’un büyüme motoru: Eski uygulamalar nasıl nakit üretiyor?
• Gemini 3.8 Flash daha çok düşünüyor: İlk yanıt 13,3 saniyeyi buluyor
• Muse Spark 1.3 daha az araç çağırıyor: En güçlü düşünme modu gecikecek