Bu Help Net Security röportajında GitLab’ın CISO’su Josh Lemos, DevOps’tan DevSecOps’a geçişten bahsediyor ve sistem oluşturmanın ve güvenlik araçlarını entegre etmenin karmaşıklığına odaklanıyor. Geliştirme hızını korumaya, iş birliğini teşvik etmeye ve DevSecOps başarısını takip etmek için ölçümleri kullanmaya yönelik ipuçları paylaşıyor.
DevOps’tan DevSecOps’a geçişte kuruluşların en önemli zorlukları nelerdir?
Kuruluşların oluşturma süreçlerinin ve geliştirici ekosistemlerinin karmaşıklığı, güvenliği DevOps uygulamalarına uygulamak isteyenler için önemli bir zorluktur. Her biri özel araçlara sahip olan ve güvenlik araçlarıyla bütünsel olarak entegre olmayan çok sayıda yapı sisteminin olması olağandışı bir durum değildir. Ayrıca, güvenlik ekibinin geliştirici araçlarına bitişik araçları çalıştırması ve uzun geri bildirim döngülerinden muzdarip olması da yaygındır.
DevOps’taki geliştiriciler günde onlarca veya yüzlerce kez kod dağıtabilirken, tarayıcılar, örneğin statik uygulama güvenlik araçları (SAST), genellikle planlı bir şekilde çalışır ve bu da geri bildirim döngülerinde gecikmelere yol açar. Bu model en çok mono depolara sahip kuruluşlarda yaygındır.
Kuruluşların DevOps’tan DevSecOps’a geçiş yaparken bilinçli olmaları gerekir. Derleme sistemlerinizi ortak bir teknoloji yığınında basitleştirmek, ekiplerin tüm yazılım projelerini ortak bir araç zinciriyle gerçekleştirmesine olanak tanır. Verimlilik faydaları çok büyüktür ve güvenlik kontrollerini doğrudan boru hattına yerleştirerek kısa çevrim sürelerine olanak tanır.
Kuruluşlar, daha büyük bir saldırı yüzeyi oluşturabilecek ve ekiplerin sıralaması için daha fazla güvenlik taraması bulgusu üretebilecek, bakımı zor kod ve gereksiz bağımlılıklar gibi optimal olmayan tasarım kararlarından kaynaklanan karmaşıklığı önlemek için sistemlerine güvenliğin uygulanmasını kolaylaştıracak adımlar atmalıdır. aracılığıyla, önceliklendirin ve adresleyin.
Kuruluşlar aynı zamanda geliştirmeye yazılımı en aza indirme hedefiyle yaklaşmalıdır; yani benimsedikleri araçlar ve kod tabanlarına ne eklemeye karar verdikleri konusunda bilinçli olmalıdırlar. Bu, bağımlılıkların ortadan kaldırılmasına, yazılım tedarik zincirinin güvenliğinin artırılmasına, tarayıcı gürültüsünün azaltılmasına ve geliştiricilerin kritik olmayan sorunları düzeltme yükünü hafifletmeye yardımcı olabilir.
CI/CD hattını önemli ölçüde yavaşlatmadan güvenlik araçlarını entegre etmenin pratik yolları nelerdir?
CI sistemleri, kod gibi altyapı (IaC), yazılım kompozisyon analizi ve SAST gibi statik yapılar için ideal bir iç gözlem noktasıdır. Bu araçlar, çevreye uygun şekilde ayarlanana kadar proje bazında engellemesiz modda etkinleştirilebilir.
Yapay zeka destekli araçlar, kuruluşların kod analizi gibi rutin görevleri hızlandırmasına ve geliştirme iş akışından ayrılmadan eyleme dönüştürülebilir iyileştirmeler sağlamasına yardımcı olabilir. Yüksek Lisans’lara ve geliştiricilere bağlam sağlayarak ve güvenlik ekipleriyle iletişime geçmeden önce veya bunun yerine güvenlik anti-kalıplarına yönelik çözümler belirleyerek.
Kuruluşlar, güvenliğin tüm ekipler arasında ortak bir sorumluluk olarak görüldüğü bir kültürü nasıl geliştirebilir?
Güvenliği zaten mühendislik ekiplerindeki bir uygulama değişikliği olarak görüyoruz ve ikisi arasındaki sınırların bulanıklaşmaya devam etmesini bekleyebiliriz.
Birçok kuruluşta güvenlik testleri yazılım geliştirme yaşam döngüsünün çok sonlarında gerçekleşir. Bu, ekipler yazılımı göndermeye hazır olduğunda ancak bir güvenlik açığının çok geç tespit edilmesi nedeniyle geciktiğinde hayal kırıklığına neden olur.
Ekipler, “asfalt yollar” yaklaşımı olarak bilinen, tekrarlanabilir kullanım senaryolarına dayalı, test edilmiş ve garanti edilmiş tasarım modellerini benimseyerek bu durumun önüne geçebilir.
Asfalt yolların benimsenmesi esnekliği bir miktar ortadan kaldırır ancak sonuçta mühendislik ekiplerinin operasyonel yükünü ve yeniden çalışmayı azaltır. Aynı zamanda güvenliği artırır ve güvenlik ile geliştirme arasında daha işbirlikçi bir çabaya olanak tanır.
Ancak yapay zekanın benimsenmesi ve buna bağlı olarak yazılım geliştirmenin hızlanmasıyla birlikte kuruluşların, en önemli güvenlik avantajını optimize edecek sistemler ve çerçeveler oluşturması gerekiyor. İşbirliği kültürünü teşvik etmek önemlidir, ancak güvenlik ve mühendislik ekiplerinin, mevcut kod tabanlarını optimize etmek ve kuruluş genelindeki teknik ekiplerin sorunsuz bir şekilde benimseyebileceği ölçeklenebilir mühendislik merkezli çözümler oluşturmak gibi yazılım geliştirmenin temel yönlerini yeniden düşünmek için birlikte çalışması gerekir.
OWASP Top 10 veya NIST 800-53 gibi çerçeveler DevSecOps için güvenlik politikaları oluşturmada nasıl bir rol oynuyor?
NIST 800-53 gibi çerçeveler, kontrol çerçeveleri olarak kullanılarak kuruluşların CI/CD ortamında kullanabilecekleri araçları anlamalarına yardımcı olur. Ancak çerçeveler perspektif değildir. Kuruluşların teknoloji yığınlarını tehdit modellerine ve iş gereksinimlerine göre belirlemeleri gerekir. OWASP İlk 10, kuruluşları ortak tehdit sınıfları hakkında bilgilendirmek için tasarlanmış listelerdir ve politikada kodlanmamalıdır.
DevSecOps girişimlerinin başarısını izlemek için en yararlı ölçümler nelerdir ve kuruluşlar, güvenlik açıklarını tehdide dönüşmeden önce ele almak için proaktif izlemeyi nasıl uygulayabilir?
DevSecOps’un başarısını ölçmek için geleneksel güvenlik ölçümlerinin ötesine geçmeli ve geliştirme, güvenlik ve operasyonların entegre doğasını yansıtanlara odaklanmalıyız. Güvenlik liderliği perspektifinden bakıldığında aşağıdaki dört temel alana öncelik veriyorum:
Varlık ve Yazılım Envanterleri (SBOM’lar dahil): Kapsamlı envanterler, saldırı yüzeyine yönelik temel görünürlük sağlayarak veritabanı korelasyonu yoluyla etkili güvenlik açığı yönetimine olanak tanır. SBOM’ların dahil edilmesi, daha güçlü tedarik zinciri güvenliği ve hassas güvenlik açığı takibi için yazılım bileşenleri ve bağımlılıkları hakkında ayrıntılı ayrıntılar ekler, proaktif izlemeyi, otomatik taramayı ve öncelikli iyileştirmeyi güçlendirir.
Projelerin Güvenlik Kapsamı: Yazılım geliştirme yaşam döngüsünde güvenlik entegrasyonunu ölçmek çok önemlidir. Kod kapsamının SAST, DAST, SCA ve sızma testi aracılığıyla ölçülmesi, güvenlik açığının erken tespitine ve giderilmesine olanak tanır. Güvenlik açığı sayılarını/şiddetini analiz etmek, risk önceliklendirmesini kolaylaştırırken kapsamın izlenmesi, testin etkinliğini ortaya çıkarır ve uyumluluğa yardımcı olur.
Kurtarma Süresi Hedefi (RTO) ve Kurtarma Noktası Hedefi (RPO): Bu temel ölçümler dayanıklılığı ölçer ve kesinti sonrasında kesinti süresini ve veri kaybını en aza indirir. RTO (kabul edilebilir kesinti süresi) ve RPO (kabul edilebilir veri kaybı), potansiyel iş etkisini yansıtır. Kurtarmayı RTO/RPO’ya karşı düzenli olarak test etmek, kurtarma stratejilerini ve yedekleme prosedürlerini doğrular ve genellikle kurtarma ve gelişmiş dayanıklılık için otomasyonu ve IaC’nin benimsenmesini sağlar.
Soğuk Başlatma Kurtarma Süresi: Bu ölçüm, en kötü senaryolardan kurtulma yeteneğini ölçer. Tam sistem arızalarının simüle edilmesi, gizli bağımlılıkları ortaya çıkarmak için IaC ve otomatik dağıtım hatlarının etkinliğini doğrulayabilir ve geleneksel yük devretme testlerinden daha kapsamlı bir dayanıklılık değerlendirmesi sağlayabilir. Düzenleyici kurtarma hedeflerinin karşılanması genellikle başarılı soğuk başlangıç testlerine, performans darboğazlarının belirlenmesine, kurtarma iyileştirmelerinin desteklenmesine ve dayanıklılık ve olgun DevSecOps taahhüdünün gösterilmesine bağlıdır.