DevSecOps Nedir ? Bileşenleri Nelerdir? Bildiğiniz üzere DevOps hayatımıza girdiğinden bu yana kısa sürede birçok kurumun ve kişinin ana gündemi haline geldi. Gelmek de zorundaydı. Şirketlerin arasındaki rekabet ve markete yazılımlarının sürümlerini olabildiğince hızlı çıkma gereksinimleri bu ihtiyacı adresliyordu. Müşteri memnuniyetinin bu kadar kritik ve taleplerin bu kadar hızlı değiştiği bir çağda müşterilerin ihtiyaçlarını en hızlı arza dönüştüren şirketin kazanacağı aşikardı. Hatalı kod sürümlerinin, geciken projelerin ve ön görülemeyen operasyonel eksikliklerin tolere edilemeyeceği bir rekabetin sonucu DevOps‘u sık sık konuşur olduk. Sadece üretilen kodun kalitesini ölçümlemek tabii ki yetersiz kalacaktı. Bunun yanı sıra üretilen kodun sistemsel etkileşimi, yani verilen hizmetin bütününe nasıl tesir ettiği aslında DevOps‘un asıl gündemiydi. Bu durumu ise, Agile yaklaşım ve DevOps etkileşiminin sonucu olarak özetleyebiliriz.
Peki, bu hızın ve rekabetin beraberinde getirdikleri gibi götürdükleri de oluyor muydu? Bu soru sorulduğunda artık yazımın ana konusu olan DevSecOps, benim sevdiğim şekliyle “Secure DevOps” konusuna yavaş yavaş gelmiş oluyoruz. Cevaba dönecek olursak hem evet, hem de hayır diyebiliriz. Evet, çünkü DevOps onay mekanizmalarını veya yerleşik güvenlik politikaları esnetmeye, kısmen hasıraltı etmeye neden olabiliyordu. Hayır, çünkü zaten eski geliştirme metodolojisinde (Waterfall) zaten güvenlik eksiklikleri vardı. Nasıl ki DevOps bir atılım olduysa ve klasik tanımıyla DEV ve OPS’u bir arada uyum ile çalışabilmesine vesile olduysa, DevSecOps da yazılım süreçlerinin sıkı bir güvenlik politikası olmadan müşteriye götürülmesinin tehlikeli olabileceğinin, en önemlisi de şirkete geri dönüşü olamayacak mali kayıplara neden olabilecek açıklar barındırabileceğinin ön görülmesi ve buna göre dizayn edilmesi gerektiğinin sonucu olarak ortaya çıktı.
Peki, başka bir soru sormak gerekirse bu durum “hız” konusundan taviz verilmesi anlamına mı geliyor?
Cevap gene aynı. Hem evet, hem de hayır.
Evet, çünkü doğal olarak ekstra güvenlik önemleri; DevOps Pipeline‘larında ek adımlar, ek bilgi birikimi ve ek olarak güvenlik ekipleriyle koordinasyon demek.
Hayır, çünkü biraz sonra bahsedeceğim ek adımlar olmadan, ilgili kodun mümkün olan en kısa süre içerisinde sorunlu olduğunu anlayamaz ve bu sorunu canlı ortamda bunu fark edersek, tüm yazılım döngüsünün baştan işletilmesine, itibar ve para kaybına neden olabiliriz. Bu da bolca zaman kaybı demek oluyor.
Günün sonunda sorulacak soruların cevaplarının önemi şirketten şirkete değişmekte, kodtan koda ise uygulanacak metotlar başkalaşmaktadır. DevOps aslında bütüne bakmaktır. DevSecOps ise perspektifimizi daha da genişletmeyi, atacağımız her adıma “güvenlik” endişesini yansıtmamızın önemini vurgular. Bu sebeple, Secure DevOps yaklaşımı şirketler için git gide daha da zaruri olacak ve her DevOps mühendisinin kabiliyetini bu yönde geliştirme zorunluluğunu da doğuracaktır. Bunun yanı sıra seçeceğimiz toollar, yani ürünler de DevSecOps’un olmazsa olmazıdır. Doğru tool set ile hareket etmemiz istediğimiz sonuca daha kolay varmamıza, ekiplerin “DevSecOps” kültürüne daha hızlı adapte olmalarına, hatta ve hatta üst yönetimin DevSecOps’un çıktılarını ve faydalarını daha net görmelerine vesile olacaktır.
Resim-1
İsterseniz artık yavaş yavaş hangi adımların “Secure DevOps” sürecine eklenebileceğine ve bize daha güvenli bir pipeline oluşturmamızda hangi ürünlerin yardımcı olabileceğine bakalım. Bu yazımda her bir maddeden kısaca bahsedeceğim. Bir sonraki yazılarımda ise her bir madde üzerinde detaylı duracak ve onlarla ilgili sizlere örnek uygulamalar yapmaya çalışacağım.
Not: Aşağıda belirttiğim başlıklar çoğaltılabilir ve ihtiyaca göre çıkartılabilir olduğunu belirtmeliyim.
- Pre-Commit Hooks
Yazdığımız kodun kullandığımız source control repolarına (bitbucket, git vb.) gitmesinden hemen önce yapılması gereken güvenlik kontrollerinin bir tool aracılığı ile yapılması diye özetleyebiliriz. Yazdığımız kodun içerisinde hassas bir bilgi var mı, yok mu diye kontrol edilmesi bu kontrollerden biri olarak gösterilebilir.
Örnek toollar: Talisman ve Puma Scan
- Secrets Management
Bilindiği üzere artık tüm pipeline’larımızı, altyapımızı, hatta güvenlik önemlerimizi bile “as a Code” felsefesiyle kod olarak yazıyoruz. Birçok API ile konuşuyoruz ve oradan gelecek cevaplara göre ise kodumuzun markete çıkmasına engel oluyor veya izin veriyoruz. Bundan dolayı ise, tüm işlemlerde yer alan hassas bilgilerin (API key, Subscription bilgileri, kullanıcı adı/şifreleri vb.) bir ambarda (vault) bulunması ve gerektiğinde buradan alınıp kullanılması gerekliliği doğuyor. İşte buna Secrets Management adı veriliyor.
Örnek toollar: Hashicorp Vault, AWS Secrets Manager ve Azure Key Vault
- Software Composition Analysis
Yapılan araştırmalara göre yazdığımız kodların yüzde 85’i community’nin commitlediği open source kütüphanelerden oluşuyor. Yani sizler az veya çok open source kütüphanelere kodlarınızda yer veriyorsunuz, veriyoruz. Ancak bu kütüphanelerde meydana gelen güvenlik zafiyetlerinden çoğunlukla bir haber oluyoruz. Kodumuzda kullandığımız her dependecy’inin mutlaka kontrol edilmesi ve buradaki tüm dependecy’lerin güncel olup olmadığının veya sağlıklı olup olmadığının markete çıkılmadan önce mutlaka incelenmesi gerekiyor. Software Composition Analysis de bu işin genel geçer adı ve şahsi fikrime göre bu yazıdaki en önemli noktalardan birisi de bu analiz işlemi diyebilirim. Bir sonraki yazılarımda bu başlığı detaylandıracağım ve özellikle Whitesource’un gücünü sizlere anlatmaya çalışacağım.
Örnek toollar: Whitesource ve Snyk
Resim-2
- Static Analysis Security Testing
SQL injection, Cross-site scripting ve Deserialization gibi zafiyetleri bulmamızı sağlayan, kodunuzu build esnasında inceleyen yönteme denir. SAST, en çok bilinen ve kullanılan güvenlik adımı diyebiliriz. Birazdan kısaca bahsedeceğim DAST’tan en büyük farkı “White box security testing” metoduyla kodunuzu incelemektedir. Test yapan kişi kodun tüm framework’üne, dizaynına ve implementasyonuna erişebilir durumdadır. O yüzden de size kodun “güzelliği” ile ilgili de geri dönüş verebilir, hatta tekrarlayan kod bloklarının yüzdesel oranını bile sizlere raporlayabilir. İlerleyen yazılarımda bu işin genel geçer toolu olan SonarQube’dan bahsedeceğim.
Örnek toollar: SonarQube ve FindSecBugs
- Dynamic Analysis Security Testing
Tam aksine “Black box testing” metoduyla kodunuzu inceler. Ne teknoloji kullandığınızı ve frameworkunuzu bilmez. Kaynak koduna veya binary’lere ihtiyacı yoktur. Örnek olarak runtime’da akan kodunuzu, websitenizi dışarıdan-içeriye doğru test eder. İlerleyen yazılarımda bu kısmın üzerinde uzunca durmak ve buradaki OWASP felsefesini irdelemek istiyorum. DevSecOps’un vazgeçilmez adımlarından biridir.
Örnek toollar: OWASP ZAP ve Nikto
- Security in «Infrastructure as Code»
Konteynırlar hayatımıza girdiğinden bu yana işler çok değişti. Host güvenliği ve onun yönetimi baya bir karmaşıklaştı. O yüzden bu başlığı kısaca özetlemek bu yazıda en zorlanacağım nokta diyebilirim. Kısaca özetlemek gerekirse; konteynırlar sandığımızdan çok daha fazla güvenlik zafiyeti potansiyeli olan bileşenler. Ve bu bileşenler günün sonunda bir host üzerinde çalışıyorlar. Buradaki her konteynırın sağlıklı olduğundan emin olmazsak tüm networkümüze bulaşabilecek bir tehlikeyi barındırıyor olma ihtimaliyle yaşıyoruz demektir. Bu sebeple runtime’da konteynır güvenliği ve halihazırda konteynırın katmanlarının güvenliği konusu bu yazının en ama en önemli güvenlik konusu. Bir sonraki yazımın konusu da bu konu olacak ve Twistlock özelinde konuyu ele alacağım.
Resim-3
- Compliance As Code
Organizasyonumuzun mutlaka belli başlı IT kuralları mevcuttur. Hatta ve hatta bu kurallar ülkesel veya evrensel regülasyonlar olabilir. (SOX, HIPAA, KVKK vb.) Bu kuralların otomatik bir şekilde test edilmesini belli başlı toollarla, “as a code” mantığı ile sağlayabiliyoruz. En önemli tool ise burada InSpec. Zaten bu ürünü Chef yakın zamanda satın aldı ve adını Chef InSpec olarak değiştirdi.
Örnek toollar: Chef InSpec ve serverspec
- Alerting and Monitoring
Belki de hepimizin en çok kullandığı ve anlatısı en kolay olan kısım; Monitoring ve Alert mekanizması. Ancak burada ufak bir farklılık mevcut. Burada bahsetmek istediğim aktif bir monitoring ve sorunun engellenmesi mekanizması… Örnek vermek gerekirse; eğer ki runtime’da çalışan kodunuza OWASP Top 10 listesindeki bir saldırı mevcutsa bunun algılanması, ilgili ekibin bilgilendirilmesi ve saldırının engellenmesi gerekmektedir. ModSecurity WAF ürünü bunun öncülerinden diyebilirim.
Resim-4
Bu konuyla ilgili sorularınızı alt kısımda bulunan yorumlar alanını kullanarak sorabilirsiniz.
Referanslar
TAGs: devsecops nedir, devsecops bileşenleri, devsecops, devsecops bileşenleri nedir
