- Serangan rantai pasok adalah cara pembaruan berbahaya menyusup ke dalam kode open source yang didistribusikan, dan untuk meminimalkannya Obsidian menggunakan strategi mengurangi ketergantungan eksternal itu sendiri
- Sebagian besar fitur aplikasi diimplementasikan sendiri, atau bila perlu kode yang di-fork dimasukkan ke codebase mereka dan dikelola langsung
- Library besar yang benar-benar diperlukan (
pdf.js, Mermaid, MathJax, dll.) diamankan dengan mengunci versi, dan pembaruan hanya dilakukan dengan hati-hati saat ada patch keamanan
- Semua dependensi dikunci dengan lockfile, dan skrip
postinstall tidak dijalankan untuk mencegah eksekusi kode arbitrer saat instalasi
- Melalui prosedur pembaruan yang hati-hati dan strategi jeda waktu ini, Obsidian dapat merespons sebelum potensi ancaman terdeteksi oleh komunitas
Apa itu serangan rantai pasok
- Serangan rantai pasok adalah cara pembaruan berbahaya menyusup ke kode yang didistribusikan dalam ekosistem open source
- Karena banyak aplikasi menggunakan kode open source, satu pembaruan berbahaya dapat berdampak luas ke banyak aplikasi
- Obsidian merancang aplikasinya agar aman dengan mengurangi permukaan serangan semacam ini melalui strategi meminimalkan dependensi
Strategi meminimalkan dependensi: Less is Safer
- Dibandingkan aplikasi lain di kategorinya, Obsidian bergantung pada sangat sedikit library eksternal
- Fitur utama (mis. Bases, Canvas) diimplementasikan sendiri alih-alih mengadopsi library eksternal
- Dengan begitu, mereka dapat mempertahankan kendali penuh atas kode yang dijalankan
- Fungsi utilitas kecil hampir selalu diimplementasikan langsung oleh tim pengembang
- Modul berukuran menengah akan di-fork dan dimasukkan ke codebase jika lisensinya mengizinkan
- Library besar (
pdf.js, Mermaid, MathJax, dll.) disertakan dengan versi tervalidasi yang dikunci, dan hanya di-upgrade seminimal mungkin saat ditemukan isu keamanan penting
- Semua perubahan eksternal ditinjau secara rinci dan melalui prosedur pengujian yang ketat
- Dengan cara ini, jumlah sub-dependensi juga diminimalkan, sehingga struktur dasarnya mengurangi risiko utama masuknya kode berbahaya
Komponen yang benar-benar masuk ke aplikasi
- Dalam aplikasi yang benar-benar dijalankan pengguna, hanya ada segelintir paket seperti Electron, CodeMirror, dan moment.js
- Sementara itu, alat pengembangan lainnya hanya dipakai pada proses build aplikasi dan tidak dikirim ke pengguna akhir
Penguncian versi dan pengelolaan lockfile
- Semua dependensi eksternal dikelola melalui version pinning yang ketat dan commit lockfile
- Dengan begitu, instalasi selalu dapat direproduksi dan riwayat perubahan mudah dilacak
- Melalui kebijakan tidak menjalankan skrip
postinstall, kemungkinan eksekusi kode arbitrer selama instalasi diblokir sejak awal
Prosedur pembaruan yang lambat dan hati-hati
- Saat upgrade dependensi diperlukan, mereka menjalankan prosedur peninjauan sistematis berikut
- Meninjau changelog secara teliti baris demi baris
- Memeriksa dependensi turunan baru yang ditambahkan pada versi terbaru
- Jika perubahan besar atau ada faktor risiko, mereka memeriksa langsung diff dengan source upstream
- Melakukan pengujian otomatis/manual untuk jalur utama dan berbagai platform
- Commit lockfile hanya dilakukan setelah semua tahap di atas lolos
- Karena sebagian besar dependensi tidak perlu sering diubah, frekuensi pembaruan sendiri memang rendah
- Pengenalan kode eksternal baru ditinjau dan dikelola setara dengan adopsi dependensi baru
"Jeda waktu" demi stabilitas: Time is a buffer
- Berbagai upgrade tidak langsung dirilis, melainkan ditunda selama periode tertentu
- Selama masa ini, komunitas open source dan peneliti keamanan dapat mendeteksi versi berbahaya lebih dulu, sehingga menjadi jendela mitigasi awal
- Saat waktu rilis aktual tiba, kemungkinan masalah sudah teridentifikasi lebih tinggi, sehingga efektif meminimalkan risiko
Kesimpulan
- Tidak ada satu langkah keamanan pun yang dapat sepenuhnya menghilangkan risiko serangan rantai pasok
- Namun, Obsidian secara signifikan menurunkan risiko dengan menggabungkan minimalisasi dependensi, graph yang dangkal, penguncian versi, pelarangan
postinstall, dan pembaruan lambat berbasis peninjauan
- Prosedur ini juga memberi lebih banyak waktu untuk mendeteksi risiko sebelum kode mencapai pengguna
- Pendekatan keamanan Obsidian secara keseluruhan dan riwayat audit keamanan sebelumnya dapat dilihat di security page resmi
1 komentar
Komentar Hacker News
Banyak komentar mengabaikan fakta bahwa sebagian besar pengguna memakai plugin komunitas pihak ketiga di Obsidian; pada kenyataannya model keamanan plugin Obsidian sangat lemah, karena plugin diberi akses ke semua file di dalam vault. Jika Obsidian berupaya menanamkan lebih banyak fitur secara langsung, risiko keamanan bisa berkurang. Atau, sistemnya bisa diperbaiki seperti ekstensi browser, dengan menyatakan izin yang digunakan plugin dan memblokir akses ke izin yang tidak disetujui. Semua ini akan memberi keamanan pengguna yang jauh lebih nyata daripada logika “lebih sedikit ketergantungan pihak ketiga”.
Dulu ada beberapa tokoh di dunia perangkat lunak yang membahas bagaimana ide-ide dari desain video game mengalir ke perangkat lunak umum lainnya, tetapi sekarang hampir tak terdengar lagi. Akan sangat membantu bagi seluruh ekosistem perangkat lunak jika para personel inti dari perusahaan game lama seperti Blizzard menulis buku yang merinci bagaimana sistem plugin World of Warcraft bekerja selama 10 tahun pertamanya, apa saja masalahnya, dan bagaimana keamanannya diperkuat. Sistem plugin di banyak proyek adalah campuran dari kerapuhan dan ketidakmatangan.
Plugin Obsidian bisa mengakses bukan hanya file di dalam vault, tetapi semua file di komputer. Saya pernah menyinggung hal ini di Discord sebelumnya, tetapi diabaikan.
Saya memikirkannya seperti Arch Linux; bahkan insinyur pun kesulitan menangani keamanan saat mengelola perangkat lunak langsung dari AUR, jadi terlalu berat berharap pengguna biasa bertanggung jawab atas keamanan.
Saya rasa cepat atau lambat akan muncul kasus kebocoran data dari plugin Obsidian, dan saat itu timnya akan mulai menerapkan pengaman. Minimal perlu ada sistem penerbit terverifikasi.
Saya sedang mengembangkan plugin Obsidian secara komersial, dan berharap ada proses peninjauan tingkat lebih tinggi untuk plugin di atas ambang kualitas tertentu. Seperti AUR di Arch Linux, akan membantu jika ada dua repositori: satu yang dikelola komunitas dan satu lagi dengan peninjauan yang lebih ketat, agar kecepatan peninjauan plugin meningkat sekaligus keamanan membaik.
Ada penjelasan bahwa “serangan rantai pasok adalah ketika pembaruan berbahaya disisipkan ke dalam kode open source yang dipakai banyak aplikasi”, tetapi sumber kode apa pun, bukan hanya open source (FOSS), bisa menjadi sasaran serangan. Anggapan bahwa FOSS pasti lebih rentan adalah masalah.
Kebijakan “tidak menjalankan skrip postinstall saat instalasi” memang berniat baik, tetapi jika paketnya sudah dikompromikan, melewati postinstall tidak berarti sisa kodenya aman. Jika paketnya normal, postinstall justru bisa membantu instalasi yang sah. Dalam praktiknya, insiden lebih sering muncul dari patch kerentanan biasa daripada serangan rantai pasok, sehingga memblokir pembaruan justru bisa meningkatkan risiko.
Saat ini pemindaian keamanan umumnya dilakukan setelah instalasi (post install). Bagus jika selama instalasi tidak ada apa pun yang dijalankan. Saya berharap ke depan akan lebih banyak fitur untuk melakukan pemindaian atau pembatasan di tahap instalasi. Beberapa alat komersial memang mendukungnya, tetapi belum umum.
Tetap ada manfaatnya untuk melindungi mesin build, karena saya tidak perlu khawatir skrip sembarang dieksekusi dari begitu banyak dependensi saya.
Tanggung jawab atas semua kode yang didistribusikan ke pengguna ada pada pengembang. Jika dependensi tidak dipin, itu seperti "mengunduh kode acak dari internet dan berharap beruntung".
Kalau dependensi dipin, patch keamanan berikutnya bisa terlewat. Itu juga berisiko, jadi harus ada sistem yang bisa menyadarkan ketika patch keamanan baru keluar. Patch tersebut perlu di-backport atau diperbarui ke versi baru.
Dependensi yang dipin pun masih membawa dependensi lain di dalamnya, jadi pada akhirnya strukturnya tetap seperti "mengunduh kode acak dan berharap". Terutama pada aplikasi berbasis Electron, jumlah kodenya benar-benar sangat besar.
Di antara saran yang belakangan sering saya lihat, ada pendapat bahwa dependensi tidak perlu diperbarui meskipun ada patch release, dan saya tidak mengerti. Tidak memperbarui mungkin mengurangi risiko memasang malware, tetapi biasanya patch dibuat untuk perbaikan keamanan. Saya penasaran apakah tidak memasang patch terbaru memang pilihan yang bijak.
Kuncinya adalah memahami alasan patch diterapkan dan apa isi perubahannya. Karena tidak ada waktu untuk membaca semua source code, saya memakai alat dan layanan utama seperti Npm Audit untuk memeriksa ringkasan informasi kerentanan. Saya memakai strategi menunda pembaruan kecuali benar-benar diperlukan, karena pembaruan adalah vektor serangan sekaligus sumber utama bug. Namun saya tetap secara berkala memeriksa kerentanan mana yang benar-benar mengekspos saya. Jika kerentanannya ada pada fitur yang tidak dipakai, saya kadang menunda pembaruan. Hanya cacat yang benar-benar penting yang langsung saya perbarui. Keamanan adalah proses aktif dan berkelanjutan, dan responsnya harus disesuaikan dengan toleransi risiko organisasi; bukan sekadar "selalu update" atau "jangan pernah update".
Belakangan ini setiap kali saya memperbarui Z-WaveJS UI, pembaruan dependensi terus berulang. Karena pola yang tidak memuaskan ini, saya memeriksanya sendiri. Sekarang semua orang hidup di era dependensi atas dependensi, jadi "tidak ada akhirnya", dan satu kali auto-update saja bisa berbahaya.
Saat melakukan pembaruan, selalu ada risiko perbaikan maupun kemunduran, dan di ekosistem npm (yang dipakai Obsidian) risikonya jauh lebih besar. npm memerlukan campur tangan manusia untuk menghapus paket berbahaya, sehingga penanganannya lambat. Menunda pembaruan dengan sengaja setidaknya memberi sedikit pertahanan.
Akhir-akhir ini trennya adalah menunggu sebentar setelah patch release keluar sebelum memasangnya. Sekarang banyak insiden terdeteksi dalam hitungan jam. Ada banyak perusahaan yang memantau npm dan menjalankan bisnis keamanan. pnpm bisa diatur agar hanya memasang paket yang sudah lebih dari X menit sejak dipublikasikan. Saya sendiri menunggu setidaknya 24 jam pengaturan minimumreleaseage di pnpm
Serangan yang mengenai paket saya dua minggu lalu menargetkan patch release; itu bukan skrip postinstall. Pemindaian otomatis mendeteksinya dengan cepat, jadi isu ini sekarang tidak terlalu menonjol. Jika kerentanan pada paket ditemukan, pemberitahuannya datang seketika dan jelas. Menggunakan version ranges adalah pilihan terburuk untuk menghadapi serangan rantai pasok.
Sulit setuju dengan klaim bahwa paketnya tidak besar hanya karena hanya menyertakan Electron, CodeMirror, dan moment.js. Electron adalah perangkat lunak dengan kompleksitas luar biasa besar karena berbasis webview, dan moment.js sudah punya API yang lebih baik sebagai pengganti. Tingkat pengelolaan dependensi Obsidian terasa hanya memenuhi standar minimum, bukan kebijakan keamanan yang luar biasa. Meski begitu, fakta bahwa mereka rutin melakukan audit keamanan adalah hal positif.
Saya selama ini memakai aplikasi lain selain Obsidian, tetapi mulai tertarik pada Obsidian juga. Fakta bahwa ini aplikasi Electron terasa boros sumber daya dan tidak native, dan JS selalu memberi saya rasa tidak tenang. Saya penasaran apakah saya terlalu bernostalgia dengan cara lama.
JavaScript adalah bahasa yang sangat aman. Web browser adalah contoh sukses berskala global dalam menjalankan JavaScript secara aman; tiap situs web tidak bisa membaca data satu sama lain. Electron juga melakukan sandboxing JavaScript dengan mesin v8. Selama tidak mengeksekusi kode dari input pengguna, ini sangat aman. Masalah serangan rantai pasok berasal dari npm itu sendiri, bukan dari bahasa JS, dan npm bertanggung jawab menerapkan kebijakan keamanan yang lebih ketat saat distribusi paket.
JavaScript, dengan ukuran apa pun, adalah salah satu bahasa yang paling banyak digunakan di dunia. Ia berjalan di hampir semua komputer dan smartphone. Karena itu pula isu keamanannya lebih sering ditemukan. Tidak ada dasar bahwa aplikasi native otomatis lebih aman.
Aplikasi Electron bukan masalahnya. GitHub, VS Code, Slack, Discord, dan Postman semuanya berbasis Electron. Saya sering ingin bertanya: pekerjaan apa sih yang benar-benar dilakukan di aplikasi catatan Markdown sampai performa jadi masalah? Sampai-sampai rasanya seperti ingin tahu apakah orang itu masih memakai laptop tua sekali dan membuka semuanya dalam mode teks lewat browser Lynx.
Saya memang tidak terlalu suka Electron (itulah sebabnya saya suka tauri), tetapi Obsidian sendiri sangat bagus, jadi tidak perlu menolaknya hanya karena Electron. Ia juga bagus dipakai sebagai basis pengetahuan pribadi yang terhubung dengan MCP, jadi saya merekomendasikannya.
Electron memang berat. Di PC itu biasanya bukan masalah besar, tetapi di mobile, ketika catatan sudah ribuan, startup aplikasi mulai terasa lambat bahkan tanpa plugin. Pengguna menyiasatinya dengan plugin/aplikasi pencatatan cepat, tetapi tetap ada harapan akan hadirnya Obsidian native yang lebih ringan.
Obsidian berbasis Electron, dan karena sifat itu ia membawa konsekuensi berupa bobot yang berat dan risiko kerentanan keamanan.
Saya memakai Emacs dan Org-Roam, dan menjalankannya dalam VM tanpa koneksi jaringan (Qube di Qubes OS). Saya tidak bisa meninjau langsung semua kode yang berjalan di Emacs.
Jika ingin aplikasi native dan risiko rantai pasok yang lebih rendah, Zim Wiki berbasis GTK yang sudah dipaketkan di distribusi Linux utama bisa menjadi alternatif Kunjungi Zim Wiki