GitHub Secret Scanning API ve Webhook İyileştirmeleri
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.
📋 İçindekiler
-
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.
Pratikte Bu Değişiklikleri Nasıl Kullanmalı?
Küçük Takımlar İçin
Şahsen, 5-10 kişilik bir ekipseniz,
exclude_secret_typesfiltresi 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 tabiî — 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_urlalanı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.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_typesgü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.
Kaynaklar ve İleri Okuma
GitHub Secret Scanning REST API Dokümantasyonu
İlginç olan şu ki, GitHub Blog — Secret Scanning Improvements Changelog
GitHub Secret Scanning Hakkında Genel Bilgi
Bu yazı yapay zeka (büyük dil modelleri) ile hazırlanmış, insan editör tarafından incelenmiştir. İçerik üretim sürecimiz.Aşkın KILIÇYazar20+ 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
GitHub Actions’da Agentic Workflow Ayarlarını Anında Görmek: Gerçekten Oyun Değiştirici mi?28 Mar 2026GitHub Copilot for Eclipse Açık Kaynağa Dönüyor: Neden Önemli?8 Nis 2026Azd Uzantılarını Otomatik Kurmak: Dev Container Kolaylığı15 Mar 2026Visual Studio'da GitHub Copilot: Temmuz 2026 Güncellemesi3 Ağu 2026
İlginizi Çekebilir
Zeynep A.
exclude_secret_types filtresini duyunca rahatladım açıkçası, her yeni token tipi eklendiğinde script’i güncellemek gerçekten can sıkıcıydı. Acaba bu filtre wildcard destekliyor mu yoksa tam tip adı mı vermek gerekiyor?
Emre Ç.
exclude_secret_types filtresini ilk okuduğumda “zaten neden bu yoktu ki” dedim içimden. Her yeni secret type geldiğinde script’leri güncellemek gerçekten can sıkıcıydı, enterprise ortamlarında bu iş ciddi efor istiyor.
Tolga F.
exclude_secret_types filtresini görünce gerçekten “keşke daha önce olsaydı” dedim, her yeni token tipi eklendiğinde allowlist’i güncellemek can sıkıcıydı. Repo seviyesinde mi org seviyesinde mi kullanmak daha mantıklı acaba, enterprise’ı olmayanlara org yeterli geliyor mu peki?
Bu arada şu yazınız da güzeldi: GitHub Bildirimlerinde Sıralama Geldi: Küçük Detay mı? — https://www.askinkilic.com.tr/github-bildirimlerinde-siralama-geldi-kucuk-detay-mi/
Yorumlar kapalı.
3 comments