Süresi hiç dolmayan anahtar: Sızan yüzlerce GitHub App anahtarı hâlâ çalışıyor

GitHub App kimliğini nasıl kanıtlıyor?

GitHub App’ler, bir organizasyona kurulup senin yerine iş yapan uygulamalar: CI araçları, PR’lara yorum yazan tarayıcılar, iş takip entegrasyonları, küçük botlar. Her birinin kendi kimliği ve izinleri var.

Kimlik zinciri üç adımlı:

1. Uygulamanın sahibi GitHub’dan bir özel anahtar (private key) oluşturuyor.
2. Uygulama bu anahtarla bir JWT imzalıyor. Bu kısa belge en fazla 10 dakika geçerli.
3. JWT karşılığında, kurulu olduğu organizasyon için bir kurulum token’ı alıyor. Bu token 1 saat sonra geçersiz oluyor.

Token’lar kısa ömürlü, yani güvenli görünüyor. Sorun en baştaki anahtarda. GitHub’ın belgelerine göre bu anahtarların son kullanma tarihi yok. Biri elle silene kadar çalışıyorlar.

Sunucu JWT’nin imzasını doğrulamazsa ne olduğunu Microsoft Titan yazısında anlattık.

GitGuardian ne buldu?

Sızan parolaları ve anahtarları tarayan GitGuardian, 22 Eylül’de bir araştırma yayınladı. Herkese açık yerlere sızmış 500 binden fazla RSA anahtarından, yanında bir uygulama kimliği bulunan 4.802 tanesini ayırdılar. Her biriyle GitHub API’sine giriş denediler.

Sonuç:

• 474 anahtar (yaklaşık %10) hâlâ çalışıyordu. Bunlar 440 farklı uygulamaya aitti.
• Bu uygulamaların %72’si özel depoları okuyabiliyordu, 207’si yazabiliyordu.
• 44 uygulamada organizasyon yöneticisi yetkisi vardı. 98’i iş akışlarını (workflow) değiştirebiliyordu.

Birkaç örnek:

• Crusher.dev adlı bir test aracının anahtarı Kasım 2020’de sızmış. Proje terk edilmiş, ama anahtar hâlâ çalışıyordu.
• ABD Hastalık Kontrol ve Önleme Merkezi’ne (CDC) bağlı bir organizasyonun uygulama anahtarı Nisan 2025’te sızmış. Uygulama iki özel depoya yazabiliyordu. Anahtar ancak GitGuardian’ın bildiriminden sonra, 18 Eylül 2026’da iptal edildi. Yani yaklaşık 17 ay açıkta kaldı.
• 300 organizasyona kurulu bir uygulamanın anahtarı Ocak 2024’te yanlışlıkla bir commit’e girmişti.

Araştırmaya göre uygulamaların %59’u tek bir yere kuruluydu. Yani çoğu, biri bir zamanlar yazıp sonra unuttuğu iç araçlar.

Neden bu kadar tehlikeli?

Anahtarı ele geçiren, uygulama adına token alabiliyor. GitHub’ın gözünde bu token, uygulamanın kendi token’ından farksız. Uygulama nereye kuruluysa oraya aynı yetkilerle giriyor. Yazma yetkisi varsa depoya zararlı kod ekleyip bir tedarik zinciri saldırısı başlatabiliyor. Etkilenen sadece uygulamanın sahibi değil, onu kuran herkes.

Videoda haklı bir itiraz da var: SSH anahtarların da süresiz. Fark şu: GitHub ürettiği her token’a kısa bir ömür veriyor, ama hepsini üreten anahtara vermiyor.

Bir yapay zekâ aracından çalınan OAuth anahtarının Vercel’e nasıl kapı açtığını Vercel saldırısı yazısında anlattık.

Kontrol listesi

Bir GitHub App’in sahibiysen:

• Anahtarı yenile (rotate). Bir uygulama için en fazla 25 anahtar tutabiliyorsun. Önce yenisini oluştur ve kullanmaya başla, sonra eskisini sil. Arada kesinti olmaz.
• Anahtarı koda, depoya ya da açık bir dosyaya koyma. GitHub’ın önerisi, onu bir anahtar kasasında (key vault) sadece imzalama için tutmak.
• Uygulamaya sadece gereken izinleri ver. Token isterken de belirli depolar ve izinlerle sınırlayabilirsin.
• Depolarını sızmış sırlar için tarayan bir araç kullan. Commit öncesi çalışan bir kontrol, hatayı daha internete çıkmadan yakalar.

Bir organizasyonu yönetiyorsan:

• Kurulu uygulamaların listesine bak. Sahibi kalmamış ya da artık kullanılmayanları kaldır.
• Her uygulamanın hangi depolara eriştiğine bak. “Tüm depolar” yerine sadece gerekenleri seç.

Düşün

• En son ne zaman hesabında ya da şirketinde kurulu GitHub uygulamalarının listesine baktın?
• Kullandığın anahtarlardan hangilerinin süresi hiç dolmuyor?

Kendi cümlelerimizle yazılmış bir özettir, çeviri değildir. Tüm kaynaklar yukarıda.