Bot PR’lere de CI yolu açıldı: Güvenlikte ince ayar zamanı
Küçük bir detay: Geçen hafta bir ekip toplantısında tam da şu cümleyi duydum: “Bot açtı diye bu pull request’i atlayalım mı?” Açık konuşayım, işin aslı şu ki artık o refleks biraz eski kaldı. GitHub, github-actions[bot] tarafından oluşturulan pull request’lerin, kullanıcı onayıyla workflow çalıştırabilmesini sağladı. Küçük gibi dürüyor. Ama pratikte baya iş görüyor.
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.
Neden bu kadar ses getirdi?
İlk bakışta “Zaten approval vardı, ne değişti?” diyebilirsiniz. Haklısınız gibi dürüyor. Ama detayda fark büyük: Daha önce github-actions[bot] tarafından üretilen PR’ler bazı senaryolarda workflow tarafında kenara itiliyordu ve bu da otomasyon zincirini kırıyordu. Yanı kod geldi ama test kapısından geçmeden ilerleme ihtimali oluşuyordu.
Ş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.
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.
| Senaryo | Öneri | Dikkat Noktası |
|---|---|---|
| Küçük startup | Bazı bot PR’lerini manuel approval ile workflow’a al | Aşırı kural koyup ekibi yavaşlatma |
| Büyüyen ürün ekibi | Branch protection + code owners + review zorunluluğu kullan | Tüm repolarda aynı standardı uygula |
| Enterprise / regülasyonlu sektör | Ayrıntılı audit log ve kontrollü approval akışı kur | Sadece write access yetmez; yetki matrisini netleştir |
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ı. Daha fazla bilgi için
Bunu nasıl uygularsınız?
Lafı gevelemeden söyleyeyim: İlk işiniz repository policy’nızı gözden geçirmek olsun. Hele bir de de branch protection kurallarını ve kimlerin approve verebildiğini netleştirin.
İnanın, Sonra workflow dosyalarınızı inceleyin; hangi job secret erişiyor? Hangi step dış servise dokunuyor? Bunları bilmeden “approve ettim gitsin” yapmak bana göre kumar gibi biraz…
# Örnek kontrol listesi
1) Bot tarafından oluşturulan PR türlerini ayır
2) Approval yetkisini yazılı hale getir
3) Workflow secret kullanımını sınıflandır
4) Kritik repolarda manuel review şartını koru
5) Audit log'ları düzenli izle
- Kritik depolar: Manuel approval + sıkı branch protection kullanın.
- Düşük riskli depolar: Otomasyonu biraz daha serbest bırakabilirsiniz.
- Sekret içeren işler: Onaysız hiçbir şeyi koşturmayın.
- Ekip alışkanlığı: Her approve işlemini kısa notla belgelemek iyi fikir. — bunu es geçmeyin
Neyse uzatmayalım… Bence buradaki kazanım hızdan çok süreklilikte yatıyor. Bot PR geldiğinde tamamen kilitlemek yerine kontrollü şekilde CI yoluna almak hem modern DevOps pratiğine uyuyor hem de security ekibinin içini rahatlatıyor birazcık.
Bana göre eksik kalan taraf ne?
Bence, Beni en çok düşündüren nokta eğitim kısmı öldü aslında — dur bir saniye — çünkü teknoloji güzel de insanlar aynı olgunlukta ilerlemiyor her zaman.
Bir kurumda platform ekibi olgun olabilirken başka takım hâlâ “workflow neden tetiklendi?” sorusunun cevabını bilmiyor olabiliyor.
İşte bu yüzden dokümantasyon şart.
Ben Logosoft’ta geçen sene Haziran ayında yürüttüğümüz bir Azure DevOps migrasyonunda bunu yaşadım:
aynı organizasyonda iki farklı ürün grubu vardı,
biri release disiplinine sahipti,
diğeri işe her merge’i neredeyse production’a atacak gibiydi.
Teknik çözüm tamamdı ama kültür farkı yüzünden süreç yamalı bohça gibi kaldı.
Az önce X dedim ama aslında Y daha doğru olabilir:
burada teknik kontrol kadar eğitim. Sahiplenme gerekiyor.”
Bence bu özellik kim için daha değerli?
Eğer startup iseniz bu haber size doğrudan hız getirir. Eğer enterprise iseniz size hızdan önce standartlaşma fırsatı verir. Ve ikisi arasında kalan orta ölçekli firmalar… işte onlar en çok faydayı görebilir çünkü süreç oturtmak için yeterince büyükler. Hantallaşmamış oluyorlar henüz.”
Bir de şunu söyleyeyim:
GitHub Copilot app ya da ajan tabanlı üretken araçlarla çalışan ekiplerde bot kaynaklı değişikliklerin artacağını düşünüyorum. Yanı bu konu bugünün haberi gibi dursa da yarının normaline hazırlanıyoruz.”
Sıkça Sorulan Sorular
>
`github-actions[bot]` tarafından açılan pull request’ler artık otomatik mi çalışıyor?
Hayır, yanı pull request açıldığında workflow’lar kendiliğinden tetiklenmiyor. Önce birinin onay vermesi gerekiyor. Onayı verecek kişinin de repository’de write access yetkisi olması şart.
Bu değişiklik güvenliği düşürüyor mu?
Aslında her zamanki gibi, mesele nasıl kullandığınızla ilgili. Onay zorunluluğu sayesinde güvenlik modeli zayıflamıyor; bence tam tersine işler daha kontrollü bir hâle geliyor. Ama approval sürecini gevşetirseniz, açıkçası risk yeniden büyür.
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.
2 comments