GitHub App Token Formatı Değişiyor: Hazırlık Rehberi
Geçen hafta bir müşterimizin CI/CD pipeline’ı patladı. Sebep mi? Token uzunluğu kontrolü. Adam yıllarca ghs_ ile başlayan 40 karakterlik token’lara güvenmiş, kodun bir yerine if len(token) != 40 yazmış; sonra bir baktık, GitHub bu formatı değiştiriyor ve o tarz hardcoded kontrollerin hepsi tek tek tökezleyecek. Nisan 2026’nın sonundan itibaren yeni token’lar yaklaşık 520 karakter uzunluğunda olacak — evet, 40’tan 520’ye. Bu yazıda ne değişiyor, neden değişiyor, ve en önemlisi sız ne yapmalısınız, onlara bakalım.
📋 İçindekiler
-
Şimdi gelelim işin can alıcı noktasına.
Log ve Monitöring Sistemleri
Token’ın bir kısmını loglayan mekanizmalarınız varsa, mesela ilk 8 karakteri alıp maskeleyen yapılar kurduysanız, bunlar da etkilenebilir (ki bu çoğu kişinin gözünden kaçıyor). Yeni formatta
ghs_APPID_kısmından sonra JWT geliyor; yapı biraz farklı ilerliyor. Log parsing kurallarınızı gözden geçirin, çünkü eski varsayımlar burada sessizce patlayabilir.Secret Scanning ve Vault Konfigürasyonları
Eğer HashiCorp Vault veya Azure Key Vault’ta token boyutu için limit koyduysanız, önü güncellemeniz gerekecek (şaşırtıcı ama gerçek). Ayrıca GitHub’ın kendi secret scanning özelliği yeni formatı tanıyacak. Üçüncü parti araçlar (GitLeaks, TruffleHog vb.) hemen yetişemeyebilir, orası biraz bekleme işi. Onları da takip edin. Bu arada bu konuyla bağlantılı olarak
Network tarafında da token boyutu büyüyor, evet. 40 byte’tan 520 byte’a çıkmak tek başına göz korkutmuyor, (ki bu çoğu kişinin gözünden kaçıyor). Dakikada binlerce request dönüyorsa o küçük farklar birikiyor; yine de açık konuşayım, sırf bundan dolayı bant genişliği darboğazı yaşarsınız demek biraz abartı olur (buna dikkat edin). Hani bazen sayılar büyür ama etki sandığınız kadar dramatik olmaz ya, işte o hesap.
Asıl maliyet riski başka yerde dürüyor: hazırlıksız yakalanırsanız kırılan entegrasyonları toparlamak için harcayacağınız mühendislik saati. Bir finans kuruluşunda bu tip bir token format değişikliğini 2 ay gecikmeyle fark etmişlerdi (sonra düzeltme işi 3 haftalık sprint yemişti), yanı mesele token’ın kendisi değil, geç kalınca çıkan operasyon faturası. Önceden hazırlanmak daha ucuz. Maalesef.
Pratik Hazırlık Adımları: Şu An Ne Yapmalısınız?
Tamam, lafı uzatmayalım. Şimdi işin pratik kısmına geldik. Yapılacaklar aslında net, ama küçük bir detay var: bazı ekipler bunu görünce “sonra bakarız” deyip geçiyor, sonra da sabah 09:10’da alarm çalıyor.
- Kod taraması yapın: Repository’lerinizde
ghs_,len(token),token.length,VARCHAR(40)gibi pattern’leri arayın. Bunları düzeltin; çünkü ilk bakışta masum duran bu kontroller, ileride sizi sessizce duvara toslatabiliyor. - Token’ları opaque string olarak ele alın: Parse etmeyin, uzunluk kontrolü yapmayın, içindeki JWT’yi decode etmeye çalışmayın. Şey, burada refleksle “bir bakayım içinde ne var” deme alışkanlığı var ya, önü bırakmak gerekiyor. (bu kritik)
- Veritabanı şemalarını güncelleyin: Token sütunlarını en az 1024 karakter veya TEXT yapın. Ben olsam burada biraz cömert davranırım, çünkü 40 karakterlik alanlar bugün idare eder gibi görünse de yarın sıkıntı çıkarabiliyor.
- Üçüncü parti entegrasyonları kontrol edin: Kullandığınız GitHub App’lerin, webhook handler’ların ve CI/CD araçlarının bu değişikliğe hazır olduğundan emin olun. Evet, kendi kodunuz tamam olsa bile dışarıdaki bir bağımlılık işi bozabiliyor; hani en sınır bozucu yer tam da burası.
- GitHub’ın brownout dönemini takip edin: Mayıs-Haziran arasında test imkânı sunulacak, bunu kaçırmayın. Bu pencereyi atlayan ekipler genelde son anda koşuşturuyor, sonra da “neden şimdi patladı?” diye soruyor.
Küçük ekipseniz muhtemelen yarım günde halledersiniz. Büyük kurumsal yapıdaysanız işler biraz dağılıyor tabiî; o yüzden şimdiden bir JIRA ticket açıp ilgili ekiplere paylaştırın (güvenlik ekibi, DevOps ekibi, uygulama geliştirme ekibi), çünkü tek kişinin omzuna bırakınca konu uzuyor da uzuyor.
Copilot kullananlar da dikkatli olsun. Bu iş sadece bugünün token yapısıyla bitmiyor; ileride user-to-server token’lar tarafında da değişiklik gelecek gibi dürüyor. GPT-5.5 GitHub Copilot’a Geldi: Ne Değişiyor, Ne Kadar Ediyor? yazısında Copilot’un son durumuna da bakabilirsiniz.
Garip gelecek ama, Evet.
Sıkça Sorulan Sorular
Mevcut GitHub App installation token’larım çalışmaya devam edecek mi?
Evet, mevcut token’lar expire olana kadar sorunsuz çalışıyor. Ama yeni oluşturulan token’lar artık yeni formatta geliyor —. Aslında kodunuzu er ya da geç güncellemeniz kaçınılmaz.
GitHub Enterprise Server kullanıyorum, etkileniyor muyum?
Hayır, hiç etkilenmiyorsun. Bu değişiklik sadece GitHub Enterprise Cloud ve Data Residency ortamlarını kapsıyor. Enterprise Server’da herhangi bir şey değişmiyor, merak etme (evet, doğru duydunuz)
Yeni token’daki JWT’yi decode edip kullanabilir mıyım?
Kullanmamalısın, bence bu önemli bir nokta. GitHub açıkça söylüyor: JWT, GitHub’ın internal issuer’ı tarafından imzalanıyor. Client app’ler token içeriğine bağımlılık oluşturmamalı. Yanı token’ı opaque bir string olarak ele al, noktayı koy.
Actions workflow’larım otomatik olarak bozulur mu?
Standart kullanımda hayır. GITHUB_TOKEN’ı doğrudan authentication header’ında kullanıyorsan sorun olmaz. Ama — tecrübeme göre asıl tehlike burada — token uzunluğunu kontrol eden ya da token’ı parse eden custom logic varsa, evet, kırılabilir. Sorun yaşarsan GitHub Support’tan geçici opt-out talep edebilirsin.
Token uzunluğu tam olarak kaç karakter olacak?
Yaklaşık 520 karakter, ama sabit değil. Hani token içindeki veriye göre değişebiliyor. Bu yüzden açıkçası kesin bir uzunluk beklemeyi bırak, değişken uzunluklu string kabul eden bir yapıya geç — çok daha sağlıklı olur.
Kaynaklar ve İleri Okuma
GitHub Blog: Notice about upcoming new format for GitHub App installation tokens
GitHub Docs: Generating an installation access token for a GitHub App
GitHub Docs: Automatic token authentication in GitHub Actions (bizzat test ettim)
Bu yazı yapay zeka (büyük dil modelleri) ile hazırlanmış, insan editör tarafından incelenmiştir. İçerik üretim sürecimiz.Aşkın KILIÇYazar20+ 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.
AZ-305AZ-104AZ-500AZ-400DP-203AI-102İlgili Yazılar
- Kod taraması yapın: Repository’lerinizde
İlginizi Çekebilir
Arda K.
CI/CD pipeline’larında token’ı bir yere hardcode edip uzunluk kontrolü yapan var mı gerçekten diye düşündüm ama production’da gördüm, var tabii. Bizim sistemde de regex ile doğrulama yapan bir yer vardı, şimdi kontrol etmem gerekecek. Stateless yapıya geçiş mantıklı ama migration süreci her zaman sancılı oluyor.
Yasemin İ.
Bizim pipeline’da token uzunluğunu regex ile kontrol eden bir kısım vardı, tam olarak böyle bir değişiklikle patlamıştı. Hardcoded varsayımların ne kadar kırılgan olduğunu bir kez daha görüyoruz. Bu arada şu yazınız da güzeldi: GPT-5.5 GitHub Copilot’a Geldi: Ne Değişiyor, Ne Kadar Ediyor? — https://www.askinkilic.com.tr/gpt-55-github-copilota-geldi-ne-degisiyor-ne-kadar-ediyor/
Cenk B.
Biz de geçen ay bir pipeline’da token uzunluğunu validation’a sokmuştuk, tam bu değişikliği okuyunca içim sıkıştı. Acaba ghs_ prefix’ini regex ile kontrol eden yerleri tek tek bulmak için otomatik bir yol var mı? Bu arada şu yazınız da aklıma geldi: GitHub Bildirim Saklama Süresi Kısalıyor: Ne Yapmalı? — https://www.askinkilic.com.tr/github-bildirim-saklama-suresi-kisaliyor-ne-yapmali/
Yorumlar kapalı.
3 comments