Less is Safeer: bagaimana Obsidian mengurangi risiko serangan rantai pasokan Serangan rantai pasokan adalah pembaruan berbahaya yang menyelinap ke kode sumber terbuka yang digunakan oleh banyak aplikasi. Inilah cara kami mendesain Obsidian untuk memastikan bahwa aplikasi tersebut adalah lingkungan yang aman dan pribadi untuk pemikiran Anda. Lebih sedikit lebih aman Ini mungkin terdengar jelas, tetapi cara utama kami mengurangi risiko serangan rantai pasokan adalah dengan menghindari bergantung pada kode pihak ketiga. Obsidian memiliki jumlah dependensi yang rendah dibandingkan dengan aplikasi lain dalam kategori kami. Lihat daftar pustaka sumber terbuka di halaman Kredit kami. Fitur-fitur seperti Bases dan Canvas diimplementasikan dari awal alih-alih mengimpor perpustakaan siap pakai. Ini memberi kita kendali penuh atas apa yang berjalan di Obsidian. - Untuk fungsi utilitas kecil, kita hampir selalu mengimplementasikannya kembali dalam kode kita. - Untuk modul menengah, kami mencabang dan menyimpannya di dalam basis kode kami jika lisensi mengizinkannya. - Untuk perpustakaan besar seperti pdf.js, Mermaid, dan MathJax, kami menyertakan file yang diketahui baik, terkunci versi dan hanya meningkatkan sesekali, atau ketika perbaikan keamanan mendarat. Kami membaca catatan rilis, melihat perubahan hulu, dan menguji secara menyeluruh sebelum beralih. Pendekatan ini membuat grafik dependensi kita dangkal dengan sedikit sub-dependensi. Area permukaan yang lebih kecil menurunkan kemungkinan pembaruan berbahaya terlewatkan. Apa yang sebenarnya dikirimkan di aplikasi Hanya beberapa paket yang merupakan bagian dari aplikasi yang Anda jalankan, misalnya Electron, CodeMirror, moment.js. Paket lainnya membantu kami membangun aplikasi dan tidak pernah dikirim ke pengguna, misalnya esbuild atau eslint. Penyematan versi dan kuncifile Semua dependensi disematkan versi secara ketat dan dilakukan dengan file kunci. Lockfile adalah sumber kebenaran untuk build sehingga kita mendapatkan instalasi deterministik. Ini memberi kami jejak audit langsung saat meninjau perubahan. Kami tidak menjalankan skrip pascainstalan. Ini mencegah paket mengeksekusi kode arbitrer selama penginstalan. Peningkatan yang lambat dan disengaja Saat kami melakukan pembaruan dependensi, kami: 1. Baca changelog dependensi baris demi baris. 2. Periksa sub-dependensi yang diperkenalkan oleh versi baru. 3. Diff hulu ketika set perubahan besar atau berisiko. 4. Jalankan pengujian otomatis dan manual di seluruh platform dan jalur pengguna penting. 5. Terapkan file kunci baru hanya setelah tinjauan ini berlalu. Dalam praktiknya, kami jarang memperbarui dependensi karena umumnya berfungsi dan tidak memerlukan perubahan yang sering. Ketika kita melakukannya, kita memperlakukan setiap perubahan seolah-olah kita mengambil ketergantungan baru. Waktu adalah penyangga Kami tidak terburu-buru peningkatan. Ada penundaan antara meningkatkan dependensi apa pun dan mendorong rilis. Kesenjangan itu bertindak sebagai jendela peringatan dini: komunitas dan peneliti keamanan sering mendeteksi versi berbahaya dengan cepat. Pada saat kami siap untuk dikirim, ekosistem biasanya telah menandai rilis yang bermasalah. — Tidak ada tindakan tunggal yang dapat menghilangkan risiko rantai pasokan. Tetapi memilih dependensi yang lebih sedikit, grafik dangkal, pin versi yang tepat, tidak ada pascainstalan, dan irama peningkatan yang lambat dan berat tinjauan bersama-sama membuat Obsidian jauh lebih kecil kemungkinannya untuk terpengaruh, dan memberi kami jendela panjang untuk mendeteksi masalah sebelum kode mencapai pengguna. Jika Anda ingin tahu tentang pendekatan keamanan kami yang lebih luas, lihat halaman keamanan kami dan audit sebelumnya.