Açık kaynaklı yazılım düzenlenebilir mi? Düzenlenmeli mi? Eğer öyleyse, bu gelişmiş güvenliğe yol açacak mı? Eylül ortasında, iki hükümetin açık kaynaklı yazılımın güvenliğini sağlamaya yönelik yaklaşımları sergilendi, ancak her ikisinin de açık kaynak ekosisteminde iyileştirmelere yol açıp açmayacağı konusunda sorular vardı.
12 Eylül’de ABD Siber Güvenlik ve Altyapı Güvenliği (CISA) kurumu, hükümet kurumunun güvenli yazılım tedarikini teşvik etmek için açık kaynak yazılım topluluğuyla birlikte çalışma sözü verdiği “Açık Kaynak Yazılım Güvenliği Yol Haritasını” yayınladı. Bunun aksine, bir hafta sonraki Açık Kaynak Zirvesi Avrupa’da açık kaynak savunucuları, Avrupa Siber Dayanıklılık Yasası’nın (CRA), işletim sistemi yazılımındaki güvenlik açıklarının sorumluluğunu, açık kaynak yazılım projelerini yöneten geliştiricilere ve kar amacı gütmeyen kuruluşlara etkili bir şekilde yüklediğine ilişkin endişelerini dile getirdi.
İki yaklaşım, devlet kurumlarının ve düzenlemelerin güvenli bir açık kaynak yazılım ekosisteminin geliştirilmesine nasıl yardımcı olabileceğini gösteriyor — Açık Yazılım Güvenliği Vakfı (OpenSSF) genel müdürü Omkhar Arasaratnam, bunun ya da gelişimin baltalanması olduğunu söylüyor.
“Açık kaynak topluluğu etkileşimi seviyor ve açık kaynak topluluğunda bir ortak olarak katılımlarına saygı duyulduğunu görmekten hoşlanıyor” diyor. “Aksine, tıpkı diğer toplulukların kendilerine bir şeyler yapılmasından hoşlanmadığı gibi, Avrupa’daki açık kaynak topluluğunun tepkisine neden olan şeyin, hükümetin bu şeyi, CRA’yı, istişarede bulunmadan onları etkileyen bir yasayı yürürlüğe koyması olduğunu düşünüyorum. “
Açık kaynak yazılım dünya çapında teknik yenilikleri teşvik ederek hükümetleri açık kaynak yazılımın güvenliğini artırırken ekosistemden faydalanmak için en iyi yaklaşımı aramaya itti. Yazılım tedarik zinciri yönetimi şirketi Sonatype’in verilerine göre, 2022’de dört büyük ekosistemde (Javascript, Java, Python ve .NET) açık kaynak bileşenlerin indirilme sayısı 2 milyarı aştı.
Aynı zamanda, Log4j günlük kitaplığındaki sorunlardan yararlanılması gibi yaygın açık kaynak bileşenlerindeki kritik güvenlik açıkları, açık kaynak yazılımın güvenliğini sağlama çabalarına ivme kazandırdı. Örneğin Census II girişimi, iki farklı ekosistemde güvenlik durumu açısından kritik olan ve Log4j benzeri olaylara yol açabilecek en iyi 500 projeyi belirledi.
Bununla birlikte, hükümetlerin sorumluluğu ve açık kaynak yazılımları düzenleme konusundaki yaklaşımına bağlı olarak, yazılım geliştiricileri önemli ölçüde farklı sonuçlara bakıyor olabilir: ekosistem için daha fazla güvenlik ve dayanıklılık, ya da her şey geri tepebilir ve inovasyon sekteye uğrayabilir, diyor CEO’su Dan Lorenc. Yazılım tedarik zincirini güvence altına almayı amaçlayan Chainguard.
“Açık kaynak, doğrudan düzenleyebileceğiniz bir şey değil. Hükümetin gelip insanlara ne yapmaları gerektiğini söyleyebileceği bir şey değil” diyor. “Kodlarını yayınlamak için aynı lisansları ve mekanizmaları kullanan devasa, parçalanmış bireylerden oluşan bir grup.”
İyi Bir Ortak Olacağımıza Söz Veriyoruz
CISA, bu parçalanmış grupların ortağı olmayı amaçlıyor, onları güvenli tasarım kullanmaya teşvik ediyor ve ABD hükümetinin diğer şubelerine, yazılım satıcılarının açık kaynaklı yazılım içeren ve federal hükümete satılan güvenli ürünler üretmeleri için gereksinimler oluşturmaları konusunda tavsiyelerde bulunmaya çalışıyor.
Açık Kaynak Yazılım Güvenliği Yol Haritasının yayınlanmasıyla kurum, genel olarak yazılımın güvenliğini, en kritik açık kaynak bağımlılıklarını anlamaya çalışarak ve daha geniş açık kaynak yazılım ekosistemini ilk hedef olarak yazılımın güvenliğini sağlama hedefiyle güçlendirerek desteklemeyi amaçlıyor. hükümet.
CISA’nın kıdemli teknik danışmanı Jack Cable, Log4Shell saldırılarının, hükümetin kendi teknolojisinin ve ekosisteminin çoğunu destekleyen tedarik zincirinin güvenliğini artırmak için daha fazla eyleme geçmesi gerektiğini gösterdiğini söyledi.
“Çok daha dayanıklı, çok daha güvenli bir geleceğe sahip olmak istiyorsak İnternet’in bu temelleri hakkında düşünmeye başlamalıyız” diyor. “Federal hükümet genelinde kritik altyapılarda kullanılan yazılımı geliştirenlerin güvenli olduğundan nasıl emin olabileceğimiz en önemli sorudur ve bunların başında açık kaynaklı yazılım gelir.”
Biden yönetimi ve Ulusal Standartlar ve Teknoloji Enstitüsü’nden (NIST), Savunma Bakanlığı’na ve CISA’ya kadar çeşitli teknik kurumları, açık kaynak ekosisteminin güvenliğini sağlama çağrısında bulunan Ulusal Siber Güvenlik Stratejisini oluşturmak için endüstriyle defalarca bir araya geldi. diğer girişimlerin yanı sıra. Tüm çabalar onay alamadı: Açık Kaynak Yazılımın Güvenliğini Sağlama Yasası (SOSSA), özellikle siber güvenlik konusunda vasıflı çalışanların yetersiz olması nedeniyle şirketlerden eleştirilere maruz kaldı.
Sorunlara Yol Açan Avrupa Çözümü
Avrupa Birliği’nin bir yıl önce önerilen ve Temmuz ayında kabul edilen CRA’sı, açık kaynak güvenliğinin sorumluluğunu birçok açık kaynak projesi ve bakımcıları da dahil olmak üzere yazılım üreticilerine yüklüyor. Açık Kaynak Zirvesi Avrupa’da katılımcıların ateşini ölçen OpenSSF’den Arasaratnam, Avrupa Birliği mevzuat taslağının hazırlanmasında teknoloji şirketlerine de danışsa da, CRA taslağının hazırlanmasında ve oluşturulmasında açık kaynak topluluğuna yeterince danışılmadığını söylüyor geçen hafta.
“Avrupa’daki CRA ve burada hükümet tarafından alınan kararlar ve özellikle sorumluluk açısından bireysel katkıda bulunanlar ve vakıflar üzerindeki profilleri olan potansiyel olumsuz etkiler hakkında çok şey duyduk” dedi. diyor. “Ve korku şu ki, CRA iyi niyetli olsa da istişare eksikliği nedeniyle savunulabilir olmayan bir miktar mevzuatla sonuçlandı.”
Sorun, açık kaynak ekosisteminin atom biriminin, hiçbir garanti veya bakım sözleşmesi olmaksızın internette yayınlanan tek geliştiricili bir proje olmasıdır. Grup lideri ve baş siber güvenlik mühendisi Andrew Brinker, Avrupa CRA’sının açık kaynak yazılım bakımcılarının dünyasını, bulutun bu projeleri sorumlu tutacak şekilde karmaşık hale getirdiğini, yazılımın güvenliğini düzeltmeyi zorlaştırdığını ve aynı zamanda inovasyonun cesaretini kırabileceğini söylüyor. GÖNYE
“Açık kaynağın ‘altın yumurtlayan kaz’ olduğunu düşünürseniz, yarattığı yumurtanın sorumluluğunu kazın sorumluluğuna atayarak kazı öldürme riskini alabilirsiniz” diyor. “Dolayısıyla, bu açık kaynağı daha sonra ticarileştirip satacakları ürün ve hizmetlere entegre eden gruplara sorumluluk uygulamak daha mantıklı.”
Açık Bir Cevap Yok
Yaklaşımlar ne siyah beyazdır ne de hafif dokunuşa karşı ağır el dersidir. Örneğin, CISA’nın yaklaşımı açık kaynak topluluklarındaki büyük bir sorunu ele almıyor: projelerin finansmanı. Sonatype’ın baş teknoloji sorumlusu Brian Fox, şirketlerin kodunu kullandıkları açık kaynak projelerine yatırım yapması gerektiğini ve hükümetin de bu yatırımı teşvik etmesi gerektiğini söylüyor.
“Okyanusun her iki yakasının da ortak olduğu birkaç şey var; bu da hepimizin kullandığı yazılımın siber güvenliğini geliştirmeyi arzulamamız ve pazara sunulan ürünlerin kalitesine odaklanmamız ve minimum güvenliği tanımlamamızdır. standartlar ve beklentiler” diyor.
Sorumluluğa odaklanmanın, yazılım şirketlerini, güvenliğin doğru yapıldığından emin olmak için güvendikleri projeleri finanse etmeye zorlayabileceğini söylüyor. Ve Fox, gelecek gereksinimlerin uygulama yönlerine geçmek için “biraz uğraşırken”, sektörün yavaş hareket ettiği gerçeğine teslim oldu.
Konuya ilişkin örnek: Log4j’deki güvenlik açıklarının, şirketlerin uygulamalarında potansiyel tehlike noktalarını bulmak için çabalamasına neden olmasından yaklaşık iki yıl sonra, Maven deposundan indirilen sürümlerin neredeyse dörtte biri (%23) savunmasız kalmaya devam ediyor. Fox, başka hiçbir sektörün bilinen güvenlik açığı olan ürünleri piyasaya sürmesine izin verilmeyeceğini ve yazılım sektörünün bu hedefe ulaşacağını söylüyor.
“Sektörü, yazılım satıcılarının sorumluluk sahibi olduğu bir yere taşımak çok büyük bir değişim” diyor. “Bence gecikti ve aynı zamanda kaçınılmaz.”