Geliştiriciler gerçekten kod yazmak için ne kadar zaman harcıyor?
yakın zamana göre çalışmalar, geliştiriciler, kod yazmaya veya geliştirmeye harcadıklarından daha fazla zaman harcarlar. Güvenlik açıklarının, yazılım geliştirme sürecinde ortaya çıkma, yalnızca bir uygulama dağıtıldıktan sonra ortaya çıkma gibi kötü bir alışkanlığı vardır. Hayal kırıklığı yaratan kısım, bu güvenlik kusurlarının ve hatalarının birçoğunun daha erken bir aşamada çözülmüş olması ve bunları ortaya çıkarmak için uygun yöntemler ve araçların bulunmasıdır.
Bir geliştirici, işleyen bir kod yazmayı öğrenmek için ne kadar zaman harcar? Ve kod güvenliği hakkında bilgi edinmek için ne kadar harcanıyor? Ya da nasıl kodlanmayacağını öğrenmek?”
Sorunu orada bulundurmaktan ve ardından onu hedefleyen devam eden bir saldırıyı tespit etmeye ve durdurmaya çalışmaktansa, sorunu sistemden ortadan kaldırmak daha iyi olmaz mıydı?
Bu kısa programla güvenli kodlama becerilerinizi test edebilirsiniz. öz değerlendirme.
Hataların gerçek maliyeti
Herkes hata yapar, geliştiriciler bile. Yazılım hataları kaçınılmazdır ve bu alanda “iş yapmanın maliyeti” olarak kabul edilir.
Bununla birlikte, koddaki herhangi bir sabitlenmemiş hata, saldırganların can damarıdır. Bir sistemde doğru şekilde yararlanılabilecek en az bir hata (yani bir yazılım güvenlik açığı) bulabilirlerse, bu güvenlik açığından yararlanarak potansiyel olarak on milyonlarca dolar ölçeğinde büyük hasara neden olabilirler. Her yıl manşetlere çıkan iyi duyurulan davaları görün.
Ve daha az ciddi güvenlik açıkları söz konusu olduğunda bile, bunları düzeltmek çok maliyetli olabilir – özellikle bir tasarım hatası veya eksik bir güvenlik gereksinimi nedeniyle SDLC’de çok daha önce bir zayıflık ortaya çıkarsa.
Yazılım güvenliğine yönelik mevcut yaklaşım neden yetersiz kalıyor?
1 – Teknolojiye çok fazla güvenmek (ve insanlara yeterince güvenmemek)
Otomasyon ve siber güvenlik araçlarının yazılım açıklarını tarayarak, tespit ederek ve azaltarak geliştiriciler ve uygulama güvenlik personeli için iş yükünü azaltması beklenir, ancak:
- Bu araçlar siber güvenlik çabalarına katkıda bulunurken, çalışmalar gösteriyor ki bu araçların yalnızca %45’ini keşfedebiliyorlar. genel güvenlik açıkları
- Ayrıca gereksiz endişelere, gecikmelere ve yeniden çalışmaya yol açan “yanlış pozitifler” üretebilirler.
- …ya da daha da kötüsü, son derece tehlikeli bir yanlış güvenlik duygusu yaratan “yanlış negatifler”
2 — DevSec bağlantısı
DevSec bağlantısının kesilmesi, yeni özellikler ve hata düzeltmeleri söz konusu olduğunda farklı (ve çoğu zaman çelişen) öncelikler nedeniyle geliştirme ekipleri ve güvenlik ekipleri arasındaki iyi bilinen gerilimi ifade eder.
Bu sürtünme sonucunda, geliştiricilerin %48’i savunmasız kodu düzenli olarak üretime itmekle sonuçlanır. Geliştirme döngüsünde daha sonra keşfedilen güvenlik açıkları genellikle hafifletilmez veya ileride ekstra maliyetler, gecikmeler ve riskler oluşturur. Bunlar kısa vadeli düşünmenin sonuçlarıdır: nihayetinde, yazılım geliştirme yaşam döngüsünün sonraki aşamalarında kod kusurlarını bulmaya zaman ve kaynak harcamak yerine sorunu kaynağında düzeltmek daha iyi olacaktır.
3 — Tedarik zincirinizi izleyin, ancak kendi yazılımınızı değil
Diğer bir yaygın hata, yalnızca yazılım tedarik zinciri güvenliğine odaklanmak ve yalnızca ünlü Ortak Güvenlik Açıkları ve Etkilenmeler veritabanında veya Ulusal Güvenlik Açığı Veritabanında listelenen mevcut yazılım ürünleri ve paketlerindeki bilinen güvenlik açıklarını ele almaktır.
Üçüncü taraf bileşenlerindeki, bağımlılıklarınızdaki veya işletim ortamındaki güvenlik açıklarıyla ilgilenmek önemlidir, ancak bu, kendi kodunuzdaki güvenlik açıkları konusunda size yardımcı olmaz.
Benzer şekilde, izinsiz giriş tespit sistemleri (IDS) veya güvenlik duvarları aracılığıyla olası saldırıların ardından olay yanıtının izlenmesi iyi bir fikirdir ve OWASP Top 10 tarafından bir zorunluluk olarak kabul edilir, ancak bu faaliyetler siber saldırıların nedeninden ziyade sonuçlarıyla ilgilenir.
Çözüm: Güvenli kodlamayı bir takım sporu yapın
Siber güvenliğiniz yalnızca en zayıf halkanız kadar güçlüdür. Yazılım geliştirme bir montaj hattı işi değildir ve – tüm tahminlere rağmen – yakın zamanda tam otomatik hale gelmeyecektir. Programcılar, kod yazarken her gün yüzlerce karar vermesi gereken yaratıcı problem çözücülerdir, çünkü yazılım geliştirme bir tür ustalıktır.
Konuya gelince, bir kod parçasının güvenli olup olmadığı bireysel geliştiricilerin becerilerine bağlıdır.
Süreçler, standartlar ve araçlar en iyi uygulamaları teşvik etmeye ve güçlendirmeye yardımcı olabilir, ancak bir geliştirici belirli bir tür kötü uygulama hakkında bilgi sahibi değilse, muhtemelen aynı hatayı yapmaya devam edecektir (ve aynı tür güvenlik açığını kodu) tekrar tekrar.
Güvenli kodlamayı güçlendirmek için 6 ipucu
Yeni keşfedilen güvenlik açıklarının sayısı artıyor ve kötü niyetli siber aktörlerin oluşturduğu tehditler giderek daha karmaşık hale geliyor. Çoğu kuruluş, bir olaydan sonra güvenli bir geliştirme yaşam döngüsü uygulamaya başlar, ancak bize ne zaman başlamanız gerektiğini sorarsanız, yanıt elbette her zaman ne kadar erken, o kadar iyi olacaktır.
Bunun nedeni, kritik güvenlik açıkları söz konusu olduğunda, saatler bile kalıcı hasar olmaması ile finansal bir felaket arasındaki fark anlamına gelebilir.
İşte tam olarak bunu yapmak için en iyi ipuçlarımız:
1 — Sola kaydır – güvenlik perspektifini geliştirmenin erken aşamalarına genişletin
DevSecOps tarzı güvenlik aracı otomasyonuna güvenmek tek başına yeterli değildir, gerçek bir kültür değişikliği uygulamanız gerekir. SDLC’de SAST, DAST veya sızma testi sağdadır; daha kapsamlı bir kapsam için yazılım geliştirme yaşam döngüsünün başlangıcına doğru sola kaydırın.
2 — Güvenli bir geliştirme yaşam döngüsü yaklaşımı benimseyin
Örneğin MS SDL veya OWASP SAMM, süreçleriniz için bir çerçeve sağlayacak ve siber güvenlik girişiminiz için iyi bir başlangıç noktası görevi görecektir.
3 — Tüm BT ekosisteminizi kapsayın
Üçüncü taraf güvenlik açıkları, işletmenizin siber güvenliği için büyük bir risk oluşturur, ancak kendi geliştiricileriniz de uygulamada sorunlar yaratıyor olabilir. Şirket içinde, bulutta ve üçüncü taraf ortamlardaki güvenlik açıklarını tespit edip çözebilmeniz gerekir.
4 — Tepkiden önlemeye geçiş
Kodlama yönergelerinize savunma amaçlı programlama kavramları ekleyin. Sağlamlık, ihtiyacınız olan şeydir. Sonuçta, iyi güvenlik tamamen paranoya ile ilgilidir.
5 — Zihniyet teknolojiden daha önemlidir
Güvenlik duvarları ve IDS’ler, yazılımınızı kendi başlarına bilgisayar korsanlarından korumaz; sadece zaten var olan güvenlik açıklarının sonuçlarıyla ilgilenirler. Sorunu kökünden ele alın: geliştiricilerin zihniyeti ve kişisel sorumluluğu.
6 — Güvenli kod eğitimine yatırım yapın
Çok çeşitli programlama dillerini kapsayan ve güvenli kodlama standartlarını, güvenlik açığı veritabanlarını ve endüstride tanınan kritik yazılım zayıflık türlerini kapsamlı bir şekilde kapsayan bir arama yapın. Geliştiricilerin yerel ortamlarında uygulamalı laboratuvar alıştırmaları, onları hızla hızlandırmak ve bu sinir bozucu bilme-yapma boşluğunu kapatmak için büyük bir artıdır.
Cydrill’in harmanlanmış öğrenme yolculuğu tüm dünyadaki Fortune 500 şirketlerinden geliştiriciler için proaktif ve etkili güvenli kodlama eğitimi sağlar. birleştirerek eğitmen liderliğindeki eğitim, e-öğrenme, Uygulamalı laboratuvarlar ve oyunlaştırma ile Cydrill, güvenli kodlamayı öğrenmek için yeni ve etkili bir yaklaşım sunar.