Bir sonraki Log4j’yi bulmak – OpenSSF’den Brian Behlendorf, açık kaynak geliştirmenin ‘risk merkezli görüşüne’ dönme konusunda


Apache öncüsü, OpenSSF son kullanıcı katılımını artırdığı için ‘riski size ait olmak üzere kullanın’ modelinin artık savunulamaz olduğunu söylüyor

OpenSSF ve Apache Brian Behlendorf

Açık Kaynak Güvenlik Vakfı (OpenSSF), açık kaynak yazılımındaki güvenlik açıklarını azaltmaya yardımcı olmak için yakın zamanda Microsoft’un Güvenli Tedarik Zinciri Tüketim Çerçevesini (S2C2F) benimsedi – Redmond’un açık kaynağa olan eski düşmanlığı göz önüne alındığında bir zamanlar düşünülemez bir ortaklık.

2016’dan beri GitHub’ın sahibi ve önemli bir Linux katılımcısı olan Microsoft, 2019’da S2C2F’yi geliştirdi.

Tehdit tabanlı risk azaltma çerçevesi, açık kaynak yazılımlara yönelik tedarik zinciri tehditlerini listeler ve kuruluşlara olgunluklarını değerlendirmek ve çerçevenin gereksinimlerini uygulamak için kılavuzlar sağlar.

Hareket, OpenSSF’in açık kaynak güvenlik açıklarındaki artış ve ekosisteme yönelik saldırılardaki yedi kat artışla mücadele etmek için attığı adımlardan yalnızca biri.

Değişen derecelerde titizlik

OpenSSF genel müdürü Brian Behlendorf için S2C2F’yi benimsemek, OpenSSF’in 100 üyeyi aştığı görevdeki ilk yılının en önemli olaylarından biri.

Behlendorf, Apache HTTP Sunucusunun ortak yaratıcısı, Dünya Ekonomik Forumu’nun eski CTO’su ve 2014’ten beri OpenSSF projesini yürüten Linux Foundation üyesidir.

“OpenSSF, açık kaynaklı yazılımları daha güvenli hale getirmeyi, güvenlik açıklarını daha hızlı bulmayı, bu güvenlik açıklarını daha hızlı düzeltmenin yollarını bulmayı… ama aynı zamanda küresel yazılım tedarik zincirinde ortaya çıkan zayıflıkları gerçekten ele almayı amaçlayan bir girişimler topluluğudur. Behlendorf anlatıyor günlük yudum.

“Açıkçası, herhangi bir ticari paketteki yazılımın %70 ila 90’ı önceden var olan açık kaynak kodu olduğundan, artık açık kaynak dünyası ile ticari yazılım dünyası arasında hiçbir ayrım yok” diyor.

MUTLAKA OKUYUN “Geliştiricilere nasıl güvenli yazılım yazılacağını öğretmiyoruz” – Linux Foundation’dan David A Wheeler, CVE artışını tersine çevirme hakkında

Behlendorf ayrıca, Kubernetes gibi ortamlar aracılığıyla açık kaynak kodunun çoğalmasına ve bunun, tümü “aynı derecede titizlikle oluşturulmamış” olabilecek yazılım bileşenlerini açığa çıkarma biçimine de işaret ediyor.

“Açık kaynaklı yazılımlar, sağlamlaştırmaya, test ve doğrulamaya ve bu tür şeylere yapılan yatırım miktarının oldukça yüksek olduğu Linux gibi kayan yazı projeleri sayesinde güvenlik konusunda oldukça iyi bir üne sahip olma eğilimindedir” diyor.

“Kodun bütünlüğü ve güvenliği söz konusu olduğunda, diğer birçok projede yüksek derecede özen gösteriliyor. Ancak tüm projeler bunu başaramaz. Ve pek çok yazılım, özellikle de daha küçük modüller, açıkçası başka bir şey yapma yolundaki insanlar tarafından inşa ediliyor.”

Devam ediyor: “GitHub’a koyuyorlar veya NPM’ye bir paket atıyorlar. Bir gün uyanıyorlar ve binlerce ya da milyonlarca insan paketlerini gerçekten düşünmeden ya da bir paketin diğerinden daha titizlikle yapılıp yapılmadığını, incelenip incelenmediğini ölçmenin bir yolunu bulamadan kullanıyor.”

Log4j Dersleri

OpenSSF’in misyonunun bir kısmı, geliştiriciler arasındaki güvenlik uygulamalarını iyileştirmektir. Bu, güvenlik risklerini değerlendirmek için açık kaynak kodu kullanan kuruluşlara yardımcı olmakla el ele gider.

“Odak noktası, objektif risk ölçümlerine ve tüketicilerin yazılım seçimleri konusunda programatik olarak daha akıllı olmalarına yardımcı olmanın yollarına ve [for] geliştiriciler, son kullanıcılarını korumak için yapabilecekleri daha çok şeyin olduğunun farkına varıyor,” diyor Behlendorf.

Log4j

Log4j’den bu yana bu daha da önemli hale geldi. “Geçen yıl boyunca, özellikle Log4j’nin ardından, birçok insanın küresel tedarik zincirlerinde riskleri sistematik olarak nasıl azaltacağını daha iyi anlamak istediğini keşfettik. Bir sonraki Log4j’nin şansını nasıl azaltabiliriz?”

Bunun, bir güvenlik açığının dünya çapında açık kaynaklı yazılıma güvenen milyonlarca işletme üzerindeki etkisini azaltmak için yapılması gerektiğini söylüyor. Yazılım geliştirmeye yönelik yeni süreçler, kod ve yazılım bileşenlerinin daha fazla incelenmesi, yazılım malzeme listelerinin (SBOM’ler) daha iyi kullanılması ve geliştirici eğitiminin tümü yardımcı olacaktır.

“Bir sonraki Log4j’nin ne olacağını söyleyemeyiz, ancak bir sonraki Log4j olma olasılığı %1 olan 200 paketin hangileri olduğunu söyleyebiliriz” diyor.

İLİŞKİLİ Log4j indirmelerinin üçte biri, tedarik zinciri saldırıları tehdidine rağmen hala savunmasız sürümü çekiyor

Şu anda kullanımda olan kodun çoğu – hem ticari hem de açık kaynak – günümüzün tehditlerine karşı koyacak şekilde tasarlanmamıştı. Zorluk, bu savunmasız bileşenleri belirlemek ve herhangi bir güvenlik açığını düzeltmek veya azaltmaktır. Behlendorf’a göre, güvenlik araştırmalarına yapılan yatırımdaki nispeten küçük bir artış, “milyarlarca dolarlık potansiyel etkiyi” kurtarabilir.

“Yazılım geliştirmeye risk uygulama konusunda çok zayıftık” diyor. “Hepsi bir uyarı ve iyi şanslar. Umarız kritik dijital altyapının nasıl inşa edileceğine dair daha risk merkezli bir bakış açısına sahip olma ekseninin bir parçasıyız.”

Güvenlik güncellemeleri konusunda tereddüt

Bunu yapmanın bir yolu, geliştiricilerin kaynak kodunu, yapıyı, bağımlılıkları, testi ve proje bakımını etkileyen güvenlik açıklarını kontrol etmek için kullanabilecekleri OpenSSF puan kartıdır. Behlendorf, kusursuz olmadığını, ancak geliştiricilerin güvenliği ciddiye almalarını sağladığını kabul ediyor.

Ancak sektör ve özellikle son kullanıcı işletmelerindeki geliştiriciler başka engellerle karşı karşıya. Behlendorf, bilinen güvenlik açıklarına yama uygularken bile düzeltmeleri dağıtma konusundaki tereddütlerini vurguluyor. Korku, kritik bir sistemi bozmaktır.

Endüstrinin CIO’ları “bu güncellemeyi altyapılarının geri kalanı üzerinde art arda gelen etkileri olmadan yapabileceklerine” ikna etmesi gerekiyor, diyor. “Birçok kuruluş, sık güncellemeler yaparak ve API’lerin değiştiğini ve eski şeylerin çalışmadığını keşfederek yandı.” Bunu ele almak için, geliştiricilerin kodlarını ileriye dönük olarak daha uyumlu hale getirmeleri ve güncelleme sürecini otomatikleştirmeleri gerekir.

Kuruluşların teknik borcu ölçmenin ve eski kodların ortaya çıkardığı güvenlik risklerini ölçmenin etkili yolları da yoktur. “Yalnızca açık kaynaklı yazılımlar değil, tüm ticari yazılımlar her zaman ‘riski size ait olmak üzere kullanın’ şeklinde olmuştur,” diye açıklıyor. Ve bu “sorumluluk yok” modeli, açık kaynak ekosisteminin büyümesi için çok önemliydi.

Microsoft ile ortaklık

Sonuç olarak, yazılım dağıtıcıları ve son kullanıcılar, riski belirlemek ve azaltmak için daha iyi araçlara ihtiyaç duyar. Bu nedenle OpenSSF, Richmond ve açık kaynak topluluğu arasındaki sert geçmişe rağmen S2C2F’yi kullanmak için Microsoft ile birlikte çalıştı.

Behlendorf, “Bu uzun zaman önceydi” diyor. “Bugün Microsoft, Linux çekirdeğine önemli bir katkıda bulunuyor. Pek çok farklı açık kaynak paketindeki iyileştirmeler için çok para harcıyorlar.”

OpenSSF, S2C2F’nin yazılım geliştirmeye daha fazla titizlik katacağına ve SLSA çerçevesi gibi diğer girişimleri tamamlaması gerektiğine inanıyor.

Behlendorf, S2C2F’nin artık OpenSSF’de kendi Özel Girişim Grubuna sahip olacak ve Behlendorf, onu diğer satıcılara ve paydaşlara açacağını söylüyor.

“Artık bu bir OpenSSF projesi, diğer şirketlerin katılımını bekliyoruz,” diyor hem satıcılar hem de son kullanıcı firmalar. OpenSSF, bu yılın başlarında bir son kullanıcı çalışma grubu başlattı.

Behlendorf, “Son kullanıcılar bu türden çok sayıda dahili araç oluşturuyor ve modernleştirmeye, güncellemeye ve endüstrinin gittiği yöne uyum sağlamaya çok hevesliler” diyor.

İnternetin karanlık maddesini korumak

OpenSSF ayrıca, Rust ve Linux çekirdeği ile çalışan ve DNS kitaplıkları ve hatta ağ zamanı gibi kaynakları bellek açısından güvenli bir şekilde yeniden kodlayan Prossimo girişimi aracılığıyla bellek açısından güvenli mimariler üzerinde çalışıyor.

“Bu, internetin çalışmasını sağlayan karanlık madde gibidir. Ve eğer o şey dışarı çıkarsa, hepimiz gerçekten kötü, kötü bir durumdayız,” diye uyarıyor Behlendorf.

OpenSSF ayrıca tedarik zinciri şeffaflığını artırmanın bir yolu olarak SBOM’ları desteklemeye devam edecektir. Behlendorf, SBOM’ların yazılım sürümlerindeki benioku dosyaları kadar evrensel olmasını istiyor, ancak bunun yukarı akış geliştiricilerine aşırı yük bindirmeden yapılması gerektiğini kabul ediyor.

Ayrıca, açık kaynak güvenliğini iyileştirme beklentileri konusunda gerçekçi, güvenlik açıklarının olmadığı bir gelecek tasavvur ediyor, ancak yalnızca “inanılmaz derecede niş” hataların kaldığı bir gelecek.

“Kusursuz kod diye bir şey yoktur” diyor. “En sevdiğim sözlerden biri, son kullanıcı öldüğünde son hatanın düzeltildiğidir!

“Hiçbir zaman sıfır CVE’nin olmadığı bir noktaya gelemeyeceğiz, ancak bunları düzeltmenin BT altyapı bakımının rutin bir parçası olduğu ve özellikle kritik altyapı için kesintiye neden olmayacağı bir noktaya gelmeliyiz.

“Bir söz vardır: ‘Yeterince göz ile tüm böcekler yüzeyseldir’. Behlendorf, orada her kod satırı için yeterli göz küresi yok,” diye sözlerini tamamlıyor.

ÖNERİLEN “Güvenlik ekipleri, AppSec’in kontrolünü ele geçiren geliştiricilere karşı sık sık savaşır”: Tanya Janca, DevSecOps’u benimseme yolunda



Source link