Kodun Olmadığı Yerde SDLC Yoktur



Güvenliği geliştirme süreçlerine dahil etmek için başvurulacak yöntem olarak yazılım geliştirme yaşam döngüsüne (SDLC) büyük ölçüde güvenmeye başladık. Aslında, kapsamlı bir CI/CD varsayımı o kadar temel hale geldi ki, bir endüstri olarak geçen yılın çoğunu bunun türevlerinden birini ele almaya odakladık: yazılım tedarik zincirinin merkezi parçası olarak CI/CD ardışık düzeninin güvenliği. Bu elbette iyi bir haber. Uygun bir SDLC ve operasyonel tezahürü olan CI/CD, güvenlik kontrollerini en yararlı oldukları yerlere – geliştirici yazılımlarını oluştururken ve test ederken – yerleştirmemize izin verdi.

Kuruluşta düşük kodlu/kodsuz ve vatandaş geliştirmede devam eden artışla birlikte, birçok AppSec ekibi bu yeni iş uygulamaları için güvenli geliştirme yönergeleri oluşturmakla meşgul oldu. Bir güvenlik riski çerçevesi sağlamak için sektörler arası işbirlikleri ortaya çıkmıştır. Ancak asıl zorluk, geliştiriciler haline gelen bu yeni iş kullanıcıları dalgasını güvenlik şemsiyesi altına getirmektir.

İş kullanıcıları, işletmenin neye ihtiyacı olduğunu en iyi şekilde bilirler ve bu nedenle, kendi uygulamalarını oluşturmalarına izin veren az kodlu/kodsuz araçlarla yetkilendirildiklerinde bu ihtiyaçları karşılamak için en iyi konumdadırlar. Öte yandan, iş kullanıcılarıyla güvenlik risklerini veya geliştirme uygulamalarını tartışmaya çalışmak zorlu olabilir.

SDLC’ye gömülü güvenlik, geliştiricilerin onu kullanmasının daha rahat olduğu ve bir güvenlik açığını düzeltmeyi daha az maliyetli hale getirdiği için çalışır. Aynı şeyi iş kullanıcıları için de yapabilmek için, uygulama oluşturma süreçlerinin nasıl çalıştığını anlamamız gerekir.

SDLC’ye RIP

SDLC’nin ortak bir versiyonu, yazılımın işletmenin bir ihtiyacını dile getirmekten nasıl geçtiğini gösterir; mühendislik ve Soru-Cevap ekipleri tarafından planlama, geliştirme ve test yoluyla; ve operasyon ekipleri tarafından dağıtım, izleme ve yönetim. Bu elbette kuruluşlar arasında büyük farklılıklar gösterir. Tartışmamız için önemli olan nokta, sorumluluğun geliştirme yaşam döngüsü boyunca farklı ekipler ve belki de farklı departmanlar arasında kaydırılmış olmasıdır. İster SAST/DAST/IAST araçları gibi otomatik, ister tehdit modelleme veya güvenlik incelemesi gibi manuel olsun, her geçiş bir kalite veya güvenlik güvence kapısı olarak da kullanılabilir.

Bunun aksine, düşük kodlu/kodsuz geliştirme sürecini düşünün. Bir iş kullanıcısı ihtiyaçlarını dile getirir, sezgisel bir sürükle ve bırak arabirimi ile uygulamalarını veya otomasyonunu oluşturmaya devam eder, tıklamaları kaydeder ve … işte bu kadar! Bazen yararlı bir otomatik kaydetme ile kaydetme adımı bile atlanır. Tüm düşük kodlu/kodsuz uygulamalar, onları tasarlayan kişi tarafından bu şekilde oluşturulmasa da çoğu öyledir. Geliştirme sürecinin artık ne kadar hızlı olabileceğine dikkat edin – sorumluluk alışverişi veya başka birini hedeflerinize uymaya ikna etmek yok ve herkes kendi iş ihtiyaçlarını tespit edildiğinde kendi başlarına çözebilir. Bu, iş liderliğindeki kalkınmanın ve olgun vatandaş geliştirme girişimlerinin gücüdür.

Ne yazık ki, geliştirme yaşam döngüsüne dahil ettiğimiz güvenlik ve kalite kapılarını atlama pahasına geliyor. Bu kapılar, özellikle iş üretkenliği kadar önemli olan güvenlik, uyumluluk ve gizlilik gibi değerleri uygulamaya koyması gereken bir kuruluşta kritik öneme sahipti.

Geliştiricilerle Bulundukları Yerde Buluşma

İş kullanıcıları, şimdiye kadar gördüğümüzden daha fazla uygulama geliştiriyor ve geliştirmeye devam edecek. Onları güvenlik şemsiyesi altına almak için bulundukları yerde buluşmalı ve onların dilini konuşmalıyız. Bir CI/CD ardışık düzeninin varlığına güvenmek ve bunları üretime karşı test ortamları gibi kavramlarla tanıştırmak yerine, gerçeği kabul etmeli ve güvenli uygulamalar oluşturmayı kolaylaştırmaya ve riskli uygulamalar oluşturmayı zorlaştırmaya odaklanmalıyız.

Bunu yapmak için, uygulamaları oluşturmak için kullandıkları düşük kodlu/kodsuz platformları ve bu uygulamaların başkaları tarafından nasıl oluşturulup benimsendiğini anlamalıyız. Bu yeni geliştiricilere rehberlik etme sorumluluğumuzu benimsemeli, en iyi güvenlik uygulamalarını kuruluşumuzun risk iştahına göre oluşturdukları uygulamalara uygulamalı ve kritik sorunları hızla ele almak için geriye dönük bir yaklaşım izlemeliyiz.



Source link