Bilişim ProfesyonelleriYazılım Geliştirme

Yazılım Geliştirme İşlem Yolu için Kontrol Planı

Uygulama kapsayıcıları ve bulut gibi teknolojiler, yazılım oluşturma ve yazma şeklini değiştirdikçe, aynı şekilde yazılım geliştirme metotları da son yıllarda önemli ölçüde değişime uğradı. Ne yazık ki, siber saldırganlar bu değişiklikleri çok yakından takip ediyor. Yazılım geliştirme veya oluşturma ortamlarında nispeten zayıf güvenlik kontrollerinden yararlanmak için saldırı stratejilerini yeniden şekillendirdiler.

Siber saldırganlar, güvenlik ekiplerinin altyapıyı korumaya daha fazla odaklandığını ve yazılım geliştirme ve tedarik zincirlerine daha az odaklandığını biliyor. SolarWinds gibi zarar veren saldırılar bu şekilde gerçekleşir ve siber saldırganların daha da başarılı sonuçlar elde etmek için tekrar saldırması muhtemeldir.

Yazılım geliştirme hattının güvenliğini sağlamak için yeni bir yaklaşıma ihtiyaç var. Dahası, bu yaklaşımın bilgi güvenliği ekipleri tarafından değil, yazılımı geliştiren mühendisler tarafından uygulanması gerekir. Mühendislik ekiplerinin tasarım veya uygulamadan sorumlu olması gerekirken, güvenlik ekiplerine kontrollerin çalıştığına ve politikaların uygulandığına dair görünürlük ve güvence sağlaması gerekiyor.

İşlem hattını güvence altına almak için yeni bir taslak, kimlik doğrulama ve yetkilendirmenin düzgün bir şekilde yönetilmesini, yazılım yapılarının bütünlüğünün uygun aşamalarda test edilmesini ve kontrollerin üçüncü taraflara yerleştirilmesini sağlayarak yazılım oluşturma, işlem hattını güvence altına alan esnek bir kontrol kümesine odaklanır. Ardından yazılıma dahil edilen açık kaynaklı çözümler bulunması gerekir. Sonuç: Yazılım yeniliği ve tedarik zinciri kurcalama riski daha düşük olan teslimat ve geliştirme sırasında saldırıların azalması.

Pragmatik Tasarım Felsefesi

Bu modern yazılım güvenliği planı aşağıdaki tasarım felsefesine dayanmaktadır:

  • En az ayrıcalık: Yalnızca bir işi gerçekleştirmek için gereken erişim ve izinleri verin, daha fazlasını değil.
  • Değişmezlik: Yapılar ve altyapı, bir ortama dağıtıldıktan sonra değiştirilmez. Bir değişiklik gerekiyorsa, geliştirme ortamında görüntü veya komut dosyasında yapılır ve daha sonra daha yüksek ortamlarda tanıtılır.
  • Her şey kod olarak: Altyapı, güvenlik politikaları ve ardışık düzenin diğer bölümleri de kod olarak uygulanır ve yazılım yapılarıyla aynı kontrollere tabidir.
  • İzlenebilirlik: Altyapı veya iş koduyla ilgili tüm değişiklikler sürüm kontrollüdür. 

Güvenli Yazılım Geliştirme ve Oluşturmak İçin Uygulanması Gereken Plan

Bu yazılım güvenliği planının temeli, geliştiricilerin, işlem hatlarının ve yürütmenin dünyanın herhangi bir yerinde gerçekleşebileceği modern geliştirme işlem hatları için oluşturulmuş 15 kontrol kümesi etrafında toplanıyor.

Kontrol 1: CI/CD araçlarına yönetici erişimini kısıtlayın. İşlem hattı tanımlarında yetkisiz değişiklikleri önleyen CI/CD sisteminde yalnızca yetkili kişilerin yönetimsel değişiklikler yapabileceğinden emin olun.

Kontrol 2: Yalnızca geliştirici GPG anahtarıyla imzalanmış taahhütleri kabul edin. İmzasız kod taahhütleri, kod tabanının bütünlüğünü izlemek ve risk oluşturmak için imkansız değilse de zordur. 

Kontrol 3: Otomasyon erişim anahtarlarının süresi otomatik olarak sona erer. Geliştiriciler, otomasyon tarafından kullanılan erişim anahtarlarının periyodik olarak süresinin dolmasını sağlayarak, anahtarların güvenliği ihlal edildiğinde daha kısa bir saldırı penceresi oluşturur.

Kontrol 4: Otomasyon erişimini salt okunur olarak azaltın. CI sistemleri, en az ayrıcalıklı erişim ilkesini izleyen kaynak kod havuzlarına salt okunur erişime sahip olmalıdır.

Kontrol 5: Yalnızca güvenilir kayıtlardan alınan bağımlılıklar kullanılabilir. Bağımlılık yöneticisini yalnızca yetkili bir kayıt listesine bağlantılara izin verecek şekilde yapılandırarak, genel kayıtlardaki kötü amaçlı paketlerin boru hattına girmesini engelleyerek saldırılar engellenebilir.

Kontrol 6: Herhangi bir kritik veya yüksek önemdeki güvenlik açığı yapıyı bozar. Tedarik zinciri saldırıları, yazılım boru hattına güvenlik açıkları içeren kodlar sokabilir. Statik uygulama güvenlik testi (SAST), zayıf şifreleme uygulamaları, sabit kodlanmış kimlik bilgileri ve enjeksiyon güvenlik açıkları dahil olmak üzere ciddi güvenlik sorunlarının belirlenmesine yardımcı olur. 

Kontrol 7: Artifaktlar geliştirme, evreleme ve üretim sırasında bir havuzda depolanır. Bu kontrol, geliştirme, hazırlama ve üretim havuzlarında karşılaştırılabilmeleri için eserlerin değişmezliğini güçlendirmeye yardımcı olur.

Kontrol 8: Yapıt özetini doğrulayın. Bir yapı herhangi bir ortamda konuşlandırılmadan önce, güvenliğinin ihlal edilmediğinden emin olmak için özetin depodaki yapıtla doğrulanması gerekir.

Kontrol 9: Çekme istekleri, iki gözden geçiren (bir varsayılan gözden geçiren dahil) ve birleştirilmiş bir derleme gerektirir. Bu kontrol, iyi kodlama uygulamalarını desteklemenin yanı sıra, yetkin insan gözetimi olmadan hiçbir taahhütte bulunulmamasını sağlamaya da yardımcı olur. 

Kontrol 10: Daha yüksek depolardaki eserler imzalanır. Yapıtların süreç boyunca bir havuzda imzalanmasını gerektirmek, üretime dağıtılan her şey için görünürlük ve izlenebilirlik sağlar. 

Kontrol 11: Kullanılabilir kapsayıcı görüntülerinde yüksek veya kritik güvenlik açıkları yoktur. Uygulamaların üretime alınmadan önce güvenlik açıkları için test edilmesi gerektiği gibi, dağıtım için paketlendikleri kapsayıcı görüntülerin de test edilmesi gerekir. Kapsayıcı görüntüleri, açık kaynaklı yazılım içeriyorsa, açık kaynak güvenlik açıklarına sahip olabilir. 

Kontrol 12: Yapay imzaları ve özetleri doğrulayın. Özete karşı yapıtın imzasını doğrulamak, yapıtın depoda kurcalanmamasını ve dağıtılan yapıtın test edilenle aynı olmasını sağlar.

Kontrol 13: Üretimde konuşlandırılmış görüntüleri tarayın. Bu, üretimdeki tüm yazılımlar için önceki kontrollerin takip edilmesini sağlamaya yardımcı olur.

Kontrol 14: Kubernetes kaynak bildirimlerini doğrulayın. Kaynak bildirimleri tahrif edilirse, saldırganın tercih ettiği bir kapsayıcıyı dağıtmaları için kandırılabilirler. 

Kontrol 15: Yapı ortamlarının geçici ve değişmez olduğundan emin olun. Derleme ortamları, otomatik oluşturma veya ayırma ile kodda tanımlanmalı ve her yapı için yeni bir ortam oluşturulmalıdır. Derleme ana bilgisayarlarına etkileşimli oturum açmalar kullanılarak erişilebilir olmamalıdır.

Bu planın mühendislik ekiplerine, güvenlik ekiplerinin arkasında toplanıp destekleyebileceği, eyleme geçirilebilir bir mimari sağladığına inanıyoruz. Ancak bu standartları benimseyen mühendislik ekiplerine, tedarik zinciri kurcalama, geliştirme sırasında saldırıların azaltılması ve aşamalandırma ve üretimde manipülasyon riskine karşı daha düşük garantili yazılım teslimi sözü verilir.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Bu site, istenmeyenleri azaltmak için Akismet kullanıyor. Yorum verilerinizin nasıl işlendiği hakkında daha fazla bilgi edinin.