Policy drift, hedef güvenlik standardı ile gerçek repo ayarları arasındaki farktır. Örneğin standart şunu söylüyor olabilir: main branch doğrudan push kabul etmez. En az iki reviewer gerekir. Yeni commit gelirse eski onay düşer. Secret içeren commit push anında engellenir. CI testleri geçmeden merge yapılamaz. Release branch'leri daha sıkı korunur. Gerçekte ise bazı repolarda bu kontroller eksiktir. Bu eksiklik genellikle kötü niyetle değil, hızlı kurulum, migration, istisna veya unutulan ayar nedeniyle oluşur. Saldırgan için sebep önemli değildir; açık branch policy yeterlidir.

Git Policy Governance ve DevSecOps Ölçeği

Git Policy Elle Yönetilmez

Küçük ekiplerde branch protection, reviewer sayısı ve secret scanning ayarları elle yönetilebilir. Ancak repo sayısı onlarca, yüzlerce veya binlere çıktığında manuel politika yönetimi drift üretir. Bir repo'da minimum reviewer vardır, diğerinde yoktur. Bir ekip secret scanning'i açmıştır, başka ekip kapatmıştır. Release branch'leri korunurken hotfix branch'leri unutulmuştur.

DevSecOps ölçeğinde Git policy governance, güvenli yazılım tedarik zincirinin ilk kontrol katmanıdır. Kod production'a gitmeden önce hangi kuralların uygulanacağı burada belirlenir.

Policy Drift Nedir?

Policy drift, hedef güvenlik standardı ile gerçek repo ayarları arasındaki farktır. Örneğin standart şunu söylüyor olabilir:

main branch doğrudan push kabul etmez.
En az iki reviewer gerekir.
Yeni commit gelirse eski onay düşer.
Secret içeren commit push anında engellenir.
CI testleri geçmeden merge yapılamaz.
Release branch'leri daha sıkı korunur.

Gerçekte ise bazı repolarda bu kontroller eksiktir. Bu eksiklik genellikle kötü niyetle değil, hızlı kurulum, migration, istisna veya unutulan ayar nedeniyle oluşur. Saldırgan için sebep önemli değildir; açık branch policy yeterlidir.

Governance Servisi Nasıl Çalışmalı?

Büyük organizasyonlarda Git policy yönetimi kodla yapılmalıdır. Hedef state merkezi tanımlanır, mevcut state API ile okunur ve farklar raporlanır veya otomatik düzeltilir.

Sağlıklı model:

Repo envanteri çıkarılır.
Repo risk sınıfı belirlenir.
Hedef policy seti atanır.
Mevcut policy düzenli taranır.
Drift raporlanır veya otomatik düzeltilir.
İstisnalar süreli ve onaylı tutulur.

Bu yaklaşım "güvenlik ayarı yaptık" yerine "güvenlik ayarı hâlâ doğru mu?" sorusunu cevaplar.

Kritik Git Policy Kontrolleri

Branch protection ve pull request zorunluluğu
Minimum reviewer sayısı
Code owner onayı
Secret scanning ve push protection
Status check zorunluluğu
Signed commit veya verified identity
Force push ve branch deletion yasağı
Release branch pattern'leri

Bu kontroller DevSecOps pipeline'ın ilk kapısıdır.

Eresus Yaklaşımı

Eresus Security, DevSecOps değerlendirmelerinde Git policy drift riskini repo envanteri, branch protection, secret scanning ve CI/CD yetkileriyle birlikte inceler. Kod güvenliği sadece scanner çıktısı değildir; kodun hangi kuralla production'a yaklaştığı da güvenlik kontrolüdür.

Saha Kontrol Notları

DevSecOps güvenliği, pipeline’a araç eklemekten daha fazlasıdır. Asıl hedef, riskli değişikliğin production’a taşınmadan görünür ve durdurulabilir hale gelmesidir.

İnceleme sırasında şu kanıtlar toplanmalıdır:

CI/CD token’ları hangi kaynaklara erişiyor?
Secret bulunduğunda otomatik revoke veya rotate akışı var mı?
Branch protection ve environment approval açık mı?
Build artefact’ları imzalanıyor mu?
Container image kaynakları doğrulanıyor mu?
Dependency güncellemeleri güven politikasıyla yönetiliyor mu?
Pipeline loglarında hassas veri tutuluyor mu?
Deploy kimliği kişisel hesaplardan ayrılmış mı?
Incident halinde hangi secret’ın kullanıldığı görülebiliyor mu?
Retest için pipeline kanıtı üretilebiliyor mu?

Uygulama Kontrol Listesi

Uzun ömürlü token’lar azaltılmalı.
Secret scanning rotasyon akışıyla bağlanmalı.
İmzasız artefact production’a alınmamalı.
Kritik branch’lerde review ve status check zorunlu olmalı.
Pipeline yetkileri ortam bazında ayrılmalı.
Olay müdahalesi kod temizliğiyle sınırlı bırakılmamalı.

Karar Noktası

Secret veya CI/CD token production erişimi sağlayabiliyorsa olay acildir. Eresus Security pipeline, token ve artefact zincirini birlikte inceleyerek gerçek etki alanını çıkarır.

Ek Kontrol Soruları

Bu risk hangi varlıkları etkiliyor?
Hangi kullanıcı rolleri bu akışa erişebiliyor?
Aynı sorun başka endpoint veya entegrasyonda tekrar ediyor mu?
Bulgunun müşteri verisine etkisi var mı?
Loglardan olayın izi sürülebiliyor mu?
Düzeltme sonrası retest nasıl yapılacak?
Geçici önlem ile kalıcı çözüm ayrıldı mı?
İş etkisi teknik ekibin dışında da anlaşılır mı?
Benzer hata için önleyici kontrol eklenebilir mi?
Ekip bu kontrolü release sürecine bağlayabilir mi?
Gerekirse bağımsız doğrulama için hangi kanıtlar hazırlanmalı?
Sonraki sprintte hangi iç bağlantı ve servis sayfası desteklemeli?