GitHub’da Açık Kaynak Tedarik Zincirini Korumak: Benim Sahada Gördüklerim
Geçen ay, yanı 2026’nın başlarında, bir müşteride yine aynı hikâye döndü: depoda her şey temiz görünüyordu ama CI/CD tarafında ufak bir açık, bütün güvenlik resmini gölgeledi (bizzat test ettim). İşin can sıkıcı kısmı şu ki saldırganlar artık tek tek projeleri kovalamıyor; önce workflow’a sızıp sonra oradan anahtarları çekmeye bakıyor. Hani kapıyı kilitledim sanıyorsun ama pencere açık kalmış gibi.
Open source tedarik zinciri dediğimiz şey biraz mutfak gibi. Malzeme çok, el değmeden akış yok, herkes birbirinin paketini kullanıyor. O yüzden tek bir zayıf halka bazen domino etkisi yaratıyor. Actions" data-glossary-term="GitHub Actions">GitHub Actions bu zincirin tam ortasında dürüyor; hem üretkenlik veriyor hem de yanlış kurgulanırsa saldırgana baya iyi bir geçit açabiliyor.
Peki neden?
Saldırıların yeni oyunu: önce sırları bul, sonra yayıldıkça yayıl
Bak şimdi, Açık konuşayım, son yıllarda gördüğüm en rahatsız edici desen şu: saldırgan önce API key peşine düşüyor, sonra o anahtarlarla kötü paket yayınlıyor, ardından da başka projelere sıçramaya çalışıyor. Bu artık “bir repoyu bozduk” seviyesi değil. Daha çok “ekosisteme tutunma” çabası. Ve evet, bu iş çoğunlukla bir GitHub Actions workflow’undan başlıyor.
2019’da benzer bir zincirleme riski kendi lab ortamımda test etmiştim; o zamanlar olay daha kaba kuvvet gibiydi. Şimdi işe çok daha sessizler. Loglara bakıyorsun, ilk anda masum gibi duran bir pull request ya da script parçası var… sonra pat diye secret dışarı çıkmış oluyor. Ne güzel değil mi? Değil tabiî.
İşte tam da bu noktada devreye giriyor.
Bir finans kuruluşunda 2024 sonunda yaptığımız gözden geçirmede de aynı tabloyu gördük: geliştiriciler iyi niyetliydi ama bazı workflow’lar fazla geniş yetkiliydi. Aslında sorun teknikten çok alışkanlıkla ilgiliydi; insanlar hızlı olsun diye bazı korumaları gevşetmişti. İşte tam orada güvenlik ile rahatlık birbirine giriyor.
Workflow hedefi neden bu kadar cazip?
Hani, Çünkü workflow içinde sadece build adımları yok; erişim var, token var, repository context var, bazen cloud bağlantısı bile var. Saldırgan için bu resmen Swiss army knife gibi bir şey (şaşırtıcı ama gerçek). Bir noktadan girince birkaç kapı daha açılıyor.
Ha bu arada, GitHub Actions tarafında en tehlikeli noktalardan biri kullanıcı girdisini doğrudan shell komutuna yedirmek. Küçük görünen bir satır… büyük bela çıkarabiliyor. Bu konuyla ilgili Python Eklentisinde Mart 2026: Hız, Arama ve Küçük Sürprizler yazımıza da göz atmanızı tavsiye ederim.
En hayatı mesele şu: sırları pipeline’da tutuyorsanız, onları sanki cam kavanozdaymış gibi düşünün. Güvenliymiş gibi durur ama darbe alınca ilk çatlayan yer orası olur.
Bugün ne yapabilirsiniz? En sağlam üç hamle
Benim pratikte en çok önerdiğim şeylerden biri CodeQL’i Actions workflow incelemesi için açmak öldü. Özellikle public repolarda ücretsiz olması bayağı iş görüyor. Hani ne farkı var diyorsunuz, değil mi? AZ-500 ve AZ-305 sınavlarına hazırlanırken de bunu defalarca not aldım; çünkü konu sadece kod taraması değil, pipeline mantığını da okumayı öğrenmek. Daha fazla bilgi için Azure ile Spring Testlerinde Docker Kullanınca Ne Değişiyor? yazımıza bakabilirsiniz.
İkinci önemli nokta üçüncü parti action’ları full commit SHA ile pinlemek. Tag’e güvenmek kulağa kolay geliyor ama tag değişebilir; SHA daha net. Daha serttir (hani kapıyı kilitlemek yerine çelik sürgü takmak gibi). Dependabot burada yardımcı olabiliyor ama dışarıdan gelen “ben güncelledim” pull request’lerine körü körüne atlamamak lazım.
Üçüncüsü de user-submitted content üzerinden script injection riskini ciddiye almak. Bir PR yorumunu ya da issue içeriğini shell’e taşırken araya filtre koymazsanız iş uzar gider… ve genelde iyi yönde uzamaz.
| Konu | Neden önemli? | Sahadaki etkisi |
|---|---|---|
| CodeQL ile workflow analizi | Zayıf akışları yakalar | Sessiz hataları erken görürsünüz |
| Pinned action kullanımı | Tag kaymasını engeller | Tedarik zinciri sürprizlerini azaltır |
| User input sanitization | Script injection riskini düşürür | Basit ama ölümcül açıkları kapatır |
| Dependabot / Advisory Database | Zafiyet takibi sağlar | Panik yerine düzenli aksiyon verir |
Sadece önlem yetmiyor; yayınlama modelini de değiştirmek gerekiyor
İtiraf edeyim, Neyse uzatmayalım… eski modelde secrets ile yayın yapan birçok ekip aslında farkında olmadan saldırıya davetiye çıkarıyor. GitHub’ın OpenID Connect tabanlı yaklaşımı burada bence fena değil, hatta bayağı iş görüyor (kendi tecrübem). Workflow’un kimliğiyle yetki almak varken neden uzun ömürlü secret saklayasınız ki? Bu konuyla ilgili GitHub Secret Scanning Büyüdü: Yeni Detektörler, Daha Az Sızıntı yazımıza da göz atmanızı tavsiye ederim.
Bunu geçen yıl Logosoft tarafında bir SaaS müşterisine anlatırken şöyle örnek verdim: Kasadaki anahtarı her çalışan cebinde taşımasın da gerektiğinde geçici kart kullansın düşüncesi gibi davranın dedim. Abartılı gelmedi çünkü operasyon ekibi de hemen kavradı. Geçici token mantığı hem izlenebilirlik veriyor hem de sızıntının etkisini küçültüyor. Daha fazla bilgi için PowerShell 7.6 Neden Geç Geldi? Perde Arkası ve Dersler yazımıza bakabilirsiniz.
E tabiî trusted publishing konusu da burada devreye giriyor.
Bu model npm, PyPI, NuGet, RubyGems. Crates gibi depolarda destekleniyor ve benim gözümde iki faydası var: Birincisi secrets azaltılıyor; ikincisi topluluk için sinyal üretiyor.
Bir paket normalde trusted publishing kullanırken aniden kullanmayı bırakıyorsa insanın aklına doğal olarak soru geliyor:
“Burada ne değişti?” Bu soru bazen bir güvenlik ihlalinin ilk ipucu oluyor.
Küçük startup mı, enterprise mı?
Küçük startup tarafında olay genelde hız odaklı ilerliyor ve ben buna kızmıyorum; herkes ayağa kalkmaya çalışıyor sonuçta.
Ama startup’ın da en azından hayatı action’larını pinlemesi lazım.
Enterprise tarafta işe mevzu başka:
çok sayıda repo,
çok sayıda sahip,
çok sayıda onay akışı…
Burada merkezî politikalar olmadan işi elle yönetmek mümkün olmuyor.
Aksi hâlde biri düzeltme yaparken öbürü fark etmeden geri açıyor.
Tam bir kedi-fare oyunu.
Maalesef. Bu konuyla ilgili github ile ilgili önceki yazımız da göz atmanızı tavsiye ederim.
- Kritik repo’larda branch protection kullanın. — ciddi fark yaratıyor
- Pinned action dışında dış kaynak kabul etmeyin.
- Secrets yerine OIDC tercih edin. — bunu es geçmeyin
- Aylık olarak advisory incelemesi yapın.
- User input geçen job’larda escaping kontrolü koyun.
npm taraması neden önemli? Çünkü gürültü azalmıyor
npm dünyası inanılmaz büyük; günde on binlerce paket yayınlanıyor denince kulağa teorik geliyor. Gerçek hayat tam öyle değil. Ben bunu ilk kez geniş ölçekte duyduğumda şaşırmıştım. Sonra birkaç müşteri ortamında dependency yoğunluğunu görünce “tabiî ya” dedim. Kütüphane sayısı arttıkça saldırı yüzeyi de büyüyor. GitHub’ın her npm sürümünü malware açısından taraması bu yüzden kıymetli. Ama buradaki küçük hayal kırıklığım şu:
Tek başına tarama yetmiyor. Tespit geldiğinde insan incelemesi şart oluyor çünkü false positive meselesi hiç bitmiyor. Yanı otomasyon iyi ama son kararı hâlâ zeki olmayan sistemlere bırakınca işler dağılıyor. Bence doğrusu hibrit yaklaşım.
Tespit ile müdahale arasında boşluk bırakmayın
Bazı ekipler “nasıl olsa scanner yakalar” rahatlığına kaçıyor. Bu rahatlık kısa vadede hoş gelebilir ama uzun vadede pahalıya patlıyor. Ben Azure danışmanlığı yaparken hep şunu söylerim:
Tespit ayrı,
yanıt ayrı,
geri alma ayrı konudur. İlginç, değil mi? Hepsini tek sepet sanarsanız gece yarısı telefon çalar!
# Basit örnek yaklaşım
# Action'ları commit SHA ile sabitleyin
uses: actions/checkout@8ade135a41e...
uses:/some-third-party-action@c0ffee1234...
# Secret yerine OIDC tabanlı geçici kimlik kullanın
permissions:
id-token: write
contents: read
Beni sahada en çok zorlayan şey teknikten çok disiplin öldü
Yanı, Açık söyleyeyim; çoğu kurumda teknoloji eksik değil.
Eksik olan şey tutarlılık.
Bir ekip pinning yapıyor,
öbürü yapmıyor;
biri OIDC’ye geçmiş,
öteki hâlâ eski secret dosyasını taşıyor;
sonra herkes “neden alarm geldi?” diye bakışıyor.
Bakın şimdi… sorun çoğu zaman araçta değil süreçte çıkıyor.
AZ-104 hazırlığında öğrendiğim ağ segmentasyonu mantığıyla bunun arasında ciddi paralellik görüyorum:
Dar alan,
minimum yetki,
net sınırlar…
CI/CD’de bunlar yoksa pipeline büyüdükçe risk de büyüyor.
Ve kurumsalda büyüyen şey genelde risk oluyor. (ne yazık ki).
Bir arkadaşım Londra’daki küçük fintech girişiminde bunu uyguladı;
sadece trusted publishing’e geçerek üç ay içinde yanlış credential kullanımını ciddi biçimde azalttılar — yüzde vermeyeyim çünkü ortamdan ortama değişir — ama operasyon ekibinin yüz ifadesi değiştiğini bizzat anlattı bana.
İşte o an anladım:
bazı iyileştirmeler raporda değil pratikte hissediliyor.
Kendi çalışma listem nasıl görünüyor?
Eğer bugün sıfırdan sertleştirme yapacak olsam önce şunlarla başlarım:
- Tüm hayatı workflow’lar için CodeQL taramasını açarım.
- Tüm üçüncü parti action’ları commit SHA’ye sabitlerim
- .pull_request_target kullanımını gözden geçiririm
- User input geçen adımlarda injection testi yaparım
- Mümkün olan her yerde OIDC ve trusted publishing’e geçerim.
Bir dakika, şunu da ekleyeyim: Advisory Database takibini sadece güvenlik ekibine bırakmamak lazım.
Sıkça Sorulan Sorular
GitHub Actions’da en kritik güvenlik riski nedir?
Genelde kullanıcı girdisinin işlenmesi sırasında oluşan injection açıkları. Secrets sızıntısıdır. Bilhassa kötü yapılandırılmış workflow’lar saldırgan için kolay hedef olur.
`pull_request_target` neden riskli kabul ediliyor?
Çünkü bu tetikleyici çoğu senaryoda yüksek ayrıcalıklı bağlamda çalışabilir. Dış katkılarla birleşince beklenmeyen kod çalıştırma riski doğar.
Action’ları neden commit SHA ile pinlemek gerekiyor?
Tag’ler değişebilir ama commit SHA sabittir. Bu yüzden supply chain manipülasyonuna karşı daha güvenlidir.
OIDC kullanmak secrets ihtiyacını tamamen bitirir mi?
Her durumda tamamen bitirmez ama büyük kısmını azaltır. Geçici ve kapsamlı kimlik doğrulama sağladığı için pratikte çok güçlüdür.
Kaynaklar ve İleri Okuma
GitHub Blog — Securing the open source supply chain across GitHub
GitHub Docs — CodeQL for GitHub Actions
GitHub Docs — Security hardening with OpenID Connect
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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder