GitHub üzerinde kullanılan iki popüler action paketinde, sürüm etiketlerinin saldırgan kontrolündeki sahte commit’lere yönlendirilmesiyle başlayan bir tedarik zinciri olayı tespit edildi. Bu durum, CI/CD hatlarında çalışan iş akışlarının gizli anahtarlar, token’lar ve diğer hassas kimlik bilgilerini sızdırma riski taşımasına yol açıyor. Etkilenen yapıların özellikle yazılım geliştirme ekipleri, DevOps ortamları ve GitHub Actions kullanan kurumsal projeler olduğu değerlendiriliyor.
İlk incelemelere göre saldırı, bir action deposundaki mevcut tag’lerin normal commit geçmişinde görünmeyen kötü amaçlı bir commit’e işaret edecek şekilde değiştirilmesiyle ilerledi. Böylece sürüm numarasına güvenen iş akışları, bir sonraki çalıştırmada fark edilmeden zararlı kodu çekmeye başladı. Bu yöntem, klasik PR incelemelerini atlatabildiği için tedarik zinciri saldırılarında özellikle tehlikeli kabul ediliyor.
Saldırı Zinciri Nasıl İşledi?
Teknik analizler, kötü amaçlı commit’in GitHub Actions runner üzerinde çalıştığında birkaç aşamalı bir veri sızdırma akışı başlattığını gösteriyor. Önce Bun JavaScript runtime indiriliyor, ardından Runner.Worker sürecinin belleği okunarak ortam değişkenleri ve kimlik bilgileri ayıklanıyor. Son adımda ise çalınan veriler, saldırganın kontrol ettiği bir HTTPS alan adına gönderiliyor.
Bu yaklaşım, özellikle CI/CD ortamlarında saklanan erişim anahtarlarını, paket yayınlama token’larını, bulut sağlayıcı kimlik bilgilerini ve depo erişim jetonlarını hedef alıyor. Eğer bu tür sırlar ele geçirilirse saldırganlar yalnızca kaynak koda değil, aynı zamanda artefact depolarına, container registry’lere ve bulut hesaplarına da erişim kazanabilir.
Hangi Action’lar Etkilendi?
İlk bulgular, actions-cool/issues-helper deposundaki etiketlerin sahte commit’e taşındığını ortaya koydu. Daha sonra aynı yöntemle actions-cool/maintain-one-comment için ayrılmış 15 etiketin de benzer biçimde ele geçirildiği bildirildi. Bu durum, tek bir paketteki sorunla sınırlı olmayan, daha geniş bir tedarik zinciri manipülasyonuna işaret ediyor.
GitHub, ilgili depoya erişimi hizmet şartları ihlali gerekçesiyle devre dışı bıraktı. Ancak bu kararın hangi teknik veya operasyonel bulgulara dayandığı kamuya açık şekilde paylaşılmadı. Etiketlerin kötü amaçlı commit’lere çözülmesi nedeniyle, sürüm adıyla çağrılan her iş akışı bir sonraki çalıştırmada zararlı kodu çekebiliyor. Yalnızca bilinen ve doğrulanmış tam commit SHA ile sabitlenen iş akışlarının bu değişiklikten etkilenmediği belirtiliyor.
Mini Shai-Hulud Bağlantısı ve Olası İlişki
Veri sızdırma için kullanılan alan adının, son dönemde Mini Shai-Hulud kampanyasının bir parçası olarak npm ekosistemindeki @antv paketlerini hedefleyen faaliyetlerde de görülmesi dikkat çekti. Bu örtüşme, iki olayın aynı saldırı kümesine bağlı olabileceği ihtimalini güçlendiriyor. Özellikle exfiltration altyapısındaki ortaklık, saldırganların yeniden kullanılan bir C2 veya veri toplama zinciri işletmiş olabileceğini düşündürüyor.
Güvenlik ekipleri açısından bu tür eşleşmeler önemlidir; çünkü aynı alan adı, aynı TLS parmak izi, aynı IP bloğu veya benzer kullanıcı ajanı davranışları, olay müdahale sürecinde vakaları ilişkilendirmek için güçlü sinyaller sağlar. SIEM korelasyon kuralları, DNS log’ları, proxy kayıtları ve GitHub audit log’ları birlikte incelendiğinde saldırının kapsamı daha net görülebilir.
Kurumsal Ortamlarda Risk Neden Yüksek?
GitHub Actions, yazılım teslimat zincirinin merkezinde yer aldığı için tek bir action paketindeki bozulma, çok sayıda projeye aynı anda sıçrayabilir. Özellikle SaaS sağlayıcıları, e-ticaret platformları, fintech ekipleri ve bulut tabanlı ürün geliştiren şirketler; build, test ve release aşamalarında bu tür action’lara bağımlıysa risk katlanır. Bir CI/CD sırrının sızması, sonrasında kaynak kodu değiştirme, sahte paket yayınlama veya üretim ortamına yetkisiz erişim gibi daha büyük olaylara kapı açabilir.
Bu nedenle konu yalnızca bir depo güvenliği meselesi değil; aynı zamanda bulut güvenliği, ağ segmentasyonu, IAM politikaları ve olay müdahale süreçlerinin birlikte ele alınması gereken bir tedarik zinciri güvenliği problemidir. Kurumlar, üçüncü taraf action kullanımını envanterlemeli ve hangi iş akışının hangi sırları kullandığını net biçimde izlemelidir.
SOC ve DevOps Ekipleri İçin Pratik Kontrol Listesi
• GitHub Actions iş akışlarında sürüm etiketi yerine mümkün olduğunda tam commit SHA kullanın.
• CI/CD secret’larını en az ayrıcalık prensibiyle sınırlayın ve kısa ömürlü token’lara geçin.
• Runner.Worker, bash, curl, powershell ve benzeri süreçlerde olağandışı bellek erişimi veya ağ çıkışlarını EDR ile izleyin.
• DNS ve proxy log’larında yeni görülen alan adları, özellikle build sırasında yapılan HTTPS çıkışları için alarm üretin.
• Depo sahipliği ve tag bütünlüğü için korumalı branch, release onayı ve imzalı commit kontrollerini zorunlu hale getirin.
• CI ortamında kullanılan sırları düzenli olarak döndürün; sızıntı şüphesinde anında iptal edin.
• GitHub audit log’larını, workflow run geçmişini ve artifact erişim kayıtlarını SIEM’e aktarın.
• Üçüncü taraf action’ları periyodik olarak gözden geçirip kullanılmayanları kaldırın.
Teknik Özet
Kullanılan yöntem: GitHub Action tag yönlendirmesi, sahte commit üzerinden tedarik zinciri manipülasyonu.
Hedeflenen veri: CI/CD kimlik bilgileri, token’lar, ortam değişkenleri ve olası bulut erişim anahtarları.
Davranış zinciri: Runtime indirme → süreç belleğinden veri çıkarma → saldırgan alan adına HTTPS ile sızdırma.
İlişkili kampanya: Mini Shai-Hulud ile olası altyapı ve exfiltration alan adı örtüşmesi.
Temel savunma: SHA pinning, secret minimizasyonu, EDR/SIEM korelasyonu, tag bütünlüğü ve düzenli secret rotasyonu.
Bu olay, yazılım tedarik zincirinde güvenin yalnızca repoya değil, sürümleme mekanizmasına ve bağımlılıkların nasıl çağrıldığına da bağlı olduğunu bir kez daha gösteriyor. Özellikle otomasyonun yoğun olduğu ortamlarda, küçük görünen bir tag değişikliği bile üretim hattına kadar uzanan ciddi bir güvenlik olayına dönüşebilir.