Siber güvenlik dünyasında her sene yayınlanan raporlara bakarsanız, organizasyonların yüzde 90’ından fazlasının 'Shift Left' (sola kaydırma) stratejisini benimsediğini iddia ettiğini görürsünüz. Ancak aynı raporların alt satırlarında, kritik zafiyetlerin kapatılma süresinin (remediation time) hala ortalama 200 günün üzerinde olduğu gerçeği tokat gibi çarpar yüze. Bu devasa bir çelişki değil mi? Eğer her şeyi daha yazılım geliştirme aşamasının en başında yakalıyorsak, neden hala o 'kritik' etiketli açıklar aylarca sistemlerimizde misafir ediliyor? Benim bu konudaki pozisyonum net: Shift Left çoğu zaman güvenliği sola kaydırmak değil, güvenliğin yükünü ve suçluluğunu geliştiricinin (developer) omuzlarına bırakıp aradan çekilmektir. Eğer bu süreci sadece pipeline üzerine fırlatılmış üç beş tane tarama aracı olarak görüyorsak, aslında güvenliği artırmıyor, sadece gürültü miktarını maksimize ediyoruz.
Bir dönem PrimeBasket (kurgusal şirket) benzeri büyük ölçekli bir e-ticaret yapısında sızma testleri gerçekleştirirken şunu fark ettim: CI/CD süreçlerine entegre edilmiş statik kod analiz (SAST) araçları binlerce bulgu üretiyordu. Geliştiriciler ise bu bulguların yüzde 95’inin 'yanlış pozitif' (false positive) olduğunu bildikleri için artık 'güvenlik uyarısı' görmeye karşı bağışıklık kazanmışlardı. Bir kutucuğun kırmızı yanması artık kimseyi heyecanlandırmıyor, aksine işini engelleyen bir parazit gibi algılanıyordu. Ben sisteme girdiğimde, o devasa gürültü bulutu içinde kaybolmuş, sömürülmesi çocuk oyuncağı olan basit bir 'güvensiz doğrudan nesne başvurusu' (IDOR - Insecure Direct Object Reference) zafiyetini kullanarak binlerce kullanıcının adres bilgilerine ulaştım. Otomatik araçlar bunu yakalayamamıştı çünkü iş mantığını (business logic) anlayamıyorlardı. Geliştirici ise aracın ürettiği 500 sayfalık PDF raporuyla boğuştuğu için manuel olarak bu mantık hatasını kontrol edecek vakte sahip değildi.
Karşı argümanı duyabiliyorum: 'Sedat, hiç yoktan iyidir, en azından bilinen kütüphane açıklarını (SCA - Software Composition Analysis) yakalıyoruz.' Evet, bu doğru. Bilinen bir CVE'ye sahip eski bir kütüphaneyi kullanmak intihardır. Ancak mesele şu ki, güvenliği bir kontrol listesine (checklist) indirgediğimizde, ekip içindeki o 'güvenlik sezgisini' yok ediyoruz. Güvenlik bir 'gate' (kapı) değil, bir 'flow' (akış) olmalı. Eğer bir geliştiriciye 'bu kodu commit etmeden önce şu 10 kurala bak' derseniz, o 10 kuralı geçer ama 11. adımdaki felaketi görmezden gelir. Çünkü ona öğretilen şey güvenli kod yazmak değil, güvenlik aracını atlatmaktır.
Bu arada, sırf pipeline'da 'secret scanning' (gizli veri tarama) aracınız var diye kendinizi güvende hissediyorsanız yanılıyorsunuz; basit bir base64 encode işlemi ya da değişken isminin yaratıcı seçilmesi çoğu zaman o 'pahalı' araçları kör edebiliyor. Hiç kendi yazdığın bir regex'in (düzenli ifade), gerçekten koruman gereken API anahtarını neden yakalayamadığını merak edip o kodun derinliklerine indin mi?
Peki, neden bu durumdayız? Çünkü satın alması ve kurması en kolay şey araçlardır. Bir SAST veya DAST (Dinamik Uygulama Güvenliği Testi) aracını lisanslayıp Jenkins'e bağlamak iki günlük iştir. Ama bir geliştiriciye 'tehdit modelleme' (threat modeling) yapmayı öğretmek, ona bir saldırgan gibi düşünme yetisi kazandırmak aylar sürer. Biz kolayı seçiyoruz. Şirketler, güvenlik açıklarını bulma sorumluluğunu otomatize ettiklerini sanırken, aslında sadece sorumluluğu 'log' dosyalarının arasına gömüyorlar.
Şöyle bir senaryo düşün: Yarın sabah uyandığında tüm güvenlik araçlarının lisansı iptal edilmiş olsun. Ekibinde kaç kişi, bir girdi alanına (input field) baktığında oradan bir 'yük enjeksiyonu' (payload injection) yapılabileceğini araç yardımı olmadan görebilir? Eğer cevabın seni tatmin etmiyorsa, 'sola kaydırdığın' şey güvenlik değil, sadece bürokrasidir. Gerçek DevSecOps, o pipeline'daki kırmızı ışığın neden yandığını anlayan ve o ışığın yanmaması için tasarımı en baştan değiştiren insanların bir arada çalışmasıdır.
Şu soruyu dürüstçe kendine sor: En son ne zaman bir geliştiriciyle oturup, bir aracın raporunu değil de, uygulamanın mimarisindeki bir zayıflığı kahve eşliğinde tartıştın? Eğer araçların arkasına saklanmaya devam edersek, sadece daha hızlı ama aynı derecede güvensiz yazılımlar üretmeye devam edeceğiz.
Yazının başında verdiğim o rahatsız edici veriyi hatırlayalım: Şirketlerin yüzde 90'ı güvenliği sola kaydırdığını söylerken zafiyetler neden hala 200 gün boyunca sistemlerde yaşıyor? Cevap basit: Çünkü o araçlar zafiyeti buluyor ama kimse o zafiyeti 'sahiplenmiyor'. 'Bulunmuş' olması, 'çözülmüş' olduğu anlamına gelmiyor. Shift Left, bir araç seti değil, bir kültür dönüşümüdür. Eğer kültürü değiştirmeden sadece araçları sola iterseniz, elinizde kalan tek şey daha fazla gürültü ve mutsuz bir mühendislik ekibi olur. Şimdi o 200 günlük süreyi tekrar düşün; o süre boyunca sızan veri senin verin olsaydı, hala 'en azından aracımız var' diyebilir miydin?