Avrupa’nın siber güvenlik politikasında açık kaynak sorunu var. ABD ile karşılaştırıldığında, Birleşik Krallık ve Avrupa, açık kaynak yazılım tedarik zincirlerinin kötü niyetli aktörlere karşı dayanıklılığı için ulusal güvenlik stratejisi konusunda arayı kapatıyorlar. Açık kaynak, kritik yazılım altyapımıza güç verir ve buna karşı bir tehdit olarak kullanılabilir – Microsoft kısa bir süre önce, savunmasız açık kaynak bileşenlerinin Hindistan’daki enerji şebekelerini hacklemek için kullanıldığını tespit etti. 2021’de, yakın tarihin en büyük yaygın güvenlik açığı olan Log4shell güvenlik açığı, yönetilmeyen yazılım tedarik zincirlerinin risklerini ortaya çıkardı.
Bu küresel bir endişe olduğu için hükümetler harekete geçiyor. Geçen yıl Birleşik Krallık hükümeti, tedarik zincirindeki küçük güvenlik risklerinin bile sahip olabileceği muazzam etkiyi vurgulayan ‘Birleşik Krallık’ın Siber Direncini Artırmak’ için bir Mevzuat Önerisi yayınladı. Bu arada Almanya, Bilgi Güvenliği Yasası 2.0’ı (IT-SiG) yayınladı ve daha yakın zamanda, Avrupa Birliği (AB) Siber Direnç Yasasını önerdi (buna geri döneceğiz).
Bunun neden önemli olduğunu anlamak için, açık kaynak tüm modern uygulamalardaki kodun %80 ila %90’ını oluşturur. Uygulama katmanından kaynaklanan tespit edilen saldırıların en az dörtte biri, onu oluşturmak için kullanılan bir açık kaynak bileşenindeki bir güvenlik açığına bağlanabilir. Ne yazık ki, açık kaynağın birçok ticari tüketicisi, yazılım tedarik zincirlerini herhangi bir merkezi şekilde yönetmiyor. Güvenlik açığı olduğu bilinen indirilen açık kaynak bileşenlerinin %96’sında daha iyi, savunmasız olmayan bir sürüm mevcuttu.
Uygulamaları Log4shell’e karşı savunmasız hale getiren bileşen olan Log4j bile benzer davranışlara maruz kaldı. Log4j’nin savunmasız sürümlerinin ortalama tüketimi 2022’nin tamamı için %38 olarak gerçekleşti. Bu, zamanın %38’inde birisinin şimdiye kadar gördüğümüz en yaygın olarak duyurulan ve istismar edilen güvenlik açığını içeren bir sürümü indirip yazılımlarına oluşturduğu anlamına geliyor.
Sorun, şirketlerin harekete geçmesi için teşvik eksikliğinden kaynaklanmaktadır. Açık kaynak, modern ekonomimizi mümkün kılan güçlü bir araçtır, ancak onu yönetememek, yazılım geliştirme ekiplerini teknik borca ve kötü güvenlik riskine açık bırakır.
Açık kaynak yazılım güvenliği ile Birleşik Krallık sorunu
Geçenlerde Birleşik Krallık Ulusal Denetim Ofisinin tehlikeleri vurguladığını gördük. Birleşik Krallık Çevre, Gıda ve Köy İşleri Bakanlığı (Defra) tarafından kullanılan yazılımların yaklaşık üçte birinin ömrünün sonuna geldiğini ve Defra’nın bunu güncelleme planı olmadığını tespit etti. Bu, İngiltere’nin kamu sektörünün siber saldırılara karşı savunmasız olduğu anlamına gelir, çünkü onu oluşturmak için kullanılan binlerce açık kaynak eskimiş ve keşfedilen yeni tür güvenlik açıklarına karşı daha savunmasız hale gelmiştir.
Birleşik Krallık hükümeti dijital tedarik zinciri güvenliğinin önemini kabul etmeye çalışsa da mevcut politika, açık kaynağı bu tedarik zincirinin bir parçası olarak görmemektedir. Bunun yerine, düzenleme veya önerilen politikalar, geleneksel anlamda yalnızca üçüncü taraf yazılım satıcılarına odaklanır, ancak günümüzdeki tüm yazılımların yapı taşlarını ve arkasındaki tedarik zincirini tanımakta başarısız olur.
Bu noktayı vurgulamak için, İngiltere’nin 11.000’den fazla kelimelik Ulusal Siber Güvenlik Stratejisi, açık kaynağa tek bir referans içermiyor. Bu arada, GCHQ rehberliği, ‘yazılımınızın açık kaynak bileşenlerinin bir listesini bir araya getirin veya tedarikçilerinize sorun’ dışında çok az ayrıntılı yönerge ile sınırlı kalır.
Ulusal düzeyde açık kaynak uygulamalarının iyileştirilmesine önemli bir önem verilmedikçe, hükümetin siber dayanıklılığı artırma hedeflerini gerçekleştirmesi pek olası değildir.
AB, açık kaynak yazılım güvenliğini daha iyi idare ediyor mu?
Bu anlamda AB kesinlikle dinliyor. Yakın zamanda yayınlanan Siber Direnç Yasası (CRA), herhangi bir dijital varlığı etkileyen tehditlerle mücadele etmek ve ‘daha güvenli donanım ve yazılım ürünleri sağlamak için siber güvenlik kurallarını desteklemek’ için önerilen düzenlemesidir.
İlk olarak, cesaret verici kısımlar: CRA, yalnızca yazılım satıcılarını ve üreticilerini (diğer şeylerin yanı sıra) bir Yazılım Malzeme Listesi’ne (SBoM) sahip olmaya çağırmakla kalmaz, şirketlerin bileşenleri geri çağırma yeteneğine sahip olmasını talep eder. Bu çok önemli kısım, şirketleri dağıtılmış yazılımlarına nelerin girdiği konusunda farkındalık oluşturmaya zorladığı için uzun süredir politikalarda eksik.
Tıpkı otomobil endüstrisi gibi fiziksel ürün üreticilerinden beklediğimiz gibi, açık kaynağın ticari tüketicilerinin, bilinen kötü bitleri hedefli bir şekilde geri çağırma yeteneğine sahip olmaları istenmelidir. Araba üreticilerinin bir arabanın servis kılavuzundaki parça listesini yazdırıp torpido gözünde bırakması ve araç sahibine aracı tamir ettirmesi gerektiğini hayal edin. Bu kimsenin hoşuna gitmez ve kritik altyapı veya verilerle ilgilenen yazılımlara farklı şekilde davranmamalıyız.
CRA, açık kaynaklı yazılımları bu düzenlemelerden muaf tutmaya bile çalışır. Bu harika – OSS ve proje sahipleri meli inovasyonu ve fikir paylaşımını engellememek için yükümlülük uygulayan düzenlemelerden muaf olun. Ancak, CRA’nın ticari ve ticari olmayan OSS kullanımı arasında açık kaynağın geleceğine zarar verebilecek bir çizgi çekmesiyle ilgili bazı sorunlu dil var.
Şu anda, metin (Sayfa 15, Paragraf 10; Sayfa 43, Paragraf 4), OSS’den ticari fayda elde eden bir geliştirici veya tedarikçinin OSS’yi CRA’ya tabi kılacağını ima etmektedir. Hatta, yazılımların dağıtımı ile ilgili olarak, açık kaynak üreticilerinin veya geliştiricilerinin, açık kaynak projelerinin ticari olarak kullanılması durumunda sorumlu tutulabileceklerini ima eder.
Bunun açık kaynaklı yazılımlar için ne anlama geldiği çok belirsizdir. Bu, PyPi, npm veya Maven Central gibi halka açık depolara nasıl uygulanır? Bunlar, dünyanın sırasıyla Python, Javascript ve Java için açık kaynak bileşenlerinin kopyalarını tükettiği fiili kaynaklardır. OSS sağlayan ve ticari fayda sağlayan kuruluşlar birdenbire içerik için potansiyel olarak sınırsız sorumluluğu omuzlamak ister mi?
Her açık kaynak güvenlik açığı, belirli bir bileşenin tüm olası kullanımları için geçerli olmadığından, Central veya npm gibi bir havuzun her güvenlik açığının etkisini değerlendirmesi imkansızdır. Bir güvenlik açığı, bir bileşenin tüm kullanımları için nadiren geçerlidir. Bir kullanıcının sorununu çözmek için bir bileşeni etkili bir şekilde kaldırmaya teşvik eden yukarı akışları zorlama politikası, onu tamamen güvenli bir şekilde kullanan bir başkasında onarılamaz hasara neden olabilir.
Açık kaynak rehberliği açık ve mevcut olmalıdır
Avrupa mevzuatındaki siber güvenlik politikası, OSS’yi kabul etmelidir, ancak spesifik, eyleme geçirilebilir yönergeler olmadan genel rehberlik, siber dayanıklılığı anlamlı bir şekilde artırmayacaktır.
CRA herhangi bir açıklama yapılmadan AB yasası haline gelirse, bunun OSS üzerindeki etkisi, işbirliğini zorlaştıran veya imkansız hale getiren açık kaynağın balkanlaştırılması da dahil olmak üzere, yıkıcı şekilde istenmeyen sonuçlara yol açabilir. Kamuya açık depoları AB’ye erişilemez hale getirebilir – yazılım ekosistemi için felaket.
Yayıncılara karşı sorumluluk devam ediyorsa, belirli projelerin etkilenen ülkelerden katkıda bulunanları engelleyerek yetenekli geliştiricilerin OSS projelerine katkıda bulunmalarını engellemesi düşünülemez değildir. Projeler, özellikle AB’ye gönderilen ürünlerin içindeki kullanımı hariç tutmak için lisansları değiştirmeye başlayabilir.
Yine de bu mevzuat, dijital ürünlerdeki siber güvenlik duruşunu muadillerinin çoğundan daha gelişmiş bir şekilde artırmaya yönelik yapıcı bir istekten kaynaklanmaktadır. En son 2022 Açık Kaynak Güvenliği Yasası ve NSA/CISA rehberliği olan ABD’deki mevcut politika, doğru yönde atılmış bir adım olsa da, çok yüksek seviyede olmaya devam ediyor. Yazılım tedarik zinciri yönetimi için daha spesifik standartlarla uyumluluğu zorunlu kılmak için, tüm satıcıların yazılım tedarik zincirleri için sertifikasyon gerekliliklerine ek olarak, diğer tüm düzenlemeler ve kılavuzlar GDPR’nin kural koyuculuğunu takip etmelidir.
Hiçbirinin olmadığı bir yerde politika getirmek önemli bir çaba gerektirecektir, ancak bu, açık kaynak ve Avrupa yazılım endüstrisi için bir felaketten kaçınmak anlamına geliyorsa, buna değer.
İlkka Turunen, Sonatype’ta saha CTO’su