GitHub Secret Scanning: Genişletilmiş Metadata ve Çoklu Doğrulama

Secret scanning, sahada danışmanlık yaparken beni en çok uğraştıran başlıklardan biri öldü. Bir müşteride oturuyorsunuz, panelde “aktif secret” alarmı yanıyor,. Ortada net bir sahip yok; kimin açtığı belli değil, hangi projeden geldiği belirsiz, sonra üç kişi birden telefona sarılıyor: “Bu senin token’ın mı?” (en azından benim deneyimim böyle) — valla güzel iş çıkarmışlar —

İşte tam bu can sıkıcı noktaya GitHub bir güncelleme çıkardı. Extended metadata ve multipart validation artık GA’da (Genel Kullanıma Açık). Kağıt üstünde küçük dürüyor, evet; ama pratikte triage süresini baya kısaltacak gibi. Hani bazen küçük görünen şey asıl yükü alır ya, bu da biraz öyle. Anlatayım.

Durun, bir saniye.

Önce Sorunu Doğru Tarif Edelim

Secret scanning zaten uzun zamandır GitHub tarafında çalışıyor. Depoya biri yanlışlıkla bir Azure Storage key’i push ederse, GitHub bunu yakalıyor, provider ile konuşup “bu key hâlâ aktif mi?” diye validity check yapıyor. Buraya kadar tamam.

Gel gelelim… alarm düştükten sonra iş bitmiyor, asıl mesele orada başlıyor. Şu sorular bir anda önünüze düşüyor:

• Bu secret kime ait? Hangi kullanıcı oluşturmuş? (bu kritik)
• Ne zaman üretilmiş, ne zaman biteceği belli mi?
• Hangi projenin/aboneliğin altında yaşıyor?
• Rotate edersem ne kırılır?

Vallahi, Eskiden bu cevaplar için provider konsoluna girip token ID ile arama yapmanız gerekiyordu (bizzat test ettim). Azure Portal, AWS Console, Databricks paneli… Her provider ayrı bir yolculuk, ayrı bir ekran, ayrı bir sürpriz (bu beni çok şaşırttı). Şimdi işin güzel yanı şu: bu metadata doğrudan GitHub alert ekranında görünüyor.

Peki Extended Metadata Tam Olarak Ne Getiriyor?

Kısaca anlatayım: GitHub, desteklenen provider’larda validity check yaparken artık sadece “aktif mi?” diye bakmıyor. Yanına bir iki parça bilgi daha çekiyor, hani işin içine biraz bağlam giriyor. Şunlar pakete dahil oluyor:

• Owner bilgisi — token’ı kim oluşturmuş
• Oluşturma ve son kullanma tarihi (bence en önemlisi)
• Proje veya organizasyon bağlamı — hangi tenant, hangi workspace
• Bazı provider’larda ek scope/permission detayları

Bi saniye — Bu metadata sadece detay ekranında durmuyor, o da güzel tarafı. Alert list filtreleri, security campaign oluşturma, webhook event’leri ve REST API üzerinden de erişilebiliyor. Yanı otomasyon yazan biriyseniz, eliniz baya rahatlıyor; ama dur bir saniye, her şey güllük gülistanlık değil, bazı provider’larda alanlar eksik gelebiliyor.

Bir uyarı: GitHub bu konuda best-effort çalışıyor. Metadata her zaman, her token için gelmeyebilir. Provider’ın API’si o an cevap vermezse ya da token tipi desteklenmiyorsa boş görebilirsiniz. Yanı “bu alan yoksa alarm sahte” gibi bir mantık kurmayın.

Multipart Validation Neyi Çözüyor?

Burada iş biraz daha teknikleşiyor, ama can alıcı nokta şu: bazı secret türleri tek başına anlamlı değil. Mesela Databricks token’ı elinizde varsa, tek başına pek bir şey ifade etmiyor; yanında workspace URL’i de lazım. Nereye bağlanacağınızı anlayasınız. Azure tarafında da benzer durum var, Storage Account key’i alıyorsunuz. Endpoint belli değilse ortada yarım kalmış bir parça dürüyor.

İnanın, Eski sistemde GitHub bu tip secret’lara bakıp net karar veremiyordu; (şaşırtıcı ama gerçek). İkinci parçayı bulamazsa validity check yapamıyordu. Şimdi multipart validators devreye giriyor — depoda başka bir yerde workspace URL’i varsa ya da host bilgisi geçiyorsa, ikisini eşleştirip provider’a soruyor. Şey gibi düşünün, tek anahtar yetmiyor; kapının kendisini de bulmanız gerekiyor (bu beni çok şaşırttı)

Aslında, Şu an kapsama giren senaryoların bir kısmı şöyle:

• Alibaba Cloud kimlik bilgileri — ciddi fark yaratıyor
• Databricks token + workspace URL kombinasyonu
• Birden fazla Microsoft Azure key + host/endpoint çifti
• Ve rolling olarak eklenmeye devam eden diğer türler

Türkiye’deki Ekipler Açısından Ne Anlama Geliyor?

Açık konuşayım, Türkiye’de secret management tarafı biraz karmakarışık. Bir tarafta finans ve telekom ekipleri var; Key Vault kullanıyorlar, HSM tarafını da boş geçmiyorlar, envanterleri de fena değil. Öte tarafta işe 50 kişilik yazılım ekipleri var, hâlâ .env dosyasını repo’ya atıyor ve sonra da “bu nasıl öldü” diye bakıyor.

İşin garibi, İşin garibi şu: ortada bir de “GitHub Enterprise kullanıyoruz ama Advanced Security’yi tam kullanmıyoruz” diyen kalabalık bir grup var. Bence asıl hikâye burada dönüyor. Advanced Security lisansı ucuz değil, evet; ücret dolar bazında ve kullanıcı sayısı arttıkça can sıkabiliyor. Ama dur bir saniye — bir secret leak olduğunda masraf sadece rotate etmekle bitmiyor, incident response, denetim işleri, KVKK bildirimi derken toplam rakam bir anda altı haneli TL seviyesini geçebiliyor.

Açık konuşayım, Küçük ekipseniz. Advanced Security için bütçe çıkmıyorsa, en azından public repo’larda ücretsiz gelen secret scanning’i açık bırakın. Extended metadata özellikleri de public repo’larda çalışıyor, yanı elinizde boşta duran bir şey yok aslında. Enterprise seviyesindeyseniz iş değişiyor; push protection, secret scanning. Bu yeni metadata özelliklerini birlikte açmanız lazım, tek tek bakınca idare eder gibi dürüyor ama birlikte baya iş görüyor (ilk duyduğumda inanamadım)

Evet.

Küçük Ekip vs Kurumsal Yapı — Farklı Yaklaşımlar

Doğrusu, 10-20 kişilik bir ekipseniz, ben olsam önce lisans peşine düşmem. Bir gün ayırır, trufflehog ya da gitleaks gibi açık kaynak araçları CI pipeline’a koyarım; sonra çıkan alarmları manuel triage ederim, çünkü ilk bakışta saçma görünen uyarılar bazen gerçekten can alıcı bir şeyi yakalıyor. Sonra karar verirsiniz.

Kurumsal yapıdaysanız tablo baya farklı. 500+ developer, onlarca org, yüzlerce repo… Böyle yerde manuel triage yapmaya kalkarsanız işler uzar da uzar. Neden önemli bu? İşte extended metadata burada devreye giriyor; alert listesinde “owner: [email protected]” görüyorsanız doğrudan o kişiye ticket açabiliyorsunuz ve aradaki süre saatlerden dakikalara düşüyor.

Bakın, peki neden? Çünkü ölçek büyüyünce insan eliyle takip etmek yetmiyor. Az önce küçük ekip için “önce açık kaynakla başlayın” dedim ama kurumsalda aynı reçete biraz naif kalıyor; orada otomasyon şart oluyor, yoksa olaylar inbox’ta kaynayıp gidiyor.

Alert Triage Akışında Ne Değişiyor?

Bir örnekle gidelim. Diyelim ki panelde şöyle bir alarm düştü:

Alert #4271
Type: Azure Storage Account Key
Status: Active (validity confirmed)
--- Extended Metadata ---
Owner: devops-svc-prod
Created: 2026-03-15
Expires: N/A (long-lived)
Subscription: sub-prod-payments-01
Resource: st-payments-prod-weu
--- Multipart validation ---
Paired with: https://stpaymentsprodweu.blob.core.windows.net

Şunu söyleyeyim, Eski düzende bu bilgilerin çoğu ortada yoktu, işte orası biraz can sıkıyordu; “Azure Storage key sızmış” denirdi, sen de Portal’da tek tek arar, hangi hesapmış, hangi abonelikteymiş, kim açmış diye uğraşırdın, backup key ile rotate edebilir mıyım kısmı da cabası, yarım gün böyle eriyip giderdi.

Şimdi metadata tarafı baya iş görüyor. Owner bilgisiyle Terraform state’e bakıp resource’u buluyorsunuz, sonra rotate script’ını çalıştırıyorsunuz; toplam süre 15-20 dakikaya düşüyor, açık konuşayım ben bunun son dönemde gördüğüm en somut developer productivity kazanımlarından biri olduğunu düşünüyorum. Evet.

Webhook ve API Entegrasyonu

Şunu fark ettim: Burada güzel olan şu: Metadata REST API üzerinden de dönüyor. Yanı bir senaryo kuruyorsunuz, mesela GitHub’dan alarm geliyor, webhook bir Logic App’i tetikliyor, Logic App metadata’yı okuyup ServiceNow’da ticket açıyor, ticket’ta owner bilgisi zaten hazır geliyor; kulağa düz bir otomasyon gibi geliyor ama pratikte baya fark yaratıyor. Bu tarz akışları Türkiye’de daha çok bankalar ve büyük perakendeciler kuruyor, küçük ekiplerde işe Slack notification bile çoğu zaman yeterli oluyor.

Bu arada Logic Apps üzerinden bu tarz otomasyonlarla ilgili daha önce yazdığım Cosmos DB Built-in Connector for Logic Apps Standard GA Öldü yazısında connector mantığından bahsetmiştim; oradaki kafa da aynıydı aslında — event-driven işlem akışı. Neyse, çok dağıttım, konumuz yine triage hızına dönüyor.

Peki neden?

Provider Kapsaması: Tabloyla Bakalım

Şu an desteklenen bazı önemli provider’lar ve durumları aşağıda; GitHub bu listeyi rolling şekilde büyütüyor. Evet, iş biraz böyle akıyor.

Tabloda kısmi yazan yerlere özellikle dikkat edin. Provider’ın API’si, her metadata alanını her token için dönmüyor;. “AWS destekliyor” demek, “her — itiraz edebilirsiniz tabi — AWS token’ında owner göreceksiniz” anlamına gelmiyor. IAM user token’larında çıkabiliyor, STS temporary credential’larda işe bazen boş geliyor, garip ama gerçek bu. Test etmeden emin olmayın.

Daha açık söyleyeyim, peki neden? Çünkü burada belirleyici olan şey provider’ın kendisi kadar, o anda kullandığınız kimlik tipi de oluyor (yanlış duymadınız). Kısacası, aynı servis farklı credential ile bambaşka davranabiliyor. Şaşırdım açıkçası.

Neyse, çok dağıtmayayım, konu net: kısmi destek gördüğünüz yerde varsayım yapmayın. Bir örnekle doğrulayın, sonra rahat edin.

Pratik Uygulama: Nereden Başlayalım?

Bu özelliği devreye almak isteyen bir ekibe olsam, açık konuşayım, şu sırayla giderim:

1. Envanter: GitHub Advanced Security lisansınız var mı? Hangi org’lar altında aktif? Bilmeyen çok var, önce buna bakın. Hatta bazen lisans var sanılıyor ama başka org’da boşta dürüyor, işin aslı biraz karışık. Önce tabloyu netleştirin.
2. Secret scanning’i aç: Org seviyesinde default açık olacak şekilde ayarlayın. Repo repo uğraşmayın; tek tek aç-kapa işi bir süre sonra insanı yoruyor, sonra da bir iki repo unutuluyor. Merkezden yönetmek daha temiz gidiyor.
3. Push protection’ı devreye al: Zaten sızmış secret’ları bulmak güzel ama esas iş sızmadan yakalamak. Push protection burada anahtar. Yanı commit daha gitmeden kapıyı çalıyor, bu tarafı baya iş görüyor.
4. Alert list’i filtrele: Yeni gelen metadata alanlarına göre (owner, expiry) filtre kurun. Yakında biten token’ları önceliklendirin. Şey gibi düşünün, hepsi aynı sepette durmasın; süresi dolacak olanı öne alın, diğerini sonra bakarsınız.
5. Webhook + otomasyon: Alarm geldiğinde Slack/Teams’e düşsün, ticket sistemine gitsin. Elle triage sürdürülebilir değil. Bir noktadan sonra insanın eli yoruluyor, hele ortam büyüyünce bu iş büyük ölçüde çorba oluyor.
6. Rotate playbook: Her secret tipi için “sızarsa ne yaparız” playbook’u yazın. Azure Storage key rotate etmek 2 dakikadır, ama koordinasyon 2 saati bulabilir. Tam da mesele bu zaten; teknik adım kısa, asıl zaman insan tarafında gidiyor.

Sıkça Yapılan Hata

Bir şey söyleyeyim, sahada en sık gördüğüm hata şu: Ekip secret scanning’i açıyor, alarm listesi doluyor… ve üç gün sonra kimse bakmıyor. Alarm fatigue. Peki neden? Çünkü başlangıçta temizlik yapılmıyor; backlog şişiyor, herkes “sonra bakarız” diyor ve konu sessizce ölüyor. Bu yüzden ilk açtığınızda önce mevcut backlog’u temizleyin. Aktif olanları rotate edin, false positive’leri işaretleyin, sonra “temiz sayfa” ile devam edin — itiraf edeyim, beklentimin üstündeydi —. Aksi hâlde metadata da olsa fark etmez, kimse listeye bakmaz. Evet.

Bence Nasıl Bir Adım?

Doğrusu, bu güncelleme bir devrim değil; daha çok, eldeki yapının üstüne eklenmiş sağlam bir katman gibi dürüyor. Push protection çıktığında ben de “vay be” demiştim, çünkü o iş bayağı bir sıçramaydı, ama bu gelen parça da öyle boş değil, triage tarafındaki o can sıkıcı sürtünmeyi epey azaltıyor.

Şimdi, ama dur bir saniye, burada küçük bir ama var: multipart validation kısmı hâlâ beklediğim kadar geniş değil. Mesela AWS tarafında STS ve federated identity senaryolarına bakınca bazı boşluklar göze çarpıyor, GitHub da “rolling basis” diyor zaten; yanı iş biraz dalga dalga geliyor. Şimdilik Azure ve Databricks kullananlar için tam yerinde, diğerleri işe biraz daha bekleyecek gibi.

İşte tam da bu noktada devreye giriyor.

Kısaca söyleyeyim: Advanced Security lisansınız varsa bunu açıp geçmek mantıklı. Yoksa, bir sızıntı yaşamadan önce lisans maliyetiyle risk maliyetini yan yana koyup yeniden hesaplayın; bazen rakamlar insanı şaşırtıyor, hatta açık konuşayım, beklediğinizden farklı çıkabiliyor.

Bu konuya paralel bir okuma olarak, DevOps tarafında kimlik yönetimindeki dönüşüme Git’te NTLM Kapanıyor: Azure DevOps Server İçin Kritik Uyarı yazımı öneririm. Orada da benzer bir mesele var: kimliği doğru yönetmezsen sonra yetişmeye çalışıyorsun, işte olayın özü biraz bu.

Sıkça Sorulan Sorular

Extended metadata GitHub Free planında da çalışıyor mu?

Kısmen. Yanı public repo’larda secret scanning — ki bu tartışılır — zaten ücretsiz geliyor, validity check ve metadata da bazı provider’lar için çalışıyor. Ama private repo’larda tüm bu özellikleri görmek istiyorsanız GitHub Advanced Security (GHAS) lisansı şart. Enterprise Cloud ve Enterprise Server müşterileri için GHAS ayrı bir add-on olarak satılıyor.

Multipart validation için her iki parçanın da depoda olması lazım mı?

Evet, aslında mantık tam olarak bu. Mesela Databricks için token. Workspace URL’ının aynı depoda (veya aynı organizasyon içinde tarama kapsamında) bulunması gerekiyor. Sadece token varsa GitHub eşleştirme yapamıyor ve validity’i kesin olarak doğrulayamıyor. Bu yüzden bazen hâlâ “possibly active” gibi durumlar görebilirsiniz — bence bu biraz can sıkıcı ama anlayışla karşılamak gerek.

Metadata bilgileri ne kadar süre dürüyor?

Yanı, Alert kaydıyla birlikte saklanıyor. Alert açıkken erişebilirsiniz, kapatıldıktan sonra da geçmiş kayıtta görünmeye devam ediyor. Ama şöyle bir şey var: provider’daki gerçek zamanlı durum değişirse, mesela token silinirse, metadata “stale” olabiliyor. Açıkçası kritik kararlar için provider tarafını da teyit etmek iyi bir alışkanlık (yanlış duymadınız)

Ve işler burada ilginçleşiyor.

Webhook payload’ında metadata alanları nasıl geliyor?

Webhook’un secret_scanning_alert event’inde validity alanı zaten vardı, şimdi bunun yanına ek metadata alanları geliyor: publisher_metadata benzeri bir yapıda owner, created, expiry gibi alt alanlar var. Yapı provider’a göre değişebiliyor. Yanı entegrasyon kodunuzda null-safe yazmak şart — tecrübeme göre bunu atlarsanız sonradan başınız ağrıyor.

Push protection ile birlikte nasıl çalışıyor?

Push protection secret’ı depoya girmeden önce yakalıyor. Extended metadata işe zaten depoya girmiş (veya geçmişten kalma) secret’lar için triage’ı hızlandırıyor. Birbirinin yerine geçmiyorlar, tamamlıyorlar. Bence doğru yaklaşım ikisini de birlikte açmak.

Kaynaklar ve İleri Okuma

GitHub Changelog: Secret scanning extended metadata and multipart validation

Doğrusu, GitHub Docs: About Secret Scanning

Dürüst olmak gerekirse, GitHub Docs: Supported Secret Scanning Patterns (Tam Liste) (en azından benim deneyimim böyle)

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 Boards’ta Markdown Düzenleyici Neden Daha Sakin Oldu?5 Nis 2026

Azure DevOps Remote MCP Server: Hibrit Takımlarda Yepyeni Bir Dönem18 Mar 2026

Kubernetes v1.36: Mixed Version Proxy ile Yükseltme Korkusu Azalıyor17 May 2026

GitHub’ın Erişilebilirlik Yolculuğunda Yeni Dönem24 May 2026