GitHub Actions Şüpheli Workflow’ları Onaya Alıyor
GitHub, tedarik zinciri saldırılarına karşı GitHub Actions tarafında yeni bir koruma katmanını devreye aldı. Artık potansiyel olarak kötü niyetli görülen workflow çalıştırmaları, otomatik olarak başlatılmıyor; önce bir depo yetkilisinin onayını bekliyor. Bu yazıda, GitHub’ın açıkladığı bu değişikliğin ne olduğunu, neden gerekli görüldüğünü ve hangi depoları kapsadığını sade bir şekilde özetliyorum.
Neden Yeni Bir Onay Adımı Geldi?
Son dönemde gündeme gelen tedarik zinciri saldırılarında saldırganlar, ele geçirilmiş GitHub kimlik bilgilerini kullanarak depolara kötü niyetli GitHub Actions workflow’ları gönderiyor. Bu workflow’lar tetiklendiğinde CI/CD ortamındaki kimlik bilgilerini çalabiliyor ve buradan ilerleyen ek saldırıların önünü açabiliyor. Yani sorun yalnızca tek bir deponun tehlikeye girmesi değil; çalınan sırlarla başka sistemlere sıçrama ihtimalinin ortaya çıkması.
GitHub, bu senaryoyu özellikle herkese açık depolarda kırmak için Actions çalıştırma akışına yeni bir kontrol noktası ekledi. Amaç, saldırganın “commit’i pushla, workflow otomatik koşsun, sırları dışarı sızdır” zincirini onay adımıyla kesmek.
Koruma Nasıl İşliyor?
Yeni davranışa göre bir workflow çalıştırması potansiyel olarak kötü niyetli şeklinde tespit edildiğinde, çalıştırma doğrudan başlamıyor. Bunun yerine “beklemede” tutuluyor ve deponun write yetkisine sahip bir kolaboratörü tarafından incelenip onaylanana kadar tetiklenmiyor. Onay geldikten sonra workflow normal akışında çalışmaya devam ediyor.
Onayın nasıl verildiği de burada önemli bir ayrıntı: Onayın kimliği doğrulanmış bir web oturumu üzerinden verilmesi gerekiyor. Yani kullanıcı, GitHub’a giriş yapmış bir tarayıcı oturumu üzerinden bu adımı gerçekleştiriyor. Bu, saldırganın çalınmış bir token veya otomatik bir yöntemle sessizce onay geçmesini zorlaştıran bir tasarım tercihi olarak öne çıkıyor.
Kimlerin Onay Verebildiği
Onay yetkisi herkeste değil. Kaynağa göre yalnızca deponun write erişimine sahip bir kolaboratörü, beklemedeki workflow çalıştırmasını inceleyip onaylayabiliyor. Bu, yalnızca yazma yetkisi olmayan dış katkı sağlayıcıların otomatik olarak koruma kalkanını devreden çıkaramayacağı anlamına geliyor. Aynı zamanda inceleme sorumluluğunun, depoyu yakından tanıyan ekip üyelerinde kalmasını sağlıyor.
Yapılandırma Gerektirmiyor
Bu korumanın belki de en pratik yani, herhangi bir kurulum veya ayar değişikliği gerektirmemesi. Depo yöneticilerinin ekstra bir güvenlik anahtarını açmasına, YAML dosyalarında değişiklik yapmasına veya politikaları yeniden tanımlamasına gerek yok. GitHub, koşulları oluştuğunda korumayı otomatik olarak uyguluyor. Yani “gözden kaçırdığımız bir ayar yüzünden bu koruma kapalı kalmasın” endişesi de büyük ölçüde ortadan kalkıyor.
Kapsam: Hangi Depolar Etkileniyor?
Bu koruma şu anda yalnızca github.com üzerindeki herkese açık (public) depolar için geçerli. Özel depolar veya kurumsal ortam için farklı bir davranış tanımlanmış değil. Ayrıca GitHub Enterprise Server tarafında şu an için bu koruma eklenmiş değil; yani kendi altyapısında GHES çalıştıran ekiplerin bu davranışı henüz beklememesi gerekiyor.
Kapsamın herkese açık depolarla sınırlı olması aslında saldırı yüzeyi açısından mantıklı: Bu depolar, dış katkıların ve dolayısıyla saldırganların en kolay etkileşime geçebildiği alanlar. Kötü niyetli workflow’ların en görünür etkisi de bu tür projelerde ortaya çıkıyor.
Bakım Ekipleri İçin Ne Anlama Geliyor?
Herkese açık bir proje sürdüren ekipler için pratik sonuç şu: Bazı workflow çalıştırmalarının artık doğrudan başlamayıp onay bekleyebileceğini varsaymak gerekiyor. Bu, özellikle otomatik pipeline’lara alışkın olan projelerde workflow durumunu düzenli takip etmenin önemini artırıyor. Beklemedeki bir çalıştırma fark edilip onaylanmadığında, sonraki adımlar da doğal olarak ilerlemeyecek.
Öte yandan bu davranış, sırların dışarı sızma riskini azaltan bir sigorta işlevi görüyor. Yani kısa vadeli bir “bir adım daha” yükü karşılığında, kimlik bilgilerinin ele geçirildiği bir senaryoda saldırının otomatik yayılmasını kesme şansı sunuyor. Özellikle popüler açık kaynak projelerinde bu tür bir insan onayının değeri, yaşanan olaylar düşünüldüğünde daha net anlaşılıyor.
Özet
Kısaca: GitHub Actions, herkese açık depolarda şüpheli görülen workflow çalıştırmalarını otomatik olarak beklemeye alıyor, write yetkili bir kolaboratör kimliği doğrulanmış bir web oturumundan onay verene kadar tetiklenmesine izin vermiyor. Kurulum gerektirmiyor, GitHub tarafında otomatik uygulanıyor ve şimdilik yalnızca github.com üzerindeki herkese açık depoları kapsıyor; GitHub Enterprise Server bu aşamada kapsam dışı.
Kaynaklar ve İleri Okuma
- GitHub Actions holds potentially malicious workflows for approval (GitHub Changelog)
- The GitHub Blog
- GitHub Actions 2026 Güvenlik Yol Haritası: Sırada Bizi Neler Bekliyor?
- GitHub Actions Nisan 2026 Güncellemeleri: Üç Küçük Ama Etkili Hamle
- GitHub Actions’ta 50 Yeniden Çalıştırma Sınırı: Sahada Ne Değişiyor?
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.
2 comments