Bazen insanların dili anlama ve işleme biçiminde ortaya çıkabilecek küçük bir tuzak vardır. Spesifik olarak, bazen bir kelimenin veya deyimin anlamını kesin olarak kabul ederiz. Bununla demek istediğim, belirli bir şey anlamında bir terim kullanıyoruz, sadece bizi duyanlar terimi tamamen farklı bir şekilde anlasınlar.
Bu, günlük iletişimde gerçekleştiğinde verimsizdir, ancak siber güvenlik, güvence ve yönetişim gibi riskleri etkileyen disiplinler bağlamında tehlikeli olabilir. Bu durumlarda risk oluşturabilir.
Bunu gündeme getirmemin nedeni, işlerinin bir parçası olarak dahili veya harici kullanım için yazılım yazan ve sürdüren kuruluşlarda “güvenli kodlama” sağlamanın yollarını sık sık duyduğumuz için. Bu önemli çünkü açıkçası günümüzde çoğu işletme bu kategoriye giriyor. Yazılım riskinin zorluklarını bu şekilde tartışmak doğal olsa da, “güvenli kodlama” teriminin kendisinin amaçlanan son durumu fiilen gerçekleştiren bir bağlamı önceden varsaydığına inanıyorum. Daha güçlü başarmak – en azından tam anlamıyla alındığında.
Ve bunu sadece anlamsal anlamda söylemiyorum. Örneğin, bu ifadenin neden doğru olduğunu anlamanın gerçek, somut, pratik değeri olduğunu iddia ediyorum. Pek çok kuruluşun uygulama ve yazılım riskleriyle mücadele etmesinin temel nedenine değiniyor ve kuruluşların gelişmek için atabilecekleri pratik adımları vurguluyor. Bunu akılda tutarak, gerçek yazılım risk azaltma hedeflerinin ne olduğunu ve yazılımları güvenli ve esnek bir şekilde geliştirmek ve yayınlamak için gereksinimlerimizi yerine getirirken bunları en iyi nasıl etkileyeceğimizi açıklayalım.
Yazılım geliştirme güvenliği ve risk azaltma
Paketten çıkarılacak ilk şey, “güvenli kodlama” ile kastettiğimiz şeyin amaçlanan son durumudur. Kanımca, genellikle bu terimle kastedilen birkaç farklı, birbiriyle ilişkili hedef vardır. İlk olarak, bu bağlamda “güvenlik” ile insanlar genellikle iki şeyi kasteder:
- Risk azaltma ilkelerini (ör. gizlilik, bütünlük ve kullanılabilirlik) destekleyen uygulama mimarisi ve tasarım modellerini kullanma
- Saldırıya dayanıklı yazılımlar oluşturma (ör. güvenlik açıkları ve hatalı yapılandırmalar gibi yollar yoluyla)
Bunların her ikisi de, elbette, inanılmaz derecede önemlidir. Uygulama güvenliği uzmanlarıyla konuşmaya biraz zaman ayırdığınızda, haklı olarak, Barry Boehm’in güvenlik açıklarını geliştirme sürecinin başlarında bulma ve düzeltme ekonomisi hakkındaki ünlü çalışmasını size vurgulayacaklardır. Yazılımda güvenlik tasarımı konularının ne olduğunu ve nerede olduğunu anlamak için uygulanabilecek uygulama tehdit modellemesi gibi araçların değerini size haklı olarak açıklayacaklardır. Tuzak şu ki, bu şeyler ne kadar önemli olsalar da konu yazılımdaki riski azaltmak olduğunda ilgilenebileceğimiz şeylerin tamamı değil. Örneğin, en azından eşit derecede ilgilenebileceğimiz diğer şeyler şunları içerebilir:
- Olgunluk – süreçlerin olgun olmasını sağlamak, böylece çalışanların yıpranmasına karşı dirençli ve sonuçların tutarlı olması
- şeffaflık – ürünlerimizin güvendiği bileşenlerin ve kitaplıkların tedarik zincirinde şeffaflığı sağlamak (ve bu şeffaflığı müşterilere sağlayabilmek)
- uyma – yazılımımızı geliştirirken kullandığımız çeşitli (ticari ve açık kaynak) lisanslarla uyumlu olmamızı sağlamak
- Tasarım sadeliği – tasarım kolayca anlaşılmaya ve değerlendirilmeye uygun mu?
Ve benzeri. Aslında, bunlar pratik bir mesele olarak yazılım riskini etkileyebilecek ve etkileyebilecek hususlar buzdağının yalnızca görünen kısmıdır. Amaca uygunluk, tasarım titizliği, desteklenebilirlik, test kapsamı, kod kalitesi, pazara sürüm süresi ve tasarlama, geliştirme, test etme, devreye alma, bakım yapma şeklimizle ilişkili riskleri etkileyen diğer pek çok şeyi de kolayca dahil edebilirsiniz. destekleyin ve nihayetinde yazılımımızı devre dışı bırakın.
Bu bakış açısından, sormamız gereken soru kesinlikle “güvenlik” ile ilgili değil, bunun yerine risk azaltma (ki bu güvenlik, büyük ve önemli olsa da bunun bir alt kümesidir.) paydaşlar, sorumluluğu daraltır ve tartışmayı değiştirir. Buna karşılık, riske odaklanmak, herkesin – yazılım geliştirme evreninden uzakta olanların bile – oynayacağı hayati bir role sahip olduğu anlamına gelir.
yazılım yaşam döngüsü
Dikkatinizi çekeceğim ikinci şey, cümlenin “kodlama” unsurudur. Evet, kodlama önemlidir. Ancak tıpkı “güvenlik” gibi, yazılım geliştirmede yer alan yaşam döngüsünün – büyük olmasına rağmen – yalnızca bir parçasıdır. Yazılımın normalde nasıl tasarlandığını ve kaç farklı adımın dahil olduğunu düşünün. Bireysel yazılım geliştirme yaşam döngüleri (SDLC’ler) bunları farklı şekilde tanımlasa da, yüksek düzeyde – yine de soyut olarak – aşağıdakine benzer adımlara sahip olabilirsiniz:
- ihtiyacın belirlenmesi
- Fikir/Başlangıç
- Gereksinim toplama
- Tasarım
- Gelişim
- Test yapmak
- dağıtım
- Destek
- Bakım
- Hizmetten çıkarma
Bu birçok adımdır. Ve her birinin kendisinin de sayısız bireysel alt adıma bölünebileceğini fark edeceksiniz. Örneğin, “test etme” gibi bir adım şunları kapsayabilir (kullanımdaki SDLC’ye, bağlama vb. bağlı olarak): birim testi, işlevsel test, regresyon testi, performans testi, güvenlik testi ve herhangi bir sayıda başka bağımsız öğe. Bunlardan kaç tanesi sadece “kodlama” içeriyor, kaçı ise sonunda sağlam bir ürün sağlamak için kritik öneme sahip ama yine de önemli?
Başka bir deyişle, bu sürecin herhangi bir aşamasında yer alan paydaşların izledikleri süreçlere, eğitimlerine, farkındalıklarına ve diğer birçok faktöre bağlı olarak riskleri ortaya çıkarmaları veya azaltmaları için birçok olası yol vardır. Bu, yazılım riskini azaltmak, yönetmek ve hafifletmek için tasarlanmış risk farkındalığına sahip bir programın tüm bunları hesaba katması ve mümkün olan yerlerde risk azaltma sonuçlarını destekleyen eylemleri desteklemesi gerektiği anlamına gelir. Kodlama, yazılım geliştirme ve piyasaya sürme sürecinde (en azından dahili olarak) tartışmasız en “görünür” adım olsa da, odaklanmamız gereken tek yer de burası değil.
Beklediğiniz gibi, uygulamanız – veya tercih ettiğiniz deyime bağlı olarak yazılımınız – risk yönetimi çabalarınız tüm yaşam döngüsünü içermelidir. Bu, ek olarak iki anlama gelir: 1) tüm yaşam döngüsünü bütünsel olarak anladığınız ve hesaba kattığınız ve 2) planlamanızı, yine de bir çıkarı olan geliştirme dışındaki alanları içerecek şekilde genişlettiğiniz. Test personelini, iş analistlerini, proje ve ürün yöneticilerini, destek ekiplerini, satış, pazarlama, İK ve hukuk departmanlarını dahil edin ve onlara vekâlet edin; onları inşa ettiğiniz şeyin güvenliğini önemseyen bir şemsiye altına getirin.
Başta da söylediğim gibi, bu sadece semantikle ilgili değil (her ne kadar konuyu anlatmak için bu şekilde çerçevelendirdiğimi kabul etsem de). Bunun yerine, riskin yazılım geliştirme ve bu risk, güvenlik açıkları gibi şeylere bakarken geleneksel olarak odaklanma eğiliminde olabileceğimizin çok ötesine uzanır.
Neden sadece semantik değil? Çünkü inanılmaz derecede önemli olan daha büyük bir şeye hitap ediyor. İçinde Amaçlar ve AraçlarAldous Huxley bir keresinde ünlü bir şekilde şöyle demişti: “Kullanılan araçların üretilen amaçların doğasını belirlemesi gibi basit ve açık bir nedenle amaç, araçları haklı çıkaramaz.Onun anlatmak istediği, bir şeyi nasıl yaptığımızın, nihai durumun ne olacağını büyük ölçüde belirlediğiydi. Bunu yazılım geliştirmeye genişleterek, düzensiz, olgunlaşmamış ve “slapdash” geliştirme süreçlerinin, bunun yerine daha sağlam ve disiplinli bir süreç izlendiğinde ortaya çıkacak duruma göre, kaçınılmaz olarak daha kalitesiz tasarlanmış ve daha kötü uygulanan yazılımlar üreteceğini iddia ediyorum. . Bu da, güvenliğin ötesindeki hedefleri hedeflediğimiz ve kod yazmanın ötesindeki süreçleri benimsediğimiz anlamına gelir.