GitHub Actions’ta Kötü Amaçlı İş Akışları Artık Onay Bekliyor: Tedarik Zinciri Savunması
GitHub’ın yeni koruması ne yapıyor?
GitHub, 28 Temmuz 2026 tarihli duyurusunda potansiyel olarak kötü amaçlı görülen bazı GitHub Actions iş akışlarını çalışmadan önce beklemeye aldığını açıkladı. Bekletilen bir çalışma, depoda yazma yetkisi bulunan bir işbirlikçi tarafından incelenip onaylanana kadar başlamıyor. Onay işleminin kimliği doğrulanmış bir web oturumu üzerinden verilmesi gerekiyor; onaydan sonra iş akışı normal biçimde devam ediyor.
Bu koruma için ayrıca bir ayar açmak gerekmiyor; GitHub özelliği uygun çalışmalara otomatik uyguluyor. Ancak kapsamın sınırı önemli: duyuru şu anda github.com üzerindeki herkese açık depoları kapsıyor. GitHub Enterprise Server aynı korumayı sağlamıyor ve bir iş akışının beklemeye alınmamış olması, içeriğin güvenli olduğuna dair mutlak bir garanti oluşturmuyor.
Neden CI/CD iş akışları hedefte?
GitHub’ın tedarik zinciri değerlendirmesine göre saldırganlar önce bir bakımcının hesabını veya projenin otomasyon dosyalarını ele geçirmeye çalışabiliyor. Kötü amaçlı iş akışı çalıştığında kod deposu belirteçlerine, yayınlama anahtarlarına ya da bulut erişim bilgilerine ulaşmayı deneyebilir. Ele geçirilen kimlik bilgileri daha sonra başka projelere yayılmak veya zararlı paket yayımlamak için kullanılabilir.
Bu nedenle yalnızca kaynak kodu incelemek yeterli değildir; .github/workflows altındaki değişiklikler de üretim kodu kadar kritik kabul edilmelidir. Bir YAML dosyasındaki birkaç satır, geniş yetkili bir GITHUB_TOKEN ile birleştiğinde depo içeriğini değiştirebilir veya dağıtım zincirine erişebilir. GitHub’ın bekletme mekanizması, şüpheli çalışmanın otomatik başlaması ile insan incelemesi arasına bir kontrol noktası ekler.
Onay ekranında ne incelenmeli?
İnceleme yapan kişi yalnızca değişikliği gönderen hesaba bakmamalıdır. İş akışında yeni eklenen komutlar, dışarıdan indirilen betikler, bilinmeyen alan adlarına ağ çağrıları, sırların ortam değişkenlerine taşınması ve genişletilen izinler birlikte değerlendirilmelidir. Özellikle kodlanmış uzun metinler, beklenmedik paket kurulumları ve günlükleri dış sisteme gönderen komutlar açıklama gerektirir.
- Değişikliği kimin, hangi oturum ve dal üzerinden yaptığına bakın.
permissionsalanında yazma yetkisi eklenip eklenmediğini kontrol edin.- Üçüncü taraf action sürümlerinin güvenilir ve sabitlenmiş olduğunu doğrulayın.
- Yeni ağ hedeflerini, indirme komutlarını ve yayınlama adımlarını inceleyin.
- Şüphe giderilmeden “Approve and run” seçeneğini kullanmayın.
Onay verecek kişinin değişikliğin sahibiyle aynı kişi olmaması tercih edilir. İnsan onayı ancak nitelikli bir incelemeyle güvenlik kontrolüne dönüşür. Yoğunluk nedeniyle her uyarıyı hızla onaylamak, korumanın sağlayacağı zaman avantajını ortadan kaldırır; ekipler bekletilen çalışmalar için kısa ama zorunlu bir kontrol listesi oluşturmalıdır.
Otomatik korumanın tamamlamadığı alanlar
GitHub, yalnızca “bazı” potansiyel kötü amaçlı çalıştırmaların bekletildiğini söylüyor; algılama mantığının her saldırıyı yakalayacağı iddia edilmiyor. Özel depolar, GitHub Enterprise Server kurulumları ve başka CI/CD ürünleri için aynı davranış varsayılmamalıdır. Ayrıca meşru görünen bir hesaptan gelen, yavaş ve hedefli değişiklikler otomatik sinyallerden kaçabilir.
Kurumlar bu özelliği tek savunma katmanı olarak değil, mevcut kontrolleri tamamlayan bir güvenlik ağı olarak görmelidir. Dal koruması, zorunlu kod incelemesi, iş akışı dosyaları için CODEOWNERS, en az ayrıcalıklı belirteç izinleri ve ortam onayları uygulanmaya devam etmelidir. Üretim sırları yalnızca gerçekten ihtiyaç duyan işlere açılmalı ve mümkün olduğunda uzun ömürlü anahtarlar yerine kısa ömürlü OIDC kimlikleri kullanılmalıdır.
GitHub Actions için sertleştirme planı
GitHub’ın güvenli kullanım rehberi, GITHUB_TOKEN için varsayılan izinlerin yalnızca içerik okuma düzeyinde tutulmasını ve gerekli yazma izinlerinin iş bazında verilmesini öneriyor. Üçüncü taraf action’ları tam uzunluktaki commit SHA değerine sabitlemek, bir etiket sonradan taşındığında beklenmedik kod çalışması riskini azaltır. Hassas değerler iş akışı dosyalarında düz metin olarak tutulmamalı; açığa çıkan sırlar silinip hemen döndürülmelidir.
- Kuruluş genelinde varsayılan
GITHUB_TOKENizinlerini gözden geçirin. - İş akışı dizinini güvenlik veya platform ekibinin sahipliğine bağlayın.
- Üçüncü taraf action referanslarını tam commit SHA değerlerine sabitleyin.
- Self-hosted runner’ları herkese açık depolarda kullanmaktan kaçının.
- Ortam sırları için zorunlu inceleyici ve dağıtım kuralları tanımlayın.
- Denetim günlüklarında iş akışı ve sır değişikliklerini düzenli izleyin.
Ek olarak, herkese açık depolardaki iş akışı dosyaları için değişiklik geçmişi düzenli taranmalı ve beklenmedik yetki artışları raporlanmalıdır. Self-hosted runner kullanan özel ortamlarda ağ erişimi bölümlenmeli, her iş sonrasında temiz bir çalışma ortamı hazırlanmalı ve üretim sistemlerine erişen kimlikler yalnızca gerekli süre boyunca geçerli olmalıdır.
Bir şüpheli çalışma görülürse
Bekletilen çalışma açıklanamıyorsa onaylanmamalı; ilgili commit, hesap hareketleri ve iş akışı geçmişi korunarak olay kaydı açılmalıdır. Depoya yazma erişimi olan hesabın oturumları, kişisel erişim belirteçleri ve SSH anahtarları gözden geçirilmelidir. İş akışının daha önce çalışmış olma ihtimalinde, erişebildiği sırlar ve yayınlama kimlik bilgileri kapsam belirlenmeden güvenli kabul edilmemelidir.
Gerekli anahtarlar döndürüldükten sonra kötü amaçlı değişiklik geri alınmalı, dal ve sürüm etiketleri doğrulanmalı, yayımlanan paketlerin bütünlüğü kontrol edilmelidir. GitHub’ın otomatik bekletme özelliği ekiplerin tepki vermesi için değerli zaman kazandırır; kalıcı güvenlik ise en az ayrıcalık, bağımsız inceleme, kısa ömürlü kimlik bilgileri ve ayrıntılı kayıtların birlikte işletilmesine bağlıdır.