Yazılım, tüm modern işletmelerin merkezinde yer alır ve operasyonların her alanında çok önemlidir. Tescilli yazılımlar bile açık kaynak kitaplıklarına bağlı olduğundan, hemen hemen her işletme, bilerek veya bilmeyerek açık kaynaklı yazılım kullanacaktır. OpenUK’ler 2022 “Açık Durum” raporu, işletmelerin %89’unun açık kaynaklı yazılımlara güvendiğini, ancak hepsinin güvendikleri yazılımın ayrıntıları konusunda net olmadığını ortaya koydu.

İşletmeler, operasyon açısından kritik yazılımları hakkında giderek daha fazla bilgi talep ediyor. Sorumlu işletmeler, yazılım tedarik zincirleriyle ayrıntılı olarak ilgileniyor ve her uygulama için bir yazılım malzeme listesi (SBOM) oluşturuyor. Bu bilgi düzeyi, yazılımlarında güvenlik açıkları tespit edildiğinde, hangi yazılım ve sürümlerin kullanımda olduğundan ve hangi sistemlerin etkilendiğinden hemen emin olabilmeleri için çok önemlidir. Bu durumlarda bilgi güçtür!

Gönüllülere Güven

2021’in sonlarında, yaygın olarak kullanılan bir Java günlük kaydı çerçevesinde Log4j’de Log4Shell adlı bir güvenlik açığı tespit edildi. Bu yaygın olarak kullanılan, açık kaynaklı bir kitaplık olduğundan, güvenlik açığı iyi bir şekilde duyuruldu ve düzeltmeler bekleniyordu. Ancak projenin yürütücüleri gönüllülerdi. Günlük işleri vardı ve çok sayıda sistem etkilenmiş olsa bile acil güvenlik düzeltmeleri için çağrıda bulunmuyorlardı. Bu güvenlik açığının tek başına kurumsal bulut ortamlarının %93’ünü etkilediği tahmin ediliyor.

O zamanlar açık kaynak hakkında bazı olumsuz basın vardı, ancak gerçek şu ki, eğer bu bir kapalı kaynak bileşeni olsaydı, güvenlik açığı hiçbir zaman kamuoyu tarafından bilinmeyebilir ve kuruluşları saldırıya açık hale getirebilirdi. Kütüphanenin açık kaynak yapısı, incelenebileceği, bulunan problemler ve başkaları tarafından sunulan tavsiyeler anlamına geliyordu. Yani evet, bakıcılar gönüllü projelerinde güvenlik sorunları için çağrıda bulunmadılar. O halde büyük soru şudur: Büyük şirketlerin, faturalarını ödemek için başka bir şey yapan birinin sorumluluğunda olan yazılıma bağımlı olduğu bir duruma nasıl geldik?

Yazılım bağımlılıklarının ihmal edilmesi, yazılımın lisansı ne olursa olsun riskli bir iştir, ancak açık kaynak olduğunda ve çok yaygın olarak kullanıldığında özellikle tehlikeli hale gelir. Bir güvenlik açığı hikayesine bağlı kalmak; sorun yıllardır kod tabanında mevcuttu, ancak fark edilmedi. Bu kadar yaygın olarak kullanılan araç aslında bu kadar yaygın olarak desteklenmedi ve bundan sonra olanlar tarih oldu.

Bu hikaye, kritik bağımlılıkları olan ancak bakımcıları veya projeleri desteklemek için harekete geçmeyen pek çok işletmede tekrar tekrar tekrarlanıyor. Bir işletme tarafından kullanılan yazılım için bir SBOM’a sahip olmak, bilgiye sahip oldukları anlamına gelir. Başkalarına yazılım sağlayan kuruluşlar için, kodun yanı sıra SBOM’u da sağlama beklentisi giderek daha fazla norm haline geliyor.

Riski Değerlendirmek için Bağımlılıkları Bilin

Bağımlılıklar hakkında bilgi getirmek, her biriyle ilişkili riski değerlendirmeyi kolaylaştırır. Bu açık kaynak projeleri, değerlendirilmesi en basit olanlardır: sorunlara yanıt verildi mi ve yakın zamanda herhangi bir sürüm yayınlandı mı? Her proje için bakımcıları ve proje etkinliğini görebilmek, projenin sağlığı hakkında iyi bir fikir verir.

İşletmeler, bağlı oldukları projeleri destekleyerek riskleri azaltmak için üzerlerine düşeni yapabilirler. Bazı projeler, sponsorluğu doğrudan GitHub Sponsorları programı aracılığıyla kabul ederken, diğerleri bunun yerine barındırma tekliflerini veya güvenlik denetimini takdir edebilir. Her açık kaynak projesi katkıları takdir eder. İşletmeniz bu kütüphaneyi kendisi oluşturmuş olsaydı, şirket içindeki mühendislerin her hatayı kendilerinin düzeltmesi gerekirdi.

Açık kaynak daha çok paylaşılan bir sahiplik planı gibidir. Hepimiz aynı şeyi tekrar tekrar inşa etmek zorunda değiliz, bunun yerine katkıda bulunabiliriz, bu da hem daha az çaba hem de sonuç olarak daha iyi kaliteye yol açar. İşletmelerin yapabileceği en etkili şeylerden biri, mühendislik kaynaklarının birazını kullanmak ve iş için çok önemli olan projelere hata düzeltmelerine veya özelliklere katkıda bulunmaktır.

Kendi mühendislerinizi bir projeye dahil etmenin birçok faydası vardır. Bunu öğrenirler ve yeni özelliklere veya yeni bir sürüm çıktığında göz kulak olabilirler. En önemlisi, işletmenin bağımlı projenin sağlığı ve durumu hakkında bilgi sahibi olması ve onu sağlıklı tutan şeyin bir parçası olması, işletmenin bir bağımlılık sorunu yaşama riskini azaltmasıdır. Aiven dahil olmak üzere bir dizi kuruluş, kuruluş tarafından kullanılan projelere katkıda bulunmaya ve hatta bunları sürdürmeye adanmış personel ile bir OSPO’ya (açık kaynak program ofisi) sahiptir. Bu departmanlar genellikle şirketin açık kaynak ekosistemindeki genel varlığına katkıda bulunur ve diğer çalışanların açık kaynak ile etkileşim kurmasını sağlar.

Başka bir yaklaşım, açık kaynağı desteklemek için var olan kuruluşları desteklemektir. OpenSSF (Açık Kaynak Güvenlik Vakfı), açık kaynak projelerinin güvenliğini artırmak için çalışır ve bu projelere bağlı kuruluşlar tarafından finanse edilir. Ayrıca, işletmelerin kullandıkları yazılımın riskleri hakkında kendilerini eğitebilmeleri için mükemmel öğrenme kaynakları yayınlar. Benzer bir organizasyon daha gelgit kaldırmaBelirli temel gereksinimlerin karşılanmasını sağlamak için bakımcılarla ortak olan , yine kuruluşlar tarafından finanse edilmektedir. Tidelift ayrıca işletmelerin yazılım tedarik zincirlerini yönetmelerine ve bu alandaki en iyi uygulamaları benimsemelerine yardımcı olmak için araçlar ve eğitim sağlar.

Daha Güvenli Bir Yazılım Geleceğini Güvence Altına Almak

İşletmeler yazılıma bağımlıdır ve buna yaygın olarak kullanılan ve genellikle tescilli alternatiflerden daha güvenli olan açık kaynaklı yazılımlar dahildir.

Bu akıllıca bir harekettir, ancak daha da akıllıca bir hareket, yazılım tedarik zinciri ve bağımlılıkları hakkında net bir bilgiye sahip olmaktır. Bir problem ortaya çıktığında, sağlıklı projelere bağlı olarak ve yazılımınızın detaylarının mevcut olması her organizasyona yardımcı olur. Bunu her kuruluş yaptıysa, Log4Shell güvenlik açığı gibi olaylara sahip olma riski azalır.



siber-1