Bot PR’lere de CI yolu açıldı: Güvenlikte ince ayar zamanı

Ben bu haberi okuduğumda aklıma ilk güvenlik gelmedi, operasyon geldi. Çünkü kurumsal tarafta çoğu zaman sorun güvenliği teoride çözmek değil; güvenli kalırken işi akıtmak oluyor. Logosoft’ta 2024 sonlarında bir finans müşterisinde buna benzer bir tartışma yaşamıştık. Bot’un açtığı dependency update PR’leri merge ediliyordu ama CI koşmadığı için kalite kapısı yarım kalıyordu. Sonra bir gün staging’e kaçan ufak bir kırılma yüzünden herkes aynı masaya toplandı… hani o klasik “keşke kontrol etseydik” anı vardır ya, aynen öyle.

Hmm, bunu nasıl anlatsamdı…

Size bir şey söyleyeyim, Bu güncelleme bana şunu söylüyor: GitHub artık bot ile insan arasında daha dengeli bir çizgi kurmaya çalışıyor. Copilot-generated pull request’lerde gördüğümüz mantık burada da var; yanı üretkenlik artsın ama otomatik olarak her şey koşmasın. Kullanıcı onayı olmadan workflow çalışmıyor. Bu iyi mi? Evet, baya işe yarıyor. Ama dur bir saniye — hâlâ dikkat gerektiriyor çünkü onay mekanizması yanlış kurgulanırsa kapı açık kalabilir.

Şimdi gelelim işin can alıcı noktasına.

Bir de şu var; bot PR’leri genelde rutin işleri taşır: paket güncellemesi, lock file yenilemesi, ufak refactor’lar, security patch’ler… Bunların çoğu aslında elle uğraşmayı pek istemeyeceğiniz işlerdir. 2019’da kendi lab ortamımda benzer otomasyonlar kurarken bunu çok net görmüştüm (ki bu çoğu kişinin gözünden kaçıyor). Bir yanda hız isteği, diğer yanda “workflow niye tetiklenmedi?” sorusu (şaşırtıcı ama gerçek). O dönem elimizde bugünkü kadar temiz bir model yoktu, açıkçası biraz el yordamıyla gidiyorduk.

Bu yeni davranış bana göre doğru yönde atılmış bir adım, ama henüz tam pişmiş değil. Çünkü approval modeli teknik olarak güçlü olsa da insan faktörü var; yazılımcı bazen hızlıca onay verir, bazen de repo’nun hassasiyetini unutup standart PR gibi davranır. İşte orada süreç tasarımı devreye giriyor. Bu konuyla ilgili Azure Cosmos DB’de Partition Key Değiştirmek: Artık Daha Az Acı Veriyor yazımıza da göz atmanızı tavsiye ederim.

Küçük ekip ile enterprise aynı yerde durmuyor

Bunu yaşayan biri olarak söyleyeyim, Küçük ekiplerde mesele daha basit: Genelde 3-5 kişi repoyu biliyor. Kimin neyi onayladığı ortada oluyor. Böyle yapılarda bot PR’nın workflow çalıştırması ciddi rahatlık verir; özellikle dependency update ya da docs üretimi gibi işlerde zaman kazandırır.

Enterprise tarafında tablo farklıdır. Onlarca repo, ayrı ayrı branch protection kuralları, code owners yapıları ve denetim gereksinimleri derken olay büyüyor. Ben 2023 baharında İstanbul’daki bir telekom müşterisinde bunun acısını birebir gördüm: Aynı tip bot PR’leri farklı takımlarda farklı davranıyordu çünkü repository policy standardize edilmemişti. Bir takımda onay sonrası test koşuyor, diğerinde görünmez şekilde takılıyordu… sonra herkes birbirine bakıyordu.

E tabi burada benim önerim net: Küçük ekipseniz akışı sade tutun; enterprise iseniz merkezî politika yazın. Istisnaları az bırakın. Aksi hâlde güvenlik ile hız arasında salınan garip bir yapı çıkıyor ortaya — ne tam güvenli ne tam çevik.

Bence asıl mesele workflow değil, yetki tasarımı

Pek çok ekip konuyu “CI koşsun mu koşmasın mı?” diye görüyor ama bence asıl oyun burada değil. Asıl mesele kim onaylıyor, hangi durumda onaylıyor ve hangi secret’lar devreye giriyor? Çünkü workflow çalışınca sadece test koşmaz; bazen package registry’ye erişir, bazen internal artifact indirir, bazen deployment hazırlığı yapar.

Ben AZ-500 sınavına hazırlanırken de benzer düşünce yapısı kafama çakılmıştı: Güvenlik sadece kapıyı kilitlemek değildir; anahtarları kime verdiğinizi bilmektir. Burada da aynı mantık var. Bot’un ürettiği kodu insan gözüyle doğrulamak gerekiyor. Bunu “her şeyi durdur” seviyesine çekerseniz otomasyonun anlamı kalmaz.

Bot-created PR’ler için en iyi yaklaşım bence şu: Otomasyonu kapatma, denetimi sıklaştır.
Ama approval sürecini öyle ağırlaştırma ki ekip sonunda workaround aramaya başlasın.

Nerede hata yaptım?

İlginç olan şu ki, Bunu da dürüstçe söyleyeyim; ilk denediğim benzer modelde ben yanlış branch protection ayarı yüzünden beklenmedik bir durum yaşadım. Pipeline hiç başlamadı. Hata mesajı baya kafa karıştırıcıydı çünkü sorun kodda değildi, policy tarafındaydı: Yetki olan kullanıcı approve etmişti ama repo kuralı belirli actor tiplerini dışarıda bırakıyordu. Çözümü basitti — kuralları sadeleştirdik — fakat ilk anda baya can sıktı. EWS Bildirimlerinden Microsoft Graph’a Geçiş: Sessiz Ama Büyük Değişim yazımızda bu konuya da değinmiştik. Daha fazla bilgi için vcpkg Mayıs 2026 Güncellemesi: Sessiz Güç, Büyük Etki yazımıza bakabilirsiniz.

Maliyet etkisi küçük görünür ama toplamada büyür

Açık konuşayım, bu tarz değişikliklerin maliyet etkisi hemen görünmez. Azure dünyasında da böyle şeyler çok olur; tek tek bakınca önemsiz duran loglama veya test tekrarı yıl sonunda bütçe yer bitirir! Actions" data-glossary-term="GitHub Actions">GitHub Actions tarafında da fazla çalışan pipeline demek daha fazla dakika tüketimi demek olabilir (özellikle self-hosted runner kullanmıyorsanız).

Türkiye’de şirketler açısından düşününce iş biraz daha hassaslaşıyor çünkü döviz bazlı servis maliyetleri TL tarafında çabuk hissediliyor. Bir proje yöneticisine “bu change ile yüzde kaç tasarruf ettik?” diye sorduğunuzda cevap çoğu zaman belirsiz oluyor ama operasyonel kazanç netleşiyor: Daha az manuel kontrol hatası, daha az tekrar işleme ve daha temiz release süreci. .NET 11 Preview 5: Sessiz Gelen Yenilikler, Büyük Etki yazımızda bu konuya da değinmiştik. Daha fazla bilgi için Discovery to Execution: Foundry’de Ajanları Toolbox ile Ölçeklemek yazımıza bakabilirsiniz.