GitHub secret scanning artık Actions workflow loglarını da tarıyor (public preview)

GitHub, 9 Kasım'da yayımladığı changelog notunda secret scanning özelliğinin artık GitHub Actions workflow loglarını da taradığını duyurdu. Tarama bugüne kadar issue, wiki, discussion ve pull request içeriklerini kapsıyordu. Yeni kapsam public preview aşamasında ve yalnızca GitHub Secret Protection ya da GitHub Advanced Security kullanan Enterprise Cloud müşterilerine açık.

Duyuru, CI/CD hatlarının saldırganlar için ne kadar verimli bir hedef olduğu düşünüldüğünde zamanlı. Bugün yazdığımız GhostAction'ın yeni varyantı da GitHub Actions üzerinden gizli bilgilere ulaşmayı hedefleyen bir kampanyaydı.

Nasıl çalışıyor?

GitHub'ın açıklamasına göre tarama, bir workflow çalışması tamamlandığında devreye giriyor. Yalnızca özellik etkinleştirildikten sonra tamamlanan çalışmalar taranıyor; mevcut loglar geriye dönük taranmıyor. Preview kapsamında bazı sınırlar var:

• Generic pattern, custom pattern ve AI ile tespit edilen gizli bilgiler bu yüzeyde algılanmıyor.
• Actions'ın zaten maskelediği secret'lar tespit kapsamı dışında.
• Preview süresince uyarılar bildirim göndermiyor; uyarıları güvenlik sekmesinden takip etmek gerekiyor.
• Politika varsayılan olarak kapalı; yöneticinin açması gerekiyor.

Neden önemli?

Build loglarına yanlışlıkla basılan token, parola veya bulut erişim anahtarları, depoya okuma erişimi olan herkesin görebileceği yerde kalabiliyor. Maskelenmemiş bir değişken, hata ayıklama için açılan ayrıntılı çıktı ya da bir üçüncü taraf action'ın yazdırdığı yanıt bu tür sızıntıların tipik kaynakları. Kod taramasında temiz görünen bir depo, logları üzerinden anahtar sızdırıyor olabilir.

Kimin işine yarar / ne yapabilirsiniz?

1. Enterprise Cloud ve Secret Protection ya da Advanced Security lisansınız varsa, politikayı önce düşük riskli birkaç organizasyonda açıp uyarı hacmini gözlemleyin.
2. Tarama geriye dönük çalışmadığı için eski logları ayrıca gözden geçirin; gerekirse log saklama süresini kısaltmayı değerlendirin.
3. Preview'da bildirim gelmediğinden uyarıları düzenli kontrol edecek bir sorumlu belirleyin.
4. Logda görülen bir gizli bilgiyi silmek yetmez; ilgili anahtarı iptal edip yenisini üretin.
5. Lisansınız yoksa, workflow'larda secret'ları yalnızca secrets bağlamından okuyun ve ayrıntılı hata ayıklama çıktısını üretim depolarında kalıcı açık bırakmayın.