Shift-Left Security: İnceleme Kuyruğu Darboğazını Kaldırmak

Birçok organizasyonda tamamlanmış bir değişiklik, üretime çıkmadan önce günlerce inceleme kuyruğunda bekler. Bu kuyruğun nedeni, güvenlik incelemesinin tek tip manuel bir kapı gibi ele alınmasıdır: her değişiklik, riski ne olursa olsun, üretime ulaşmadan önce bir insanın arkasında sıraya girer. Çözüm güvenlikten vazgeçmek değil; incelemeyi her değişiklik için bir kapı olarak görmeyi bırakmaktır; onu otomatik, risk-tabanlı korkuluklara dönüştürün ki sıradan durum hiçbir zaman bir insanı beklemesin. Kuyruk böylece güvenliği zayıflatmadan ortadan kalkar ve kapı yalnızca riskin gerektirdiği yerde kalır.

Argümanın dört hamlesi var: sıradan durumu otomatikleştirin, yalnızca gerçekten yüksek riskli değişiklikleri bir insana yönlendirin, güvenli yolu varsayılan yol yapın ve bağımlılık hijyenini bir ritme oturtun. Her biri aynı noktayı pekiştirir: güvenlik incelemesi lead time’ınızın sahibi olmamalı. Bu yazının içinde durduğu daha geniş ritim tablosu için Compressing Time to Production yazısına; geri almanın (rollback) bizzat kısıt olduğu eksen için geri alamadığınız istemci yazısına bakın.

Lead-Time Vergisi Olarak İnceleme Kuyruğu

Değişiklikler için lead time, commit’ten üretimde çalışır hale gelene kadar geçen süredir. Bir değişikliğin kuyrukta atıl beklediği her dakika saf bekleme durumudur ve zorunlu manuel güvenlik incelemesi bunun en güvenilir kaynaklarından biridir. Kapı seri çalışır ve tek tip uygulanır: tek satırlık bir metin değişikliği ile yeni bir kimlik doğrulama akışı aynı sıraya girer, böylece ortalama değişiklik en riskli değişikliğin bekleme süresini miras alır.

DORA’nın yaygın güvenlik (pervasive security) rehberi, bunu işin sabit bir maliyeti değil aşağı çekilecek bir sayı olarak görmenin izin belgesidir. İncelemeyi açıkça lead-time terimleriyle çerçeveler: “incelemenin geliştirme sürecine ne kadar süre eklediğini” ölçün, bu süre “üzerinde anlaşılan bir asgariye ulaşana kadar düşmelidir” ve “güvenlik inceleme süreci geliştirmeyi yavaşlatmamalıdır.” Üzerinde anlaşılan asgari hedeftir; sabit, çok günlük bir kuyruk ise hata durumudur.

Bunun mümkün olmasının asıl nedeni, hız ve istikrarın bir trade-off olmamasıdır. DORA’nın araştırması 2015’ten bu yana yüksek performans gösterenlerin her ikisini de elde ettiğini ortaya koyar ve Accelerate kitabı aynı tezi veriye dayandırır. Yani günler ekleyen bir güvenlik kapısı, hız karşılığında güvenlik satın almıyor; kanıtların kabul etmek zorunda olmadığınızı söylediği bekleme durumunu ekliyor. (DORA’nın tam çerçevesi ve performans bantlarının her yıllık ankete göre nasıl kaydığı, burada yeniden türetilmek yerine yukarıda bağlantısı verilen ritim genel bakışında ele alınmıştır.)

Yukarıdaki saat baştan sona işler, ama inceleme kuyruğu insan müsaitliğine bağlı olduğunda sınırsız büyüyen segmenttir. Diğer segmentler makine süresiyle sınırlıdır; kuyruk ise bir backlog ile sınırlıdır. Bu asimetri, kuyruğun neden lead time’a hükmettiğini açıklar ve sıkıştırılmaya değer segment de budur.

Kaliteyi İnşa Etmek, Denetlemek Değil

İlk hamle, değişiklikleri “bitti” denildikten sonra denetlemeyi bırakıp kontrolleri pipeline’ın içine inşa etmektir. DORA bunu Deming’in terimleriyle söyler: “kaliteyi sağlamak için denetime bağımlılığı bırakın” ve güvenlik kontrollerini teslimat pipeline’ına otomatikleştirerek “kaliteyi ürünün içine inşa edin.” Somut olarak bu, statik analiz (SAST), bağımlılık ve bileşen analizi (SCA), gizli anahtar taraması (secret scanning) ve dinamik analizin (DAST) her değişiklikte pipeline adımları olarak çalışması demektir; bir insanın sonradan planladığı ayrı bir aşama olarak değil.

Kontroller pipeline’da çalıştığında iki şey değişir. Sıradan durum, build’in çalıştığı sürede makineler tarafından doğrulanır, böylece temiz bir değişiklik bir insanı hiç beklemez. Ve denetim kanıtı bir yan ürün olarak üretilir; DORA’nın çerçevesi, kanıtı son dakikada elle toplamak yerine denetçiler için “talep üzerine üretmektir” (generate evidence on demand). İnceleme kuyruğu küçülür çünkü çoğu değişiklik artık ona hiç girmez.

OWASP’ın DevSecOps Olgunluk Modeli bunun için somut bir benimseme merdiveni verir. Seviye 2’de SAST, SCA ve DAST otomatik raporlama ile CI içinde çalışır. Seviye 3’te “pipeline’lar önem derecesi eşiklerine göre başarısız olacak şekilde yapılandırılır” ve bulguların ayrı bir kuyrukta birikmemesi için zorunlu giderme süreleri tanımlanır. İlerleme önemlidir: yalnızca rapor veren tarama tavsiye niteliğindedir, bir eşikte build’i başarısız kılan tarama ise bir insanın tutmasına gerek olmayan gerçek bir kapıdır.

Bir uyarı bunu dürüst tutar. DORA 2016’da güvenliği teslimata entegre eden ekiplerin giderme süresinin yaklaşık yarısını harcadığını bildirdi, ancak bu rakam eski ve korelasyona dayalıdır; kaynak cümlesi yalnızca güvenliği değil, performans ve erişilebilirliği de birlikte kapsar. Bunu nedensel bir vaat olarak değil, yönsel bir destek olarak görün. Otomasyon sıradan durumu triyaj eder ve bulguları erken yüzeye çıkarır; yargının asıl mesele olduğu değişiklikler için insan yargısının yerini almaz. Bir sonraki hamle de tam olarak bunu ele alır.

Risk-Tabanlı İnceleme, Tek Tip Kapı Değil

Otomasyon kuyruğu inceltir, ama onu kaldıran kaldıraç yönlendirmedir. İlke şudur: her değişikliği riske göre sınıflandırın ve yalnızca gerçekten yüksek riskli değişiklikleri bir insana gönderin; geri kalanı otomatik kapılardan ya da self-servis bir yoldan geçsin. Tek tip kapı tam da bu ayrımı yapmayı reddettiği için başarısız olur; metin değişikliğini kimlik doğrulama değişikliğinin oranıyla vergilendirir.

NIST’in Güvenli Yazılım Geliştirme Çerçevesi (SSDF) tam da bu öncül üzerine kuruludur. SSDF “sonuç-tabanlıdır” (outcome-based) ve yazarları açıktır: “SSDF’nin amacı izlenecek bir kontrol listesi oluşturmak değil, risk-tabanlı bir yaklaşımı planlamak ve uygulamak için bir temel sağlamaktır.” Otomasyonu da birinci sınıf bir kaygı olarak adlandırır: “otomatikleştirilebilirlik (automatability), özellikle uygulamaları ölçekte hayata geçirmek için dikkate alınması gereken önemli bir faktördür.” Risk-tabanlı, otomatikleştirilebilir bir çerçeve, kapı koymak yerine yönlendirmenin resmi gerekçesidir.

Aşağıdaki yönlendirme diyagramı tüm bu yaklaşımın omurgasıdır. Üç şeridin önünde bir risk sınıflandırıcı durur. Düşük riskli değişiklikler yalnızca otomatik kapılardan geçer. Orta riskli değişiklikler, yerleşik kontrollere sahip hazır yol (paved road) self-servis yolunu izler. Yalnızca yüksek riskli değişiklikler (yeni kimlik doğrulama, veri işleme değişiklikleri, yeni dış yüzey, hassas izinler) white-glove insan incelemesi alır. Kenar rengi risk seviyesini gösterir: yeşil otomatik geçer, amber self-servistir, kırmızı insan şerididir.

Açıkça söylenmeye değer trade-off şudur: yönlendirme, insan dikkatini her değişikliğe ince ince yaymak yerine fayda sağladığı yere yoğunlaştırır. Risk sınıflandırıcı, sahip olup ayarladığınız bir şeye dönüşür; yanlış sınıflandırma yeni hata durumudur, bu yüzden yüksek-risk şeridinin ölçütleri açık ve gözden geçirilebilir olmalıdır. Ama bu, tek tip bir kuyruktan çok daha iyi bir sorundur. Bu model otomasyonun incelemeyi tamamen gereksizleştirdiğini iddia etmez; incelemenin gerçekten ihtiyaç duyan değişikliklere ayrılması gerektiğini ve bu ayırmanın bir backlog ile değil, politika ile yapılması gerektiğini iddia eder.

Hazır Yol

Yönlendirme bir değişikliğin hangi şeride gireceğini söyler; hazır yol ise sıradan şeritleri varsayılan olarak güvenli kılan şeydir. Fikir, güvenli yolu en az direnç gösteren yol yapmaktır: varsayılanların (kimlik doğrulama, gizli anahtar yönetimi, ağ politikası, temel imajlar, loglama) zaten doğru olduğu merkezi bir platform; böylece bir ekip güvenliği bir incelemeden geçerek değil, platformu kullanarak edinir.

Netflix, uygulama güvenliğini ölçeklendirme anlatımında bunu doğrudan tarif etti. Strateji “varsayılan olarak güvenli merkezi platformlardı” (secure by default central platforms) ve içselleştirmeye değer sonuç şudur: “bu güvenlik kontrollerinin benimsenmesini sağlamak… zafiyet giderimine kıyasla daha fazla uygulama riskini azaltır.” Gerekçe yapısaldır. “Uygulama başına güvenlik değerlendirmeleri… ölçeklenmez”, bu yüzden tek tek uygulama bazında bulgu kovalamak, bir risk sınıfını her yerde aynı anda düzelten bir platforma karşı kaybeder. Bu evrensel bir buyruk değil, tek bir şirketin deneyimidir, ancak ölçeklenme argümanı genellenebilir: varsayılan olarak benimsenen bir kontrol, elle düzeltilen bir bulgudan daha iyi performans gösterir.

Hazır yol ile yönlendirme modeli birbirine oturur. Korkuluk (guardrail) yolun içine inşa edilmiş bir kontroldür; kapı ise bir insanın görevlendirildiği bir kontrol noktasıdır. Aşağıdaki tablo, bir liderin gerçekten önemsediği boyutlarda ikisini karşılaştırır.

Boyut	Manuel kapı	Hazır yol korkuluğu
Kim hareket eder	Bir inceleyen, değişiklik başına	Platform, otomatik olarak
Ne zaman hareket eder	Değişiklik “bittikten” sonra	Değişiklik inşa edilirken
Bir düzeltmenin etki alanı	Aynı anda tek değişiklik	Platformu kullanan her değişiklik
Lead-time etkisi	Değişiklik başına bekleme ekler	Sıradan durumda hiç
Neyle ölçeklenir	İnceleyen sayısı	Platform benimseme oranı

Netflix bir insan şeridini de korudu: yüksek riskli ekipler ve değişiklikler için “white glove” inceleme. Bu, yönlendirme diyagramındaki yüksek-risk şeridinin aynısıdır ve dürüst sınırdır. Hazır yol, sıradan durum için kuyruğu kaldırır; riskin gerektirdiği durumlar için insan incelemesini ortadan kaldırmaz.

Bağımlılık Hijyenini Ritme Oturtmak

“Güvenli kodu ne sıklıkta çıkarmalıyız?” sorusu genellikle periyodik bir bağımlılık denetimiyle yanıtlanır; bu da riski parça parça ele alır ve zafiyetli geçişli (transitive) bağımlılıkların denetimler arasında uzun süre kalmasına izin verir. Daha iyi yanıt bir ritimdir: bağımlılık güncellemelerini otomatikleştirin ki yamalama sürekli olsun ve tedarik zinciri köken kanıtını (provenance) artımlı olarak benimseyin ki her güvence seviyesi ertelediğiniz bir proje değil, atabileceğiniz bir adım olsun.

Otomatik bağımlılık güncellemeleri, Dependabot veya Renovate gibi araçlar aracılığıyla yamalamayı periyodik bir olaydan küçük pull request’lerden oluşan istikrarlı bir akışa çevirir. GitHub’ın Octoverse 2025 raporu burada somut hareket bildiriyor: kritik düzeltmeler yaklaşık %30 daha hızlı geldi, medyan giderme süresi 37 günden 26 güne düştü ve kritik uyarı taşıyan depo sayısı %26 azaldı. Benimseme bu ritmi izledi; Dependabot 2,66 milyondan fazla depoda etkindi ve yıldan yıla yaklaşık %24 arttı. Bunlar bildirilen popülasyon rakamlarıdır, kontrollü bir deney değil, ama bir ritmin ürettiği şekli tarif ederler: daha hızlı düzeltmeler, daha az kalıcı kritik zafiyet.

Tedarik zinciri köken kanıtı diğer yarıdır ve değeri artımlı olarak benimsenebilir olmasındadır. SLSA build track (v1.2 referans alınmıştır) tek bir çıta değil, bir merdiven tanımlar. Build Seviye 1, köken kanıtının var olması demektir: build, artefaktın nasıl üretildiğine dair bir kayıt yayar. Seviye 2, barındırılan bir build platformundan imzalı köken kanıtı ekler ki bu, build’den sonra artefakta müdahaleye karşı koruma sağlar. Seviye 3, sertleştirilmiş bir build platformu gerektirir ve build’in kendisi sırasındaki müdahaleye karşı koruma sağlar. Görünürlük için L1’den başlayıp güvence maliyetine değer hale geldikçe tırmanabilirsiniz.

Bir yazılım malzeme listesi (SBOM), bu tabloda geri kalanı yönetilebilir kılan envanter olarak yer alır: bir build’in içinde ne olduğunu listeler, böylece yeni bir zafiyet geldiğinde “etkileniyor muyuz?” sorusuna manuel bir tarama olmadan yanıt verebilirsiniz. Bu, giderim değil katalogdur; onu otomatik güncellemelerle eşleştirmek, bilinen bir maruziyeti bir yangın tatbikatı yerine rutin bir pull request’e dönüştürür.

Dürüst Sınır

Öneri şudur: sıradan durumu otomatikleştirin, riske göre yönlendirin ve bağımlılıkları bir ritme oturtun; böylece güvenlik lead time’ınızın sahibi olmayı bıraksın. Bu önerinin sınırı, ciddiye alınmaya en değer kısımdır: korkuluklar yalnızca hazır yol gerçekten self-servis olduğunda lead time’ı sıkıştırır. Yarı inşa edilmiş bir platform, vaat ettiğinin tam tersini yapar.

DORA’nın 2024 araştırması buradaki dengeleyici bulgudur. İç geliştirici platformu benimsemenin geliştirici verimliliğini artırdığını, ancak kısa vadede throughput’ta (yaklaşık %8 mertebesinde) ve istikrarda (yaklaşık %14 mertebesinde) bir düşüşle yönsel olarak ilişkilendirildiğini buldu; kesin rakamlar ikincil özetler arasında değiştiği için bunları kesin bir ölçüm değil, tek bir ikincil sinyal olarak görün. DORA’nın belirttiği neden, güvenlik adımlarının kendisi değil, eklenen aktarımlardı (handoffs). Güvenlik yorumu DORA’nın bulgusu değil, makul bir mekanizmadır: gerçekten self-servis olmayan bir güvenlik platformu, bir ekip ile üretim arasına yeni bir aktarım yerleştirir; bu da yalnızca eski inceleme kuyruğunun platform kılığına girmiş halidir.

Bu, temiz bir test verir. Bir ekibin bilet açıp beklemeden karşılayamadığı bir korkuluk, korkuluk değildir; ek adımları olan bir kapıdır. Modelin tüm değeri, sıradan yolun döngüde bir insan olmadan yürünebilir olmasına bağlıdır, bu yüzden platform varsayılan yolun kolay yol olacağı kadar bitmiş olmalıdır. Değilse, bir kuyruk kaldırmamış, bir kuyruk eklemiş olursunuz.

Tek bir sonraki adım hem en ucuz hem de en aydınlatıcı olanıdır: güvenlik incelemenizin bugün lead time’a eklediği bekleme süresini ölçün. O sayı bir kez ortaya çıktığında, yukarıdaki her hamle ona karşı bir kaldıraca dönüşür. Önce sıradan durumu otomatikleştirin, geri kalanı riske göre yönlendirin; böylece kuyruk, ne zaman çıkacağınızı belirleyen kalem olmaktan çıkar.

Kaynaklar

• DORA — Capabilities: Pervasive security - İnceleme süresini aşağı çekilecek bir lead-time metriği olarak çerçeveler ve kaliteyi-içine-inşa-et argümanını sunar.
• Scaling Appsec at Netflix - Kapılar yerine korkuluklar; uygulama başına değerlendirmeler ölçeklenmez; yüksek risk için white-glove inceleme.
• NIST SSDF (SP 800-218) - Kontrol listesi değil, sonuç-tabanlı ve risk-tabanlı; PO/PS/PW/RV uygulama grupları.
• OWASP DevSecOps Maturity Model - Seviye 2 CI’da otomatik tarama; Seviye 3 önem-eşiği pipeline hataları.
• SLSA v1.2 — Build track basics - Artımlı benimsenebilir tedarik zinciri güvence seviyeleri (L1’den L3’e).
• GitHub Octoverse 2025 - Bağımlılık giderim rakamları: %30 daha hızlı kritik düzeltmeler, 37’den 26 güne, kritik uyarılı depolarda %26 azalma.
• DORA — A history of DORA’s metrics - 2015’ten beri geçerli ‘trade-off yok’ bulgusu ve performans bantlarının yıllık değişimi.
• DORA 2024 State of DevOps Report - Platform mühendisliğinin throughput ve istikrar karşı ağırlığı.
• Are you an Elite DevOps performer? — Google Cloud - Değişiklikler için lead time’ın commit’ten üretime kadar tanımı.
• Accelerate (Forsgren, Humble, Kim) - “Hız ve istikrar bir trade-off değildir” tezinin arkasındaki veri.