Güvenlik, açık kaynak topluluğunda uzun zamandır bir endişe konusu olmuştur. Dikkatli bir şekilde yönetilmezse, küresel kullanıcıların yenilikçi kod katkılarına izin veren aynı açıklık, kötü niyetli aktörler için savunmasız saldırı yüzeyleri de sunabilir. Aslında, kuruluşlarının açık kaynak kullanımını engelleyen engeller hakkında soru sorulduğunda, Anaconda’ya yanıt verenler 2021 Veri Biliminin Durumu raporu Diğer endişelerin yanı sıra “CVE’ler, potansiyel maruziyetler veya risklerden korkma” (%41) ve “Açık kaynaklı yazılım güvensiz kabul edilir, bu nedenle izin verilmez” (%26).

Yine de açık kaynak inovasyonu teşvik eder ve açık kaynaklı yazılım kullanımından kaynaklanan potansiyel riskleri önemli ölçüde azaltmanın yolları vardır. Bu nedenle birçok kuruluş, güvenlik önlemlerine öncelik verirken açık kaynağı benimseyen “her iki dünyanın da en iyisi” yaklaşımını benimser.

Açık kaynak güvenliğini bir uçta “güvenlik denetimi olmayan” ve diğer uçta “kilitlenmiş denetimler” olan bir spektrum olarak düşünürseniz, teknik olarak gelişmiş kuruluşlar ortada bir yere düşme eğilimindedir. İşte onların yaklaşımlarından öğrenebileceğiniz bazı dersler.

1. Herkes Dahil Olmalı
Açık kaynak güvenlik parametrelerinin ayarlanması yalnızca BT ve veri bilimi ekiplerine bırakılmamalıdır. Başarılı olmak için, yönetici liderlik de dahil olmak üzere tüm organizasyonun katılımına ihtiyacınız var. Liderler, güvenlik riskleri ile inovasyon ödüllerinin ödünleşimlerini birlikte göz önünde bulundurmalı ve açık kaynaklı yazılım kullanımı için kabul edilebilir bir risk düzeyi tanımlayacak bir çerçeve oluşturmalıdır.

Kuruluşlar arasında güvenlik çerçeveleri oluştururken önleyici ve sınırlamaya dayalı bakış açıları gereklidir. Açık kaynak projeleri, küresel olarak dağılmış katkıda bulunanlara açık olduğundan, kod, özel satıcı uygulamalarıyla aynı düzeyde yerleşik güvenliğe sahip değildir. Bu nedenle, güvenlik konusunda proaktif bir yaklaşıma sahip olmanız, açık risk parametreleri belirlemeniz ve bir ihlal durumunda önleyici tedbirler uygulamanız gerekir. İkinci bileşenin önemli bir yönü, her uygulamada veya pakette çalışan tüm kodun kaynağını listeleyen bir yazılım malzeme listesi (SBOM) fikridir. Yerinde bir SBOM ile, geçen yılki Log4j olayı gibi bir olay meydana geldiğinde, altyapınızın hangi alanlarının etkilendiğini hızlı bir şekilde belirleyebilirsiniz.

2. Farklı Bir Yaklaşım Yapın
Güvenlik çerçevesi, katı ve hızlı bir dizi spesifik olmayan kuralsa, büyük olasılıkla iki sorunla karşılaşırsınız. İlk olarak, güvenliğin, uygulayıcıların eylemleri hakkında mutlaka eleştirel düşünmediği ve yalnızca bir güvenlik kontrol listesindeki öğelerin üzerini çizdiği bir kutu kontrol alıştırması haline gelme riskini alırsınız. İkincisi, açık kaynağın sunduğu en iyi yeniliği büyük olasılıkla kaçıracaksınız.

Elbette, erişim kontrolleri ve güvenlik duvarları uygulamak ve yalnızca güvenli bir ortam üzerine kurulmuş veya bu ortamdan yansıtılmakta olan depoları kullanmak gibi güvenlik protokollerinizde çok sıkı olmak istediğiniz birkaç alan vardır.

Ancak, kabul edilebilir CVE puanları etrafındaki parametreler gibi bazı nüansları tanıtabileceğiniz başka alanlar da vardır. Örneğin, yalnızca Python alanında on binlerce açık kaynak paketi vardır. Veri bilimcilerinizin yalnızca CVE puanı 6 veya daha düşük olan paketleri kullanmasına izin veren otomatik filtreler ayarlarsanız, puanı 7 olan ancak sizin özel kullanımınızda güvenlik açığı ortaya çıkmayacak olan temel işlevlere sahip bir paketi kaçırabilirsiniz. durum.

Diğer bir yaklaşım, geliştirme ve üretim ortamlarında farklı risk tolerans seviyeleri oluşturmaktır. Bu, geliştiricilere ve veri bilimcilerine, bir güvenlik duvarının arkasında ayrılabilen geliştirme ortamındaki paketleri keşfetme konusunda daha fazla özgürlük verir. Ardından, iş akışlarını üretime taşıma zamanı geldiğinde, daha katı güvenlik protokolleri uygulayabilirsiniz. Belirli bir paket bu gereksinimleri karşılamıyorsa, kurallara daha fazla nüans eklenip eklenmeyeceğini keşfetmek için bir fırsattır.

3. Açık Kaynak Topluluğuna Geri Verin
Açık kaynaklı bir projeyi çatallamak ve çatalı şirket içinde getirmek, size kod dağıtımı üzerinde daha sıkı kontrol sağlayarak güvenlik sorunlarını azaltmaya yardımcı olacağını düşünmek cazip gelebilir. Bununla birlikte, yakın tarihli bir raporda belirtildiği gibi, bu yolun birkaç dezavantajı vardır. Savunma Bakanlığı’ndan açıklama. Bunlar arasında artan destek riski (kodu kontrol eden birkaç çift gözün kaybı nedeniyle), topluluk tarafından yönlendirilen yeniliklere erişimin azalması ve artan kod bakım maliyetleri yer alır.

Birçok sektör lideri, bir projeyi devretmek yerine, gerektiğinde güvenlik açıklarını ortaya çıkarmak, azaltmak ve yamalamak için açık kaynak topluluğuyla yakın işbirliği içinde çalışır. Çoğu proje gönüllü çabaya dayanır ve herhangi bir kaynak katkısı (geliştirici zamanı, parasal destek ve sunucu alanı gibi ayni bağışlar dahil) bir projeyi kullanan herkese fayda sağlayacaktır.

ÇözümGüvenlik bir yolculuktur ve herkes farklı bir hızda ilerler. Sektörünüz, kaynak seviyeniz ve uzmanlığınıza uygun sistemler ve stratejiler uygulamak önemlidir. Aynı zamanda, güvenlik duruşunuzu sürekli olarak iyileştirmeye ve daha karmaşık uygulamaları benimsemeye değer. Siber tehdit ortamı sürekli gelişiyor, bu nedenle teknoloji uzmanları olarak gelişmek ve uyum sağlamak, korunmak, güvende kalmak ve bir adım önde olmak için bize düşüyor.



siber-1