![Search icon](https://hackernoon.imgix.net/search-new.png?w=19&h=19)
Merhaba HackerNoon! Adım Sofia ve DevOps/Bulut mühendisiyim. HackerNoon ve Aptible'ın düzenlediği yarışmaya katılmaya karar verdim.
Bu yazımda DevSecOps boru hattının özelliklerinden ve Sola Kaydırma kavramından bahsedeceğim. DevSecOps hattının ana aşamaları, yazılım geliştirmede otomatik güvenlik kontrolleri ve ücretsiz ve açık kaynaklı araçlar hakkında bilgi edineceksiniz. Ayrıca güvenlik açıklarını daha erken tespit etmenize ve uygulama güvenliğini artırmanıza yardımcı olacak ipuçları da bulacaksınız.
Bu makale, DevSecOps hattınızın olgunluğunu değerlendirmenize, geliştirilmesi için bir yol haritası geliştirmenize, her görev için doğru araçları seçmenize ve DevSecOps felsefesini takip ederek projeleri nasıl yöneteceğinizi daha iyi anlamanıza yardımcı olacaktır.
DevSecOps metodolojisinin ana hedefi DevOps hatlarına, yani yazılım geliştirme sürecine otomatik güvenlik kontrolleri eklemektir.
Çok uzun zaman önce bilgi güvenliği uzmanları geliştirme sürecini tamamladıktan sonra testler gerçekleştirdi. Bu yaklaşım verimsizdir; güvenlik testi sırasında hatalar tespit edilirse tüm geliştirme döngüsünün yeniden başlatılması gerekir. Bu zaman alıcı ve pahalıdır.
Aşağıdaki resme bir göz atın. Hata düzeltme maliyetinin her adımda arttığını görebilirsiniz.
Geliştirme ve işlevsel testler sırasında keşfedilen güvenlik sorunlarını düzeltmenin neredeyse hiçbir maliyeti yoktur. Kaynak kodunda gerekli tüm değişiklikler anında yapılıp tekrar kontrole gönderilebilir.
Artefakt oluşturma aşamasında sorunları düzeltmek en az iki kat daha pahalıdır. Derleme sürecinde değişiklikler yapmanız (örneğin Dockerfile'ı düzenlemeniz) gerekecektir; bu da DevOps mühendislerinin yardımına ihtiyacınız olacağı anlamına gelir.
Entegrasyon testi sırasında bir hata tespit edilirse, düzeltilmesi 10 kat daha pahalı olacaktır. Bu durumda geliştirme döngüsünü yeniden başlatmanız ve geliştiricileri, DevOps mühendislerini ve test uzmanlarını dahil etmeniz gerekir.
Dağıtım aşamasında tespit edilen güvenlik sorunları, kullanıcı veri sızıntılarına yol açabilir. Şirket milyonlarca dolar para cezasına çarptırılabilir ve itibarı zedelenebilir, bu da bir hatanın maliyetinin yüzlerce kat artması anlamına gelir.
Dolayısıyla ana sonuç, güvenlik kontrollerinin mümkün olduğu kadar erken yapılması gerektiğidir. Eğer görselleştirirseniz, bunları Boru Hattının sol tarafına taşıyın. Bu, güvenlik uzmanlarının hakkında konuşmayı çok sevdiği Sola Kayma kavramıdır.
DevSecOps işlem hatları, uygulamaları üretim ortamında oluşturan, test eden, sunan ve bunları her aşamada güvence altına alan otomatikleştirilmiş bir süreç ve araçlar zinciridir.
Yukarıdaki resim, güvenlik kontrollerinin tüm ana aşamalarıyla birlikte DevSecOps Pipeline yapısını göstermektedir. İşte her biri hakkında birkaç kelime:
Şimdi bu kontrollerin ne olduğuna ve bunları gerçekleştirmek için hangi araçların kullanıldığına daha yakından bakalım.
Ön taahhüt kontrolleri, deponun yerel kopyasında değişiklik yapmadan önce geliştiricinin makinesindeki kaynak kodunu analiz etmenize olanak tanır. İfadelerden herhangi biri hata döndürürse, taahhüt gerçekleştirilmez. Bu durumda geliştiricinin hatayı düzeltmesi ve tekrar taahhüt etmesi gerekir.
Bu kontrol, örneğin şifrelenmemiş sırlara sahip kontrol edilmemiş kodun depoya girmesi durumunu önler.
İşlem öncesi kaynak kodu kontrollerini gerçekleştirmek için geliştiricilerin yerel makinelerine araçların yüklenmesi gerekir. Bu yaklaşımın sadece avantajları değil aynı zamanda dezavantajları da vardır. Örneğin çevresel farklılıklar: araçların farklı versiyonları, çeşitli işletim sistemleri ve hatta işlemci mimarileri.
Geliştiriciler ön işleme araçlarının farklı sürümlerini kullanırsa, kontrol sonuçları farklı olacaktır ve bu, birlikte çalışmayı zorlaştırabilir. Bir ekip içinde veya şirket genelinde taahhüt öncesi kontrolleri uygularken bunu göz önünde bulundurun.
Ön taahhüt kontrollerini ayarlamak için birçok açık kaynak araç kullanılabilir:
Bunlar taahhüt öncesi kontroller için harika araçlardır.
Oluşturma öncesi aşamada Beyaz Kutu Testi gerçekleştirilir. Bu kontroller, önceki adımda olduğu gibi kaynak kodunu analiz etmek için kullanılır. Bu durumda uygulama bir "beyaz kutudur" çünkü mimarisini ve iç yapısını biliyoruz ve anlıyoruz.
Birkaç tür oluşturma öncesi kontrol vardır:
Şimdi bunları ayrıntılı olarak tartışalım.
Gizli Tespit, şifrelenmemiş hassas bilgileri tespit eden otomatik bir kontroldür: sürüm kontrol sistemine giren kaynak kodundaki şifrelenmemiş sırlar.
Derleme öncesi kontroller, kaynak kodu sürüm kontrol sisteminin deposuna girdikten sonra gerçekleştirilir. Bu nedenle, örneğin deponun içeriğinin sızdırılması durumunda, depodaki tüm şifrelenmemiş hassas verilere saldırganlar tarafından potansiyel olarak erişilebilir.
Ayrıca gizli tespit kontrollerinin uygulanması süreci sıfırdan değil, gelişen bir projede gerçekleşebilir. Bu durumda şifrelenmemiş sırlar eski taahhütlerde ve farklı depo dallarında bulunabilir.
Bu sorunları çözmek için birçok farklı şey yapmamız gerekiyor. Örneğin, şifrelenmemiş sırların depolarını temizlemeli veya Hashicorp Vault gibi çeşitli gizli yönetim araçlarını uygulamalıyız.
Gizli Algılama kullanılarak yapılandırılabilir
Statik Uygulama Güvenliği Testi (SAST), analizcilerin yalnızca sözdizimsel doğruluğu kontrol etmekle kalmayıp aynı zamanda benzersiz ölçümler yardımıyla kod kalitesini de ölçtüğü bir testtir. SAST tarayıcılarının ana görevi güvenlik testidir.
Özellikle, SAST analizörleri yaygın güvenlik açıkları için kaynak kodu içerir; örneğin bazı güvenlik açıkları.
SAST analizine Beyaz Kutu Testi denir çünkü analizör uygulamanın iç yapısına erişebilir. Analizcilerin kaynak kodunu çalıştırmadan kontrol ettiklerini unutmamak önemlidir; bu nedenle hatalı pozitif sonuçlar üretebilir ve bazı güvenlik açıklarını tespit edemeyebilirler.
Bu nedenle kendinizi yalnızca SAST analiziyle sınırlamamalısınız. Konuya kapsamlı bir şekilde yaklaşmak ve farklı analiz türlerini kullanmak daha iyidir: SCA, DAST, IAST ve OAST.
Tescilli çözümler:
Ücretsiz çözüm GitLab SAST'tır.
Yazılım Bileşimi Analizi (SCA), açık kaynak bileşenlerini analiz ederek uygulamaları güvence altına alan bir metodolojidir.
SCA tarayıcıları, bilinen güvenlik açıklarını ve istismarları içeren güncel olmayan bağımlılıkları arar. Ayrıca bazı SCA araçları, bileşenlerin lisans uyumluluğunu ve lisans ihlali risklerini belirleyebilir.
Kaynak SCA, kaynak kodunu ve daha spesifik olarak kaynak kodunda tanımlanan uygulama bağımlılıklarını analiz eder. Bu analize genellikle Bağımlılık Taraması adı verilir.
SCA, bir bileşendeki güvenlik açığının tüm uygulamalarda güvenlik sorunlarına yol açabileceği bir sorunu tespit etmenize olanak tanır.
İyi bir örnek
Ücretsiz fiyatlandırma planlarına sahip ticari çözüm:
GitLab'ın bir parçası olarak (yalnızca Ultimate sürümünde mevcuttur), şunları kullanabilirsiniz:
Derleme sonrası aşama, CI Pipeline'daki kaynak kodundan yapıtlar oluşturulduktan sonra gelir: Docker görüntüsü, RPM paketi veya JAR arşivi. Derleme sonrası kontrollerle bu ikili yapılardaki bağımlılıkları analiz edebilirsiniz.
İkili SCA analizi, Docker görüntüleri, RPM paketleri ve JAR/WAR/EAR arşivleri gibi ikili yapıların incelenmesini içerir. Genellikle Konteyner Taraması olarak da anılır. İkili yapılar oluşturulduğunda, yani oluşturma sonrası aşamadan önce değil, onu çalıştırmak mantıklıdır.
Docker görüntüleri ile çalışırken bazı heyecan verici özellikler vardır. İkili SCA analizörleri, Docker görüntülerinin katmanlarını kontrol eder ve bunları, aşağıdakiler gibi genel güvenlik açığı veritabanlarında karma toplamlar olarak arar:
Analizcilerden bazıları yalnızca savunmasız bileşenleri bulmakla kalmaz, aynı zamanda örneğin halihazırda düzeltilmiş bir güvenlik açığına sahip bir bileşenin gerekli minimum sürümünü belirterek bir düzeltme önerebilir.
Ücretsiz çözüm:
Açık Kaynak çözümleri:
Yerleşik analizörlere sahip Docker Registry -
Bu aşamada dinamik Gri Kutu Testi ve Kara Kutu Testi gerçekleştirilir. Uygulamanın iç yapısı kısmen veya tamamen bilinmediğinde, bu güvenlik kontrolleri, güvenlik açıklarını bulan ve bunları kullanarak uygulamayı "kırmaya" çalışan bir saldırganın eylemleri taklit edilerek gerçekleştirilir. Her birini kısaca tartışalım: DAST, IAST ve OAST.
DAST tarayıcıları, çeşitli güvenlik açıkları aracılığıyla harici saldırıları simüle ederek uygulamaları otomatik olarak test eder. Uygulama analizör için bir kara kutudur; bu konuda hiçbir şey bilinmiyor.
DAST kontrolleri için uygulamanın çalışan bir örneğinin tarayıcıda mevcut olması gerekir. Ayrıca, uygulamanın test örneğinin parametreleri üretim kurulumuna ne kadar yakınsa, hatalı pozitif sonuçlar da o kadar az olacaktır.
Örneğin, yalnızca HTTP protokolü aracılığıyla erişilebilen bir test uygulaması örneğini dağıttığınızı, ancak üretimde uygulamaya yalnızca HTTP protokolü aracılığıyla erişilebildiğini varsayalım.
Bu durumda DAST tarayıcısı, istemci (analizör) ile sunucu (uygulama örneği) arasındaki trafik şifrelemesinin eksikliğiyle ilgili bazı hatalar üretecektir.
Dikkatinize değer araçlar:
Harika, devam et.
IAST (Etkileşimli Uygulama Güvenliği Testi), Beyaz Kutu Testi SAST ve Kara Kutu Testi DAST'ın avantajlarını ve güçlü yönlerini birleştiren bir Gri Kutu Testidir.
Geliştiriciler, SAST ve DAST yöntemlerinin tüm avantajlarını toplamak ve dezavantajlarını ortadan kaldırmak için, bu yöntemleri birleştiren hibrit bir mekanizma olan IAST'ı icat etti. Kod analizi yoluyla uygulamanın işleyişi hakkında daha fazla bilgi verdiği için dinamik testin doğruluğunu artırır.
IAST'ın avantajlarının yanı sıra sınırlamalarının da olduğunu hatırlamakta fayda var. En temel olanı, test edilen uygulamanın yazıldığı dile bağımlılıktır. IAST çözümleri uygulama düzeyinde çalışır ve davranışını analiz etmek için yürütülebilir koda erişim gerektirir.
Bu, IAST çözümlerinin uygulamanın yazıldığı programlama dilini anlayabilmesi gerektiği anlamına gelir. Belirli bir IAST çözümüne yönelik desteğin bazı diller için diğerlerinden daha iyi uygulanabileceği unutulmamalıdır.
IAST analizi de uzun zaman alıyor. Uygulamanın boyutu ve karmaşıklığı, dış bağımlılıkların sayısı ve kullanılan IAST aracının performansı gibi birçok faktöre bağlıdır.
Ayrıca analiz süreci kodun kendisini taramaz, yalnızca doğrudan yürütülen parçaları kontrol eder. Bu nedenle, mümkün olduğu kadar çok uygulama senaryosunu test edebildiğinizde, IAST analizinin işlevsel testlerle birleştirilmesi en iyisidir.
İşte sizin için harika araçlar:
Harika, devam et.
OAST (Bant Dışı Uygulama Güvenliği Testi), tarafından geliştirilen bir tekniktir.
Seni öneririm:
Devam et.
Bu, uygulama güvenliğinin ve çalışabilirliğinin sağlanmasında önemli bir aşamadır. Geliştirme aşamasında gerçekleştirilen taahhüt öncesi kontrollerin aksine, dağıtım sonrası kontroller, uygulamanın doğal ortamda çalışması sırasında olası sorunları tespit etmenize olanak tanır.
Yeni güvenlik açıklarını zamanında tespit etmek için, bir uygulamanın devreye alınmasından sonra da dahil olmak üzere düzenli yapı denetimleri yapılması gerekir.
Bu, özel depolar veya araçlar kullanılarak yapılabilir:
Güvenliği sağlamanın bir diğer yolu ise uygulamanın kendisini izlemektir. Bu amaç için çeşitli teknolojiler mevcuttur:
RASP'ın WAF'a göre temel avantajı, uygulamanın nasıl çalıştığını anlaması ve saldırıları ve yasa dışı trafiği tespit etmesidir. RASP yalnızca imza eşleştirmeyi kullanan tipik saldırıları görmekle kalmaz, aynı zamanda anormalliklere tepki vererek sıfır gün güvenlik açıklarından yararlanmaya çalışır.
WAF'tan farklı olarak RASP, uygulama içinde ve uygulamayla birlikte çalışır. WAF kandırılabilir. Bir saldırgan uygulama kodunu değiştirirse WAF, yürütme bağlamını anlamadığından bunu algılayamaz.
RASP, uygulama hakkındaki teşhis bilgilerine erişebilir, uygulamayı analiz edebilir, anormallikleri tespit edebilir ve saldırıları engelleyebilir.
RASP teknolojisinin, saldırıları varsayılan olarak önlemeye odaklanma özelliği vardır. Sistem kaynak koduna erişim gerektirmez.
Seni öneririm:
Harika, devam et.
Pipeline'ın farklı aşamalarında birçok Uygulama Güvenliği Testi/DevSecOps analizörü kullanıyorum. Her biri kendi formatında bir rapor oluşturur ve bazıları Yanlış Pozitifler olarak adlandırılan sonuçlar üretir. Bu nedenle bir uygulamanın güvenliğini bir bütün olarak analiz etmek kolay değildir.
Güvenlik açıklarını etkili bir şekilde analiz etmek ve düzeltme sürecini yönetmek için, genellikle yalnızca Güvenlik Kontrol Panelleri olarak adlandırılan özel Güvenlik Açığı Yönetimi araçları kullanılır.
Güvenlik Kontrol Panelleri, DevSecOps analizlerinin sonuçlarını birleşik ve analiz edilmesi kolay bir biçimde sunarak sorunu çözer. Bu şekilde güvenlik mühendisleri hangi sorunların mevcut olduğunu, hangilerinin en kritik olduğunu ve hangilerinin ilk önce ele alınması gerektiğini görebilir.
Güvenlik Kontrol Panelleri olarak genellikle çok çeşitli araçlar kullanılır: örneğin, klasik SOAR/SIEM sistemleri ve Swordfish Security'nin özel DevSecOps orkestratörü AppSec.Hub veya açık kaynaklı güvenlik açığı yönetimi araç seti DefectDojo.
DefectDojo yaygın bir araçtır. Kurumsal şirketlerde bile yaygın olarak kullanılmaktadır. Bununla birlikte, popülaritesine ve sağlam yaşına rağmen, katkıda bulunanlar taahhütteki temel işlevselliği bozduğunda bu araç zaman zaman bazı başlangıç düzeyinde kusurlara sahiptir.
Ancak güzel olan şey, DefectDojo geliştiricilerinin ve bakımcılarının karmaşıklıkları çözmeye yardımcı olmasıdır. DefectDojo geliştiricileri çok duyarlı insanlardır; GitHub'daki Sorunlar aracılığıyla kendileriyle doğrudan iletişime geçmenizi öneririz.
Bir kez daha, makalede neler olduğuna dair kısa bir özet sunuyoruz.
Sola Kaydırma konseptinin ne olduğunu ve hata düzeltme maliyetlerini ve geliştirme süresini azaltmaya nasıl yardımcı olduğunu açıkladım: geliştirme sürecinde güvenlik kontrollerine ne kadar erken başlarsanız o kadar iyi.
Ardından DevSecOps Pipeline yapısını yeniden yapılandırdım ve Pipeline'ın her aşamasında hangi güvenlik kontrollerinin yapıldığına baktım:
Artık DevSecOps Pipeline'ın nasıl çalıştığını anlıyorsunuz. Artık DevSecOps işlem hatlarınızın olgunluğunu değerlendirebilir, geliştirilmesi için bir yol haritası geliştirebilir ve her görev için doğru araçları seçebilirsiniz.