Audit Keamanan

Apa Itu Audit Keamanan dalam Kripto?

Audit keamanan dalam kripto adalah peninjauan terstruktur terhadap sistem blockchain, smart contract, wallet, protokol, bridge, dApp, dan infrastruktur untuk menemukan kerentanan sebelum dapat dieksploitasi oleh penyerang.

Sederhananya, audit keamanan adalah pemeriksaan profesional terhadap kode kripto, arsitektur, asumsi, izin, dan kontrol operasional.

Tujuannya adalah mengidentifikasi bug, kelemahan desain, hak istimewa yang tidak aman, jalur serangan ekonomi, dan risiko integrasi sebelum dana pengguna benar-benar terpapar.

Audit keamanan sangat penting dalam kripto karena smart contract dapat menyimpan nilai yang besar, sementara transaksi blockchain biasanya sulit atau mustahil dibatalkan setelah dikonfirmasi.

Bug perangkat lunak biasa dapat menyebabkan layanan berhenti atau data hilang, tetapi bug smart contract dapat mengakibatkan kehilangan token secara langsung, dana terkunci, governance rusak, likuidasi gagal, atau likuiditas dicuri.

Panduan keamanan smart contract resmi Ethereum menjelaskan bahwa audit berguna, tetapi tidak boleh dianggap sebagai solusi yang dapat mengatasi semua masalah.

Artinya, audit keamanan merupakan lapisan pertahanan yang penting, bukan jaminan bahwa protokol sepenuhnya aman.

Proses keamanan kripto yang kuat menggabungkan desain aman, pengujian, tinjauan kode, audit, metode formal, pemantauan, bug bounty, respons insiden, dan pengelolaan upgrade yang cermat.

Definisi Sederhana Audit Keamanan

Audit keamanan adalah peninjauan terperinci untuk memeriksa kelemahan sistem kripto sebelum peluncuran atau upgrade besar.

Untuk smart contract, audit biasanya meninjau kode sumber, logika bisnis, kontrol akses, pencatatan token, penggunaan oracle, kemampuan upgrade, perilaku biaya gas, dan pola kerentanan yang diketahui.

Untuk protokol secara keseluruhan, audit juga dapat meninjau risiko frontend, layanan backend, kunci admin, kontrol multisig, desain bridge, infrastruktur validator, proses governance, dan rencana pemantauan.

Laporan audit keamanan biasanya mencantumkan temuan berdasarkan tingkat keparahan, menjelaskan risikonya, merekomendasikan perbaikan, serta mencatat apakah tim telah memperbaiki atau mengakui setiap masalah.

Audit keamanan membantu pengguna, developer, investor, dan mitra ekosistem memahami apakah proyek telah mengambil langkah yang wajar untuk mengurangi risiko yang dapat dicegah.

Namun, audit tidak membuktikan bahwa protokol bebas risiko.

Audit hanya menunjukkan bahwa lingkup tertentu ditinjau oleh auditor tertentu dalam periode tertentu.

Mengapa Audit Keamanan Penting dalam Kripto

Audit keamanan penting karena sistem kripto sering mengelola aset secara langsung melalui kode.

Kontrak pinjaman DeFi dapat menyimpan agunan dan posisi utang.

Pool likuiditas dapat menyimpan token yang disediakan pengguna.

Bridge dapat mengendalikan aset wrapped di berbagai chain.

Kontrak staking dapat mengelola delegasi validator dan pencatatan reward.

Kontrak governance dapat mengendalikan upgrade, dana treasury, dan parameter protokol.

Jika salah satu sistem tersebut memiliki kerentanan serius, penyerang mungkin dapat menguras dana atau merusak kepercayaan secara permanen.

Audit keamanan mengurangi kemungkinan kesalahan yang jelas dan berdampak besar masuk ke lingkungan produksi.

Audit juga membantu tim meningkatkan dokumentasi, memperjelas asumsi, dan menyiapkan prosedur deployment yang lebih aman.

Hal yang Biasanya Ditinjau dalam Audit Keamanan Kripto

Audit keamanan kripto biasanya dimulai dengan dokumentasi proyek dan threat model.

Auditor perlu memahami fungsi yang seharusnya dijalankan protokol sebelum dapat menilai apakah kode beroperasi dengan aman.

Selanjutnya, auditor meninjau kode smart contract baris demi baris.

Auditor memeriksa apakah saldo dicatat dengan benar, izin dibatasi, panggilan eksternal aman, dan kondisi khusus ditangani.

Auditor juga menguji apakah sistem dapat disalahgunakan melalui reentrancy, manipulasi harga, sumber keacakan yang buruk, kesalahan integer, pemutaran ulang tanda tangan, denial of service, upgrade yang tidak aman, atau kontrol akses yang rusak.

Halaman resmi pertimbangan keamanan Solidity memperingatkan bahwa panduan keamanan smart contract tidak akan pernah lengkap karena risiko dan pola baru terus bermunculan.

Karena itu, audit memerlukan checklist yang telah dikenal sekaligus pemikiran adversarial yang kreatif.

Audit yang baik tidak hanya menanyakan apakah kode berfungsi, tetapi juga bagaimana kode dapat gagal dalam kondisi yang bermusuhan.

Audit Keamanan vs. Tinjauan Kode

Tinjauan kode memeriksa apakah kode mudah dibaca, benar, mudah dipelihara, dan sesuai dengan standar pengembangan.

Audit keamanan berfokus lebih mendalam pada cara kode dapat diserang, disalahgunakan, dilewati, atau digunakan secara keliru.

Keduanya berguna, tetapi tidak sama.

Peninjau kode biasa mungkin menanyakan apakah suatu fungsi rapi dan mudah dipahami.

Auditor keamanan menanyakan apakah fungsi tersebut dapat dieksploitasi melalui input yang tidak biasa, urutan panggilan yang tidak terduga, penyalahgunaan governance, manipulasi oracle, atau interaksi kontrak berbahaya.

Tim kripto sebaiknya melakukan tinjauan kode internal sebelum menyewa auditor eksternal.

Auditor eksternal seharusnya bukan pihak pertama yang membaca kode yang belum selesai.

Hasil audit biasanya paling baik jika tim sudah menguji, mendokumentasikan, dan merapikan codebase.

Audit Keamanan vs. Verifikasi Formal

Verifikasi formal menggunakan metode matematika untuk membuktikan bahwa kode memenuhi sifat tertentu berdasarkan asumsi yang telah ditetapkan.

Audit keamanan memiliki cakupan lebih luas dan dapat mencakup tinjauan manual, analisis berbantuan alat, penalaran ekonomi, tinjauan arsitektur, dan penilaian risiko deployment.

Verifikasi formal dapat sangat berguna untuk sifat penting, seperti pelestarian saldo, aturan otorisasi, atau pemeliharaan invariant.

Namun, verifikasi formal hanya membuktikan sifat yang benar-benar ditentukan.

Jika spesifikasinya tidak lengkap atau keliru, pembuktian tersebut mungkin tidak melindungi dari risiko yang sebenarnya.

Audit dan verifikasi formal bekerja paling baik jika digunakan bersama.

Auditor dapat membantu mengidentifikasi sifat yang penting, sementara metode formal dapat memberikan keyakinan lebih kuat bahwa sifat tersebut terpenuhi.

Untuk protokol bernilai tinggi, verifikasi formal dapat menjadi pelengkap yang berguna bagi audit keamanan manual.

Audit Keamanan vs. Bug Bounty

Audit keamanan biasanya merupakan peninjauan terencana oleh auditor terpilih dengan lingkup dan jangka waktu yang ditentukan.

Bug bounty adalah program berkelanjutan yang memberi reward kepada peneliti eksternal yang melaporkan kerentanan secara bertanggung jawab.

Audit berguna sebelum peluncuran karena memberikan tinjauan ahli yang terfokus.

Bug bounty berguna setelah peluncuran karena sistem dapat menghadapi integrasi, kondisi pasar, dan metode serangan baru seiring waktu.

Bug bounty juga dapat menarik peneliti dengan keterampilan dan perspektif yang beragam.

Bug bounty tidak boleh menggantikan audit sebelum deployment.

Audit tidak boleh menggantikan pemantauan keamanan berkelanjutan setelah deployment.

Program keamanan kripto yang kuat sering menggunakan keduanya.

Jenis Audit Keamanan Kripto yang Umum

Audit Smart Contract

Audit smart contract meninjau kode on-chain yang menjalankan logika protokol.

Inilah makna audit keamanan yang paling umum dalam dunia kripto.

Auditor memeriksa kontrak token, kontrak pinjaman, kontrak staking, kontrak vault, kontrak governance, pool likuiditas, kontrak NFT, dan kontrak bridge.

Peninjauan mencakup bug teknis dan kelemahan logika bisnis.

Audit Arsitektur Protokol

Audit arsitektur protokol meninjau cara berbagai kontrak, layanan, pelaku, dan sistem off-chain bekerja bersama.

Audit ini penting karena protokol dapat tidak aman meskipun setiap kontrak secara terpisah tampak wajar.

Misalnya, oracle mungkin terlalu dipercaya, kunci admin mungkin memiliki terlalu banyak wewenang, atau aturan likuidasi mungkin gagal saat kondisi pasar ekstrem.

Audit arsitektur membantu mengidentifikasi risiko pada tingkat sistem.

Audit Keamanan Bridge

Audit bridge meninjau verifikasi pesan cross-chain, kumpulan validator, relayer, ambang tanda tangan, kustodi aset, logika minting, dan pemulihan dari kegagalan.

Sistem bridge berisiko tinggi karena sering mengendalikan aset di lebih dari satu chain.

Bug bridge dapat berdampak pada chain asal dan chain tujuan.

Audit bridge sebaiknya mencakup tinjauan kode, analisis kepercayaan terhadap validator, kontrol operasional, dan perencanaan respons darurat.

Audit Keamanan Wallet

Audit wallet meninjau pengelolaan kunci privat, perlindungan frasa pemulihan, penandatanganan transaksi, tampilan alamat, alur pemulihan, logika account abstraction, dan keamanan antarmuka pengguna.

Keamanan wallet sangat penting karena pengguna mengandalkan wallet untuk memahami apa yang mereka tanda tangani.

Wallet dapat memiliki kriptografi yang kuat, tetapi tetap membuat pengguna rentan terhadap phishing jika permintaan transaksi tidak jelas.

Audit wallet sebaiknya mencakup tinjauan keamanan teknis dan pengalaman pengguna.

Audit Infrastruktur

Audit infrastruktur meninjau node, endpoint RPC, indexer, layanan backend, pipeline deployment, kontrol akses, sistem cloud, pemantauan, dan proses respons insiden.

Pengguna kripto sering berfokus pada smart contract, tetapi kegagalan infrastruktur juga dapat menyebabkan kerugian besar atau gangguan layanan.

Protokol mungkin bergantung pada keeper off-chain, feed harga, validator, sequencer, relayer, atau bot.

Sistem tersebut perlu ditinjau sebagai bagian dari model keamanan yang lebih luas.

Cara Kerja Audit Keamanan Smart Contract

Audit keamanan smart contract biasanya dimulai dengan penentuan lingkup.

Tim dan auditor menyepakati kontrak, branch, commit, dokumentasi, pengujian, skrip, dan rencana deployment yang akan disertakan.

Selanjutnya, auditor mempelajari perilaku yang diharapkan dari proyek dan threat model-nya.

Auditor meninjau kode secara manual dan menjalankan alat analisis otomatis.

Auditor dapat menulis exploit proof-of-concept untuk memastikan apakah suatu kerentanan benar-benar dapat dieksploitasi.

Auditor juga dapat menguji kondisi khusus melalui unit test, fuzz test, invariant test, atau simulasi.

Setelah peninjauan, auditor menyampaikan temuan beserta tingkat keparahan dan rekomendasi.

Tim proyek memperbaiki masalah, lalu auditor dapat melakukan peninjauan remediasi untuk memastikan perbaikannya berfungsi.

Apa yang Perlu Dicakup dalam Lingkup Audit?

Lingkup audit sebaiknya mencakup semua kode yang dapat memengaruhi dana pengguna, izin, pencatatan, upgrade, governance, atau integrasi eksternal.

Lingkup audit sebaiknya mencakup smart contract yang direncanakan untuk deployment.

Lingkup audit sebaiknya mencakup skrip upgrade dan deployment karena kontrak yang aman dapat menjadi tidak aman jika deployment dilakukan dengan keliru.

Lingkup audit sebaiknya mencakup file konfigurasi penting, penetapan peran, pengaturan kontrol akses, dan parameter inisialisasi.

Lingkup audit sebaiknya mencakup integrasi oracle, adapter bridge, logika keeper, dan asumsi mengenai dependensi eksternal.

Lingkup audit juga sebaiknya mencakup dokumentasi yang menjelaskan perilaku yang diharapkan dan asumsi kepercayaan yang diketahui.

Lingkup yang sempit dapat menurunkan biaya audit, tetapi juga dapat melewatkan risiko tingkat sistem.

Pengguna yang membaca laporan audit sebaiknya selalu memeriksa apa yang disertakan dan dikecualikan.

Kerentanan Umum yang Ditemukan dalam Audit Keamanan

Salah satu kerentanan umum adalah reentrancy, yaitu ketika panggilan eksternal memungkinkan eksekusi berulang yang tidak terduga sebelum pembaruan status selesai.

Kerentanan umum lainnya adalah kontrol akses yang rusak, ketika alamat yang salah dapat memanggil fungsi dengan hak istimewa.

Masalah umum lainnya adalah manipulasi oracle, ketika penyerang memengaruhi input harga yang digunakan sistem pinjaman, trading, atau agunan.

Masalah umum lainnya adalah kemampuan upgrade yang tidak aman, ketika kontrak proxy atau kunci admin dapat mengubah logika dengan cara yang berbahaya.

Masalah umum lainnya adalah pemutaran ulang tanda tangan, ketika tanda tangan yang valid digunakan kembali dalam konteks yang tidak semestinya.

Masalah umum lainnya adalah keacakan yang buruk, ketika kontrak menggunakan sumber yang dapat diprediksi untuk game, lotre, atau penentuan NFT.

OWASP Smart Contract Top 10 menyediakan daftar informasi terkini tentang kategori risiko utama smart contract bagi developer dan tim keamanan.

Auditor menggunakan daftar seperti ini sebagai titik awal, tetapi audit serius juga harus mencari kelemahan logika yang spesifik pada proyek.

Tingkat Keparahan dalam Laporan Audit

Laporan audit biasanya mengklasifikasikan temuan berdasarkan tingkat keparahan.

Temuan kritis dapat memungkinkan pencurian langsung, kehilangan dana permanen, minting tanpa izin, atau pengambilalihan protokol secara penuh.

Temuan berkeparahan tinggi dapat menyebabkan kerugian serius, penyalahgunaan hak istimewa, pencatatan yang rusak, atau denial of service besar.

Temuan berkeparahan sedang dapat menimbulkan risiko berarti dalam kondisi tertentu atau jika digabungkan dengan masalah lain.

Temuan berkeparahan rendah dapat berkaitan dengan kelemahan keamanan yang lebih kecil, kondisi khusus, atau peluang untuk memperkuat sistem.

Temuan informasional dapat mencakup saran kualitas kode, peningkatan gas, kekurangan dokumentasi, atau catatan praktik terbaik.

Tingkat keparahan sebagian bersifat teknis dan sebagian bergantung pada konteks.

Bug yang tampak kecil dalam satu protokol dapat menjadi kritis dalam protokol lain jika memengaruhi pencatatan inti atau kontrol dengan hak istimewa.

Audit Keamanan dan Kontrol Akses

Kontrol akses merupakan salah satu bagian terpenting dalam audit keamanan kripto.

Auditor memeriksa siapa yang dapat menjeda kontrak, meng-upgrade logika, mengubah biaya, memperbarui oracle, melakukan mint token, menarik dana, memasukkan pengguna ke whitelist, atau mengubah parameter protokol.

Auditor juga memeriksa apakah peran dengan hak istimewa diberikan kepada multisig yang aman, timelock, kontrak governance, atau wallet berkunci tunggal yang tidak aman.

Kontrol akses yang buruk dapat mengubah protokol yang tampak terdesentralisasi menjadi sistem yang dikendalikan oleh satu kunci yang dibobol.

Auditor sebaiknya mengidentifikasi peran dengan hak istimewa secara jelas dalam laporan.

Pengguna sebaiknya membaca laporan audit untuk memahami siapa yang dapat mengubah sistem setelah peluncuran.

Kontrak yang telah diaudit pun dapat berisiko jika admin mempertahankan wewenang luas tanpa kontrol transparan.

Kontrol akses yang kuat sebaiknya mengikuti prinsip hak istimewa minimum.

Audit Keamanan dan Kontrak yang Dapat Di-upgrade

Kontrak yang dapat di-upgrade memungkinkan logika protokol diubah setelah deployment.

Fitur ini dapat membantu tim memperbaiki bug dan meningkatkan fitur.

Fitur ini juga dapat menimbulkan risiko kepercayaan dan governance yang besar.

Audit sebaiknya meninjau pola proxy, tata letak penyimpanan, fungsi inisialisasi, izin upgrade, timelock, dan kontrol darurat.

Kesalahan tata letak penyimpanan dapat merusak saldo atau izin saat upgrade.

Fungsi inisialisasi yang tidak terlindungi dapat memungkinkan penyerang mengambil alih kontrak.

Peran upgrade tanpa pembatasan dapat mengganti kode yang aman dengan kode berbahaya.

Pengguna perlu memahami apakah protokol yang telah diaudit masih dapat di-upgrade oleh admin atau governance di kemudian hari.

Audit Keamanan dan Oracle

Oracle membawa data eksternal seperti harga, suku bunga, cadangan, atau keacakan ke dalam smart contract.

Banyak protokol DeFi bergantung pada oracle untuk likuidasi, swap, batas pinjaman, penetapan harga vault, dan penyelesaian.

Audit sebaiknya meninjau apakah data oracle dapat dimanipulasi, tertunda, kedaluwarsa, atau salah dikonfigurasi.

Audit juga sebaiknya memeriksa logika cadangan, kesegaran data, penanganan desimal, circuit breaker, dan risiko spesifik aset.

Risiko oracle bukan hanya masalah kode.

Risiko ini juga berkaitan dengan ekonomi dan struktur pasar.

Feed harga mungkin benar secara teknis, tetapi tetap tidak aman jika pasar yang mendasarinya terlalu tidak likuid atau mudah dimanipulasi.

Audit yang kuat meninjau integrasi oracle sekaligus asumsi di balik datanya.

Audit Keamanan dan Serangan Ekonomi

Protokol kripto dapat gagal meskipun kodenya tidak memiliki bug pemrograman sederhana.

Serangan ekonomi mengeksploitasi insentif, likuiditas, governance, waktu oracle, leverage, atau mekanisme pasar.

Protokol pinjaman dapat gagal jika agunan dapat dinilai terlalu tinggi untuk sementara waktu.

Pool likuiditas dapat dikuras jika rumus penetapan harganya disalahgunakan.

Sistem governance dapat diambil alih jika voting power dapat dipinjam atau dikonsentrasikan dengan cepat.

Bridge dapat gagal jika insentif validator lemah atau pengelolaan kunci buruk.

Audit keamanan sebaiknya mempertimbangkan perilaku ekonomi, bukan hanya sintaks kode.

Karena itu, audit DeFi sering memerlukan keahlian teknis sekaligus analisis risiko keuangan.

Audit Keamanan dan Alat Otomatis

Alat otomatis dapat membantu auditor menemukan pola kerentanan yang dikenal dengan cepat.

Alat ini dapat mencakup static analyzer, fuzzer, alat symbolic execution, linter, pemindai dependensi, dan kerangka invariant testing.

Alat otomatis berguna, tetapi tidak dapat menggantikan tinjauan manual oleh ahli.

Sebuah makalah penelitian terbaru tentang penganalisis keamanan smart contract menemukan perbedaan besar dalam akurasi alat dan mencatat masalah seperti false positive, false negative, penjelasan yang tidak jelas, dan waktu eksekusi yang lama.

Artinya, hasil alat perlu ditinjau oleh manusia yang memahami konteks protokol.

Alat otomatis paling cocok untuk cakupan, tugas berulang, dan pola yang telah diketahui.

Auditor manual paling cocok untuk logika bisnis, penalaran ekonomi, arsitektur, dan jalur serangan kreatif.

Audit yang serius menggunakan alat sebagai asisten, bukan penentu akhir.

Audit Keamanan dan Pengujian

Pengujian merupakan fondasi proses audit yang baik.

Sebelum audit eksternal, tim sebaiknya sudah memiliki unit test, integration test, fuzz test, dan invariant test jika sesuai.

Unit test memeriksa fungsi individual.

Integration test memeriksa cara berbagai komponen bekerja bersama.

Fuzz test mencoba banyak input acak atau semiacak untuk menemukan kegagalan tak terduga.

Invariant test memeriksa apakah aturan penting selalu tetap benar.

Misalnya, protokol pinjaman mungkin mensyaratkan agar total utang dan pencatatan agunan selalu konsisten.

Audit akan lebih efektif jika auditor dapat meninjau dan mengembangkan test suite yang sudah ada, bukan memulai dari nol.

Audit Keamanan dan Standar

Standar keamanan membantu tim dan auditor menerapkan kriteria yang konsisten.

OWASP Smart Contract Security Verification Standard menyediakan persyaratan dan pengujian keamanan untuk smart contract, dApp, dan sistem blockchain berbasis EVM.

EEA EthTrust Security Levels Specification menetapkan persyaratan untuk tingkat sertifikasi keamanan smart contract.

Standar tidak menggantikan tinjauan ahli, tetapi membuat audit lebih konsisten dan mudah dibandingkan.

Standar juga membantu tim pengembangan mempersiapkan diri sebelum auditor mulai bekerja.

Protokol yang mengikuti standar yang diakui tetap dapat memiliki bug, tetapi memiliki struktur awal yang lebih baik untuk tinjauan keamanan.

Pengguna sebaiknya memilih laporan audit yang menjelaskan metodologi, bukan hanya menampilkan logo atau judul.

Metodologi yang jelas memudahkan evaluasi audit.

Hal yang Perlu Dicantumkan dalam Laporan Audit

Laporan audit yang berguna sebaiknya mengidentifikasi proyek, lingkup audit, commit kode, tanggal, auditor, metodologi, dan keterbatasan.

Laporan sebaiknya menjelaskan protokol secara umum.

Laporan sebaiknya mencantumkan semua temuan beserta tingkat keparahan, dampak, kemungkinan, file yang terdampak, penjelasan teknis, dan rekomendasi perbaikan.

Laporan sebaiknya menunjukkan apakah setiap masalah telah diperbaiki, diperbaiki sebagian, diakui, atau belum diselesaikan.

Laporan sebaiknya menjelaskan risiko sentralisasi, wewenang admin, kontrol upgrade, dan peran tepercaya.

Laporan sebaiknya menyebutkan asumsi utama yang berada di luar lingkup audit.

Laporan perlu cukup spesifik agar developer dapat mengambil tindakan dan pengguna dapat memahami risiko utamanya.

Sertifikat yang tidak jelas dan tanpa detail teknis jauh kurang berguna daripada laporan yang terperinci.

Cara Pengguna Membaca Laporan Audit

Pengguna sebaiknya terlebih dahulu memeriksa apakah laporan sesuai dengan kontrak yang telah di-deploy.

Audit terhadap versi kode lama mungkin tidak berlaku untuk deployment saat ini.

Pengguna sebaiknya memeriksa commit hash, alamat kontrak, tanggal deployment, dan riwayat upgrade.

Pengguna juga perlu membaca temuan yang belum diselesaikan, bukan hanya mencari kata “diaudit”.

Proyek dapat telah diaudit dan tetap memiliki risiko serius yang telah diakui.

Pengguna sebaiknya memeriksa apakah temuan kritis dan berkeparahan tinggi telah diperbaiki sebelum peluncuran.

Pengguna juga perlu memeriksa risiko sentralisasi, kunci admin, asumsi oracle, dan dependensi eksternal.

Panduan paling aman sederhana: audit adalah bukti bahwa peninjauan telah dilakukan, bukan bukti bahwa sistem aman.

Audit Keamanan Sebelum Peluncuran Mainnet

Audit sebelum peluncuran meninjau kode sebelum kode tersebut melindungi nilai nyata.

Inilah waktu terbaik untuk menemukan masalah serius karena perbaikan dapat dilakukan sebelum pengguna melakukan deposit aset.

Tim sebaiknya tidak menunggu hingga hari terakhir sebelum peluncuran untuk meminta audit.

Auditor memerlukan waktu untuk memahami sistem, menguji asumsi, mengajukan pertanyaan, dan meninjau perbaikan.

Audit yang terburu-buru dapat melewatkan masalah penting.

Tim sebaiknya membekukan kode sebelum audit dimulai.

Jika kode terus berubah selama peninjauan, lingkup audit menjadi tidak stabil.

Proses audit sebelum peluncuran yang rapi mencakup persiapan, pembekuan kode, peninjauan, remediasi, pengujian ulang, dan deployment yang cermat.

Audit Keamanan Setelah Deployment

Audit setelah deployment penting ketika protokol di-upgrade, menambahkan modul, mengubah oracle atau governance, atau terintegrasi dengan sistem baru.

Protokol kripto tidak bersifat statis.

Seiring waktu, protokol dapat menambahkan aset, chain, vault, pasar, strategi, atau rute bridge baru.

Setiap perubahan dapat menimbulkan risiko baru.

Protokol yang aman saat peluncuran dapat menjadi berisiko setelah upgrade yang tidak ditinjau dengan baik.

Audit setelah deployment membantu mengurangi risiko ini.

Tim juga sebaiknya memantau perilaku protokol yang berjalan karena sebagian risiko hanya muncul dalam kondisi pasar nyata.

Keamanan merupakan siklus hidup, bukan kegiatan satu kali.

Audit Keamanan untuk Protokol DeFi

Audit keamanan DeFi harus meninjau kode dan logika keuangan.

Protokol DeFi mungkin bergantung pada rasio agunan, model bunga, kedalaman likuiditas, feed harga, insentif likuidasi, pencatatan biaya, dan perilaku pengguna.

Auditor sebaiknya menguji apakah pengguna dapat menguras pool, melewati pemeriksaan utang, memanipulasi harga, mencuri reward, atau mengunci dana.

Auditor juga perlu meninjau pembulatan, konversi desimal, asumsi slippage, dan kompatibilitas token.

Audit DeFi sebaiknya mempertimbangkan token yang tidak biasa, seperti token dengan biaya transfer, token rebasing, serta token dengan fungsi blacklist atau pause.

Audit juga perlu meninjau kontrol darurat dan perilaku penarikan dalam kondisi tertekan.

Bagi pengguna, protokol DeFi yang telah diaudit tetap berisiko jika likuiditasnya tipis atau governance-nya tersentralisasi.

Status audit sebaiknya menjadi salah satu bagian dari uji tuntas DeFi.

Audit Keamanan untuk Bridge

Audit bridge termasuk jenis audit keamanan kripto yang paling penting dan sulit.

Bridge dapat mengunci aset di satu chain lalu melakukan mint atau melepas aset di chain lain.

Hal ini menimbulkan risiko pada smart contract, verifikasi pesan, relayer, validator, tanda tangan, kustodi, dan asumsi finalitas.

Auditor sebaiknya meninjau cara bridge membuktikan bahwa suatu peristiwa terjadi di chain lain.

Auditor juga perlu meninjau perlindungan kunci validator dan jumlah tanda tangan yang diperlukan.

Audit bridge sebaiknya menguji serangan replay, penerimaan pesan yang tidak valid, risiko reorganisasi chain, batas penarikan, dan penghentian darurat.

Pengguna sebaiknya berhati-hati saat menggunakan bridge meskipun telah diaudit karena sistem cross-chain bergantung pada lebih banyak asumsi daripada transfer token biasa.

Audit bridge sebaiknya menjelaskan asumsi-asumsi tersebut dengan jelas.

Audit Keamanan untuk NFT dan Game

Audit NFT dan game meninjau logika mint, kontrol metadata, keacakan, royalti, pembatasan transfer, persetujuan marketplace, dan aturan aset dalam game.

Keacakan sangat penting ketika pengguna membayar untuk mint misteri, loot box, atau atribut acak.

Keacakan yang lemah dapat memungkinkan orang dalam, miner, validator, atau bot memprediksi atau memanipulasi hasil.

Auditor juga perlu meninjau apakah pemilik proyek dapat mengubah metadata dengan cara yang menyesatkan.

Proyek game sebaiknya meninjau minting aset, burning, reward, logika inventori, dan perpindahan aset cross-chain.

Pengguna NFT tidak boleh menganggap proyek aman hanya karena kontrak mint telah diaudit.

Situs web, permintaan wallet, persetujuan marketplace, dan kontrol admin juga penting.

Jika memungkinkan, audit NFT sebaiknya mencakup seluruh alur pengguna.

Audit Keamanan untuk Wallet

Audit wallet sangat penting karena wallet merupakan antarmuka utama antara pengguna dan blockchain.

Audit wallet sebaiknya meninjau pembuatan frasa pemulihan, penyimpanan kunci privat, alur penandatanganan, tampilan alamat, prosedur pencadangan, simulasi transaksi, dan perlindungan phishing.

Audit juga sebaiknya meninjau izin ekstensi browser, penyimpanan aplikasi seluler, integrasi hardware wallet, dan distribusi pembaruan.

Wallet dapat gagal jika menandatangani data yang salah, menampilkan alamat yang keliru, atau menyembunyikan detail transaksi penting.

Audit wallet sebaiknya mencakup aspek kemudahan penggunaan agar pengguna memahami apa yang mereka setujui.

Penandatanganan yang jelas dapat mengurangi kesalahan, tetapi hanya jika detail transaksi ditampilkan secara akurat.

Keamanan wallet juga bergantung pada kanal pembaruan yang aman dan perlindungan terhadap versi palsu.

Pengguna sebaiknya mengunduh wallet hanya dari sumber tepercaya dan melindungi frasa pemulihan secara offline.

Audit Keamanan dan Risiko Governance

Risiko governance muncul ketika pemegang token, delegasi, multisig, atau peran admin dapat mengubah perilaku protokol.

Audit sebaiknya meninjau aturan voting, ambang proposal, kuorum, timelock, wewenang darurat, dan logika eksekusi.

Audit perlu memeriksa apakah penyerang dapat meminjam voting power, meloloskan proposal berbahaya, atau melewati penundaan.

Audit juga perlu meninjau apakah sekelompok kecil orang dapat meng-upgrade kontrak atau memindahkan dana treasury.

Governance dapat menjadi keunggulan jika transparan dan dirancang dengan baik.

Governance dapat menjadi risiko jika memberikan kendali luas kepada kunci yang tidak terlindungi dengan baik atau sistem voting dengan partisipasi rendah.

Pengguna sebaiknya membaca laporan audit untuk memahami asumsi governance.

Protokol dapat diaudit secara teknis tetapi tetap sangat tersentralisasi.

Audit Keamanan dan Keamanan Operasional

Keamanan operasional mencakup cara tim mengelola kunci, deployment, akses, pemantauan, dan respons darurat.

Protokol dapat memiliki kode yang aman tetapi operasional yang tidak aman.

Misalnya, kunci deployment dapat disimpan di laptop yang tidak aman.

Multisig mungkin memiliki terlalu sedikit penanda tangan atau distribusi penanda tangan yang buruk.

Upgrade dapat dijalankan tanpa checklist.

Sistem peringatan dapat gagal saat terjadi serangan.

Audit keamanan sebaiknya meninjau asumsi operasional jika asumsi tersebut memengaruhi dana pengguna.

Keamanan operasional yang kuat mencakup penyimpanan kunci yang aman, pemisahan peran, pencatatan, pemantauan, panduan insiden, dan disiplin pascainsiden.

Audit Keamanan dan Keterbatasannya

Audit keamanan tidak dapat menemukan setiap bug yang mungkin ada.

Audit tidak dapat menjamin bahwa protokol tidak akan pernah dieksploitasi.

Audit tidak dapat sepenuhnya memprediksi kondisi pasar, keputusan governance, atau perubahan integrasi di masa mendatang.

Audit tidak dapat melindungi pengguna yang menandatangani transaksi berbahaya di luar sistem yang diaudit.

Audit tidak dapat memperbaiki dokumentasi yang lemah, deployment yang terburu-buru, atau respons insiden yang buruk kecuali tim menindaklanjuti temuannya.

Audit tidak dapat menjamin keamanan upgrade mendatang yang belum diaudit.

Karena itu, pengguna sebaiknya tidak menganggap status “diaudit” sebagai label keamanan ya atau tidak.

Pertanyaan sebenarnya adalah apa yang diaudit, siapa yang meninjaunya, apa yang ditemukan, apa yang diperbaiki, dan risiko apa yang masih ada.

Tanda Bahaya dalam Audit Keamanan

Tidak adanya laporan audit publik merupakan tanda bahaya jika proyek mengklaim telah diaudit.

Laporan audit tanpa lingkup, commit hash, dan detail temuan merupakan tanda bahaya.

Laporan yang mencantumkan temuan kritis yang belum diselesaikan merupakan peringatan serius.

Proyek yang mengubah kode setelah audit tanpa peninjauan baru menimbulkan risiko tambahan.

Proyek yang menyembunyikan wewenang admin atau izin upgrade perlu disikapi dengan hati-hati.

Proyek yang menyatakan audit menjamin keamanan membuat klaim yang menyesatkan.

Proyek tanpa test suite, pemantauan, dan proses darurat dapat tetap berisiko setelah audit.

Pengguna sebaiknya bersikap skeptis jika klaim audit hanya digunakan sebagai materi pemasaran.

Praktik Terbaik Sebelum Meminta Audit

Tim sebaiknya menyiapkan dokumentasi yang jelas sebelum meminta audit.

Tim sebaiknya membekukan kode atau menentukan commit yang akan ditinjau secara tepat.

Tim sebaiknya menyiapkan diagram arsitektur, threat model, rencana deployment, dan invariant yang diharapkan.

Tim sebaiknya menyertakan test suite lengkap dan menjelaskan masalah yang diketahui.

Tim sebaiknya tidak menambahkan fitur besar selama audit.

Tim sebaiknya memberikan waktu yang cukup kepada auditor untuk melakukan peninjauan secara cermat.

Tim sebaiknya segera menjawab pertanyaan dan memperbaiki temuan dengan saksama.

Tim yang siap memperoleh lebih banyak manfaat dari audit dibandingkan tim yang menganggap auditor sebagai checklist pada menit terakhir.

Praktik Terbaik Setelah Audit

Tim sebaiknya memperbaiki temuan serius sebelum peluncuran.

Tim sebaiknya meminta auditor meninjau perbaikan yang penting.

Tim sebaiknya menerbitkan laporan akhir jika aman dan sesuai.

Tim sebaiknya mendokumentasikan risiko yang diakui tetapi tidak diperbaiki.

Tim sebaiknya memverifikasi bytecode yang di-deploy dan alamat kontrak.

Tim sebaiknya memantau protokol setelah peluncuran.

Tim sebaiknya menjalankan bug bounty atau proses pengungkapan kerentanan secara bertanggung jawab jika protokol mengendalikan nilai yang berarti.

Tim sebaiknya menjadwalkan audit baru untuk upgrade besar.

Cara Pengguna Mengevaluasi Proyek yang Telah Diaudit

Pengguna sebaiknya terlebih dahulu memastikan bahwa laporan audit asli dan tersedia untuk publik.

Pengguna sebaiknya memeriksa apakah laporan mencakup kontrak yang saat ini telah di-deploy.

Pengguna sebaiknya mencari masalah kritis atau berkeparahan tinggi yang belum diselesaikan.

Pengguna sebaiknya memeriksa apakah sistem bernilai tinggi atau kompleks memiliki beberapa audit.

Pengguna sebaiknya meninjau kontrol admin, kemampuan upgrade, desain oracle, kustodi, dan dependensi bridge.

Pengguna sebaiknya memeriksa apakah protokol memiliki bug bounty, pemantauan, dan rencana jeda darurat.

Pengguna sebaiknya mempertimbangkan Total Value Locked karena nilai yang lebih tinggi dapat menarik penyerang yang lebih kuat.

Audit seharusnya meningkatkan keyakinan, tetapi tidak menghilangkan kehati-hatian.

Audit Keamanan dan Asuransi

Sebagian pengguna kripto mencari asuransi atau perlindungan setelah melihat audit.

Audit dapat membantu perusahaan asuransi atau penilai risiko memahami protokol, tetapi tidak otomatis memberikan perlindungan asuransi.

Ketentuan pertanggungan dapat mengecualikan eksploitasi tertentu, kegagalan governance, serangan oracle, kegagalan bridge, atau kesalahan pengguna.

Pengguna sebaiknya membaca ketentuan asuransi dengan saksama sebelum mengandalkannya.

Protokol tidak boleh menyiratkan bahwa audit berarti pengguna terlindungi secara finansial, kecuali memang ada pengaturan perlindungan yang nyata.

Asuransi, audit, bug bounty, dan pemantauan adalah alat manajemen risiko yang terpisah.

Setiap alat memiliki keterbatasan yang berbeda.

Keamanan yang kuat menggunakan beberapa lapisan.

Audit Keamanan dan Ekspektasi Regulasi

Regulasi kripto semakin memperhatikan kontrol keamanan, kustodi, pengungkapan, ketahanan operasional, dan manajemen risiko.

Audit keamanan dapat membantu menunjukkan bahwa proyek menanggapi risiko teknis dengan serius.

Namun, audit smart contract tidak sama dengan kepatuhan hukum.

Token dapat diaudit dan tetap menimbulkan masalah sekuritas, perlindungan konsumen, sanksi, pajak, atau kustodi.

Proyek yang menangani dana pengguna sebaiknya mempertimbangkan tinjauan hukum selain tinjauan teknis.

Keamanan dan kepatuhan merupakan bidang berbeda, tetapi sering saling berkaitan dalam produk kripto.

Misalnya, platform aset tokenisasi mungkin memerlukan audit smart contract sekaligus kontrol hukum atas catatan kepemilikan.

Pengguna tidak boleh mencampuradukkan keamanan teknis dengan persetujuan regulator.

Kesalahpahaman Umum tentang Audit Keamanan

Kesalahpahaman umum adalah bahwa proyek yang diaudit berarti aman.

Diaudit berarti ditinjau dalam lingkup yang ditentukan, bukan dijamin aman selamanya.

Kesalahpahaman lainnya adalah satu audit cukup untuk semua versi berikutnya.

Kode baru, aset baru, chain baru, dan integrasi baru dapat menimbulkan risiko baru.

Kesalahpahaman lainnya adalah alat otomatis dapat menggantikan auditor manusia.

Alat memang membantu, tetapi sering melewatkan kelemahan logika yang spesifik pada konteks.

Kesalahpahaman lainnya adalah hanya smart contract yang memerlukan audit keamanan.

Wallet, bridge, frontend, backend, sistem governance, dan proses operasional juga memerlukan tinjauan keamanan.

FAQ

Apa itu audit keamanan dalam kripto?

Audit keamanan dalam kripto adalah peninjauan terstruktur terhadap smart contract, protokol, wallet, atau infrastruktur untuk mengidentifikasi kerentanan sebelum dieksploitasi oleh penyerang.

Apa itu audit smart contract?

Audit smart contract adalah tinjauan keamanan atas kode on-chain untuk memeriksa bug, logika yang tidak aman, masalah kontrol akses, masalah oracle, dan jalur eksploitasi lainnya.

Apakah audit berarti proyek kripto aman?

Tidak. Audit meningkatkan keyakinan, tetapi tidak menjamin proyek sepenuhnya aman atau bebas dari eksploitasi di masa mendatang.

Apa yang sebaiknya tercantum dalam laporan audit?

Laporan audit sebaiknya mencakup lingkup, commit hash, metodologi, temuan, tingkat keparahan, rekomendasi, status remediasi, keterbatasan, dan risiko yang tersisa.

Mengapa smart contract perlu diaudit?

Smart contract perlu diaudit karena dapat mengendalikan dana pengguna secara langsung dan mungkin sulit diubah setelah deployment.

Apa perbedaan audit dan bug bounty?

Audit adalah peninjauan terfokus oleh auditor terpilih, sedangkan bug bounty merupakan program reward berkelanjutan bagi peneliti eksternal yang melaporkan kerentanan.

Dapatkah alat otomatis menggantikan auditor keamanan?

Tidak. Alat otomatis berguna untuk menemukan pola yang dikenal, tetapi auditor manusia diperlukan untuk menilai kelemahan logika, serangan ekonomi, dan konteks spesifik protokol.

Apa temuan audit yang umum?

Temuan audit yang umum mencakup reentrancy, kontrol akses yang rusak, manipulasi oracle, upgrade yang tidak aman, pemutaran ulang tanda tangan, keacakan yang buruk, dan kesalahan pencatatan.

Seberapa sering proyek kripto perlu diaudit?

Proyek sebaiknya diaudit sebelum peluncuran besar dan diaudit kembali ketika melakukan upgrade besar, menambahkan modul, mengintegrasikan aset baru, atau mengubah asumsi inti.

Apa arti lingkup audit?

Lingkup audit adalah kode, kontrak, sistem, dokumentasi, dan asumsi spesifik yang disertakan dalam peninjauan.

Mengapa commit hash penting dalam audit?

Commit hash membantu pengguna memverifikasi versi kode tertentu yang ditinjau auditor.

Apakah kontrak yang telah diaudit masih dapat diretas?

Ya. Kontrak yang telah diaudit masih dapat diretas karena audit dapat melewatkan bug, kode dapat berubah di kemudian hari, asumsi dapat gagal, atau penyerang dapat mengeksploitasi bagian di luar lingkup audit.

Haruskah pengguna memercayai proyek hanya karena telah diaudit?

Tidak. Pengguna juga perlu meninjau temuan yang belum diselesaikan, wewenang admin, kemampuan upgrade, risiko oracle dan bridge, likuiditas, bug bounty, serta keamanan operasional proyek.

Kesimpulan

Audit keamanan merupakan salah satu alat terpenting untuk mengurangi risiko dalam mata uang kripto.

Audit membantu mengidentifikasi bug smart contract, kelemahan desain protokol, izin yang tidak aman, jalur serangan ekonomi, dan kelemahan operasional sebelum dieksploitasi oleh penyerang.

Audit yang baik tidak hanya meninjau kode, tetapi juga asumsi, arsitektur, kontrol akses, kemampuan upgrade, oracle, skrip deployment, dan risiko yang berdampak pada pengguna.

Namun, audit keamanan bukanlah jaminan.

Audit dibatasi oleh waktu dan lingkup, serta bergantung pada kualitas auditor, dokumentasi, codebase, pengujian, dan proses remediasi.

Proyek kripto terbaik memperlakukan audit sebagai bagian dari siklus keamanan lengkap yang mencakup desain aman, pengujian, metode formal, bug bounty, pemantauan, respons insiden, dan upgrade yang cermat.

Pengguna sebaiknya menganggap laporan audit sebagai bukti yang berguna, bukan slogan pemasaran.

Aturan praktisnya sederhana: proyek yang diaudit mungkin lebih aman daripada proyek yang tidak diaudit, tetapi pertanyaan sebenarnya adalah apa yang diaudit, apa yang ditemukan, apa yang diperbaiki, dan risiko apa yang masih tersisa.