Müthiş Ama Tehlikeli Kolaylıklar Dürüst olmak gerekirse, GitHub Actions’ın "tag ile referans ver" mantığı ilk etapta oldukça pratik görünüyor (her zaman son sürümü çekiyorsun). Ancak öbür tarafta tehlike var; bu tag’ın arkasındaki kod sabaha karşı gizlice değişirse başınız ağrıyabilir... Bağımlılık Kaosu Tablosu Referans TipiGüvenlik Açığı RiskiYönetim Kolaylığı tag (örn. v1)Çok YüksekBaya kolay branch (örn. main)Tavan!Süper rahat commit SHADüşükZahmetli ama güvenli lock file (kilit dosyası)En düşük!Zorlaştı ama risk azalıyor Kod Bloğu ile Pratik Örnek: # Eski yöntem — tehlikeli uses: actions/checkout@v2 # Yeni kilitli yöntem dependencies: — uses: actions/checkout@c47ee857bfa94eaaa11157bcbb9ce99960eb87ef Kendi blogumda GitHub Actions’da Agentic Workflow Ayarlarını Anında Görmek'ta da anlattım — dependency referansı ne kadar sabitse, beklenmedik olay ihtimali o kadar azalıyor. "Lock File" Devrimi mi Geliyor?

Bunu ilk okuduğumda kafam karıştı açıkçası… Workflow seviyesinde lock file olur mu ya dedim kendi kendime (Go modüllerine geçerken ekipte benzer tepkiler vardı). Sonra detaylara girince fikir baya hoşuma gitti: Tüm workflow’un bağımlılıkları commit hash ile kilitlenecek. Kod review sırasında PR diff içinde her değişiklik net görünecek. Eğer hash uyuşmazsa workflow hemen duracak (“fail fast” candır). Nihayet composite action’ların içindeki matruşka gibi saklı bağımlılıklar da şeffaflaşıyor.

Peki Ya Gerçek Hayatta? Küçük Startup ile Kurumsal Dev Arasındaki Uçurum... Küçük Bir Startup İçin Durum: Kilit dosyası kullanmak başlangıçta ekstra iş yükü demek ama maliyet ciddi şekilde düşüyor (geçen ay arkadaşım lock file sayesinde npm’den gelen tuhaf script’i erkenden yakaladı). Ayrıntılı ağ politikası uygulamak ilk başlarda sıkıntı yaratabilir ama ileride büyük krizleri önlüyor. Büyük Kurumsal Şirkette Ne Değişir?

Anlık izlenebilirlik şart çünkü denetimler sertleşti – SIEM entegrasyonu olmadan kimse huzurlu uyuyamıyor. \ Sertifikalı politika setleri departmanlar arasında gerginlik çıkarabiliyor ("Biz neden production’a deploy yapamıyoruz?" tartışmaları klasik…) Denge önemli! Fazla güvenlik üretkenliği baltalayabilir. Gevşek güvenlikle de sabah şirkete gelip server bulamayabilirsiniz – ikisi de tatsız (bizzat test ettim). O yüzden iyi ayarlamak lazım! 💡 Bilgi: Github Actions roadmap'teki yeni

GitHub Actions 2026 Güvenlik Yol Haritası: Sırada Bizi Neler Bekliyor? -

⏱️ 6 dk okuma📅 29 Mart 2026

Otomasyon Güvenliği: Neden Şimdi Herkes Panikte?

Birkaç aydır sektörde sessiz sedasız bir stres havası var; çoğu kişinin farkında bile olmadığı bir konu. Geçen ekim, bir finans şirketinde CI/CD pipeline’larına göz gezdiriyordum. Takım lideri yanımdaki koltukta, “Bu action dosyalarını gece güncelliyoruz ama gerçekten çalışıyorlar mı hiç bilmiyoruz,” dedi ve içimden “eyvah” dedim. Bazen en riskli şey, görünmez olan.

İşin garibi, Peki sebep ne? Açıklayayım: Eskiden hackerlar doğrudan koda saldırmaya odaklanıyordu; artık işin rengi değişti — otomasyonu ele geçirmeye çalışıyorlar. GitHub Actions tarafında birkaç örneği bizzat gördüm: tj-actions/changed-files vakası, Nx (yanlış duymadınız). Trivy-action’a yapılan ataklar hâlâ hafızamda taze.

Yazılım tedarik zinciri saldırıları eskisi gibi sadece koda değil, doğrudan otomasyonun kendisine yöneldi — hem de bazen anlaması samanlıkta iğne aramak kadar zahmetli!

İşin garip tarafı şu; kötü niyetli biri bir Action’da açık buldu mu yetkisiz kodu pat diye sisteme sokabiliyor (kendi tecrübem). Tüm bağımlılık zinciri domino taşı gibi düşüyor. Bir de fazla izinli token’lar ortada uçuşuyorsa, hassas veri için resmen kapılar ardına kadar açık demektir.

💡 Bilgi: Kontrolsüz bir CI/CD pipeline’ın güvenlik açığı yüzünden onlarca projeyi ve yüzlerce geliştiricinin emeğini anında yok edebilirsiniz.

Ekosistemi Kilitlemek: Bağımlılıklar Niye Bu Kadar Tehlikeli?

Hani, Bazen cevap burnunun ucunda durur ama kimse dönüp bakmaz ya… GitHub Actions’daki durum tam böyle! Geçen yıl mayıs ayında Logosoft’ta bir müşterinin on-prem Jenkins pipeline’ını Azure DevOps’a aktarırken workflow’lardaki Action referanslarının %80’inin tag veya branch ile işaretlendiğini fark ettik — hangi sürüm ne zaman değişiyor belli değil.

Müthiş Ama Tehlikeli Kolaylıklar

Dürüst olmak gerekirse, GitHub Actions’ın “tag ile referans ver” mantığı ilk etapta oldukça pratik görünüyor (her zaman son sürümü çekiyorsun). Ancak öbür tarafta tehlike var; bu tag’ın arkasındaki kod sabaha karşı gizlice değişirse başınız ağrıyabilir…

Bağımlılık Kaosu Tablosu

Referans Tipi	Güvenlik Açığı Riski	Yönetim Kolaylığı
tag (örn. v1)	Çok Yüksek	Baya kolay
branch (örn. main)	Tavan!	Süper rahat
commit SHA	Düşük	Zahmetli ama güvenli
lock file (kilit dosyası)	En düşük!	Zorlaştı ama risk azalıyor

Kod Bloğu ile Pratik Örnek:

# Eski yöntem — tehlikeli
uses: actions/checkout@v2
# Yeni kilitli yöntem
dependencies:
— uses: actions/checkout@c47ee857bfa94eaaa11157bcbb9ce99960eb87ef

Kendi blogumda GitHub Actions’da Agentic Workflow Ayarlarını Anında Görmek‘ta da anlattım — dependency referansı ne kadar sabitse, beklenmedik olay ihtimali o kadar azalıyor.

“Lock File” Devrimi mi Geliyor?

Bunu ilk okuduğumda kafam karıştı açıkçası… Workflow seviyesinde lock file olur mu ya dedim kendi kendime (Go modüllerine geçerken ekipte benzer tepkiler vardı). Sonra detaylara girince fikir baya hoşuma gitti:

Tüm workflow’un bağımlılıkları commit hash ile kilitlenecek.
Kod review sırasında PR diff içinde her değişiklik net görünecek.
Eğer hash uyuşmazsa workflow hemen duracak (“fail fast” candır).
Nihayet composite action’ların içindeki matruşka gibi saklı bağımlılıklar da şeffaflaşıyor.

Peki Gerçekten Ne Kazanıyoruz?

Sihir adım adım kontrolde yatıyor (ki bu çoğu kişinin gözünden kaçıyor). Mesela prod’a deploy öncesi lock dosyasını incelemediniz mi? O zaman kimin imzasını aldığınızdan pek emin olamazsınız! Bundan üç ay önce büyük bir e-ticaret platformunda Azure DevOps pipeline migration yaptık; aynı mantığı orada uygulayınca tüm team lead’ler “artık kafamız rahat” dedi — çünkü hangi bağımlılığı güncellediğimiz apaçık belliydi.

Saldırı Yüzeyini Daraltmak: Politika ve Yetki Ayarı İnce İşçilik!

Burası tam olarak mayın tarlası gibi… Otomasyona verdiğiniz her fazla yetki geri döner sizi vurur, bumerang misali! Tam burada politika setleri devreye giriyor – Azure’daki RBAC’e biraz benziyor aslında.

Sertifikalı Deneyimden Mini Senaryo:

AZ-500 sınavına hazırlanırken credential scoping mevzusu beni şaşırtmıştı çünkü varsayılan izinlerle neredeyse her şey herkese açıktı! Neyse ki şimdi GitHub Actions’da scoped credentials konsepti devreye alındı ve yetkiler sadece gerektiği kadar dağılıyor.

Sadece ihtiyaç duyulan izinler (“least privilege” felsefesine göre)
Ağ trafiği ister repo bazında ister organizasyon genelinde sınırlandırılabiliyor (network boundary enforcement yeni geliyor!)
Kritik işlerde herkes root olmuyor artık — rolleri bölmek mümkünleşiyor.

İnanın, Bunu geçen hafta küçük bir fintech startup’ında canlıya aldık; eskiden security token hacklendiğinde staging ortamları komple gidiyordu — şimdi yalnızca ilgili job etkileniyor oldu. daha önce ele aldığımız github konusu yazımızda bu konuya da değinmiştik. Bu konuyla ilgili Microsoft Entra’da Sonradan Görülen Tutarlılıkl… yazımıza da göz atmanızı tavsiye ederim.

Ayrıca Dikkat Edilecekler Listesi:

Kredi yönetimini mutlaka otomatize edin; manuel rotasyon facia çıkarabiliyor!
Ağ politikalarını merkezileştirin; IAM karmaşasına saplanmayın.
Kullanıcıya değil işe özel izin açın (“action bazlı access policy”).

Bakın, Daha ayrıntılı senaryolar için GitHub Credential Revocation API ile Sızıntılara Anında Fren‘e göz atabilirsiniz – gerçek hayattan bol bol örnek paylaştım orada… Bu konuyla ilgili neler hakkındaki detaylı rehberimiz yazımıza da göz atmanızı tavsiye ederim. Daha fazla bilgi için GitHub Issues ve Projelerde Ajan Aktivitesi: Ge… yazımıza bakabilirsiniz. Bu konuyla ilgili Merge Çakışmalarında Copilot Devrimi: Gerçekten… yazımıza da göz atmanızı tavsiye ederim.

Anlık Gözlemleme & Altyapıda Yeni Sınırlar Çiziliyor mu?

Burası teknik olduğu kadar tartışmalı… Enterprise müşterilerin çoğu gerçek zamanlı izlenebilirlik istiyor (“Kim neyi tetiklemiş? Network trafiği nereye gitmiş?”). Pratikte genelde log sunuluyor – gerisi sis perdesi gibi kalıyor maalesef.

Anlık Gözlemleme Nasıl Sağlanacak?

Tüm runner aktiviteleri merkezi dashboard’dan anlık takip edilecek (bankalardaki transaction monitoring sistemlerine benziyor).
Ağ erişimi kural bazlı zorunlu olacak – default açık sistem yavaş yavaş tarih oluyor…
Anomali yakalama mekanizmaları gelişiyor (“Neden bu job Çin’den tetiklendi?” sorusunu sormak nihayet mümkün olacak).

Kendimden örnek vereyim — Logosoft’un büyük telekom müşterisinde runner ağ izolasyonu olmadan işler kabusa dönmüştü; sonunda üçüncü parti firewall eklemek zorunda kaldık (bu da performansı %15 yavaşlatmıştı!). O yüzden yerleşik network policy kesinlikle şart diyorum!

“CI/CD güvenliği statik değil, canlı bir organizma gibi; her gün yeni zafiyet çıkabilir, eski ‘best practice’ iki haftada çöp olabilir.”

Peki Ya Gerçek Hayatta? Küçük Startup ile Kurumsal Dev Arasındaki Uçurum…

Küçük Bir Startup İçin Durum:

Kilit dosyası kullanmak başlangıçta ekstra iş yükü demek ama maliyet ciddi şekilde düşüyor (geçen ay arkadaşım lock file sayesinde npm’den gelen tuhaf script’i erkenden yakaladı).
Ayrıntılı ağ politikası uygulamak ilk başlarda sıkıntı yaratabilir ama ileride büyük krizleri önlüyor.

Büyük Kurumsal Şirkette Ne Değişir?

Anlık izlenebilirlik şart çünkü denetimler sertleşti – SIEM entegrasyonu olmadan kimse huzurlu uyuyamıyor.

Sertifikalı politika setleri departmanlar arasında gerginlik çıkarabiliyor (“Biz neden production’a deploy yapamıyoruz?” tartışmaları klasik…)

Denge önemli! Fazla güvenlik üretkenliği baltalayabilir. Gevşek güvenlikle de sabah şirkete gelip server bulamayabilirsiniz – ikisi de tatsız (bizzat test ettim). O yüzden iyi ayarlamak lazım!

💡 Bilgi: Github Actions roadmap’teki yeniliklerin hepsi sihir değiller; bazıları alışkanlıkları değiştirmeyi gerektiriyor ve adaptasyon sancısı kaçınılmaz.

Kritik Notlar ve Pratik İpuçları

Mümkün olduğunca immutable commit SHA ile action çağırmaya başlayın – lock file public preview’u beklemeden refleks haline getirin.

Ağ erişimini sadece gereken destination’a açın; “her yerden her yere” yaklaşımı geçmişte kaldı!

Kullandığınız harici Action’ın audit raporunu ara sıra gözden geçirin (audit logs can kurtarır).

Sertifikalandırılmış RBAC politikalarını takımlarla paylaşın – gizlice bypass etmeye çalışanlara dikkat edin!

Dönem dönem dummy credential leak testi yapın (“ben test ettim sorun yok” cümlesine asla inanmayın!).

Tüm workflow’lara fail-fast logic ekleyin – hata anında durdurmuyorsa felaket büyüyebilir!
Sadece teknik lead’lerin değil junior developer’ların da güvenlik eğitimine katıldığından emin olun (“benim alanım değil” bahanesini kabul etmiyorum!).

Sıkça Sorulan Sorular

GitHub Actions’da lock file nedir ve ne işe yarar?

Lock file workflow’un kullandığı tüm action’ları ve onların versiyonlarını belirlenen commit SHA’larla sabitler. Böylece dışarıdan gelecek ani değişiklikler veya zararlı kod riski ciddi şekilde azalır.

“Scoped credentials” özelliği neden önemli?

Sadece gerekli yetkinin verilmesini sağlar, böylece hata veya saldırı durumunda zarar minimumda tutulur. Bilhassa kurumlarda bu yaklaşım kritik hale geldi diyebilirim.

Anlık gözlemlenebilirlik pratikte nasıl fayda sağlıyor?

Tüm CI/CD aktivitelerini gerçek zamanlı izleyerek beklenmedik hareketlere hızlıca müdahale edebiliyorsunuz. Regülasyon yükümlülüğü olan şirketlerde olmazsa olmaz hale geldi son dönemde.

Kilit dosyasına geçmek mevcut projelerde adaptasyon sıkıntısı yaratır mı?

Evet, ilk başta fazladan iş yükü hissedebilirsiniz fakat orta vadede hem hatalar azalıyor hem güvenlik seviyesi artıyor – özellikle hızlı büyüyen startuplar için ciddi avantaj sağlayacaktır.