GitHub AI Scan artık API’den yönetiliyor; kurum ayarı depoyu kilitleyebilir

GitHub, 10 Eylül 2026’da pull request’lere yönelik AI Scan ayarını kurum ve depo düzeyinde REST API ile yönetilebilir hale getirdi. TechTimes’ın 11 Eylül tarihli haberi, yeni uç noktaların durumu okumaya, etkinleştirmeye ve devre dışı bırakmaya yaradığını; kurumda kapalı olan ayarın tekil bir depodan aşılamadığını doğruluyor.

AI Scan’i API ile açmanın kısa yanıtı şu: GitHub Advanced Security bulunan bir github.com kurumunda önce kurum ayarı etkinleştiriliyor, ardından hedef depoların ayarı ayrı ayrı güncelleniyor. Lumien’in 11 Eylül tarihli değerlendirmesi de erişimin genel önizleme statüsünde olduğunu, GitHub Advanced Security müşterileriyle sınırlandığını ve GitHub Enterprise Server’ın bu sürümde desteklenmediğini aktarıyor.

API, kurum ve depo için iki kapsam sunuyor

Yeni yapı dört temel işleme dayanıyor: kurum ayarını okuma ve güncelleme ile depo ayarını okuma ve güncelleme. Kurum için GET veya PATCH isteği /orgs/{org}/code-scanning/ai-scan yoluna, depo için aynı yöntemler /repos/{owner}/{repo}/code-scanning/ai-scan yoluna gönderiliyor.

GitHub’ın REST API belgesi, bu uç noktaların genel önizlemede olduğunu ve değişebileceğini belirtiyor. İstek gövdesindeki pr_scan alanı enabled ya da disabled değerini alıyor; başarılı yanıt da saklanan pr_scan durumunu döndürüyor.

Kurum ve depo yollarının ayrı olması, birden fazla deponun tek bir toplu istekle güncellendiği anlamına gelmiyor. Belgelenen modelde otomasyon önce kurum durumunu kontrol ediyor, ardından hedef depo listesini dolaşarak her depo için ayrı GET ve gerektiğinde PATCH isteği gönderiyor. Böylece dağıtım merkezi bir betikle yönetilebilse de sonuçlar depo bazında izleniyor.

AI Scan API nasıl etkinleştirilir?

Etkinleştirme sırası ayar hiyerarşisini izlemeli. Önce enterprise politikasının AI Scan’e izin vermesi gerekiyor; ardından kurum uç noktasına pr_scan değeri enabled olan bir PATCH isteği gönderiliyor. Kurum etkinleştirildikten sonra seçilen depolar aynı değerle ayrı ayrı açılabiliyor.

1. GET /orgs/{org}/code-scanning/ai-scan isteğiyle kurumda saklanan durumu okuyun.
2. Enterprise politikası izin veriyorsa aynı kurum yoluna pr_scan değeri enabled olan PATCH isteğini gönderin.
3. GET /repos/{owner}/{repo}/code-scanning/ai-scan ile hedef depoların mevcut durumunu alın.
4. Yalnızca değiştirilmesi gereken depolara PATCH isteği uygulayın.
5. Son GET çağrılarıyla kurum ve depo değerlerini birlikte doğrulayın.

GitHub’ın örneklerinde Accept başlığı application/vnd.github+json, Authorization başlığı Bearer belirteci ve X-GitHub-Api-Version başlığı 2026-03-10 olarak kullanılıyor. Kurumu etkinleştiren örnek isteğin gövdesi {"pr_scan":"enabled"}; depo isteğinde de aynı alan kullanılıyor.

Yetkiler, okuma ve yazma işlemlerinde farklılaşıyor. Fine-grained belirteçle kurum durumunu okumak için kurum düzeyinde Administration read, değiştirmek için Administration write gerekiyor. İşlemi yapan kimliği doğrulanmış kullanıcının kurum sahibi veya security manager olması da şart.

Depo durumunu okumak için fine-grained belirteçte Code scanning alerts read, güncellemek için Administration write izni isteniyor. Klasik personal access token veya OAuth belirtecinde depo okuması özel ve herkese açık depolar için security_events, güncelleme ise repo kapsamını gerektiriyor; yalnızca herkese açık depolarda public_repo kullanılabiliyor.

Kurumdaki kapalı durum depo ayarına üstün geliyor

Ayar önceliğinin belirleyici kuralı, disabled durumundaki bir kurumun altındaki depoların AI Scan’i etkinleştirememesi. Bir depoda enabled değeri saklanmış olsa bile kurum kapalıysa pull request taraması çalışmıyor. Enterprise politikası AI Scan’e izin vermediğinde kurum düzeyindeki etkinleştirme de reddediliyor.

Kurum ayarının enabled olması ise bütün depoları geri döndürülemez biçimde zorlamıyor. Bu durumda depolar taramayı kullanabilir, ancak tekil bir depo disabled seçeneğiyle kapsam dışında kalabilir. Başlıktaki “kilitleme”, merkezi kapatma kararının alt düzeydeki etkinleştirme tercihine üstün gelmesini ifade ediyor.

Bu öncelik, toplu dağıtım envanterinin yalnızca depo değerlerinden oluşturulmamasını gerektiriyor. Kurum ve depo durumları birlikte kaydedilmezse enabled görünen bir depoda taramanın neden çalışmadığı ayırt edilemeyebilir. Otomasyonun son doğrulama aşamasında iki katmanı birlikte okuması bu nedenle önem taşıyor.

Önizleme github.com ile sınırlı, GHES desteklenmiyor

Yeni yönetim uç noktaları genel kullanıma hazır kararlı bir sürüm değil. Erişim, github.com üzerinde GitHub Advanced Security kullanan müşterilerle sınırlı; GitHub Enterprise Server bu sürümün kapsamına girmiyor. Bulut ve şirket içi kurulumları birlikte yöneten kurumlar aynı çağrıları iki ortamda ortak bir dağıtım yöntemi olarak kullanamıyor.

API’nin görevi güvenlik bulgularının kendisini yönetmek değil, pull request AI Scan özelliğinin etkinlik durumunu okumak ve değiştirmek. Bu ayrım, yeni uç noktaların mevcut code scanning uyarı API’lerinin yerine geçmediği anlamına geliyor.

14 Eylül 2026 itibarıyla doğrulanan tablo; kurum ve depo düzeyindeki ayarların programatik olarak değiştirilebildiği, merkezi kapatma kararının depodan aşılamadığı ve GHES desteğinin bulunmadığı yönünde. Genel kullanılabilirlik tarihi, önizleme sözleşmesinin ne ölçüde değişeceği ve GitHub Enterprise Server desteğinin ne zaman gelebileceği henüz açıklanmış değil.

Ayrıca okuyun:

• Canva API artık mevcut tasarımı veriyle yerinde güncelleyebiliyor
• GitHub etiketleri artık silinmeden arşivleniyor, otomasyon ise eksik
• a16z’den yapay zekâ altyapısına 1,1 milyar dolarlık yeni fon