Açık Kaynak Yazılım Nedir? Her Açık Kaynak Güvenli midir?

Bilgisayarımıza yeni bir program yükleyeceğimizi düşünelim.

İnternette biraz araştırma yapıyoruz. Bir uygulamanın tanıtımında özellikle şu ifadenin öne çıkarıldığını görüyoruz:

“Açık kaynak kodlu, güvenli ve şeffaf.”

Bu açıklama doğal olarak güven veriyor.

Çünkü programın kodları gizlenmiyor. İsteyen geliştiriciler nasıl çalıştığını inceleyebiliyor. Güvenlik açıkları bulunabiliyor, hatalar düzeltilebiliyor ve yazılıma yeni özellikler eklenebiliyor.

Üstelik bazen bu programı geliştiren tek bir şirket bile bulunmuyor. Dünyanın farklı ülkelerinden insanlar ortak bir projeye katkıda bulunuyor.

Peki kaynak kodunun herkese açık olması, programın gerçekten güvenli olduğu anlamına mı geliyor?

Ya hiç kimse kodları yeterince dikkatli incelemiyorsa?

Ya uygulamanın kullandığı küçük bir yazılım bileşeninde ciddi bir güvenlik açığı varsa?

Daha da önemlisi, internetten indirdiğimiz programın gerçekten yayımlanan kaynak kodundan oluşturulduğunu nasıl anlayacağız?

Bu sorular, açık kaynak dünyasının en önemli konularından birine götürüyor bizi.

Açık kaynak yazılımlar modern teknolojinin vazgeçilmez parçalarından biri hâline geldi. İnternet sunucularından web sitelerine, geliştirme araçlarından profesyonel tasarım uygulamalarına kadar çok farklı alanlarda kullanılıyorlar.

Fakat yaygın olmaları, hatasız oldukları anlamına gelmiyor.

Aslında açık kaynak yazılımların en değerli özelliklerinden biri, hatalarının hiç bulunmaması değil; hataların bağımsız kişiler tarafından araştırılabilmesine, düzeltilmesine ve sonuçların paylaşılabilmesine imkân sağlamalarıdır.

Bu yazıda açık kaynak kavramını yalnızca tanımlamakla yetinmeyeceğiz.

Bir projenin arkasında kimlerin çalıştığını, güvenliğin nasıl sağlandığını, lisansların ne anlama geldiğini ve bir programı bilgisayarımıza yüklemeden önce hangi işaretlere dikkat etmemiz gerektiğini inceleyeceğiz.

Çünkü güvenilir bir yazılım seçmek için programlama bilmek zorunda değiliz.

Ancak güvenin hangi temeller üzerine kurulması gerektiğini bilmemiz gerekiyor.

Açık kaynak yazılım gerçekte ne anlama gelir?

Bilgisayarlarımızda kullandığımız programlar, geliştiriciler tarafından belirli programlama dilleriyle hazırlanır.

Bu programların insanlar tarafından okunabilir ve değiştirilebilir biçimde yazılmış talimatlarına kaynak kod denir.

Örneğin bir uygulama, kullanıcıdan alınan bilgiyi kontrol eden, bir dosyayı açan veya ekranda bir düğme gösteren kodlar içerebilir.

Bu kodlar, kullanılan teknolojiye bağlı olarak derlenebilir veya farklı çalışma süreçlerinden geçirilerek kullanıcıların çalıştırabileceği yazılımlara dönüştürülebilir.

Kapalı kaynak bir programda geliştirici, kaynak kodunu genellikle kamuya açmaz.

Kullanıcı uygulamayı çalıştırabilir ancak programın bütün iç yapısını doğrudan inceleme veya değiştirme hakkına sahip olmayabilir.

Açık kaynak yaklaşımında ise durum farklıdır.

Yazılımın kaynak kodu belirli koşullar altında erişilebilir olur. Kullanıcılar ve geliştiriciler lisansın tanıdığı haklar doğrultusunda kodu inceleyebilir, değiştirebilir ve paylaşabilir.

Burada özellikle dikkat edilmesi gereken kelime lisanstır.

Bir programın kodlarının internette görünmesi, tek başına onun açık kaynak yazılım olduğu anlamına gelmez.

Gerçek anlamda açık kaynak bir yazılımın, kullanım, değişiklik ve yeniden dağıtım haklarını belirleyen uygun bir lisansa sahip olması gerekir.

Open Source Initiative’nin Açık Kaynak Tanımı, açık kaynak lisanslarının karşılaması gereken ölçütleri açıklıyor.

Bunlar arasında kaynak koda erişim, yazılımı değiştirebilme, yeniden dağıtabilme ve belirli kişi veya çalışma alanlarına karşı ayrımcılık yapılmaması gibi ilkeler bulunuyor.

Dolayısıyla açık kaynak yalnızca bir dosyanın internete yüklenmesi değildir.

Yazılımın nasıl paylaşılabileceğini ve başkalarının geliştirme sürecine hangi haklarla katılabileceğini belirleyen bir modeldir.

GitHub’da yayımlanan her kod açık kaynak mıdır?

Bu konuda yaygın bir yanlış anlama var.

Bir geliştirici projesini GitHub üzerinde herkese açık bir depoda yayımladığında, insanlar kodları görebilir.

Ancak deponun herkese açık olması, o kodun sınırsız biçimde kullanılabileceği anlamına gelmez.

Projede açık bir lisans bulunmuyorsa normal telif hakkı kuralları geçerli olabilir.

GitHub’ın yazılım depolarının lisanslanmasıyla ilgili belgesi, herkese açık bir depoyla açık kaynak lisansına sahip bir proje arasındaki farkı özellikle açıklıyor.

Bu nedenle bir yazılımı kendi projemizde kullanmadan önce yalnızca kaynak kodunun bulunup bulunmadığına değil, hangi lisansla yayımlandığına da bakmalıyız.

Önceki Ücretsiz Yazılım Gerçekten Ücretsiz mi? yazımızda fiyatlandırma ve kullanım modellerini karşılaştırmıştık.

Burada ise farklı bir noktaya odaklanıyoruz: Bir programı kullanma, değiştirme ve dağıtma haklarımız ile o programın güvenilirliği birbirinden ayrı konulardır.

Açık kaynak projeler nasıl geliştiriliyor?

Açık kaynak yazılımların tek bir geliştirme yöntemi yoktur.

Bazı projeler büyük şirketler tarafından desteklenir. Bazıları vakıflar tarafından yönetilir. Bazılarında ise bir veya birkaç gönüllü geliştirici yıllarca çalışır.

Hatta küçük bir yardımcı program, tek bir kişinin boş zamanlarında geliştirdiği bir proje olabilir.

Bu çeşitlilik açık kaynak dünyasının önemli özelliklerinden biridir.

Bir projeyi anlamak için yazılımın kaynak kodunun yanında geliştirilme sürecine de bakmak gerekir.

Örneğin bir geliştirici uygulamada hata tespit edebilir.

Bu hatayı proje sayfasında bildirebilir. Başka bir geliştirici sorunu araştırabilir ve düzeltme önerebilir.

Projeyi yöneten yetkili kişiler önerilen değişikliği inceleyip kabul edebilir veya geri çevirebilir.

GitHub gibi platformlarda bu süreç çoğu zaman issue, commit ve pull request kavramları etrafında ilerler.

Issue, bir sorun veya geliştirme önerisinin takip edilmesini sağlar.

Commit, kaynak kodunda yapılan belirli bir değişikliğin kaydıdır.

Pull request ise önerilen değişikliğin projeye eklenmeden önce değerlendirilmesini sağlayan çalışma biçimlerinden biridir.

Ancak açık kaynak projelerde her değişiklik mutlaka birden fazla kişi tarafından inceleniyor diye bir kural yoktur.

Bir projede zorunlu kod incelemesi uygulanırken başka bir projede tek bakım sorumlusu bütün kararları alabilir.

Bu nedenle açık kaynak ifadesi bize kodların erişilebilirliği hakkında bilgi verir.

Projenin ne kadar iyi yönetildiğini ise ayrıca araştırmamız gerekir.

Bir projenin arkasında kaç kişi olduğu neden önemli?

Küçük bir açık kaynak projesinin oldukça başarılı olması mümkündür.

Hatta bazen tek bir geliştirici, belirli bir işi yapan son derece kaliteli ve güvenilir bir araç hazırlayabilir.

Sorun tek geliştiricinin bulunması değildir.

Sorun, bütün sorumluluğun tek kişiye bağlı olduğu bir projede devamlılığın nasıl sağlanacağıdır.

Geliştirici artık projeye zaman ayıramazsa ne olacaktır?

Bir güvenlik açığı tespit edilirse kim ilgilenecektir?

Yeni işletim sistemi sürümleri çıktığında gerekli değişiklikleri kim yapacaktır?

Bu soruların cevabı belirsizse kullanıcı açısından uzun vadeli bir risk oluşabilir.

Diğer taraftan çok sayıda geliştiricinin bulunduğu projelerde de koordinasyon ve güvenlik sorunları yaşanabilir.

Önemli olan yalnızca katkıda bulunan kişi sayısı değil, sorumlulukların nasıl dağıtıldığı ve projenin nasıl sürdürüldüğüdür.

Herkes kodu görebiliyorsa güvenlik açıkları neden ortaya çıkıyor?

Açık kaynak yazılımlar hakkında sık duyulan düşüncelerden biri şudur:

“Kaynak kodu herkese açıksa kötü amaçlı bir işlem zaten hemen fark edilir.”

Bu yaklaşımın önemli bir eksikliği bulunuyor.

Bir şeyi inceleme imkânının olmasıyla o şeyin gerçekten incelenmesi aynı değildir.

Büyük bir yazılım projesi binlerce dosya ve milyonlarca satır kod içerebilir.

Üstelik bütün bu kodların aynı kişi tarafından yazılması gerekmez.

Proje, farklı geliştiricilerin hazırladığı kütüphanelerden ve başka bileşenlerden yararlanabilir.

Kaynak kodunun açık olması, herkesin bu bileşenlerin tamamını düzenli biçimde denetlediğini garanti etmez.

Bazı güvenlik açıkları oldukça karmaşık koşullarda ortaya çıkar.

Örneğin normal kullanım sırasında sorunsuz çalışan bir işlev, beklenmedik bir veri gönderildiğinde farklı davranabilir.

Bir programın dosya okuma veya ağ iletişimiyle ilgili bölümünde yıllardır fark edilmeyen bir hata bulunabilir.

Hatta tecrübeli geliştiriciler tarafından hazırlanan kodlarda da güvenlik sorunları oluşabilir.

Bu durum yalnızca açık kaynak yazılımlara özgü değildir.

Kapalı kaynak programlarda da benzer hatalar bulunur.

İki yaklaşım arasındaki önemli farklardan biri, açık kaynak projelerde kodların bağımsız araştırmacılar tarafından incelenebilmesi ve uygun lisans koşullarıyla değiştirilebilmesidir.

Ancak bu imkânın gerçek bir güvenlik avantajına dönüşmesi için denetim, bakım ve düzeltme süreçlerinin işlemesi gerekir.

Açık kaynak güvenli olmayı garanti etmez; güvenliğin bağımsız biçimde değerlendirilmesi için önemli imkânlar sunar.

Gerçek bir olay: XZ Utils arka kapısı

Açık kaynak güvenliği açısından son yılların en öğretici olaylarından biri 2024 yılında ortaya çıkan XZ Utils vakasıydı.

XZ Utils, özellikle Linux sistemlerinde veri sıkıştırma ve açma işlemlerinde kullanılan yazılım araçlarını içerir.

Kullanıcıların büyük bölümü bu tür bileşenleri doğrudan açıp kullanmaz.

Ancak işletim sistemleri ve başka programlar arka planda bunlardan yararlanabilir.

Mart 2024’te XZ Utils’in belirli sürümlerinin dağıtım paketlerinde kötü amaçlı kod bulunduğu ortaya çıkarıldı.

Sorun CVE-2024-3094 numarasıyla kaydedildi.

Red Hat’in resmî güvenlik açıklamasına göre kötü amaçlı kod, XZ Utils’in 5.6.0 ve 5.6.1 sürümlerine ait belirli dağıtım paketlerinde bulunuyordu.

Bu değişiklik, uygun koşullarda kullanılan liblzma bileşeni üzerinden ciddi güvenlik riskleri doğurabilecek nitelikteydi.

Ancak olayın bütün Linux sistemlerini aynı şekilde etkilediğini düşünmek yanlış olur.

Etkilenen paketler ve kurulum koşulları dağıtıma ve sürüme göre değişiyordu.

Buradaki önemli nokta, saldırının sıradan bir yazılım hatasından farklı olmasıydı.

Amaç, güvenilen bir yazılımın geliştirme veya dağıtım sürecine kötü amaçlı bileşen yerleştirmekti.

Open Source Security Foundation ve OpenJS Foundation, olayın ardından yayımladıkları ortak güvenlik uyarısında açık kaynak projelerinin yönetimini ele geçirmeye yönelik sosyal mühendislik girişimlerine dikkat çekti.

Bu olaydan çıkarılacak ders, açık kaynak projelerin güvenilemez olduğu değildir.

Daha önemli sonuç şudur:

Kaynak kodunun açık olması kadar, kodu kimin değiştirebildiği ve yazılımın kullanıcıya nasıl ulaştırıldığı da güvenlik açısından belirleyicidir.

Bir proje çok kaliteli kodlara sahip olabilir.

Ancak geliştirme hesabı ele geçirilirse, değişiklikler yeterince incelenmezse veya dağıtım süreci manipüle edilirse kullanıcıya ulaşan yazılım riskli hâle gelebilir.

XZ Utils olayı, açık kaynak güvenliğinin yalnızca kod incelemesinden ibaret olmadığını gösterdi.

Log4j olayı bize yazılım bağımlılıkları hakkında ne öğretti?

Bir başka önemli örnek 2021 yılında ortaya çıkan Log4Shell güvenlik açığıdır.

Log4j, Java uygulamalarında olayların ve çalışma kayıtlarının tutulması için kullanılan açık kaynak bir yazılım bileşenidir.

Birçok kullanıcı Log4j adını daha önce hiç duymamış olabilir.

Ancak kullandığı web hizmetlerinden biri, arka planda Log4j kullanan bir uygulamaya dayanıyor olabilir.

2021 yılında Log4j’nin belirli sürümlerinde CVE-2021-44228 olarak bilinen ciddi bir güvenlik açığı ortaya çıktı.

Bu açık, etkilenen koşullarda uzaktan kod çalıştırmaya imkân verebilen son derece önemli bir sorundu.

Apache’nin resmî Log4j güvenlik duyuruları, etkilenen bileşenleri ve sürümleri ayrıntılı olarak açıklıyor.

Ancak Log4j kullanan bütün uygulamaların her koşulda aynı ölçüde savunmasız olduğunu düşünmek doğru değildir.

Hangi bileşenin ve sürümün kullanıldığı, uygulamanın yapılandırması ve erişim koşulları önemlidir.

Olayın öğrettiği asıl ders farklıdır.

Bir programı kullanırken onun doğrudan görmediğimiz yazılım bileşenlerine de güvenmiş oluruz.

Örneğin bir e-ticaret uygulamasının geliştiricisi sipariş yönetimi, ödeme işlemleri ve kullanıcı arayüzü üzerinde çalışıyor olabilir.

Fakat uygulama ayrıca kayıt tutma, ağ iletişimi veya dosya işleme gibi görevler için başka yazılım kütüphanelerinden yararlanabilir.

Bu bileşenlerden birinde ortaya çıkan kritik açık, onu kullanan diğer yazılımları da etkileyebilir.

Bu nedenle modern yazılım güvenliğinde yalnızca ana programın kodunu incelemek yeterli değildir.

Programın hangi bileşenlerden oluştuğunu ve bunların güvenlik durumunu da bilmek gerekir.

Yazılım tedarik zinciri neden bu kadar önemli?

Bir mobilyanın üretildiğini düşünelim.

Ahşabı bir işletme sağlıyor. Metal parçalar başka bir firmadan geliyor. Boya, menteşe ve bağlantı malzemeleri farklı üreticiler tarafından hazırlanıyor.

Ortaya çıkan ürün tek bir markayla satılıyor olabilir.

Ancak kalitesi, tedarik edilen bütün parçalarla ilişkilidir.

Modern yazılım geliştirme de buna benzer bir yapıya sahiptir.

Bir uygulamanın geliştiricileri bütün kodları sıfırdan yazmak yerine daha önce hazırlanmış bileşenleri kullanabilir.

Örneğin uygulamada kullanıcı girişini yöneten, veri tabanıyla iletişim kuran, resim işleyen veya bildirim gönderen hazır kütüphaneler bulunabilir.

Bu yaklaşım geliştirme süresini azaltır ve daha önce denenmiş çözümlerden yararlanılmasını sağlar.

Fakat her bağımlılık yeni bir bakım ve güvenlik sorumluluğu da oluşturur.

Üstelik kullanılan bir kütüphane başka kütüphanelere bağımlı olabilir.

Buna dolaylı bağımlılık denir.

Dolayısıyla bir programda doğrudan birkaç kütüphane kullandığımızı düşünsek bile gerçekte daha geniş bir yazılım bileşenleri ağına bağlı olabiliriz.

OWASP’ın açık kaynak yazılım riskleri çalışması, bilinen güvenlik açıklarını, meşru paketlerin ele geçirilmesini ve yazılım bağımlılıklarına ilişkin farklı riskleri ele alıyor.

Burada sıradan kullanıcı açısından önemli olan şu:

Bir programın güvenilirliği yalnızca ana geliştiricinin iyi niyetine veya becerisine bağlı değildir.

Programın kullandığı bileşenler, güncelleme mekanizması ve dağıtım yöntemi de güvenilir olmalıdır.

Bu yüzden yazılım dünyasında SBOM adı verilen, yani yazılım malzeme listesi olarak açıklanabilecek envanter yaklaşımı giderek önem kazanıyor.

SBOM, bir yazılımın içinde hangi bileşenlerin bulunduğunu belirlemeye yardımcı olur.

Böylece örneğin belirli bir kütüphanede güvenlik açığı ortaya çıktığında o bileşeni kullanan uygulamalar daha kolay araştırılabilir.

Ancak bir bileşenin listede bulunması, mutlaka istismar edilebilir olduğu anlamına gelmez.

Yazılımın hangi sürümü kullandığı, etkilenen özelliğin gerçekten çalışıp çalışmadığı ve sistemin yapılandırması ayrıca değerlendirilmelidir.

Bu ayrım, güvenlik uyarılarıyla karşılaşan geliştiriciler için oldukça önemlidir.

Açık kaynak lisansları neden birbirinden farklı?

Açık kaynak yazılımların güvenliği kadar, kullanım koşulları da önemlidir.

Bir proje üzerinde değişiklik yapmak veya onu kendi yazılımımıza eklemek istediğimizde hangi haklara sahip olduğumuzu lisans belirler.

Burada sık karşılaşılan lisanslar arasında MIT, Apache License 2.0 ve GNU GPL bulunur.

Bunların tamamı açık kaynak dünyasında kullanılsa da koşulları aynı değildir.

MIT ve Apache lisansları

MIT, oldukça esnek koşullara sahip açık kaynak lisanslarından biridir.

Lisans ve telif hakkı bildirimlerinin korunması gibi yükümlülüklerle yazılımın kullanılmasına, değiştirilmesine ve yeniden dağıtılmasına geniş izinler verir.

Apache License 2.0 da esnek bir açık kaynak lisansıdır.

Ancak patent hakları, değişiklik bildirimleri ve belirli lisans koşulları açısından MIT’den farklı hükümler içerir.

Bu nedenle bir projenin hangi lisansla yayımlandığını öğrenmek yalnızca ticari kullanım açısından değil, başka yazılımlarla birleştirme ve yeniden dağıtım açısından da önemlidir.

Lisansların temel izin ve koşulları Choose a License üzerinden karşılaştırılabilir.

GPL ve copyleft yaklaşımı

GNU GPL ise copyleft adı verilen bir yaklaşımla ilişkilidir.

Bu yaklaşımın amaçlarından biri, belirli türev çalışmalar yeniden dağıtıldığında kullanıcıların kaynak kod ve lisans haklarının korunmasını sağlamaktır.

Ancak bu ifadeyi “GPL kullanan herkes kendi bütün kodlarını internete koymak zorundadır” şeklinde yorumlamak yanlış olur.

Yükümlülükler lisansın sürümüne, yazılımların nasıl birleştirildiğine ve ortaya çıkan çalışmanın nasıl dağıtıldığına bağlıdır.

Örneğin GPL lisanslı bir programı bilgisayarımızda kişisel işlerimiz için kullanmak ile onu değiştirip başkalarına dağıtmak aynı hukuki durum değildir.

Ayrıca gerçek bir açık kaynak lisansının ticari kullanımı bütünüyle yasaklaması, açık kaynak tanımının ilkeleriyle bağdaşmaz.

Dolayısıyla açık kaynak yazılım ticari amaçlarla da kullanılabilir.

Fakat kaynak kodu açıklama, lisans bildirimlerini koruma veya değişiklikleri belirtme gibi yükümlülükler lisansa göre farklılık gösterebilir.

Burada hukuki bir değerlendirme gerektiğinde yalnızca kısa lisans özetlerine dayanmak yerine ilgili lisansın tam metni ve gerektiğinde uzman görüşü esas alınmalıdır.

Açık kaynak lisansı güvenlik sertifikası değildir; yazılım üzerinde sahip olduğumuz hak ve yükümlülükleri belirler.

Başarılı açık kaynak projeler bize ne gösteriyor?

Açık kaynak denildiğinde yalnızca programcıların kullandığı karmaşık araçları düşünmemeliyiz.

Günlük hayatımızda oldukça tanıdık örnekler bulunuyor.

WordPress: Açık kaynakla büyüyen bir yayın sistemi

WordPress, açık kaynak yazılımların geniş kullanım alanını gösteren iyi örneklerden biridir.

Kişisel bloglardan kurumsal web sitelerine kadar farklı amaçlarla kullanılabilir.

WordPress yazılımı GPLv2 veya sonraki sürümleri kapsamında yayımlanır.

Bu bilgi WordPress’in resmî lisans sayfasında açıklanıyor.

WordPress’in açık kaynak olması, geliştiricilerin sisteme katkıda bulunabilmesine ve farklı kullanım senaryoları için eklentiler veya temalar geliştirebilmesine olanak sağlar.

Ancak burada önemli bir ayrım bulunuyor.

WordPress’in kendisinin açık kaynak olması, kullanılan her tema ve eklentinin güvenilir olduğu anlamına gelmez.

Örneğin güncellenmeyen, hatalı hazırlanmış veya ele geçirilmiş bir eklenti web sitesi için risk oluşturabilir.

Bu nedenle bir WordPress sitesinin güvenliği yalnızca çekirdek yazılımın güvenliğine bağlı değildir.

Eklentiler, tema, sunucu yapılandırması ve güncellemeler de değerlendirilmelidir.

Bu tür bir problemle karşılaşıldığında WordPress Eklentisi Siteyi Bozduysa Nasıl Geri Dönülür? rehberimiz, sorunu kontrollü biçimde incelemeye yardımcı olabilir.

Blender: Profesyonel araçların da açık kaynak olabileceğinin kanıtı

Bir başka örnek Blender’dır.

Blender, üç boyutlu modelleme, animasyon ve görsel üretim gibi alanlarda kullanılan açık kaynak bir uygulamadır.

Proje, Blender Foundation tarafından koordine edilir ve katkılarla desteklenir.

Blender’ın resmî açıklamasında yazılımın ücretsiz ve açık kaynak olduğu, topluluk katkısıyla geliştirildiği belirtiliyor.

Blender’ın varlığı önemli bir düşünceyi değiştiriyor:

Profesyonel düzeyde bir yazılım geliştirmek için kaynak kodunun mutlaka kapalı tutulması gerekmiyor.

Ancak büyük ve bilinen bir proje olması da Blender’ın her sürümünde hiç güvenlik veya kararlılık sorunu bulunmayacağı anlamına gelmez.

Her yazılım gibi güncellemeler ve kullanım ortamı önemini korur.

Bu örneklerde ortak olan şey, kaynak kodunun açık olması değil yalnızca.

Aynı zamanda projeleri sürdüren geliştirici topluluklarının ve bakım süreçlerinin bulunmasıdır.

Güvenilir bir açık kaynak projesini nasıl tanıyabiliriz?

Artık günlük hayatta kullanabileceğimiz daha somut bir değerlendirmeye geçebiliriz.

Bir yazılımın GitHub’da bulunması veya açık kaynak etiketi taşıması tek başına yeterli değilse neye bakacağız?

Burada önemli olan bütün kaynak kodunu okumaya çalışmak değildir.

Çoğu kullanıcı için bu zaten gerçekçi olmaz.

Bunun yerine projenin geliştirilme ve dağıtılma biçimi hakkında bazı göstergelerden yararlanabiliriz.

Open Source Security Foundation’ın Açık Kaynak Yazılımları Değerlendirme Rehberi, bu konuda kapsamlı bir kontrol yaklaşımı sunuyor.

Bu önerileri günlük kullanıma uyarladığımızda birkaç önemli soru ortaya çıkıyor.

Proje gerçekten aktif mi?

Yazılımın son sürümünün ne zaman yayımlandığına bakabiliriz.

Ancak yalnızca tarihe göre hüküm vermemeliyiz.

Çok basit bir programın sık sık güncellenmesi gerekmeyebilir.

Buna karşılık internete bağlanan, kullanıcı verileri işleyen veya karmaşık bağımlılıklar kullanan bir uygulamanın yıllardır hiçbir bakım almaması daha ciddi bir risk oluşturabilir.

Bu nedenle son güncelleme tarihini projenin amacıyla birlikte değerlendirmek gerekir.

Önemli olan sürekli yeni özellik eklenmesi değil, gerekli olduğunda bakım yapılabilmesidir.

Güvenlik sorunları nasıl ele alınıyor?

Bir projede geçmişte güvenlik açığı bulunmuş olması otomatik olarak kötü bir işaret değildir.

Hatta aktif kullanılan ve bağımsız araştırmacılar tarafından incelenen yazılımlarda daha fazla güvenlik raporu görmek mümkündür.

Daha anlamlı soru şudur:

Bir güvenlik açığı bildirildiğinde geliştiriciler nasıl tepki veriyor?

Sorunu araştırıyorlar mı?

Düzeltme yayımlıyorlar mı?

Kullanıcıları bilgilendiriyorlar mı?

Gerekli sürüm güncellemelerini açıklıyorlar mı?

Güvenilirlik değerlendirmesinde bu süreçler, geçmişteki toplam hata sayısından daha açıklayıcı olabilir.

Çünkü sıfır bildirilen güvenlik açığı, mutlaka sıfır güvenlik sorunu bulunduğunu göstermez.

Kod değişiklikleri kontrol ediliyor mu?

Projede yapılan değişikliklerin başka kişiler tarafından incelenmesi güvenliği artırmaya yardımcı olabilir.

Özellikle önemli yazılım bileşenlerinde otomatik testler, kod inceleme kuralları ve geliştirme hesaplarının korunması değer taşır.

Ancak bir projenin bütün güvenlik süreçlerini dışarıdan eksiksiz değerlendirmek her zaman mümkün değildir.

Bu noktada geliştiriciler için hazırlanmış bazı araçlar yardımcı olabilir.

Örneğin OpenSSF Scorecard, açık kaynak projelerinin belirli güvenlik uygulamalarını otomatik kontrollerle değerlendirir.

Fakat böyle bir puanı kesin güvenlik garantisi olarak yorumlamamak gerekir.

Yüksek puan alan bir projede de henüz keşfedilmemiş bir güvenlik açığı bulunabilir.

Düşük puan ise her zaman kötü amaçlı kod bulunduğunu göstermez.

Puanlar, karar vermek için kullanılan göstergelerden biridir.

Projenin belgeleri anlaşılır mı?

İyi hazırlanmış bir projenin yalnızca kaynak koduna değil, kullanım ve kurulum belgelerine de önem vermesi beklenir.

Geliştirici hangi işletim sistemlerinin desteklendiğini, programın nasıl kurulacağını, bilinen sınırlamaları ve güvenlik güncellemelerinin nereden alınacağını açıklayabilir.

Elbette çok küçük bir projede kapsamlı belgeler bulunmayabilir.

Ancak temel kullanım ve güvenlik bilgilerinin eksikliği kullanıcı açısından belirsizlik yaratır.

Bu nedenle proje belgeleri, güvenilirlik değerlendirmesinin göz ardı edilmemesi gereken parçalarındandır.

Kaynak kodu açık ama indirdiğimiz program aynı mı?

Açık kaynak yazılımlarla ilgili çoğu kullanıcının düşünmediği bir ayrıntı var.

Bir projenin kaynak kodunu GitHub üzerinde incelediğimizi düşünelim.

Kodların açık ve anlaşılır olduğunu gördük.

Ardından internette bulunan bir bağlantıdan programın kurulum dosyasını indiriyoruz.

Peki indirdiğimiz dosyanın gerçekten incelediğimiz kaynak kodundan üretildiğini nereden biliyoruz?

Kaynak kodu ile çalıştırılabilir dosya arasında derleme ve paketleme süreçleri bulunabilir.

Bu süreçler sırasında ek dosyalar kullanılır, farklı bileşenler bir araya getirilir ve kullanıcıya sunulacak paket oluşturulur.

Dolayısıyla kaynak kodunun açık olması, internet üzerindeki her indirme dosyasının güvenilir olduğu anlamına gelmez.

Saldırganlar popüler açık kaynak yazılımların adlarını taklit eden sahte indirme siteleri hazırlayabilir.

Bazı durumlarda gerçek projeyle ilgisi bulunmayan kurulum dosyaları, arama sonuçları veya reklamlar üzerinden dağıtılabilir.

Bu nedenle açık kaynak programı indirirken de aynı temel güvenlik yaklaşımını uygulamalıyız:

Öncelikle projenin resmî internet sitesini veya geliştiricinin doğrulanmış dağıtım kanalını bulmalıyız.

Proje dosyaların bütünlüğünü doğrulamak için hash veya dijital imza bilgileri sunuyorsa bunlardan yararlanılabilir.

Fakat hash değerinin yalnızca dosyayla birlikte aynı güvenilmeyen sayfadan alınması, tek başına dosyanın gerçek geliştiriciden geldiğini kanıtlamaz.

Doğrulama bilgisinin de güvenilir bir kaynaktan elde edilmesi gerekir.

Konu yalnızca dosyanın değiştirilip değiştirilmediği değil, kimin hazırladığına güvenebileceğimizdir.

Bir indirme bağlantısının gerçek olup olmadığını değerlendirmek için Bir Linke Tıklamadan Önce Güvenli Olduğunu Nasıl Anlarsınız? yazımızdaki temel kontrollerden yararlanılabilir.

Bu yaklaşım açık ve kapalı kaynak yazılımların ikisi için de geçerlidir.

Açık kaynak yazılımı kullanan geliştiricinin sorumluluğu nedir?

Şimdi konuyu biraz daha ileri taşıyalım.

Bir geliştiricinin mobil uygulama hazırladığını düşünelim.

Uygulamada kullanıcı hesapları, bildirimler ve veri tabanı bağlantısı bulunuyor.

Geliştirici bütün bu işlevleri sıfırdan hazırlamak yerine çeşitli açık kaynak kütüphanelerden yararlanıyor.

Bu yöntem oldukça yaygındır.

Fakat geliştiricinin işi yalnızca kütüphaneyi projeye eklemekle bitmez.

Kullanılan sürümün desteklenip desteklenmediği, bilinen güvenlik açıkları, başka kütüphanelerle uyumluluğu ve lisans koşulları takip edilmelidir.

Bir uygulamaya eklenen bağımlılık, ileride yeni bir güvenlik açığı nedeniyle güncelleme gerektirebilir.

Güncelleme yapıldığında uygulamanın başka bir bölümü beklenmedik biçimde etkilenebilir.

Bu yüzden yazılım geliştirirken yalnızca yeni özellikleri test etmek değil, kullanılan bileşenleri de takip etmek gerekir.

OWASP Dependency-Check gibi araçlar belirli bağımlılıkların bilinen güvenlik açıklarıyla ilişkisini araştırmaya yardımcı olur.

GitHub’ın Dependabot hizmeti de desteklenen projelerde güvenlik açığı bilinen bağımlılıklar hakkında uyarılar sağlayabilir.

Ancak bu sistemler bütün güvenlik sorunlarını önceden tespit edemez.

Örneğin henüz keşfedilmemiş bir hata, genel veri tabanlarına eklenmemiş bir güvenlik açığı veya işlevin yanlış kullanılması nedeniyle oluşan bir sorun gözden kaçabilir.

Bu yüzden otomatik güvenlik kontrolleri, geliştiricinin değerlendirme sorumluluğunun yerini tamamen alamaz.

Yazılım sistemlerinin başka hizmetlerle nasıl iletişim kurduğunu öğrenmek isteyenler için API Nedir? Uygulamalar Birbiriyle Nasıl Konuşur? makalemiz bu yapının başka bir yönünü açıklıyor.

Bir API’nin güvenliği kadar onu kullanan uygulamanın bağımlılıkları da önemlidir.

Hazır yazılım kullanmak geliştirmeyi hızlandırabilir; fakat bakım ve güvenlik sorumluluğunu ortadan kaldırmaz.

Sıradan kullanıcı açık kaynak yazılımı güvenle kullanabilir mi?

Buraya kadar farklı güvenlik risklerini ele aldık.

Fakat bütün bunlar açık kaynak programlardan uzak durmamız gerektiği anlamına gelmiyor.

Tam tersine, doğru seçilmiş ve düzenli olarak bakımı yapılan açık kaynak yazılımlar günlük kullanım için son derece iyi seçenekler olabilir.

Buradaki temel mesele bir programın açık kaynak olup olmamasından çok, ihtiyacımıza uygun ve güvenilir biçimde yönetilip yönetilmediğidir.

Örneğin yalnızca fotoğraf düzenlemek isteyen kullanıcıyla bir şirketin bütün müşteri verilerini yönetecek sistem araması aynı risk düzeyine sahip değildir.

Basit bir masaüstü aracında temel güvenilirlik ve resmî indirme kaynağı yeterli değerlendirme başlangıcı olabilir.

Ancak kurumsal bilgiler işleyen veya internete açık çalışan bir sistemde güvenlik incelemeleri, bakım planı, yedekleme ve erişim yetkileri çok daha önemli hâle gelir.

Açık kaynak yazılım seçiminde şu pratik yaklaşım yararlı olabilir:

Bu kontrolleri her program için aynı derinlikte yapmak gerekmiyor.

Ancak önemli bilgilerimizi yönetecek bir uygulamada yalnızca kullanıcı puanlarına veya popülerliğine güvenmek yeterli olmayabilir.

Bir başka noktayı da unutmamak gerekiyor.

Açık kaynak olması, uygulamanın kullanıcı verilerini mutlaka yerel cihazda tuttuğu anlamına gelmez.

Açık kaynak bir program da bulut hizmeti kullanabilir, kullanıcı hesabı gerektirebilir veya belirli verileri sunucuya aktarabilir.

Bu nedenle kaynak kodu lisansı ile gizlilik koşullarını ayrı ayrı değerlendirmeliyiz.

Güvenli kullanım, doğru yazılımı seçmekle başlar ama güncelleme, izin yönetimi ve yedekleme ile devam eder.

Açık kaynak mı, kapalı kaynak mı daha güvenli?

Bu soruya bütün durumlar için geçerli tek bir cevap vermek doğru değildir.

Açık kaynak yaklaşımı kodların bağımsız şekilde incelenebilmesini sağlar.

Bu önemli bir avantajdır.

Bir güvenlik araştırmacısı belirli bir işlevin nasıl çalıştığını doğrudan inceleyebilir. Sorun bulduğunda projeye bildirebilir ve uygun koşullarda düzeltme önerebilir.

Kapalı kaynak bir yazılımda ise kaynak kodu genellikle kamuya açık değildir.

Ancak bu, yazılımın mutlaka daha az test edildiği anlamına gelmez.

Büyük şirketler kendi ekipleriyle güvenlik incelemeleri yapabilir, bağımsız uzmanlara denetim yaptırabilir veya güvenlik araştırmacılarından bildirim alabilir.

Diğer taraftan açık kaynak projeler de profesyonel güvenlik ekipleri tarafından geliştirilebilir.

Dolayısıyla tartışmayı yalnızca kaynak kodunun görünür olup olmamasına indirgemek eksik bir değerlendirmedir.

Daha anlamlı olan, yazılımın nasıl geliştirildiği ve yönetildiğidir.

Güvenlik açıklarına ne kadar hızlı müdahale ediliyor?

Güncellemeler güvenilir biçimde dağıtılıyor mu?

Kod değişiklikleri kontrol ediliyor mu?

Projenin destek ve bakım politikası açık mı?

Kullanıcı verileri uygun biçimde korunuyor mu?

Bu soruların cevapları, açık veya kapalı kaynak ayrımından daha belirleyici olabilir.

Üstelik hiçbir yazılım için mutlak güvenlik garantisi vermek mümkün değildir.

Bugün güvenli kabul edilen bir programda yarın yeni bir güvenlik açığı keşfedilebilir.

Önemli olan riskleri tamamen yok saymak yerine onları belirleyebilmek ve yönetebilmektir.

Kısaca

Açık kaynak yazılım, kaynak koduna erişimi ve belirli haklarla kullanım, değiştirme ve yeniden dağıtımı mümkün kılan lisanslar altında yayımlanan yazılımdır.

Ancak kaynak kodunun açık olması, yazılımın otomatik olarak güvenli olduğu anlamına gelmez.

Kodları herkesin inceleyebilmesi değerli bir avantajdır. Fakat inceleme imkânının bulunmasıyla etkin güvenlik denetiminin yapılması aynı şey değildir.

XZ Utils olayı, geliştirme ve dağıtım süreçlerinin kötü amaçlı müdahalelere açık olabileceğini gösterdi.

Log4j güvenlik açığı ise küçük bir yazılım bileşeninin çok sayıda uygulama açısından önemli sonuçlar doğurabileceğini hatırlattı.

Bu nedenle modern yazılım güvenliği yalnızca ana programın koduyla ilgili değildir.

Projeyi yöneten kişiler, kullanılan kütüphaneler, güvenlik güncellemeleri, yazılım lisansları ve indirme kaynakları birlikte değerlendirilmelidir.

Açık kaynak projelerin güçlü yanlarından biri, sorunların yalnızca tek bir şirketin kontrolünde kalmadan araştırılabilmesine ve çözülebilmesine imkân vermesidir.

Ancak bu avantajın karşılığını vermesi için projelerin iyi yönetilmesi, güncellenmesi ve güvenlik çalışmalarının gerçekten yapılması gerekir.

Kullanıcı açısından önemli olan, açık kaynak ifadesini kesin bir güvenlik belgesi olarak görmemektir.

Güvenilir bir program seçerken projenin gerçek kaynağını, geliştirme geçmişini, güvenlik duyurularını ve kullanım koşullarını incelemek gerekir.

Aynı şekilde kapalı kaynak programların da yalnızca kaynak kodları gizli olduğu için güvensiz kabul edilmesi doğru değildir.

Sonuç olarak bir yazılımın güvenilirliği tek bir etikete indirgenemez.

Açık kaynak, güvenliği kendiliğinden sağlayan bir garanti değildir. Güvenliğin araştırılmasını, sorgulanmasını ve iyileştirilmesini mümkün kılan önemli bir yaklaşımdır.

Ve dijital dünyada güvenin en sağlam temeli, yalnızca bir programın nasıl tanıtıldığı değil; nasıl geliştirildiği, nasıl korunduğu ve ortaya çıkan sorunlara nasıl karşılık verildiğidir.