GitHub Secret Scanning API ve Webhook İyileştirmeleri

⏱️ 7 dk okuma📅 9 Nisan 2026👁️ 3 görüntülenme

Geçen hafta bir finans kuruluşundaki müşterimizle güvenlik otomasyonu toplantısı yapıyorduk. Adam masaya vurmadı tam olarak ama ses tonundan memnuniyetsizliği anlamak için özel bir yeteneğe gerek yoktu — “Her yeni secret type eklendiğinde script’lerimizi güncellememiz gerekiyor, bu iş böyle olmaz!” dedi ve bıraktı öyle. Tam o gün. Aynı gün GitHub’ın secret scanning API’sine gelen yenilikler duyuruldu. Zamanlamayı ben planlamadım, yemin ederim.

Bakın, secret scanning çoğu ekibin “aa evet, açıktı zaten o özellik” deyip geçtiği ama güvenlik zincirinin en kırılgan halkalarından biri aslında. API key’ler, token’lar, parolalar — bunlar repo’lara sızıyor, kimse fark etmiyor, haftalarca orada öylece yatıyor. GitHub bu konuda hep bir şeyler yapıyor zaten, ama bu sefer gelen değişiklikler farklı hissettirdi. Günlük iş akışına dokunan cinsten, hani soyut “iyileştirme” değil.

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

exclude_secret_types Filtresi: Sonunda!

Şunu bir düşünün. GitHub sürekli yeni secret type’lar ekliyor — geçen yıl onlarca yeni pattern geldi ve bu sayı artmaya devam ediyor. Eğer raporlama script’lerinizde “sadece şu tipleri getir” mantığıyla,. Inclusion-based filtrelemeyle çalışıyorsanız, her yeni eklenende script’i açıp güncellemeniz gerekiyor. Kaçırırsanız ne oluyor? O yeni tip radarınızın tamamen dışında kalıyor, sız de haberdar olmuyorsunuz.

Yeni gelen exclude_secret_types parametresi tam da bu sorunu çözüyor. “Şunları istemiyorum, gerisini getir” diyebiliyorsunuz artık. Mantık olarak inanılmaz basit ama etkisi büyük — özellikle yüzlerce repo yöneten ekipler için.

Kendi deneyimimden konuşuyorum, 2024 sonlarında Logosoft’ta bir e-ticaret müşterimiz için secret scanning otomasyonu kurmuştuk. Tam olarak bu inclusion problemiyle boğuştuk o dönem. Adamlar AWS, Azure ve GCP kullanıyor — üç farklı bulut, onlarca farklı secret tipi. Her ay birileri “yeni bir pattern mi geldi, kontrol ettik mi?” diye soruyordu. Artık buna gerek yok. Gerçekten.

Üç endpoint’te de çalışıyor:

# Repo seviyesinde
GET /repos/{owner}/{repo}/secret-scanning/alerts?exclude_secret_types=aws_access_key,slack_token
# Org seviyesinde
GET /orgs/{org}/secret-scanning/alerts?exclude_secret_types=generic_password
# Enterprise seviyesinde
GET /enterprises/{enterprise}/secret-scanning/alerts?exclude_secret_types=azure_devops_pat

Ha, bir şeye dikkat edin: secret_type ve exclude_secret_types parametrelerini aynı anda kullanırsanız 422 hatası alıyorsunuz. Mantıklı aslında — ikisi birbirine zıt kavramlar, ikisi birden olunca sistem ne yapacağını bilemiyor. Ama dökümantasyonu okumadan deneyip “neden çalışmıyor?” diye 10 dakika harcayacak insanlar olacak, eminim. Ben de ilk başta denedim. İtiraf edeyim işte.

💡 Bilgi: Exclusion filtreleri GitHub UI’da -secret-type: sözdizimi ile zaten mevcuttu. Bu güncelleme ile aynı yetenek REST API tarafına da taşınmış oldu. Script’lerinizi güncellerken UI’daki filtre mantığıyla birebir aynı sonucu alacaksınız.

html_url Alanı: Küçük Ama Çok Değerli Bir Detay

İlk bakışta “ee, ne var bunda” dedirtebilir bu değişiklik. Duruyorum bir saniye, şöyle anlatayım.

Daha önce secret scanning alert location’ları sadece API URL’leri dönduruyordu. Yanı elinize /repos/{owner}/{repo}/issues/comments/{id} gibi bir şey geçiyordu (bizzat test ettim). Bunu bir Slack notifikasyonuna veya e-postaya koymak istediğinizde? İşe yaramıyor (yanlış duymadınız). Tıklayınca API JSON’ı açılıyor, insanlar “bu ne?” diye bakıyor ekrana. Tarayıcıda açılabilir bir link almak için ek API çağrısı yapmanız gerekiyordu — her alert için ayrı ayrı (ciddiyim)

Artık details objesinde doğrudan html_url alanı geliyor. Hem REST API’de hem webhook payload’larında (ciddiyim)

Location Tipi	html_url Örneği
commit	`/{owner}/{repo}/blob/{sha}/{path}#L5-L5`
issue_body	`/{owner}/{repo}/issues/{number}`
issue_comment	`/{owner}/{repo}/issues/{number}#issuecomment-{id}`
pull_request_body	`/{owner}/{repo}/pull/{number}`
pull_request_comment	`/{owner}/{repo}/pull/{number}#issuecomment-{id}`
pull_request_review	`/{owner}/{repo}/pull/{number}#pullrequestreview-{id}`

Doğrusu, Logosoft’ta müşterilere genellikle webhook tabanlı otomasyon kuruyoruz — bir alert geldiğinde Slack’e ya da Teams’e mesaj atılıyor, ilgili geliştiriciye mention düşülüyor, hepsi otomatik. Eskiden bu mesajlara tıklanabilir link eklemek için ayrı API call yapıyorduk; bu da özellikle büyük organizasyonlarda rate limit sorunlarına kapı aralıyordu. Şimdi? Link webhook payload’ında hazır geliyor (en azından benim deneyimim böyle). Bir API call tasarrufu küçük görünebilir, ama yüzlerce alert olduğunda o “küçük” şey oldukça farkedilir hâle geliyor.

Delegated Bypass İş Akışlarındaki İyileştirmeler

Delegated bypass — hani şu “ben bu alert’i kapatmak istiyorum ama önce birinin onaylaması lazım” mekanizması — kurumsal ortamlarda çok yaygın kullanılıyor. Mesela SOC ekipleriyle çalışan büyük şirketlerde her alert’in rastgele kapatılmasını istemezsiniz. Kontrol şart.

E-posta İyileştirmeleri

İki değişiklik var burada. Birincisi: reviewer’lar artık onay isteği e-postalarında son tarihi, yanı expiry deadline’ı, görebiliyor. İkincisi: geliştirici dismissal request gönderdiğinde bir onay e-postası alıyor — “tamam isteğin alındı, bekliyorsun” mesajı gibi düşünebilirsiniz.

Küçük şeyler gibi görünüyor, değil mi? Geçen ay bir bankacılık projesinde tam olarak bu eksiklikten dolayı sıkıntı yaşadık. Bir geliştirici alert dismissal isteği göndermiş, reviewer 3 gün görmemiş, süre dolmuş, tekrar göndermek zorunda kalmış. Reviewer’a sorduğumuzda “e-postada aciliyet bilgisi yoktu, normal bir bildirim sandım” dedi. İşte bu güncelleme tam da o sorunu çözüyor. Basit ama yerinde.

Closure Request Yorumları API ve Webhook’larda

Bence en değerli iyileştirme bu. Delegated closure sürecinde artık şu bilgiler alert payload’ında yer alıyor:

İsteği gönderen kişinin yorumu (requester’s comment)
Reviewer’ın yorumu (reviewer’s comment)
Reviewer’ın kullanıcı adı

Bakın, Neden bu kadar önemli? Audit trail. Bir alert kapatılmış — tamam da neden? Kim onaylamış? Ne gerekçeyle? Bu bilgiler daha önce sadece GitHub UI’da görünüyordu; API veya webhook üzerinden erişmek mümkün değildi. Dışarıda bir SIEM ya da compliance aracı kullanıyorsanız, bu verileri hiç çekemiyordunuz (en azından benim deneyimim böyle)

Şimdi düşünün: PCI DSS veya ISO 27001 denetimine giriyorsunuz. Denetçi “şu secret alert neden kapatılmış, kim onaylamış?” diye soruyor. Eskiden GitHub’a girip tek tek bakmak gerekiyordu — hem yorucu hem hata riski yüksek. Artık bu verileri otomatik olarak compliance dashboard’unuza akıtabilirsiniz. Denetimde saatlerce kazanç bu.

Peki neden? Daha fazla bilgi için AG-UI ile Çoklu Ajan Arayüzü: Gerçek Zamanlı Demo yazımıza bakabilirsiniz.

Güvenlik otomasyonunun gerçek değeri, her şeyin “tıkla ve gör” yerine programatik olarak erişilebilir olmasıdır. Bu güncelleme, delegated workflow verilerini API’ye taşıyarak tam olarak bunu yapıyor.

Bug Fix: resolution_comment Artık Null Değil

Kısa ama önemli. Delegated closure onayı ile kapatılan alert’lerde resolution_comment alanı null dönüyordu. Bug’dı. Düzeltildi. Bu konuyla ilgili GitHub Copilot for Eclipse Açık Kaynağa Dönüyor: Neden Önemli? yazımıza da göz atmanızı tavsiye ederim. MCP Apps’i Kolaylaştıran Fluent API: Sahada Ne Değişiyor? yazımızda bu konuya da değinmiştik.

Bunu neden ayrı bir bölüm olarak yazıyorum? Çünkü bu bug’a bizzat takıldım ben de. Bir müşterimizin otomasyon script’i “kapatma gerekçesi boş olan alert’leri raporla” diye çalışıyordu — mantıklı bir kural, değil mi? Ama delegated closure ile kapatılan her alert bu rapora düşüyordu, çünkü comment alanı null geliyordu. Haftalarca “neden bu kadar çok gerekçesiz kapatma var?” diye araştırdık. Meğer bug’mış. Neyse. Düzeldi artık, geçti.

Bir dakika — bununla bitmedi. Bu konuyla ilgili GitHub Universe Sahneye Çağırıyor: Ben Olsam Ne Yaparım? yazımıza da göz atmanızı tavsiye ederim.

Pratikte Bu Değişiklikleri Nasıl Kullanmalı?

Küçük Takımlar İçin

Şahsen, 5-10 kişilik bir ekipseniz, exclude_secret_types filtresi tek başına ciddi fark yaratır. Basit bir cron job ile “genel parolalar hariç büyük çoğunluk alert’leri Slack’e gönder” diyebilirsiniz, mesela. Generic password alert’leri genelde çok gürültülü oluyor — bunları filtreleyip gerçek sızıntılara odaklanabilirsiniz. Gürültüyü azaltmak, güvenliği artırmak kadar önemli bu boyutta.

Enterprise Seviyede

Büyük organizasyonlarda asıl fark closure comment’lerin API’de görünür olması. SIEM entegrasyonu yapıyorsanız — Splunk, — itiraz edebilirsiniz tabii — Sentinel, ne kullanıyorsanız — bu verileri otomatik olarak çekip compliance raporlarınıza dahil edebilirsiniz. AZ-500 sınavına hazırlanırken güvenlik otomasyonu konusunu çalışmıştım; orada da vurgulanan şey buydu: audit trail’in programatik erişilebilirliği. Sınav konusu diye değil, gerçekten kritik olduğu için vurgulanıyordu.

Bir de html_url alanını düşünün. Enterprise’da yüzlerce repo, binlerce alert olabiliyor. Otomasyon ile Jira ticket’ı açıyorsanız, o ticket’a doğrudan tıklanabilir GitHub linki koyabilmek… Bu kadar basit bir şey, ama iş akışını ciddi şekilde hızlandırıyor. Geliştirici “hangi dosyaydı bu?” diye arama yapmak zorunda kalmıyor. GitHub Copilot’un PR Etkisi Ölçülüyor: Yeni Metrikler yazımızda bu konuya da değinmiştik.

Tuhaf ama, Bu arada, GitHub Code Scanning’de Toplu Düzeltme: PR’lar Hızlandı yazımda code scanning tarafındaki benzer iyileştirmelerden bahsetmiştim. Secret scanning ve code scanning birlikte düşünülmeli — ikisi de GitHub Advanced Security’nın parçası ve birbirini tamamlıyor. Biri olmadan öbürü eksik kalıyor.

Eksik Kalan Ne Var?

Açık konuşayım. Bu güncellemeler güzel, ama hâlâ eksik gördüğüm noktalar var.

Mesela webhook payload’larında alert’in hangi branch’te tespit edildiği bilgisi hâlâ yeterince zengin değil. Multi-branch stratejisi kullanan ekipler için bu önemli bir detay — hangi ortamda sızdı bu, production mu staging mi? Bilmek istiyorsunuz.

Bir de exclude_secret_types güzel hoş da, regex tabanlı custom pattern’lar için filtreleme hâlâ sınırlı. Kurumsal müşterilerimizin çoğu kendi internal secret formatlarını tanımlıyor — bu pattern’lar için filtreleme mekanizması biraz daha olgunlaşmalı. Umarım bir sonraki turda gelir.

Ha, neredeyse unutuyordum: GitHub’da Güvenlik Sekmesi Değişti: Kalite de Eklendi yazısında güvenlik sekmesinin evriminden bahsetmiştim. Secret scanning iyileştirmeleri de o büyük resmin parçası — GitHub, güvenliği geliştirici deneyiminin merkezine koymaya çalışıyor. Yavaş yavaş oluyor ama oluyor işte.

Sıkça Sorulan Sorular

exclude_secret_types ile secret_type parametreleri aynı anda kullanılabilir mi?

Doğrusu, Hayır, kullanılamaz. İkisini aynı request’te gönderirseniz 422 hatası alırsınız. Birini seçmeniz gerekiyor — ya dahil etmek istediklerinizi belirtin ya da hariç tutmak istediklerinizi.

html_url alanı hangi location tiplerinde çalışıyor?

Commit, issue (title, body, comment), pull request (title, body, comment). Pull request review location tiplerinde çalışıyor. Yanı secret’ın tespit edildiği hemen her yerde tıklanabilir link alabiliyorsunuz.

Bu değişiklikler GitHub Free planında da geçerli mi?

Secret scanning’in kendisi GitHub Advanced Security veya public repo’lar için ücretsiz olarak mevcut. API iyileştirmeleri, secret scanning’e erişiminiz olan tüm planlarda geçerli (ben de ilk duyduğumda şaşırmıştım). Ancak delegated bypass gibi özellikler Enterprise plana özel olabiliyor — plan detaylarınızı kontrol etmenizde fayda var.

Mevcut webhook entegrasyonlarımı güncellemem gerekiyor mu?

Yeni alanlar ekleme şeklinde geldiği için mevcut entegrasyonlarınız bozulmaz. Ama html_url ve closure comment verilerinden faydalanmak istiyorsanız, webhook handler kodunuzu bu yeni alanları okuyacak şekilde güncellemeniz gerekiyor. Geriye dönük uyumluluk korunuyor.

resolution_comment bug fix’i geçmişe dönük çalışıyor mu?

Bu konuda net bir bilgi yok ama genellikle bu tür fix’ler ileriye dönük oluyor. Yanı daha önce null olarak kaydedilmiş comment’ler muhtemelen null olarak kalacak. Yeni kapatılan alert’lerde artık doğru şekilde dolduruluyor.