Aralık 2021’de Java için Log4j günlük kaydı çerçevesindeki Log4Shell güvenlik açığı, BSI’nın kritik olarak derecelendirdiği ve kırmızı alarm olarak sınıflandırdığı bir karışıklığa neden oldu. Ortalık yatıştığına göre, bir tazeleme zamanı: Tüm bunlardan ne öğrenebiliriz?
Log4j, Java’da oturum açmak için etkili bir şekilde fiili standarttır. Bununla birlikte, çerçeve yalnızca günlüğe kaydetme için bir araçtır, kulağa oldukça sıradan ve ilham verici olmayan bir konu. Ancak buna rağmen (veya belki de bu nedenle), modül, ayrıntıları CVE 2021-44228’de daha ayrıntılı olarak açıklanan göze batan bir güvenlik açığı içeriyordu.
Son haftalarda, güvenlik açığının teknik detayları, saldırı senaryosu ve güvenlik açığını kapatma stratejileri hakkında çok konuşuldu, bu nedenle her şeyi tekrarlamanın pek bir anlamı yok.
Önerilen editoryal içerik
İzninizle, buraya harici bir YouTube videosu (Google Ireland Limited) yüklenecek.
Her zaman YouTube videoları yükleyin
YouTube videosunu şimdi yükleyin
Log4j – neden açık kaynak bozuk
Ancak şu ana kadar tartışılmayan ancak daha fazla ilgiyi hak eden konular da var. Bir yandan, bu sorun için hangi nedenlerin ve nedenlerin var olduğunu, tüm durumun en başta nasıl ortaya çıktığını, buna neyin yol açtığını içerir. Bu “neden” sorusudur. Öte yandan, bundan ne öğrenilebileceği sorusu ortaya çıkıyor: gelecekte böyle bir fiyasko nasıl önlenebilir?
kültürel ve sosyal nedenler
Teknik nedenler var ama her şeyden önce kültürel ve sosyal nedenler. Kültürel sebep, Java’nın doğası gereği karmaşıklığı teşvik etmesidir. Basit çözümler tercih edilmez, bunun yerine karmaşıklık üzerine kuruludur ve Log4Shell sorunu, artık göz ardı edilemeyecek ve hatta üstesinden gelinemeyecek ezici karmaşıklığın bir sonucudur. Kristian Köhntopp bunu birkaç hafta önce mükemmel Log4j yorumunda açıkladı: Belirtildiği gibi çalışır.
Buradaki mantık, neredeyse tüm şirketlerin açık kaynak kullanmasına ve buna bağlı olmasına rağmen, çok az şirketin karşılığında katkıda bulunmaya veya geri vermeye istekli olmasıdır. AGPL & Co. gibi sadece hak vermekle kalmayıp aynı zamanda yükümlülük de talep ettikleri için aslında çok daha dürüst açık kaynak lisansları olan lisanslar, hemen hemen tüm şirketler tarafından dışlayıcı bir kriter olarak ele alınmakta ve bunun yerine MIT & Co.’nun belirlediği uygun alternatifleri tercih etmektedirler. . Ve neden?
Çünkü en azından kısa vadede daha az maliyetlidir: daha az zaman ve hepsinden önemlisi daha az para. Ama bu sadece kısa vadeli bir strateji. Uzun vadede, bu yaklaşım başarısız olacak ve Log4Shell’de etkileyici bir şekilde olan da tam olarak buydu. Şimdi bile, açık kaynağa ve arkasındaki geliştiricilere karşı çıkmak, açık kaynağı sadece kullanıcılar için değil, aynı zamanda açık kaynağı geliştiren insanlar için de yararlı kılan sürdürülebilir bir modeli proaktif olarak savunmaktan daha kolaydır.
Açık kaynak için bir iş modeli
Bu durumla ilgili acilen bir şeyler yapılması gerekiyor. Bir BT sektörü olarak ihtiyacımız olan şey, sürdürülebilir açık kaynaklı yazılım için uygulanabilir bir iş modelidir. Ve biz, açık kaynak geliştiricileri olarak, sanki gereksizmiş gibi zamanımızı boşa harcamayı bırakmalıyız.
Ancak o zaman açık kaynağı başarılı kılanlara tek taraflı yük getirmeyen, uzun vadeli, başarılı ve aynı zamanda adil bir model haline gelme şansımız olacak.
()
ana sayfaya
Log4j, Java’da oturum açmak için etkili bir şekilde fiili standarttır. Bununla birlikte, çerçeve yalnızca günlüğe kaydetme için bir araçtır, kulağa oldukça sıradan ve ilham verici olmayan bir konu. Ancak buna rağmen (veya belki de bu nedenle), modül, ayrıntıları CVE 2021-44228’de daha ayrıntılı olarak açıklanan göze batan bir güvenlik açığı içeriyordu.
Son haftalarda, güvenlik açığının teknik detayları, saldırı senaryosu ve güvenlik açığını kapatma stratejileri hakkında çok konuşuldu, bu nedenle her şeyi tekrarlamanın pek bir anlamı yok.
Önerilen editoryal içerik
İzninizle, buraya harici bir YouTube videosu (Google Ireland Limited) yüklenecek.
Her zaman YouTube videoları yükleyin
YouTube videosunu şimdi yükleyin
Log4j – neden açık kaynak bozuk
Ancak şu ana kadar tartışılmayan ancak daha fazla ilgiyi hak eden konular da var. Bir yandan, bu sorun için hangi nedenlerin ve nedenlerin var olduğunu, tüm durumun en başta nasıl ortaya çıktığını, buna neyin yol açtığını içerir. Bu “neden” sorusudur. Öte yandan, bundan ne öğrenilebileceği sorusu ortaya çıkıyor: gelecekte böyle bir fiyasko nasıl önlenebilir?
kültürel ve sosyal nedenler
Teknik nedenler var ama her şeyden önce kültürel ve sosyal nedenler. Kültürel sebep, Java’nın doğası gereği karmaşıklığı teşvik etmesidir. Basit çözümler tercih edilmez, bunun yerine karmaşıklık üzerine kuruludur ve Log4Shell sorunu, artık göz ardı edilemeyecek ve hatta üstesinden gelinemeyecek ezici karmaşıklığın bir sonucudur. Kristian Köhntopp bunu birkaç hafta önce mükemmel Log4j yorumunda açıkladı: Belirtildiği gibi çalışır.
Buradaki mantık, neredeyse tüm şirketlerin açık kaynak kullanmasına ve buna bağlı olmasına rağmen, çok az şirketin karşılığında katkıda bulunmaya veya geri vermeye istekli olmasıdır. AGPL & Co. gibi sadece hak vermekle kalmayıp aynı zamanda yükümlülük de talep ettikleri için aslında çok daha dürüst açık kaynak lisansları olan lisanslar, hemen hemen tüm şirketler tarafından dışlayıcı bir kriter olarak ele alınmakta ve bunun yerine MIT & Co.’nun belirlediği uygun alternatifleri tercih etmektedirler. . Ve neden?
Çünkü en azından kısa vadede daha az maliyetlidir: daha az zaman ve hepsinden önemlisi daha az para. Ama bu sadece kısa vadeli bir strateji. Uzun vadede, bu yaklaşım başarısız olacak ve Log4Shell’de etkileyici bir şekilde olan da tam olarak buydu. Şimdi bile, açık kaynağa ve arkasındaki geliştiricilere karşı çıkmak, açık kaynağı sadece kullanıcılar için değil, aynı zamanda açık kaynağı geliştiren insanlar için de yararlı kılan sürdürülebilir bir modeli proaktif olarak savunmaktan daha kolaydır.
Açık kaynak için bir iş modeli
Bu durumla ilgili acilen bir şeyler yapılması gerekiyor. Bir BT sektörü olarak ihtiyacımız olan şey, sürdürülebilir açık kaynaklı yazılım için uygulanabilir bir iş modelidir. Ve biz, açık kaynak geliştiricileri olarak, sanki gereksizmiş gibi zamanımızı boşa harcamayı bırakmalıyız.
Ancak o zaman açık kaynağı başarılı kılanlara tek taraflı yük getirmeyen, uzun vadeli, başarılı ve aynı zamanda adil bir model haline gelme şansımız olacak.
()
ana sayfaya