Kalıtım Zihniyetini Anlamak ve Üstesinden Gelmek
Gartner 2025 yılına kadar kurumsal uygulamaların %70’inin Salesforce ve ServiceNow gibi düşük kodlu ve kodsuz platformlardan oluşturulacağını tahmin ediyor. Miras tabanlı bir zihniyetle yanıt vermek, kurumsal uygulamaların üçte ikisinden fazlasını başarısızlığa hazırlamanın kesin bir yoludur.
“Miras zihniyeti”, altyapıyı rahatsız eden sorunlar için uygun bir tanımlayıcıdır. Tamamen yapılan işe bağımlı, zengin, şımarık çocukları ve kendilerinden önce gelenleri akla getiriyor. Bu, bir miras inşa etmek için iyi bir yol olmadığı gibi, bir sistem inşa etmek için de aynı derecede kötü bir yol.
Eski bir zihniyetiniz olduğunda, altyapının hazır olduğunu varsayıyorsunuz. Platform güvenlidir ve güvenlik yerleşiktir. Teknoloji yöneticiden önce orada olduğu için güven varsayılır.
Bu miras zihniyeti, düşük kodlu ve kodsuz platformları rahatsız ediyor. Kullanıcılar, onları tüm kurumsal altyapı boyunca taşımak için bir platformun güvenliğine güvenir. Bunun yerine, o platformun güvenliği yalnızca o platform için geçerli olmalıdır.
Salesforce geliştiricilerinin yeni müşteri adayları için otomatik bir atama programı oluşturduğunu varsayalım. Bunu Salesforce içinde dahili atamalar için kullanıyorlar ve sorun değil. Platformun güvenliğine güvenebilirler. Otomasyonu geliştirmek için genişletmeye karar verirler. Bu programı ServiceNow, SAP veya Oracle gibi harici bir CRM’ye bağlarlar. Miras zihniyeti devreye giriyor: Salesforce güvende. ServiceNow, SAP veya üçüncü taraf güvende.
Yani Salesforce + üçüncü taraf = güvenli.
Ancak, bu artı işaretinde çok fazla bilinmeyen var. Salesforce’ta oluşturulan dahili programı üçüncü taraf platformunda oluşturulan harici programa nasıl güvenli ve uyumlu bir şekilde bağlarsınız? Bu tek karakterde hataya çok yer var.
Ve bu sadece bir bağlantı. Salesforce’ta oluşturulan birçok program, yüzlerce başka programa dokunuyor. Bu, geliştirme deneyimi çok az olan veya hiç olmayan kişiler tarafından yukarıda açıklanan artı işareti gibi ele alınan yüzlerce bilinmeyendir.
Tek çözüm, DevSecOps ilkelerine geri dönüşle bu gelişmeyi dünyaya geri getirmektir.
DevSecOps Çerçevesinin Kurulması
DevSecOps kavram yaratıldığından beri çerçeveler yazıldı, yeniden yazıldı ve yeniden yazıldı. Tekerleği kurarken yeniden icat etmeye gerek yok, özellikle SAFECode ve Bulut Güvenliği İttifakı altı sütun inşa etti:
- Kolektif sorumluluk: Güvenlik, kuruluştaki herkesin sorumluluğundadır, ancak insanlar bilmedikleri standartları karşılayamazlar. Siber güvenlik politikasını yönlendirmek ve kurum genelinde yayılmasını sağlamak için potansiyel müşteriler atanmalıdır.
- İşbirliği ve entegrasyon: Bilgi paylaşılmalı ve aktarılmalıdır. İşletmelerin eski zihniyete düşmesinin yarısı, eski sistemi bilen herkesin gitmiş olmasıdır. Sürekli bilgi paylaşımı bu sorunun ortadan kaldırılmasına yardımcı olur.
- Pragmatik uygulama: Pragmatik uygulama, geliştirici deneyimiyle bağlantılıdır. Zor, sıradan ve hantal süreçler uzun süre takip edilmez. Güvenlik, geliştirme uygulamalarına dahil edilmelidir – yani her kod satırı bir test satırı gerektirir. Yüksek performanslı bir kuruluş, her bir test kodu satırını otomatikleştirmek için bir araç kullanarak bunu daha da ileri götürebilir.
- Uyumluluk ve geliştirme: Uyumluluk gereksinimleri, geliştiricilerin onlardan sapmalarına izin vermeyecek şekilde geliştirme sürecini yönlendirmelidir. Örneğin bir finans kurumunun geliştiricisi, Gramm-Leach-Bliley Yasası ile uyumlu olacak şekilde tasarlanmış bir platform üzerinde çalışır. Geliştiricinin, platformda yerleşik oldukları için uyumlu olmak için hareketin giriş ve çıkışlarını bilmesi gerekmez.
- Otomasyon: Öngörülebilir, tekrarlanabilir ve yüksek hacimli görevler, geliştiricilerin yükünü kaldırmak ve insan hatası riskini azaltmak için mümkün olduğunda otomatikleştirilmelidir.
- Monitör: Modern bulut altyapıları değişiyor ve büyüyor. Bunu takip etmek çok önemlidir – ideal olarak, çeşitli ara bağlantıların bir bakışta görülmesine izin veren bir tür orkestrasyon aracılığıyla.
İçinde düşük veya kodsuz ortamda, bu sütunlar beklendiği kadar basit değildir. Bu araçları kullanan kişiler genellikle DevSecOps temellerine çok az aşina olan iş uzmanlarıdır.
İnsanları, Süreçleri ve Teknolojiyi Bir Araya Getirmek
Düşük kodlu ve kodsuz platformların kullanılması, aslında bu beceri açığının kapatılmasına yardımcı olabilir. Çalışanlar yeni beceriler öğrenmek ister. Kuruluşlar, insanlara, süreçlere ve teknolojiye odaklanan bir DevSecOps çerçevesi oluşturarak bunu destekleyebilir.
- Süreçler: Sıfır güven ortamında, düşük kodlu ve kodsuz geliştiricilerin, sistem bütünlüğünü tehlikeye atan bağlantılar kurma konusunda endişelenmeleri gerekmez, çünkü bunu yapamazlar. Yalıtılmış sistemlerinin dışında hiçbir temel yetkileri yoktur.
- İnsanlar: Sorumluluk kültürü, suçlama kültüründen farklıdır. Hesap verebilirlik, kişilerin bir sorun veya hatayla öne çıkarken kendilerini rahat hissetmeleri anlamına gelir, çünkü odak kişi değil konu üzerindedir.
- teknoloji: Teknoloji, geliştiricilerin elinde olmadığı için DevSecOps ilkelerinin uygun şekilde uygulanmasının önündeki en büyük engeldir. Örgütün kendilerine verdiklerini kullanmaları gerekir. Bu teknoloji işe yaramazsa, geliştiriciler ne güvenli ne de güvenli olan geçici çözümler bulacaktır. Esasen, teknoloji büyük bir gölge BT üreticisi haline gelir.
Gelişim için heyecan verici bir zamanda yaşıyoruz. Gittikçe daha fazla insan yazılım geliştirme, stratejileri test etme ve iş değerini iyileştirme fırsatına sahip. Ama bununla birlikte risk de geliyor. Bu riski teknolojiye yüklemenin yollarını arayan şirketler, keşfetmeye yer bırakırken gelişimlerini de gerçekçi tutacaktır.