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.

Ne Değişiyor ve Neden Önemli?

GitHub, App installation token’larının formatını epey değiştiriyor. Eski format 40 karakterlik, düz bir string’di; yeni tarafta işe ghs_APPID_JWT benzeri, yaklaşık 520 karaktere uzayan. Içinde JWT taşıyan bir yapı geliyor (en azından benim deneyimim böyle). Prefix yine ghs_ olarak kalıyor, ama geri kalan kısmı görünce insan bir an durup “bu ne şimdi?” diyor (ben de ilk duyduğumda şaşırmıştım)

Bir dakika — bununla bitmedi.

Aslında — dur bir saniye, önce şunu net söyleyeyim: bu işin arkasında performans ve ölçeklenebilirlik var. GitHub’ın eski token modeli stateful çalışıyordu,. Her token üretildiğinde sunucu tarafında bir kayıt tutuluyordu; yeni model işe stateless gidiyor. JWT’nın içine hedef installation bilgisi, uygulama verisi ve temel doğrulama detayları zaten gömülü oluyor, böylece GitHub yoğun yük altında bile token üretimini daha rahat taşıyabiliyor.

Bunu şöyle düşünün: eskiden her bilet için gişeye uğruyordunuz, sonra sıra bekliyordunuz, sonra da görevli bir şeyler kontrol ediyordu; şimdi e-bilet mantığı geliyor (bilet sizde, bilgi biletin içinde, ayrı bir yere gidip kayıt açtırma derdi yok). Kulağa basit geliyor ama işin aslı performans tarafında baya fark ediyor.

Önemli: JWT içeriği GitHub’ın internal issuer’ı tarafından imzalanıyor. Sız bu JWT’yi decode edip validate etmeye çalışmayın — zaten yapmamanız gerekiyor. Token’ı opaque string olarak ele alın, içine bakmayın, uzunluğuna güvenmeyin.

Ha bu arada, mevcut token’larınız expire olana kadar çalışmaya devam ediyor. Panik yok. Ama yeni basılan token’lar artık yeni formatta gelecek; yanı bugün gördüğünüz kısa token’a yarın da aynı gözle bakmayın, çünkü sahne değişti.

Evet.

Rollout Takvimi: Hangi Tarihte Ne Olacak?

GitHub bu işi tek seferde bırakmıyor, yanı bir sabah uyanıp her şey değişmiş olmuyor. Takvim kabaca şöyle akıyor:

Dikkat edin, ilk dalgada hedef doğrudan Actions içindeki GITHUB_TOKEN oluyor. Eğer workflow’larda bu token’ı sadece authentication header’ında kullanıyorsanız — çoğu ekip zaten böyle gidiyor — büyük ihtimalle bir şey patlamaz. Ama dur bir saniye, token’ı alıp bir yere yazıyorsanız, sonra da uzunluk kontrolü yapıyorsanız ya da veritabanında sabit boyutlu bir kolona basıyorsanız… işte orada işler biraz karışabiliyor.

Türkiye’deki Kurumsal Ortamda Bu Neden Daha Kritik?

Bakın şimdi, bu değişiklik dünya genelinde herkes için geçerli, ama Türkiye’deki şirketlerde iş biraz daha karışıyor. Bunu boşuna söylemiyorum; son 3-4 yılda onlarca kurumsal müşteride GitHub Enterprise. Azure DevOps entegrasyonları kurarken aynı tabloyu defalarca gördüm, bazı yerlerde token yönetimi düzgündü, bazı yerlerde işe işler bayağı dağınıktı.

Birincisi şu: Türkiye’de özellikle bankacılık ve finans tarafında token’lar çoğu zaman bir secret manager içinde tutuluyor, ama bazen — maalesef — environment variable olarak düz metin halinde bir yerlere bırakılmış oluyor. Token uzunluğu değişince de bazı eski bash script’lerdeki substring işlemleri patlayabiliyor; 2023’te bir telekom projesinde buna benzer bir şey yaşamıştık, AWS’nın token formatı değişmişti, adamların script’i token’ın ilk 20 karakterini log’a basıyordu ve yeni formatta ortaya çıkan şey bayağı anlamsız görünüyordu. Güvenlik ekibi de hâliyle alarma geçti, 2 gün boyunca “sızıntı mı var” diye didik didik baktılar. Sonuç? Sadece format değişikliği. O kadar.

Bir dakika — bununla bitmedi.

İkincisi: Türkiye’de GitHub Enterprise Cloud kullanımı artıyor ama hâlâ ciddi sayıda firma GitHub Enterprise Server tarafında kalıyor. İyi tarafı şu ki — ki bu tartışılır — bu değişiklik GitHub Enterprise Server’ı etkilemiyor. Sadece Cloud ve Data Residency ortamları kapsamda. Yanı on-premises GitHub kullananlar şimdilik rahat nefes alabilir. Ama — burada küçük bir kıvrım var — buluta geçiş planınız varsa, geçişten sonra bu yeni formatla ister istemez karşılaşacaksınız.

Bir de şu var: Küçük startup’lar genelde token’ı alır, header’a koyar ve devam eder. İş biter. Ama büyük kurumlarda token’ın etrafında wrapper’lar, middleware katmanları, proxy zincirleri olur; her katmanda da biri çıkıp “acaba bu token geçerli mi?” diye kontrol ekler. İşte asıl uğraş orada başlıyor, çünkü o kontrol mekanizmalarının hepsinin güncellenmesi lazım ve enterprise ortamda bu iş 2 günde bitmez, bazen 2 ay sürer.

Durun, bir saniye.

Kodunuzda Ne Kontrol Etmelisiniz?

Şunu fark ettim: Lafı dolandırmadan söyleyeyim: token’ı opaque string gibi görmüyorsanız, bir yerde tökezlersiniz. Şimdi, işin can sıkıcı ama gerekli tarafına geçelim; nerelere bakmanız gerektiğini tek tek ayıklayalım.

Regex ve Uzunluk Kontrolleri

Kodunuzda ghs_[a-zA-Z0-9]{36} gibi bir regex var mı? Ya da len(token) == 40 kontrolü? Varsa, durup bir nefes alın. Onları kaldırın. Yeni tokenlar sabit uzunlukta gelmeyecek, yaklaşık 520 karakter civarı olabilir ama bu bile kesin değil; yanı uzunluğa güvenmek baya riskli. GitHub da zaten açıkça “token uzunluğuna bağımlı olmayın” diyor, hani mesaj net.

# ❌ ESKİ (kırılacak)
if len(token) == 40 and token.startswith("ghs_"):
# token geçerli
pass
# ✅ YENİ (doğru yaklaşım)
if token.startswith("ghs_"):
# token'ı API'ye gönder, geçerlilik kontrolünü GitHub yapsın
pass

Veritabanı Sütun Boyutları

Yanı, Token’ları veritabanında saklıyorsanız, ki bazen mecbur kalınıyor. Çoğu senaryoda ben bunu pek sevmiyorum, sütun boyutunu hemen kontrol edin. VARCHAR(40) ya da VARCHAR(100) varsa işiniz zor; bunu en az VARCHAR(1024) seviyesine çekin. Hatta hiç uzatmadan TEXT kullanın, kafa rahat olsun. 2019’da kendi bir projede benzer bir şey yaşamıştım — OAuth token sütununu 255 karakter bırakmıştım, sonra provider formatı değişti ve insert hataları ardı ardına gelmeye başladı; gece 2’de hotfix çıkardık, uyku da uçtu gitti. O günden beri token sütunlarına temkinli yaklaşıyorum. GitHub Copilot JetBrains’te Inline Agent Modu Geldi yazımızda bu konuya da değinmiştik.

Ş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 Azure DevOps Güvenlik Taraması: Tek Tıkla Başlıyor yazımda da güvenlik taraması tarafına değinmiştim, bakmak isterseniz iş görür.

Actions Workflow’ları İçin Özel Notlar

GITHUB_TOKEN, GitHub Actions tarafında en sık kullandığımız token. Her workflow run’ında otomatik geliyor, iş bitince de expire oluyor. Yeni format ilk olarak bu token’a uygulanıyor, yanı topa önce bu giriyor.

Çoğu senaryoda bir şey çıkmaz. Neden? Çünkü standart Actions kullanımında token’ı ${{ secrets.GITHUB_TOKEN }} ya da ${{ github.token }} ile alıp doğrudan API çağrısına koyuyorsunuz; uzunluğunu ölçmüyorsunuz, parse etmiyorsunuz, sadece header’a iliştirip geçiyorsunuz. Bu akış aynen devam edecek gibi dürüyor.

Ama — hmm, burada biraz durayım… Evet, custom Action’lar! Marketplace’ten indirdiğiniz ya da kendi yazdığınız Action’larda token’ı kurcalayan kod olabilir. Bilhassa de TypeScript ile yazılmış custom Action’larda token validation logic’i gördüm birkaç kere; yanı öyle “nasıl olsa dokunmaz” deyip geçmeyin. Bunları gözden geçirin. Açık kaynak Action kullanıyorsanız, maintainer’ların bu değişikliğe hazırlanıp hazırlanmadığını kontrol edin; popüler olanlar muhtemelen hızlıca güncellenir. Niş kalanlar biraz ağırdan alabilir.

Bir de composite Action tarafında shell script ile token işliyorsanız dikkat. echo $GITHUB_TOKEN | wc -c gibi bir (belki yanılıyorum ama) kontrol varsa, artık 40 değil 520+ dönecek, bu da bazı akışları sessizce bozabilir (özellikle uzunluk kontrolüne güvenen eski scriptlerde). Pipeline’larınızı tarayıp böyle kontroller var mı diye bakmanızı açık konuşayım öneririm. Bu konuyla bağlantılı olarak Axios npm Saldırısı: Azure Pipelines’ta Ne Yapmalı? yazısına da göz atabilirsiniz — pipeline güvenliği tarafında baya iş görüyor.

Maliyet ve Performans Etkisi

Açık konuşayım, bu değişikliğin doğrudan bir maliyet etkisi yok. Token formatı değişiyor diye ekstra para ödemiyorsunuz. Ama işin ilginci burada bitmiyor, dolaylı tarafta birkaç ufak oynama var.

Stateless token’lar, GitHub API’sine giden çağrılarda daha az sunucu tarafı lookup istiyor. Sistem biraz daha az oyalanıyor, özellikle de dakikada yüzlerce istek atan CI/CD akışlarında bu durum rate limiting’e takılma ihtimalini azaltabiliyor, teoride böyle, pratikte işe yükünüze göre değişir. Peki neden? Çünkü her çağrıda arka tarafta ekstra kontrol dönmeyince sistem nefes alıyor. Azure MCP Server Artık Tek Dosyayla Kuruluyor yazımızda bu konuya da değinmiştik.

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. Ingress-NGINX Göçü: 5 Şaşırtıcı Davranış ve Çözümü yazımızda bu konuya da değinmiştik.

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.

1. 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.
2. 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)
3. 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.
4. Üçü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ı.
5. 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 tabii; 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)

Aşkın KILIÇYazar

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.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102

İlgili Yazılar

Azure Local ve Armada: Edge'de Egemen AI Dönemi17 Nis 2026

Azure DevOps Güvenlik Taraması: Tek Tıkla Başlıyor18 Nis 2026

GitHub Copilot Pro Denemeleri Neden Durdu?11 Nis 2026

Azure iPaaS'ta 8. Liderlik: Ne Anlama Geliyor?18 Nis 2026