GitHub App Token Formatı Değişiyor: ghs_ Sonrası Yeni Dönem

Bakın şimdi, GitHub’dan geçen gün düşen bir duyuru var ki, eğer kendi GitHub App’ınızı yazıyorsanız ya da CI/CD pipeline’larınızda GITHUB_TOKEN ile uğraşıyorsanız, bunu kesinlikle kaçırmamanız lazım. 27 Nişan 2026’dan itibaren installation token’ların formatı değişiyor. Hem de öyle “birkaç karakter ekledik” tadında değil; uzunluk neredeyse 13 katına çıkıyor. Şaka değil.

İlk duyduğumda dürüst olayım, “ya bu kadar büyük bir şey neden bu kadar sessiz duyuruluyor” diye düşündüm. Sonra biraz kurcalayınca anladım: GitHub aslında bunun altyapısını epey önceden hazırlamış. Ama Türkiye’deki ekiplerin çoğu şu anda bu duyurudan habersiz çalışıyor, işin can sıkıcı tarafı da bu zaten; Logosoft’ta birkaç müşteri projemizde tam da bu hafta içinde token validasyonu yapan eski kodlara bakmaya başladık (yanlış duymadınız) (eh, fena değil). Evet, kırılan yerler var.

Bi saniye — Lafı uzatmadan söyleyeyim, neyin değiştiğini, neden böyle bir şeye gidildiğini ve sizde patlamadan önce ne yapmanız gerektiğini anlatayım.

Tam Olarak Ne Değişiyor?

Araya gireyim: Mevcut durumda GitHub App installation token’ları baya tanıdık bir kalıpta geliyor: ghs_ öneki, üstüne 36 karakterlik rastgele bir string, sonra da toplamda 40 karakterlik bir yapı. Düz, sade, kolay kontrol ediliyor; yıllardır da kimse çok kurcalamıyordu.

Evet. Bu kadar basit.

Yeni format işe biraz kafayı karıştırıyor, çünkü işin içine app ID giriyor. Token’ın şekli de uzayıp gidiyor: ghs_APPID_JWT (bizzat test ettim). Yanı artık önek sadece önek değil, aynı zamanda token’ın içinde kimlik bilgisi de var; uzunluk da yaklaşık 520 karaktere çıkıyor (hatta sabit değil, içeriğe göre oynuyor), dolayısıyla ilk bakışta “bu ne şimdi?” dedirtiyor (en azından benim deneyimim böyle)

• Önek: Hâlâ ghs_ (bu değişmiyor, iyi haber).
• Yapı: ghs_APPID_JWT şeklinde — yanı app ID’si önek olarak token’ın içine giriyor.
• Uzunluk: Yaklaşık 520 karakter. Hatta sabit bile değil — token’ın içeriğine göre değişiyor.
• İçerik: JWT formatında, GitHub’ın internal issuer’ı tarafından imzalanıyor.

Açık konuşayım, Daha açık söyleyeyim, peki neden? Çünkü burada asıl fikir stateless tarafa kaymak. Yanı GitHub her doğrulamada veritabanına dönüp “bu token geçerli mi, kime ait?” diye tek tek bakmak zorunda kalmıyor; token kendi bilgisini taşıyor, sistem de önü okuyup karar veriyor — bence çok yerinde bir karar —. Klasik JWT yaklaşımı işte, hani bazen fazla süslü görünür ama burada gerçekten iş görüyor (inanın bana)

Neyse, çok dağıtmayayım; can alıcı detay şu: doğrulama mantığı değişince operasyonel yük de azalıyor gıbı duruyor.

JWT içeriğinin signature‘ı GitHub-internal bir issuer ile imzalanıyor. Yanı siz client tarafta bunu validate etmeye kalkmayın — kıramazsınız zaten, ama daha önemlisi, etmemelisiniz. Token sizin için opaque (kara kutu) olmalı. Çoğu zaman olduğu gıbı.

Aslında, Açık konuşayım, bu noktada insanın aklına hemen “tamam da ben bunu nasıl okuyacağım?” sorusu geliyor. Cevap kısa: okumaya çalışmayacaksınız; özellikle client tarafında bu tokene güvenip içerik çözmeye kalkmak yerine önü opaque bırakmak daha doğru oluyor,. Hem tasarım öyle hem de güvenlik tarafı başka türlü saçmalayabiliyor (evet, doğru duydunuz)

Bence işin özü bu. Siz ne dersiniz?

Neden Bu Değişiklik? İşin Mühendislik Tarafı

Şimdi, “GitHub neden böyle bir derde girdi” diye sorabilirsiniz. Açık konuşayım: işin özü scale problemi. GitHub Actions’ın günde milyarlarca token üretip doğruladığını düşünün; her doğrulamada merkezî bir state lookup yapılıyor, yanı database hit var, ve yük arttıkça bu lookup’lar yavaş yavaş darboğaza dönüşüyor.

Açık konuşayım, Stateless token’larda tablo biraz değişiyor. Token’ın imzası geçerliyse ve süresi dolmamışsa, kimseye gidip sormaya gerek kalmıyor. Doğrulama O(1) zamanda bitiyor. AZ-305 sınavına hazırlanırken Azure tarafında da benzer mimarileri kurcalamıştık — Azure AD’nın stateless token validasyonu yıllardır bu mantıkla çalışıyor zaten. GitHub burada biraz geç kaldı gıbı geldi bana.

Doğrusu, Bunu Türkiye’deki şirketler açısından düşünürsek, asıl fark self-hosted runner’larda hissedilecek. Bir bankacılık projesinde, kapalı network içinde GitHub Enterprise Cloud kullanan bir ekibin Actions runner’ı vardı; token doğrulama latency’si onlar için bile (network gecikmesi yüzünden) hissedilir durumdaydı. Yeni format bu tarz workload’larda baya iş görecek, hatta insan şaşırıyor açıkçası.

Burada küçük ama önemli bir ayrım var. Değişiklik sadece şu token tiplerini kapsıyor: (şaşırtıcı ama gerçek)

• GitHub App installation server-to-server token’ları
• Actions GITHUB_TOKEN (aslında bu da bir installation token zaten)
• First-party featured integration’lar (Dependabot, Slack, Teams entegrasyonları vs.)

Açıkçası, Henüz dışarıda kalanlar da var:

• User-to-server token’ları (Copilot code review akışlarında kullanılan tipler) — bunlar için ayrı bir duyuru gelecek
• Personal access token’lar (PAT) — ciddi fark yaratıyor
• OAuth token’ları — ciddi fark yaratıyor
• GitHub Enterprise Server — on-prem kurulum kullananlar bu değişiklikten etkilenmiyor

Sonda söyleyeyim: Türkiye’de regülasyon nedeniyle GHES (on-prem) kullanan finans. Kamu müşterilerimizin şimdilik bu konuyla pek işi yok. Ama bulutta bir şeyler kullanıyorsanız, hazırlığı ertelemeyin; hani sonra “biz bunu kaçırmışız” demek can sıkabiliyor.

Rollout Takvimi: Ne Zaman Ne Olacak?

GitHub bu işi tek hamlede yapmıyor, adım adım gidiyor. İyi de ediyor,. Bir anda kesip atınca ortalık karışıyor; bir buçuk yıl önce SHA-1 emekliye ayrılırken de benzer bir staged rollout vardı (bu konuda daha önce GitHub HTTPS’te SHA-1’i Emekliye Ayırıyor: Ne Değişecek? başlıklı bir yazı yazmıştım, bakabilirsiniz).

Çok konuştum, örnekle göstereyim.

Brownout period kısmı önemli. Kısa süreliğine yeni formatı zorla açıp sonra geri kapatacaklar; böylece hâlâ eski token formatına yaslanan uygulamalar kendini ele verecek, yanı sessiz sedasız bekleyen sorunlar bir anda görünür olacak. Peki bunu neden söylüyorum? Hata loglarınıza o günlerde özellikle bakın derim, çünkü bazen küçük görünen uyarılar asıl kırılmayı önceden söylüyor.

Tuhaf ama, Evet.

Peki neden?

Böyle geçişler biraz can sıkıyor, ama açık konuşayım, başka türlü de ölmüyor; üretimde çalışan sistemleri test etmek için kontrollü baskı lazım ve GitHub da bunu tam orada uyguluyor. Daha fazla bilgi için Microsoft Agent Framework’te Chat History: Nerede yazımıza bakabilirsiniz.

Kodunuzu Kıracak Tipik Hatalar

Şimdi işin can sıkıcı tarafına geldik. Eğer aşağıdaki alışkanlıklardan biri kodunuzda varsa, açık konuşayım, bir yerde tökezlemeniz çok normal:

1. Token Uzunluğunu Validate Etmek

En klasik tuzak bu. Bir sürü kütüphane ve içeride yazılmış kod, token’ı kabul etmeden önce uzunluğa bakıyor; geçen sene bir e-ticaret müşterimizde tam olarak buna benzer bir şey yaşamıştık, farklı bir akıştı ama mantık birebir aynıydı. Şuna benzer bir kod görürseniz, durup el atın:

// YANLIŞ — bu kod 27 Nisan'dan sonra patlar
function isValidToken(token) {
if (token.length !== 40) {
throw new Error('Invalid token format');
}
return token.startsWith('ghs_');
}
// DOĞRU — token'ı opaque kabul et
function isValidToken(token) {
// Sadece prefix kontrolü, uzunluğa karışma
return token.startsWith('ghs_') && token.length > 4;
}

Burada mesele sadece sayı değil. İşin aslı, token artık “şu kadar karakter olmalı” diye okunacak bir metin gıbı davranmıyor; yanı siz ne kadar sıkı kural yazarsanız yazın, yarın format değişince kodunuz gereksiz yere kırılabiliyor.

2. Regex ile Token Yakalama

Loglarda token sızıntısını yakalamak için yazılmış regex’ler de başınıza iş açabilir (bizzat test ettim). ghs_[A-Za-z0-9]{36} gıbı bir pattern kullanıyorsanız, yeni formatı kaçırmanız baya mümkün; üstüne üstlük yeni token’larda _ karakteri token içinde yer aldığı için (APPID ile JWT arasında), karakter setinizi de güncellemeniz gerekiyor. Peki neden? Çünkü eski varsayımınız artık tutmuyor.

İşte tam da bu noktada devreye giriyor. Gateway API v1.5: Stable’a Taşınan Özellikler ve Notlarım yazımızda bu konuya da değinmiştik.

Kısacası, neyse, çok dağıtmayayım; burada kritik nokta şu: regex’i sadece “eski örnekleri yakalıyor mu” diye değil, gerçek üretim trafiğinde neyi kaçırdığını da düşünerek test edin. SELinux Volume Label Değişiklikleri GA: v1.37’de Neler yazımızda bu konuya da değinmiştik.

3. Database Şema Limitleri

Bu da çok yaygın. Token’ları VARCHAR(40) olarak saklıyorsanız, yetmez; hatta VARCHAR(100) bile sızı rahatlatmayabilir. En az VARCHAR(1024) ya da doğrudan — kendi adıma konuşayım — TEXT‘e geçmeniz lazım. Bir finans müşterimizde benzer bir migration’ı 2022’de yapmıştık — Azure SQL’de ALTER COLUMN, büyük tablolarda saatlerce sürebiliyor — o yüzden işi son güne bırakmak pek iyi fikir ölmüyor.

Evet.

Ayrıca şunu da unutmayın: sadece kolon tipi yetmiyor, index boyutları. Uygulamanın o alanı nasıl kullandığı da ayrı dert çıkarabiliyor; yanı tabloyu büyüttüm bitti sanmayın.

4. HTTP Header Boyut Limitleri

Bunu ilk bakışta düşünmemiş olabilirsiniz ama bazı reverse proxy’ler ve API gateway’ler header boyutunu sınırlıyor. NGINX default’unda yaklaşık 8KB var, ama bazı kurumsal load balancer’larda 4KB sınırıyla karşılaşabiliyorsunuz; 520 karakterlik bir Authorization header çoğu zaman sorun çıkarmaz ama, başka header’larla birleşince edge case’e düşmeniz an meselesi olabilir — itiraf edeyim, beklentimin üstündeydi —

Neyse, tam da öyle.

Pratik Hazırlık Rehberi: Ne Yapmalısınız?

İlk iş, sakın olun. Sonra sıraya girin. Daha fazla bilgi için Azure MCP Server .mcpb Paketi: Runtime Derdine Veda yazımıza bakabilirsiniz.

1. Kod tabanınızda arama yapın: length === 40, length == 40, VARCHAR(40), {36} gıbı pattern’leri grep’leyin. Bulduğunuz her yeri tek tek açın, çünkü bazen sorun gözünüzün önünde duruyor ama insan yine de atlıyor, hele yıllar önce yazılmış bir validation varsa iş iyice karışıyor.
2. Token saklama alanlarını kontrol edin: Database, Redis, environment variable, secret manager — hepsinde size limitleri var mı bakın. Azure Key Vault mesela secret değerini 25KB’a kadar destekliyor, orası rahat; ama ortam değişkenlerinde bazı CI sistemlerinde 4KB limiti var, yanı kağıt üstünde basit duran şey pratikte ufak bir duvara çarpabiliyor. (bu kritik)
3. Logging ve monitoring kurallarınızı güncelleyin: Token redaction (maskeleme) yapan regex’leri yeni formata uyumlu hâle getirin. Sentry, Datadog vs. tarafında eski kalıplar kalırsa log’a saçma sapan şeyler düşebiliyor, sonra bir bakıyorsunuz asıl problemi değil yan ürünü temizliyorsunuz.
4. Test ortamında simüle edin: GitHub önümüzdeki haftalarda yeni token’ları lokal test etmek için rehber yayınlayacak. Ama siz şimdiden mock’larınızda 520 karakterlik dummy token’lar kullanmaya başlayın. Evet, uzun görünüyor. Ama tam da bu yüzden iyi.
5. API gateway / proxy konfigürasyonu: Header buffer’ları kontrol edin. NGINX’te large_client_header_buffers, Azure Front Door’da default değerlerle problem olmaz ama özel bir konfigünüz varsa gözden geçirin; çünkü bazen asıl hata kodda değil, aradaki katmanda çıkıyor ve insan ilk başta bunu pek ciddiye almıyor. (bence en önemlisi)

Enterprise vs Startup: Stratejik Yaklaşım Farkı

Şahsen, Küçük bir ekipseniz, açık konuşayım, çoğu şey zaten daha rahat akıyor. Octokit, PyGithub gıbı resmî kütüphaneler token’ı opaque kabul ediyor — onları güncel tutarsanız işiniz büyük ölçüde tamamdır, risk de genelde düşük kalır.

Ama büyük kurumsal yapıdaysanız — özellikle finans, telekom, sağlık gıbı regüle sektörlerde — tablo biraz değişiyor. Çünkü bir yanda in-house yazılmış middleware. Proxy katmanları duruyor, öte yanda audit logging için hazırlanmış custom regex’ler ve SIEM entegrasyonları var; üstüne database şemaları da yıllar önce yazılmış oluyor (kimse dokunmaya cesaret edemiyor), yanı mesele sadece token uzunluğu değil, etrafa yayılmış küçük bağımlılıklar zinciri.

Şimdi gelelim işin can alıcı noktasına.

• Genelde in-house yazılmış middleware/proxy katmanlarınız var
• Audit logging için custom regex’ler kullanıyorsunuz (bence en önemlisi)
• SIEM (Splunk, Sentinel) entegrasyonlarında token pattern’leri tanımlı
• Database şemaları yıllar önce yazılmış, kimse dokunmaya cesaret edemiyor

Bir bankacılık müşterimizde tam da bu sebeple sadece audit log pipeline’ı için 2 günlük bir review oturumu planladık. Şey… ilk bakışta fazla gelebilir ama değdi; bence siz de en az bir sprint’i bu işe ayırın, yoksa sonradan toparlamak daha yorucu oluyor. Daha fazla bilgi için Kubelet Fine-Grained Authorization GA: nodes/proxy Devri yazımıza bakabilirsiniz.

Burada, tam da öyle.

Maliyet ve Performans Tarafı

FinOps gözünden bakınca, işin güzel tarafı şu: bu değişiklik için ekstra bir şey ödemiyorsunuz,. Performans tarafında ufak da olsa bir rahatlama geliyor. GitHub’ın token issuance latency’si düşüyor, o yüzden Actions workflow’larınız biraz daha çabuk ayağa kalkıyor. Peki ne kadar? Belki birkaç yüz milisaniye. Az gıbı duruyor, evet. Ama günde binlerce workflow koşturan bir CI/CD düzeniniz varsa, o kırıntılar birikip dakikaya dönüyor, hatta bazen fark etmeden akışı epey toparlıyor.

Storage tarafında işe tablo tersine dönüyor. Token’ları bir yerde saklıyorsanız, 40 karakter yerine 520 karakter tutacaksınız; yanı yaklaşık 13 kat büyüme var. Kulağa biraz kaba geliyor, değil mi? Eğer milyonlarca token kaydıyla uğraşıyorsanız (mesela bir token cache servisi işletiyorsanız), bu iş storage maliyetini gerçekten yukarı çeker. Ama açık konuşayım, çoğu uygulamada bu seviye sadece noise oluyor; hissedilir ama can sıkıcı ölmüyor.

Bu arada konu buraya gelmişken, GitHub Actions tarafındaki pipeline güvenliğiyle ilgili Azure DevOps Advanced Security: Tek Tıkla CodeQL Devri yazıma da bakabilirsiniz — özellikle token leak detection senaryolarını kurcalıyorsanız, orada işin pratik tarafına biraz daha yakından giriyorum.

Benim Endişelerim ve Eleştirilerim

Şimdi açık konuşayım: Bu değişiklik kağıt üstünde fena değil. Stateless token, daha iyi performans, daha az merkezî bottleneck (kendi tecrübem). hepsi kulağa mantıklı geliyor. Ama işin iletişim tarafında GitHub biraz eksik kalmış gıbı duruyor, yanı en azından bana öyle geldi.

Şahsen, Birinçisi, 27 Nişan’da rollout başlıyor ama duyuru görece yeni. Kurumsal müşterilerimde gördüğüm kadarıyla, Türkiye’de bu tıp geçişler biraz ağır ilerliyor; çünkü değişiklik yönetimi süreçleri uzuyor, CAB (Change Advisory Board) toplantıları giriyor, test ortamı doğrulamaları yapılıyor, prod-like simülasyonlar dönüyor. Hop diye 2 ay gidiyor. Bu takvim bana sıkışık geldi, açık söyleyeyim.

İkincisi, “lokal test rehberi önümüzdeki haftalarda gelecek” demişler. Yanı şu an elimizde resmî bir test mekanizması yok. Evet, bu biraz tuhaf. Migration için hazırlık yapmamızı istiyorsanız, hazırlık aracını da yanında vermeniz lazım; yoksa ekipler neyi neye göre deneyecek, nasıl desem, havada kalıyor.

Hani, Üçüncüsü — ve burada iş biraz can sıkıyor — user-to-server token’lar için takvim hâlâ net değil. Copilot code review akışlarını kullanan ekipler açısından bu ciddi bir soru işareti. Copilot Chat Pull Request’lerde: Gerçekten Fark Yaratıyor yazısında da değindiğim gıbı, Copilot review’leri yeni yeni production-grade tarafa kayıyor; bu belirsizlik de o alana yatırım yapan ekiplerin hızını kesebilir. Tam da öyle.

Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.

Sıkça Sorulan Sorular

Mevcut token’larım anında geçersiz mi oluyor?

Hayır, merak etme. Mevcut token’lar süreleri dolana kadar — yanı genelde 1 saat — normal çalışmaya devam ediyor. Yeni format sadece yeni üretilen token’lara uygulanıyor. Yanı aslında breaking change anlık değil, kademeli bir geçiş bu.

GitHub Enterprise Server kullanıyorum, ne yapmalıyım?

Şimdilik hiçbir şey yapman gerekmiyor. Bu değişiklik sadece GitHub Enterprise Cloud ve Data Residency ortamlarını etkiliyor, on-prem GHES kurulumların bu işten muaf. Ama bence yine de hazırlıklı olmakta fayda var — uzun vadede aynı format buraya da gelecek (kendi tecrübem)

Octokit veya PyGithub kullanıyorum, kod değişikliği yapmam gerekiyor mu?

Büyük ihtimalle hayır. Resmî kütüphaneler zaten token’ı opaque olarak ele alıyor. Yine de kütüphanelerinin güncel sürümünü kullandığından emin ol — tecrübeme göre eski sürümlerde token uzunluğu üzerinden assertion yapan testler çıkabiliyor, hani oradan sürpriz gelebilir.

Bunu biraz açayım.

Token’ı kendim validate edebilir mıyım?

Hayır. Açıkçası etmemen de gerekiyor zaten. JWT, GitHub-internal bir issuer ile imzalanıyor ve public key seninle paylaşılmıyor. İçeriğini parse edip bir şeyler almaya çalışmak da kötü bir pratik —. GitHub bu içeriği önceden haber vermeden değiştirebilir. Mantıklı değil mi? Token senin için her zaman opaque kalmalı, mesela bunu bir kara kutu gıbı düşün.

Rollout sırasında sorun yaşarsam ne yapacağım?

27 Nişan – Mayıs ortası arasındaki ilk faz için GitHub Support’a opt-out talebi açabilirsin. Sonraki fazlarda bu seçenek olmayabilir. Bence ilk fazı bir test penceresi olarak kullanmak çok mantıklı — brownout period’una geldiğinde geri dönüş şansın ciddi ölçüde azalıyor.

Kaynaklar ve İleri Okuma

Dürüst olmak gerekirse, GitHub Changelog: Notice about upcoming new format for GitHub App installation tokens — Resmî duyuru, tüm detaylar burada.

GitHub Docs: About authentication to GitHub — Token tipleri ve önek konvansiyonları için referans dokümantasyon.

Generating an installation access token for a GitHub App — Installation token üretiminin nasıl yapıldığını anlatan resmî rehber.

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

Ddev’e Aljibe Eklemek: Kurulu Projede Sürprizler14 Nis 2026

JetBrains Copilot: Inline Agent Mode ve Yeni Oyuncaklar24 Nis 2026

Autoscaling Faturayı Şişiriyorsa: Sessiz Tuzaklar13 Nis 2026

GitHub Status Sayfası Yenilendi: Şeffaflık Dönemi Başladı19 Nis 2026