Sebagian besar nasihat keamanan untuk pengguna kripto berfokus pada permukaan yang bisa kamu lihat: frasa benihmu, tautan yang kamu ketuk, situs tempat kamu masuk. Itu semua penting. Namun ada risiko yang lebih senyap di bawah semuanya — perangkat lunak itu sendiri, dan segala hal yang membangunnya. Sebuah dompet bisa ditulis dengan sempurna dan tetap mengirimkan pintu belakang, karena aplikasi modern dirakit dari ratusan blok pihak ketiga dan dari pipeline build yang mengubah kode sumber menjadi biner yang kamu pasang. Kompromikan mata rantai mana pun, dan kamu mengompromikan setiap pengguna di hilir.
Inilah rantai pasokan perangkat lunak, dan para penyerang telah belajar bahwa ia adalah salah satu target berdaya ungkit tertinggi di kripto. Artikel ini menjelaskan apa sebenarnya serangan rantai pasokan itu, mengapa dompet menjadi target yang begitu menggiurkan, pertahanan yang bertahan dalam praktik, dan apa yang diberikan build deterministik kepadamu — termasuk bagaimana SSP menerapkan semua ini.
Apa itu serangan rantai pasokan
Serangan rantai pasokan tidak menerobos aplikasi secara langsung. Sebaliknya, ia mengompromikan sesuatu yang dipercaya aplikasi: dependensi yang ditariknya, akun seorang pengelola, atau pipeline build yang merakit artefak akhir. Kode berbahaya menumpang masuk lewat pembaruan yang sah, ditandatangani dan dikirim melalui kanal normal, sehingga tampak persis seperti perangkat lunak yang ingin kamu pasang.
Ketaklangsungan itulah inti persoalannya. Menyerang satu pustaka yang dipakai luas — atau satu server build — bisa menjangkau ribuan proyek hilir dan jutaan pengguna sekaligus. Bagi dompet kripto, ganjarannya langsung: kode yang berjalan di dalam dompetmu sudah punya akses ke momen yang menentukan, saat transaksi ditandatangani dan alamat ditampilkan. Satu dependensi yang dirusak bisa menukar alamat tujuan atau menyedot materi kunci tanpa pernah menyentuhmu lewat phishing atau higiene frasa benih yang lemah. Itulah mengapa kelas serangan ini layak mendapat tempat dalam model berpikirmu.
Dua kasus yang terasa dekat
Dua insiden nyata menunjukkan bagaimana ini berlangsung — satu membidik kripto secara langsung, satu lagi nyaris menghantam seluruh internet.
event-stream dan dompet Copay
Pada 2018, sebuah paket npm populer bernama event-stream diserahkan kepada pengelola sukarelawan baru yang menawarkan bantuan. Itu serah terima yang rutin dan tampak berniat baik, jenis yang terus-menerus terjadi di sumber terbuka. Pengelola baru itu lalu menambahkan dependensi baru, flatmap-stream, yang memuat kode berbahaya yang dikaburkan.
Muatannya menargetkan secara tidak biasa. Alih-alih memicu untuk semua orang, ia hanya aktif di dalam satu proyek hilir tertentu: dompet Bitcoin Copay. Di sana ia dirancang untuk mencuri materi benih dan dana pengguna aplikasi itu. Sebagian besar pengembang yang menarik event-stream tidak pernah terdampak — kode itu tahu persis korban mana yang dicarinya.
Ini adalah pengingat klasik bahwa "saya hanya memasang satu pustaka kecil" tidak pernah menjadi keseluruhan ceritanya. Kamu juga memasang segala sesuatu yang dipercaya pustaka itu.
Pintu belakang XZ Utils
Insiden XZ Utils 2024 (CVE-2024-3094) bahkan lebih sabar. XZ Utils adalah pustaka kompresi yang hadir diam-diam di sebagian besar sistem Linux. Selama bertahun-tahun, seorang penyerang membangun kepercayaan sebagai kontributor yang membantu, sedikit demi sedikit memperoleh tanggung jawab pengelola, lalu menyelipkan pintu belakang yang dirancang untuk mengganggu OpenSSH — perangkat lunak yang mengamankan masuk jarak jauh ke server di mana-mana.
Ia tertangkap nyaris secara kebetulan, berkat seorang insinyur yang menyadari jeda sepersekian detik. Andai tersebar luas, ia bisa saja menyerahkan akses jarak jauh ke mesin yang tak terhitung jumlahnya.
Pelajaran bagi kripto terasa menyadarkan: serangan itu tidak mengeksploitasi bug yang cerdik, melainkan mengeksploitasi model kepercayaan sumber terbuka itu sendiri, memainkan permainan rekayasa sosial bertahun-tahun untuk menjadi orang yang diandalkan semua orang.
Pertahanan yang benar-benar berhasil
Tak ada kendali tunggal yang menghentikan serangan rantai pasokan. Yang berhasil adalah tumpukan kendali, masing-masing mempersempit pilihan penyerang:
- Dependensi yang dipaku dan berkas kunci. Memaku versi yang tepat dan memasukkan berkas kunci ke kontrol versi berarti sebuah build tidak bisa diam-diam menarik rilis yang lebih baru dan sudah dirusak. Pembaruan menjadi peristiwa yang disengaja dan dapat ditinjau, bukan otomatis.
- Dependensi minimal. Setiap paket yang kamu tambahkan adalah pihak yang kamu percayai. Lebih sedikit dependensi berarti permukaan serangan yang lebih kecil dan lebih sedikit pengelola yang bisa dikompromikan.
- Sandboxing dependensi. Perkakas seperti LavaMoat membatasi apa yang boleh dilakukan tiap paket saat runtime, sehingga dependensi yang dikompromikan tidak bisa bebas menjangkau jaringan atau API sensitif.
- Penandatanganan kode. Rilis yang ditandatangani memungkinkan pengguna memverifikasi bahwa sebuah biner berasal dari penerbit asli dan tidak diubah saat transit.
- Audit pihak ketiga. Firma keamanan independen meninjau kode dan dependensi dengan mata lawan, menangkap apa yang dinormalkan oleh tim internal.
- Build yang dapat direproduksi, deterministik. Pertahanan struktural terkuat, dan yang layak dipahami secara rinci.
Build deterministik, dijelaskan
Biasanya, membangun dari sumber yang sama dua kali bisa menghasilkan dua biner yang sedikit berbeda — stempel waktu, urutan berkas, dan detail mesin build menyusup masuk. Variabilitas itu jadi masalah, karena artinya kamu tidak bisa membedakan perbedaan yang tak berbahaya dari yang berbahaya.
Build deterministik (atau dapat direproduksi) menghapus variabilitas itu. Dengan kode sumber yang sama, siapa pun, di mana pun, di mesin mana pun, menghasilkan artefak yang identik bita demi bita. Implikasinya kuat: orang-orang independen dapat membangun ulang dompet dari kode sumber publiknya dan memastikan bahwa biner yang kamu unduh cocok, bit demi bit, dengan apa yang dihasilkan sumber. Jika penyerang merusak pipeline build atau menyelipkan sesuatu kemudian, nilai hash tidak akan cocok dan perusakan langsung terlihat.
Ini membalik model kepercayaan. Kamu tak perlu lagi mempercayai kata-kata penerbit; verifikasi menjadi sesuatu yang bisa dilakukan dan diperiksa silang oleh seluruh komunitas. Proyek Reproducible Builds mendokumentasikan praktik ini di seluruh ekosistem, dan kerangka seperti SLSA mendefinisikan tingkat jaminan integritas build yang bisa kamu tuntut dari sebuah proyek.
Bagaimana SSP menerapkannya
SSP memperlakukan pipeline build sebagai bagian dari model ancamannya, bukan renungan belakangan. Dompet dikirim dengan build deterministik yang mengutamakan Dockerfile: lingkungan yang sama yang didefinisikan Docker menghasilkan artefak yang sama setiap kali, sehingga rilis yang dipublikasikan bisa dibangun ulang dari sumber publik dan dicocokkan, bit demi bit, dengan yang kamu unduh. SSP juga telah menjalani tinjauan keamanan independen oleh Halborn, yang auditnya memeriksa baik kode maupun dependensi yang menjadi sandarannya.
Ada satu lapisan lagi yang khas pada cara SSP dibangun, dan di sini ia penting. SSP adalah dompet multisig 2-dari-2: setiap transaksi memerlukan persetujuan independen dari kunci kedua, SSP Key, di perangkat terpisah. Bersikaplah cermat tentang apa yang dilakukannya dan tidak. Build deterministik dan audit menurunkan peluang sebuah build yang dirusak terkirim sejak awal; itulah garis depan. Tetapi bahkan dalam kasus terburuk — sebuah build yang entah bagaimana lolos — kunci kedua adalah permukaan persetujuan terpisah yang tetap harus menyetujui setiap transaksi.
Ia bukan perisai ajaib, dan tidak membuat build yang dikompromikan menjadi dapat diterima. Ia hanya berarti bahwa satu komponen yang dirusak pada satu perangkat, dengan sendirinya, tidak memindahkan danamu. Pertahanan berlapis itulah intinya.
Apa yang bisa kamu periksa sendiri
Kamu tak perlu menjadi insinyur keamanan untuk menikmati manfaat dari semua ini. Beberapa kebiasaan sudah sangat membantu:
- Unduh hanya dari sumber resmi. Ambil dompet dari situs resminya atau cantuman tokonya, jangan pernah dari tautan dalam pesan atau iklan pencarian. Ini disiplin yang sama yang dibahas dalam higiene ekstensi peramban.
- Utamakan proyek yang mempublikasikan build deterministik dan audit. Sebuah proyek yang membiarkan komunitas memverifikasi rilisnya — dan membayar untuk tinjauan independen — sedang memberitahumu sesuatu tentang cara ia berpikir.
- Verifikasi tanda tangan dan hash saat ditawarkan. Jika sebuah rilis menyertakan tanda tangan atau checksum, luangkan semenit untuk memeriksanya. Build yang dapat direproduksi hanya melindungimu jika ada seseorang yang benar-benar melakukan pembandingan.
- Jaga opsec keseluruhanmu tetap ketat. Pertahanan rantai pasokan berada dalam gambaran yang lebih besar; telusuri daftar periksa opsec secara berkala agar tak ada satu lapisan pun yang menanggung seluruh beban.
Tak satu pun dari ini menuntut kepercayaan pada satu pihak tunggal. Itulah persis sifat yang kamu inginkan dari perangkat lunak swakelola.
Terus melangkah
Sebuah dompet hanya sepercaya rantai yang membangunnya. Kabar baiknya, ini salah satu dari sedikit masalah keamanan dengan jawaban yang bersih dan struktural: build deterministik ditambah audit independen mengubah "percayalah pada kami" menjadi "verifikasi sendiri".
Teruslah membangun pertahananmu dengan kewaspadaan phishing, praktik terbaik frasa benih, higiene ekstensi peramban, dan daftar periksa opsec yang rutin. Masing-masing menutup satu pintu; bersama-sama, itulah wujud sebenarnya dari keamanan swakelola.
