Ne Kadar Az Bağımlılık, O Kadar Güvenli: Obsidian'ın Tedarik Zinciri Saldırısı Riskini Azaltma Yaklaşımı

 (obsidian.md)
11 puan yazan GN⁺ 2025-09-20 | 1 yorum | WhatsApp'ta paylaş
  • Tedarik zinciri saldırıları, açık kaynak koda kötü niyetli güncellemelerin sızmasıyla gerçekleşir; Obsidian ise bunu en aza indirmek için harici bağımlılıkları doğrudan azaltma stratejisi kullanır
  • Uygulama işlevlerinin büyük bölümünü kendisi geliştirir; gerektiğinde fork'lanmış kodu kendi kod tabanına dahil ederek yönetir
  • Gerekli büyük kütüphaneler (pdf.js, Mermaid, MathJax vb.) için sürüm sabitleme ile güvenlik sağlanır ve güncellemeler yalnızca güvenlik yamaları olduğunda dikkatle yapılır
  • Tüm bağımlılıklar lockfile ile sabitlenir ve postinstall script'leri çalıştırılmaz; böylece kurulum sırasında rastgele kod çalıştırılması engellenir
  • Obsidian, bu temkinli güncelleme süreci ve zaman gecikmesi stratejisi sayesinde potansiyel tehditlere topluluk tarafından tespit edilmeden önce karşılık verebilir

Tedarik zinciri saldırısı nedir

  • Tedarik zinciri saldırısı, açık kaynak ekosisteminde kötü niyetli güncellemelerin dağıtılan koda gizlenmesi yöntemidir
  • Birçok uygulama açık kaynak kod kullandığı için, tek bir kötü niyetli güncelleme zincirleme biçimde çok sayıda uygulamayı etkileyebilir
  • Obsidian, bağımlılıkları en aza indirme stratejisiyle bu saldırı yüzeyini azaltır ve uygulamayı daha güvenli olacak şekilde tasarlar

Bağımlılıkları en aza indirme stratejisi: Less is Safer

  • Obsidian, aynı kategorideki diğer uygulamalarla karşılaştırıldığında çok az sayıda harici kütüphaneye bağımlıdır
  • Ana işlevler (ör. Bases, Canvas), harici kütüphane eklemek yerine şirket içinde geliştirilir
    • Bu sayede çalıştırılan kod üzerinde tam kontrol sağlamak mümkün olur
  • Küçük ölçekli yardımcı fonksiyonlar neredeyse her zaman geliştirme ekibi tarafından doğrudan yazılır
  • Orta ölçekli modüller, lisans izin veriyorsa fork'lanarak kod tabanına dahil edilir
  • Büyük kütüphaneler (pdf.js, Mermaid, MathJax vb.) için doğrulanmış sürümler sabitlenerek kullanılır ve yalnızca önemli güvenlik sorunları tespit edildiğinde asgari düzeyde yükseltme yapılır
  • Tüm harici değişiklikler ayrıntılı biçimde incelenir ve kapsamlı test süreçleri uygulanır
  • Bu yaklaşım, alt bağımlılıkların sayısını da en aza indirerek kötü niyetli kod girişinin ilk aşamadaki riskini yapısal olarak azaltır

Gerçek uygulamaya dahil edilen unsurlar

  • Kullanıcının gerçekten çalıştırdığı uygulamada Electron, CodeMirror, moment.js gibi yalnızca çok az sayıda paket bulunur
  • Diğer geliştirme araçları yalnızca uygulama derleme sürecinde kullanılır ve son kullanıcıya teslim edilmez

Sürüm sabitleme ve lockfile yönetimi

  • Tüm harici bağımlılıklar katı sürüm sabitleme (pin) ve lockfile commit etme ile yönetilir
  • Bu sayede kurulum her zaman yeniden üretilebilir olur ve değişiklik geçmişini izlemek kolaylaşır
  • postinstall script'lerini çalıştırmama politikasıyla, kurulum sırasında rastgele kod çalıştırma olasılığı en baştan engellenir

Yavaş ve temkinli güncelleme süreci

  • Bağımlılık yükseltmesi gerektiğinde, aşağıdaki gibi sistematik bir inceleme süreci uygulanır
    • Değişiklik kaydı (changelog) satır satır dikkatle incelenir
    • Yeni sürümde eklenen alt bağımlılıklar kontrol edilir
    • Değişim büyükse veya risk unsuru varsa upstream kaynak ile diff doğrudan incelenir
    • Kritik yollar ve platformlar için otomatik/manüel testler yapılır
    • Yalnızca tüm bu adımlar geçildikten sonra lockfile commit edilir
  • Bağımlılıkların çoğunda sık değişiklik gerekmediği için, güncelleme sıklığı da düşüktür
  • Yeni harici kod eklemek, mevcut bir bağımlılığı ilk kez benimsemekle aynı düzeyde incelenir ve yönetilir

Kararlılık için "zamansal tampon": Time is a buffer

  • Çeşitli yükseltmeler hemen dağıtılmaz, belirli bir süre geciktirilir
  • Bu süre içinde açık kaynak topluluğu ve güvenlik araştırmacıları kötü niyetli sürümleri tespit edebilir; bu da önleyici bir pencere işlevi görür
  • Gerçek dağıtım anına gelindiğinde sorunların daha önce fark edilmiş olma olasılığı yükselir; bu da riski en aza indirmede etkilidir

Sonuç

  • Tedarik zinciri saldırısı riskini tek bir güvenlik önlemiyle tamamen ortadan kaldırmak mümkün değildir
  • Ancak Obsidian, bağımlılık minimizasyonu, sığ bağımlılık grafiği, sürüm sabitleme, postinstall yasağı ve inceleme odaklı yavaş güncellemeleri birlikte uygulayarak riski büyük ölçüde azaltır
  • Bu süreçler sayesinde, kod kullanıcılara ulaşmadan önce riskleri tespit etmek için önemli ölçüde zaman kazanılabilir
  • Obsidian'ın genel güvenlik yaklaşımı ve geçmiş güvenlik denetimleri resmi security page üzerinden incelenebilir

İlgili okumalar

1 yorum

 
GN⁺ 2025-09-20
Hacker News görüşleri

  • Birçok yorum, çoğu kullanıcının Obsidian’da üçüncü taraf topluluk eklentileri kullandığını göz ardı ediyor; gerçekte Obsidian’ın eklenti güvenlik modeli oldukça zayıf. Eklentiler kasadaki tüm dosyalara erişim yetkisine sahip. Obsidian doğrudan daha fazla özelliği kendi içine eklemeye çalışsaydı güvenlik riski azalırdı. Ya da tarayıcı eklentilerinde olduğu gibi, eklentinin kullandığı izinlerin açıkça belirtilip yetkisiz erişimlerin engellendiği bir yapı da mümkün. Bunların hepsi, “üçüncü taraf bağımlılığı daha az” mantığından çok daha gerçek bir kullanıcı güvenliği sağlar.

    • Eskiden yazılım dünyasındaki bazı kişiler, video oyunu tasarımındaki fikirlerin diğer genel amaçlı yazılımlara nasıl aktarıldığından söz ederdi ama artık bunu pek duymuyorum. Blizzard gibi eski oyun şirketlerindeki kilit isimler, World of Warcraft eklenti sisteminin ilk 10 yılında nasıl çalıştığını, ne tür sorunlar yaşandığını ve güvenliğin nasıl güçlendirildiğini ayrıntılı anlatan bir kitap yazsa tüm yazılım ekosistemi için çok faydalı olurdu. Birçok projenin eklenti sistemi özensizlikle acemiliğin karışımı gibi.

    • Obsidian eklentileri yalnızca kasadaki dosyalara değil, bilgisayardaki tüm dosyalara da erişebilir. Bunu daha önce Discord’da gündeme getirmiştim ama görmezden gelindi.

    • Bunu Arch Linux’a benzetiyorum. AUR’dan yazılımı doğrudan yönetirken mühendisler bile güvenliği zor ele alıyor; sıradan kullanıcıların güvenlikten sorumlu olmasını beklemek gerçekçi değil.

    • Yakında bir Obsidian eklentisinde veri sızıntısı vakasının ortaya çıkacağını düşünüyorum. O zaman ekip güvenlik önlemleri ekleyecektir. En azından doğrulanmış yayıncı sistemi gerekli.

    • Ticari olarak Obsidian eklentisi geliştiriyorum. Belirli bir seviyenin üzerindeki eklentiler için daha yüksek düzeyli bir inceleme süreci olmasını isterdim. Arch Linux’taki AUR gibi topluluk tarafından yönetilen bir depo ile daha sıkı denetlenen bir depo olmak üzere iki ayrı yapı, hem eklenti inceleme hızını artırabilir hem de güvenliği iyileştirebilir.

  • “Tedarik zinciri saldırıları, birçok uygulamada kullanılan açık kaynak koda kötü amaçlı güncellemelerin gizlenmesidir” denmiş ama hedef alınabilecek şey sadece açık kaynak (FOSS) değil; kaynak kodu olan her şey saldırıya uğrayabilir. FOSS’un mutlaka daha savunmasız olduğu algısı sorunlu.

  • “Kurulum sırasında postinstall betiklerini çalıştırmıyoruz” politikası iyi niyetli ama paket zaten ele geçirilmişse postinstall aşamasını atlamak kalan kodu güvenli yapmaz. Paket sağlamsa postinstall meşru kuruluma yardımcı da olabilir. Gerçek olaylar tedarik zinciri saldırılarından çok, normal güvenlik açığı yamalarında ortaya çıkıyor; bu yüzden güncellemeleri engellemek riski artırabilir.

    • Günümüzde güvenlik taraması genellikle kurulumdan sonra yapılıyor (post install). Kurulum sırasında hiçbir şeyin çalıştırılmaması daha iyi. Gelecekte kurulum aşamasında tarama ya da kısıtlama yapan daha fazla özellik görmeyi umuyorum. Bazı ticari araçlar bunu destekliyor ama yaygın değil.

    • Yine de derleme makinesini korumak açısından anlamlı. Sayısız bağımlılığımdan rastgele bir betiğin çalıştırılmasından endişe etmek zorunda kalmıyorum.

  • Kullanıcıya dağıttığınız tüm kodun sorumluluğu geliştiriciye aittir. Bağımlılıkları sabitlemezseniz bu, “internetten rastgele kod indirip şansa güvenmek” olur.

    • Bağımlılıkları sabitlemek, sonradan çıkan güvenlik yamalarını kaçırmanıza neden olabilir. Bu da risklidir; dolayısıyla yeni güvenlik yamaları çıktığında bunu fark etmenizi sağlayacak bir sistem mutlaka olmalı. O yamayı backport etmeniz ya da yeni sürüme güncellemeniz gerekir.

    • Sabitlenmiş bağımlılıkların da kendi bağımlılıkları vardır; sonuçta yapı yine her zaman “rastgele kod indir ve umut et” noktasına çıkıyor. Özellikle Electron tabanlı uygulamalarda gerçekten çok büyük miktarda kod geliyor.

  • Son dönemde sık gördüğüm bir tavsiye, yama sürümü çıksa bile bağımlılıkları güncellemeyin şeklinde; bunu anlamakta zorlanıyorum. Güncelleme yapmamak kötü amaçlı yazılım yükleme riskini azaltabilir ama yamalar çoğunlukla güvenliği iyileştirmek için çıkıyor. En güncel yamaları uygulamamak gerçekten akıllıca mı diye merak ediyorum.

    • Önemli olan, yamayı neden uyguladığınızı ve neyin değiştiğini anlamak. Tüm kaynak kodunu okuyacak vaktimiz yok; bu yüzden temel araçlar ve hizmetlerle (Npm Audit gibi) güvenlik açığı özetlerine bakıyorum. Ben, gerçekten gerekmediği sürece güncellemeleri erteleme stratejisi izliyorum çünkü güncellemeler hem bir saldırı vektörü hem de başlıca hata kaynağı olabiliyor. Ama hangi açıkların sizi etkilediğini düzenli olarak kontrol etmek şart. Kullanmadığınız bir özelliğe ait açıklarda güncellemeyi erteleyebilirim; gerçekten önemli kusurları ise hemen güncellerim. Güvenlik aktif ve sürekli bir süreçtir; kurumun risk toleransına göre yaklaşım değişmelidir. Basitçe “her zaman güncelle” ya da “asla güncelleme” diye tek bir doğru yok.

    • Bugünlerde Z-WaveJS UI’yi her güncellediğimde yine bağımlılık güncellemeleri geliyor. Bu tatmin etmeyen döngü yüzünden artık kendim kontrol ediyorum. Artık herkesin bağımlılıklara bağımlı olduğu bir dönemdeyiz; “sonu yok”. Bir kez otomatik güncelleme yapmak bile riskli.

    • Güncellemede her zaman iyileşme ya da gerileme riski var ve npm ekosisteminde (Obsidian da buna dahil) bu risk çok daha büyük. npm’de kötü amaçlı paketlerin kaldırılması insan müdahalesi gerektirdiğinden süreç yavaş ilerliyor. Güncellemeleri bilerek geciktirmek en azından bir miktar savunma sağlayabiliyor.

    • Son zamanlarda yama sürümü çıktıktan hemen sonra kurmak yerine biraz bekleme eğilimi var. Artık olaylar çoğu zaman birkaç saat içinde fark ediliyor. Birçok şirket npm’i izliyor ve bunun etrafında güvenlik işi yapıyor. pnpm, paket yayımlandıktan sonra en az X dakika geçmiş paketlerin kurulmasına izin verecek şekilde ayarlanabiliyor. Ben en az 24 saat bekliyorum pnpm minimumreleaseage ayarı

    • İki hafta önce paketimin maruz kaldığı saldırı bir yama sürümünü hedefliyordu. postinstall betiği değildi. Otomatik tarama sistemleri bunu hızla tespit ettiği için bu konu artık eskisi kadar öne çıkmıyor. Pakette bir açık bulunduğunda anında bildirim geliyor ve durum net oluyor. Sürüm aralıkları kullanmak, tedarik zinciri saldırılarına karşı en kötü yaklaşımlardan biri.

  • Paketin yalnızca Electron, CodeMirror ve moment.js içerdiği için büyük olmadığı iddiasına katılmak zor. Electron, webview temelli ve muazzam derecede karmaşık bir yazılım. moment.js için de artık daha iyi API’ler var. Obsidian’ın bağımlılık yönetimi seviyesi bana ancak asgari bir standart gibi geliyor; özel olarak etkileyici bir güvenlik politikası hissi vermiyor. Yine de düzenli güvenlik denetimi yapmaları olumlu.

  • Obsidian dışında uygulamalar kullanıyordum ama Obsidian da ilgimi çekmeye başladı. Bir Electron uygulaması olması, kaynakları çok tüketmesi ve yerel olmaması nedeniyle JS bana hep biraz tedirgin hissettiriyor. Acaba fazla eski kafalı mıyım diye düşünüyorum.

    • JavaScript çok güvenli bir dildir. Web tarayıcıları, JavaScript’i dünya çapında güvenle çalıştırmanın başarılı örnekleridir. Her web sitesi birbirinin verisini okuyamaz. Electron da JavaScript’i v8 motorunda sandbox içinde çalıştırır. Kullanıcı girdisi olarak gelen kodu çalıştırmaktan kaçındığınız sürece oldukça güvenlidir. Tedarik zinciri saldırısı sorunu npm’den kaynaklanır; JS dilinin kendisinden değil. Güvenlik politikalarını paket yayımlanırken daha sıkı uygulama sorumluluğu npm’ye ait.

    • JavaScript, hangi ölçüte bakarsanız bakın, dünyanın en çok kullanılan dillerinden biridir. Neredeyse tüm bilgisayar ve akıllı telefonlarda çalışır. Bu yüzden güvenlik sorunlarının daha sık bulunması normal. Yerel uygulamaların daha güvenli olduğuna dair bir kanıt yok.

    • Electron uygulamaları başlı başına sorun değil. GitHub, VS Code, Slack, Discord, Postman hepsi Electron tabanlı. Ben sık sık şunu sormak istiyorum: Bir Markdown not uygulamasında performansın gerçekten sorun olduğu nasıl bir iş yapılıyor? İnsan bazen gerçekten eski bir dizüstünde Lynx tarayıcıyla sadece metin modunda mı kullanılıyor diye merak ediyor.

    • Electron’ı pek sevmiyorum (bu yüzden tauri seviyorum) ama yine de Obsidian’ın kendisi çok iyi; sırf Electron yüzünden göz ardı etmeye gerek yok. MCP ile entegre edip kişisel bilgi tabanı olarak kullanmak için de çok uygun, tavsiye ederim.

    • Electron ağır, evet. PC’de büyük sorun değil ama mobilde not sayısı binleri bulunca, eklenti olmasa bile uygulamanın açılışı yavaşlıyor. Kullanıcılar bunu hızlı kayıt için farklı eklenti/uygulamalarla aşmaya çalışıyor ama daha hafif, yerel bir Obsidian olsa güzel olurdu.

  • Obsidian, Electron tabanlı ve bunun doğası gereği ağırlık ile güvenlik zafiyeti riski getiriyor.

    • Ama tüm platformlarda aynı kullanıcı deneyimini ve yerel uygulama düzeyinde erişilebilirliği de destekliyor.

  • Emacs ve Org-Roam kullanıyorum; ağ bağlantısı olmayan bir VM’de (Qubes OS’in Qube’u) çalıştırıyorum. Emacs içinde çalışan tüm kodu bizzat inceleyemem.

  • Yerel uygulama ve daha düşük tedarik zinciri riski istiyorsanız, GTK tabanlı ve başlıca Linux dağıtımlarında paketlenen Zim wiki bir alternatif olabilir Zim wiki’ye git

    • Zim wiki’nin yerel mobil uygulaması ve senkronizasyon özelliği yok; beni Obsidian’a çeken nokta da bu. Eklentileri rastgele kurmadığınız sürece güvenlik açısından yeterince makul.