Lale Çorumlu

Linux ve açık kaynaklı yazılımlar her zamankinden daha popüler olacak, ancak asıl değişiklikler nasıl güvence altına alındıkları konusunda olacak.

Linux her yerdedir. Tüm bulutların, hatta Microsoft Azure'un çalıştırdığı şey budur . İlk 500 süper bilgisayarın 500'ünün tamamını çalıştıran şey budur. Linux kullanıcılarının %28 arttığını, Windows kullanıcılarının ise %3 azaldığını iddia eden Pornhub'a inanabilirseniz, masaüstü Linux bile büyüyor .

Açık kaynaklı yazılımlar da hızla büyüyor. Gartner'ın 2021 Açık Kaynak Yazılımı (OSS) için Hype Cycle'a göre: "2025'e kadar işletmelerin %70'inden fazlası, mevcut BT harcamalarına kıyasla OSS'ye yönelik BT harcamalarını artıracak. Ayrıca, 2025 yılına kadar hizmet olarak yazılım (SaaS), daha iyi operasyonel basitlik, güvenlik ve ölçeklenebilirlik sağlama yeteneği nedeniyle OSS için tercih edilen tüketim modeli olacak."

Veritabanlarını, kurumsal yazılımların eti ve patatesini düşünen Gartner, yeni şirket içi uygulamaların %70'inden fazlasının açık kaynaklı bir veritabanında geliştirileceğini tahmin ediyor. Eşzamanlı olarak, mevcut tescilli ilişkisel veritabanı örneklerinin %50'si dönüştürülmüş veya açık kaynaklı VTYS'lere dönüştürülecektir.

Bu numaraları satın alacağım. İlk günden beri Linux ve açık kaynaklı yazılımları takip ediyorum. Gittiğim her yerde ve konuştuğum herkes bu ikilinin yazılım evrenini yönettiğini kabul ediyor.

Ancak Örümcek Adam'ın bildiği gibi büyük güçle birlikte büyük sorumluluk da gelir. Ve birçok geliştiricinin yakın zamanda Apache Java günlük kaydı açık kaynak kitaplığı log4j2 ile birden fazla güvenlik açığı keşfedildiğinde öğrendiği gibi, aynı zamanda büyük baş ağrıları da beraberinde getiriyor .

Log4j2 sorunları, alabildiğine kötü. Ulusal Güvenlik Açığı Veritabanı (NVD) ölçeğine göre, son derece korkunç olan 10.0 CVSSv3 olarak derecelendirilmiştir.

İlginizi Çekebilir

Gerçek sorunu, açık kaynağın kendisinde değil. Orada açık kaynak metodolojisi ve güvenlik konusunda hiçbir şey büyülü. Güvenlik hataları yine de kodu girebilir. Linus'un yasası, yeterince göz küresi verildiğinde, tüm böceklerin sığ olduğudur. Ancak, yeterli sayıda geliştirici aramıyorsa, güvenlik açıkları yine de fark edilmeyecektir. Şimdi Schneier yasası olarak adlandırdığım şey, " Güvenlik bir süreçtir, bir ürün değil ", tüm yazılımların güvenliğini sağlamak için sürekli tetikte olmak gerektiğine işaret ediyor.

Bununla birlikte, log4j ile asıl sorun, Java'nın kaynak kodunun ve ikili dosyaların sayısız Java Arşivi (JAR) varyasyonunda kullandığı kitaplıkları nasıl gizlediğidir . Sonuç? Log4j'nin güvenlik açığı bulunan bir sürümünü kullanıyor olabilirsiniz ve istismar edilene kadar bunu bilmiyor olabilirsiniz.

Josh Bressers olarak Anchore başkan yardımcısı geçenlerde açıkladı, "meydan okuyan log4j açığı pozlar biri aslında. Java uygulamalarını bu aralar ve bağımlılıklar dağıtım ve kolay gerçekten çalışan yapar biçimi ambalaj çeşit genellikle, fakat bu yazılım paketlerinin içinde ne olduğunu bulmayı zorlaştırabilir."

Neyse ki, kullanımda olan arızalı log4j kitaplıklarını tespit etmenize yardımcı olabilecek log4j tarayıcıları var. Ancak mükemmel değiller.

Log4j karmaşasının arkasında başka bir sorun var, bu da "Yazılımınızın hangi açık kaynaklı bileşenleri kullandığını nereden biliyorsunuz?" Örneğin, log4j2 2014'ten beri kullanılmaktadır. Bugün hala kullanmakta olduğunuz bir programda bu ilk sürümü kullanan kimsenin bunu hatırlamasını bekleyemezsiniz.

Cevap, açık kaynak topluluğunun son yıllarda ciddiye almaya başladığı bir cevap: Yazılım Malzeme Listesinin (SBOM) oluşturulması. Bir SBOM, herhangi bir programda tam olarak hangi yazılım kitaplıklarının, rutinlerin ve diğer kodların kullanıldığını açıklar. Bununla donanmış olarak, programınızda hangi bileşen sürümlerinin kullanıldığını inceleyebilirsiniz.

Linux Vakfı'nın Açık Kaynak Tedarik Zinciri Güvenliği Direktörü David A. Wheeler'ın açıkladığı gibi, SBOM'leri ve doğrulanmış tekrarlanabilir yapıları kullanarak, programlarınızda neyin ne olduğunu bildiğinizden emin olabilirsiniz. Bu şekilde, bir bileşende bir güvenlik açığı bulunursa, onu düzeltmeden önce olası herhangi bir sorun kodunu manyak gibi aramak yerine basitçe yama yapabilirsiniz.

Bu arada Wheeler, "Tekrarlanabilir bir yapı", "yapı sonuçlarının doğrulanabilmesi için her zaman aynı girdiler verildiğinde aynı çıktıları üreten bir yapıdır. Doğrulanmış bir yeniden üretilebilir yapı, bağımsız kuruluşların kaynak koddan bir yapı ürettiği bir süreçtir. ve oluşturulan sonuçların iddia edilen kaynak kodundan geldiğini doğrulayın."

Bunu yapmak için, geliştiricilerinizin ve sizin programlarınızı Linux Foundation'ın Yazılım Paketi Veri Değişimi (SPDX) biçimini kullanarak bir SBOM'da izlemeniz gerekir. Ardından, kodunuzun gerçekten iddia ettiği gibi olduğundan daha fazla emin olmak için, Codenotary Community Onay Hizmeti ve Tidelift Katalogları gibi hizmetlerle SBOM'unuzu noter tasdik ettirmeniz ve doğrulamanız gerekir .

Bütün bunları söylemek kolay. Yapması zor. 2022'de, hemen hemen tüm açık kaynak geliştiricileri, kodlarında sorun olup olmadığını kontrol etmek ve ardından SPDX tabanlı SBOM'lar oluşturmak için çok zaman harcayacaklar. Solarwind tipi afetlerden ve log4j güvenlik sorunlarından endişe duyan kullanıcılar bunu talep edeceklerdir.

Aynı zamanda, Linux geliştiricileri, Rust Linux'un ikinci dilini yaparak işletim sistemini daha da güvenli hale getirmek için çalışıyorlar . Niye ya? Çünkü, Linux'un birincil dili olan C'nin aksine, Rust çok daha güvenlidir. Özellikle, Rust, bellek hatalarını işlemede C'den çok daha güvenlidir.

Microsoft'un başlıca bulut geliştirici savunucusu Ryan Levick'in açıkladığı gibi, " Rust tamamen bellek açısından güvenlidir." Bu büyük bir anlaşma, çünkü Linux çekirdeği geliştiricileri Alex Gaynor ve Geoffrey Thomas'ın 2019 Linux Güvenlik Zirvesi'nde belirttiği gibi, Linux çekirdeği güvenlik açıklarının neredeyse üçte ikisi bellek güvenliği sorunlarından geliyor. Ve bunlar nereden geliyor? C ve C++ ile ilgili doğal sorunlar.

Şimdi Linux, Rust'ta yeniden yazılacak. En azından bu on yıl değil, 2030'larda benimle tekrar kontrol edin, ancak birçok Linux sürücüsü ve diğer kodlar, Rust'ta ileriye dönük olarak yazılacak.

Linus Torvalds'ın bana söylediği gibi, "Hiçbir şekilde Rust'ı zorlamazken", "vaat edilen avantajları göz önünde bulundurarak ve bazı güvenlik tuzaklarından kaçınarak buna açık. Yine de, "Ayrıca, bazen sözlerin tutmadığını da biliyorum."

Her şeyin nasıl çalıştığını göreceğiz. Ayrıntılar nasıl olursa olsun, kesin olarak bildiğim bir şey var. 2022'de kodun güvenliğinin Linux ve açık kaynak geliştiricileri için en önemli sorun haline geldiğini göreceğiz. Her ikisi de başka bir şekilde uygulanamayacak kadar önemli hale geldi.

Kaynak: https://www.zdnet.com/article/in-2022-security-will-be-linux-and-open-source-developers-job-number-one/