← Kembali ke artikel[Web3]

Audit Smart Contract: Metodologi, Tahapan, dan Deliverable bagi Proyek Web3

·11 min read
Audit Smart Contract: Metodologi, Tahapan, dan Deliverable bagi Proyek Web3 cover

Abstrak. Audit smart contract adalah tinjauan keamanan berbasis bukti terhadap kode on-chain pada versi tertentu, dengan tujuan menemukan kerentanan, menguji invarian, dan merekomendasikan mitigasi sebelum aset pengguna berisiko. Karena kode yang sudah dideploy umumnya tidak dapat ditambal tanpa mekanisme upgrade, biaya kesalahan pada ekosistem Web3 sangat tinggi. Artikel ini menguraikan lanskap risiko berdasarkan OWASP Smart Contract Top 10: 2026, metodologi audit sepuluh fase, struktur laporan, model penugasan keamanan, kesiapan proyek, dan keterbatasan audit.

Catatan: artikel ini bersifat edukatif dan defensif. Seluruh pengujian yang dibahas dilakukan pada lingkungan lokal atau fork terisolasi, dan artikel ini bukan nasihat hukum maupun keuangan.

Poin Utama

  • Audit bukan jaminan. Audit menurunkan risiko, tetapi bersifat point-in-time pada commit tertentu dan tidak menjamin ketiadaan bug.
  • Risiko bergeser ke logika dan tata kelola. Edisi 2026 OWASP Smart Contract Top 10 menempatkan Access Control dan Business Logic pada dua peringkat teratas, dan menambahkan kategori Proxy & Upgradeability.
  • Metodologi berlapis. Audit yang kuat menggabungkan pemodelan ancaman, analisis statis, tinjauan manual, fuzzing dan invariant testing, serta verifikasi formal bila diperlukan.
  • Deliverable utama adalah laporan dengan ruang lingkup, metodologi, temuan berperingkat keparahan, rekomendasi, dan status perbaikan, ditambah verifikasi perbaikan.
  • Kesiapan menentukan kualitas. Kode yang dibekukan, dokumentasi yang jelas, dan tes yang lulus meningkatkan nilai setiap jam audit.
  • Keamanan tidak berhenti pada audit. Pemantauan, bug bounty, timelock, multisig, dan rencana respons insiden menutup risiko residual.

Apa yang Dimaksud dengan Audit Smart Contract

Audit smart contract adalah peninjauan sistematis terhadap kode dan desain kontrak untuk menemukan kelemahan yang dapat menyebabkan kehilangan dana, kehilangan kendali, penguncian aset, atau perilaku yang menyimpang dari spesifikasi. Sasarannya empat: mengidentifikasi kerentanan, memvalidasi invarian yang harus selalu benar, mengevaluasi asumsi kepercayaan dan model ancaman, serta memberi rekomendasi mitigasi yang dapat ditindaklanjuti.

Audit juga memiliki batas yang perlu dipahami sejak awal:

  • Audit bukan pengganti desain yang matang dan pengujian yang memadai oleh tim pengembang.
  • Audit menilai versi kode yang diserahkan. Perubahan setelah commit yang diaudit tidak tercakup.
  • Komponen di luar ruang lingkup, seperti antarmuka web, infrastruktur off-chain, dan pengelolaan kunci, tidak dinilai kecuali dinyatakan secara eksplisit.

Lanskap Risiko 2026: OWASP Smart Contract Top 10

OWASP Smart Contract Top 10: 2026 disusun dari data insiden 2025 dan masukan praktisi. Peringkatnya sebagai berikut:

  1. SC01 Access Control Vulnerabilities: fungsi dan state kritis dapat dipanggil atau diubah oleh pihak yang tidak berwenang, termasuk jalur admin, governance, dan upgrade.
  2. SC02 Business Logic Vulnerabilities: cacat desain pada logika lending, AMM, reward, atau governance yang melanggar aturan ekonomi meski pemeriksaan tingkat rendah tampak benar.
  3. SC03 Price Oracle Manipulation: oracle yang lemah atau integrasi harga yang tidak aman memungkinkan harga rujukan dibelokkan.
  4. SC04 Flash Loan Facilitated Attacks: pinjaman kilat tanpa agunan dipakai untuk memperbesar bug kecil menjadi pengurasan besar dalam satu transaksi.
  5. SC05 Lack of Input Validation: parameter dari pengguna, admin, atau lintas rantai yang tidak divalidasi masuk ke logika inti.
  6. SC06 Unchecked External Calls: kegagalan, revert, atau callback dari kontrak eksternal tidak ditangani dengan aman.
  7. SC07 Arithmetic Errors: kesalahan skala, pembulatan, dan presisi pada perhitungan share, bunga, dan AMM.
  8. SC08 Reentrancy Attacks: pemanggilan ulang fungsi sebelum state diperbarui sepenuhnya.
  9. SC09 Integer Overflow and Underflow: luapan bilangan bulat, terutama pada blok unchecked atau versi kompiler lama.
  10. SC10 Proxy & Upgradeability Vulnerabilities: kategori baru yang mencakup inisialisasi, tata letak storage, dan tata kelola upgrade.

Dua pelajaran penting bagi auditor dan pengembang. Pertama, serangan modern sering merangkai beberapa kelemahan sekaligus, misalnya flash loan dengan manipulasi oracle. Kedua, penurunan peringkat suatu kategori tidak berarti risikonya hilang. Reentrancy tetap perlu diperiksa pada setiap kontrak yang melakukan panggilan eksternal.

Prasyarat: Kesiapan Audit

Proyek yang siap diaudit menghemat waktu dan biaya, karena auditor menghabiskan jam kerja pada logika, bukan pada kekacauan basis kode. Checklist kesiapan:

  • Commit dibekukan (code freeze) dan hash commit dicatat.
  • Kode dapat dikompilasi dan seluruh tes lulus dari lingkungan bersih.
  • Dokumentasi arsitektur, peran, alur dana, dan invarian tertulis, dilengkapi NatSpec pada fungsi publik.
  • Versi kompiler, dependensi, dan konfigurasi build dikunci.
  • Skrip deployment dan parameter awal tersedia untuk ditinjau.
  • Daftar isu yang sudah diketahui dan keputusan desain yang disengaja disertakan.
  • Analisis statis dasar dan linter sudah dijalankan oleh tim sendiri.
  • Jadwal memberi ruang untuk perbaikan dan verifikasi perbaikan sebelum peluncuran.

Metodologi Audit dalam Sepuluh Fase

Fase 1: Penetapan Ruang Lingkup dan Aturan Penugasan

  • Tetapkan repositori, hash commit, daftar berkas, jumlah baris kode sumber (nSLOC), versi kompiler, dan rantai target. Perbedaan EVM dan L2 mempengaruhi opcode, gas, dan asumsi waktu blok.
  • Tentukan dependensi yang masuk dan tidak masuk ruang lingkup, serta integrasi eksternal seperti oracle, AMM, dan bridge.
  • Sepakati perjanjian kerahasiaan, kanal komunikasi, jadwal, jendela verifikasi perbaikan, dan bentuk deliverable.

Fase 2: Pemahaman Arsitektur dan Spesifikasi

  • Baca dokumentasi, diagram, dan spesifikasi, lalu petakan kontrak, peran, titik masuk, alur aset, dan layout storage pada kontrak yang dapat di-upgrade.
  • Jalankan suite tes yang ada dan lakukan sesi penjelasan dengan tim pengembang untuk menyamakan pemahaman tentang maksud desain.

Fase 3: Pemodelan Ancaman dan Perumusan Invarian

  • Identifikasi aktor: pengguna, penyerang, bot keeper, admin, governance, penyedia oracle, dan penerbit token.
  • Tetapkan aset, batas kepercayaan, dan kemampuan penyerang: flash loan, MEV dan front-running, token non-standar (fee-on-transfer, rebasing, hook ERC-777, token dengan daftar blokir, return value yang tidak konsisten), manipulasi oracle, serta kompromi kunci admin.
  • Rumuskan invarian, misalnya solvabilitas (aset selalu mencakup kewajiban), konservasi suplai, batas perubahan harga share, dan urutan status yang sah.

Fase 4: Analisis Statis dan Peninjauan Otomatis

  • Jalankan pemindai statis seperti Slither, dan periksa peringatan kompiler serta linter.
  • Tinjau versi dependensi dan daftar bug kompiler Solidity yang relevan dengan versi yang dipakai.
  • Triase hasil untuk memisahkan temuan sah dari false positive. Alat otomatis membantu cakupan, tetapi tidak menggantikan penalaran manusia.

Fase 5: Peninjauan Manual

Peninjauan manual dilakukan baris demi baris dan pada tingkat sistem. Area yang diperiksa:

  • Kontrol akses: matriks fungsi dan peran, jalur admin, dan risiko kunci tunggal.
  • Reentrancy: termasuk lintas fungsi dan read-only reentrancy pada fungsi view yang dipakai protokol lain.
  • Panggilan eksternal: pengecekan hasil panggilan tingkat rendah dan token ERC-20 non-standar.
  • Aritmetika: arah pembulatan, presisi, penanganan desimal, dan blok unchecked.
  • Vault dan share: serangan inflasi pada deposit pertama, misalnya pada pola ERC-4626.
  • Tanda tangan: domain EIP-712, nonce, tenggat, dan replay lintas rantai.
  • Oracle: kesegaran data, desimal, batas deviasi, dan ketahanan terhadap manipulasi harga spot.
  • Upgradeability: inisialisasi tunggal, penonaktifan initializer pada implementasi, delegatecall, dan layout storage.
  • Penolakan layanan dan griefing: loop tanpa batas, pola push versus pull pada pembayaran, dan ketergantungan pada saldo.
  • Parameter transaksi: perlindungan slippage dan tenggat, serta race pada approval.
  • Risiko sentralisasi: kemampuan owner untuk mencetak, menjeda, mengubah parameter, atau meng-upgrade.

Fase 6: Pengujian Dinamis, Fuzzing, dan Invariant Testing

  • Tinjau tes yang ada dan cakupannya. Cakupan tinggi tidak otomatis berarti tes memadai.
  • Tulis tes fuzz dan invariant, misalnya dengan Foundry, serta uji properti dengan Echidna atau Medusa.
  • Jalankan tes fork terhadap state jaringan untuk memvalidasi integrasi.
  • Bukti konsep untuk temuan berkeparahan tinggi dijalankan hanya pada lingkungan lokal atau fork terisolasi, tidak pada jaringan produksi.

Fase 7: Verifikasi Formal (Bila Diperlukan)

  • Terapkan pada properti kritis seperti konservasi nilai dan solvabilitas, menggunakan alat seperti Certora Prover atau Halmos.
  • Pahami batasnya: kualitas hasil bergantung pada kualitas spesifikasi, model lingkungan, dan asumsi yang dinyatakan.

Fase 8: Klasifikasi Temuan dan Tingkat Keparahan

Tingkat keparahan ditentukan oleh dampak dan kemungkinan terjadinya. Skala yang lazim:

  • Kritis: kehilangan dana atau kendali protokol yang langsung dan luas, dapat dieksploitasi tanpa prasyarat khusus.
  • Tinggi: kehilangan dana atau gangguan signifikan dengan kondisi yang masuk akal.
  • Menengah: dampak terbatas, atau memerlukan kondisi tertentu atau hak istimewa.
  • Rendah: dampak kecil atau pelanggaran praktik terbaik tanpa kerugian langsung.
  • Informasional: saran kualitas kode, dokumentasi, dan keterbacaan.
  • Optimasi gas: penghematan biaya tanpa perubahan perilaku.

Risiko sentralisasi sebaiknya dilaporkan tersendiri agar pengguna dapat menilai kepercayaan yang dibebankan pada pihak berwenang protokol.

Fase 9: Pelaporan, Remediasi, dan Verifikasi Perbaikan

  • Draf laporan dibahas bersama tim, lalu tim memperbaiki temuan.
  • Auditor memverifikasi perbaikan pada selisih commit yang relevan dan memperbarui status setiap temuan: diselesaikan, diselesaikan sebagian, diakui, atau ditolak dengan alasan.
  • Perubahan di luar perbaikan, seperti fitur baru, memerlukan peninjauan ulang tersendiri.
  • Laporan akhir menyebut hash commit yang diaudit dan hash commit akhir setelah perbaikan.

Fase 10: Pasca-audit, Deployment, dan Respons Insiden

  • Pastikan bytecode yang dideploy sesuai dengan commit yang diaudit, dan verifikasi kode sumber pada block explorer.
  • Tinjau parameter deployment, peran, timelock, multisig, dan mekanisme jeda darurat.
  • Luncurkan bertahap dengan batas nilai (cap) dan tingkatkan setelah stabil.
  • Pasang pemantauan on-chain dengan peringatan untuk peristiwa dan pola tidak lazim, dan pertimbangkan program bug bounty.
  • Siapkan rencana respons insiden tertulis dan latih secara berkala. Panduan Trail of Bits menyediakan kerangka penyusunannya.

Contoh Remediasi: Checks-Effects-Interactions dengan Guard

Pola berikut memperbaiki kelas kerentanan reentrancy pada fungsi penarikan: periksa kondisi, ubah state, baru lakukan panggilan eksternal, dengan nonReentrant sebagai lapisan pertahanan tambahan. Contoh mengasumsikan OpenZeppelin Contracts v5 dan struktur Foundry dengan berkas src/Vault.sol.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import {ReentrancyGuard} from "@openzeppelin/contracts/utils/ReentrancyGuard.sol";

contract Vault is ReentrancyGuard {
    error InsufficientBalance();
    error TransferFailed();

    mapping(address account => uint256 amount) private balances;

    event Deposited(address indexed account, uint256 amount);
    event Withdrawn(address indexed account, uint256 amount);

    function deposit() external payable {
        balances[msg.sender] += msg.value;
        emit Deposited(msg.sender, msg.value);
    }

    function withdraw(uint256 amount) external nonReentrant {
        uint256 balance = balances[msg.sender];
        if (balance < amount) revert InsufficientBalance();
        balances[msg.sender] = balance - amount;
        (bool ok, ) = msg.sender.call{value: amount}("");
        if (!ok) revert TransferFailed();
        emit Withdrawn(msg.sender, amount);
    }

    function balanceOf(address account) external view returns (uint256) {
        return balances[account];
    }
}

Tes fuzz Foundry untuk memvalidasi properti dasar penarikan (test/Vault.t.sol):

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import {Test} from "forge-std/Test.sol";
import {Vault} from "../src/Vault.sol";

contract VaultTest is Test {
    Vault private vault;

    function setUp() public {
        vault = new Vault();
    }

    function testFuzz_WithdrawReturnsDeposit(uint96 amount) public {
        vm.assume(amount > 0);
        address user = makeAddr("user");
        vm.deal(user, amount);
        vm.startPrank(user);
        vault.deposit{value: amount}();
        vault.withdraw(amount);
        vm.stopPrank();
        assertEq(user.balance, amount);
        assertEq(vault.balanceOf(user), 0);
    }
}

Jalankan forge install OpenZeppelin/openzeppelin-contracts lalu forge test. Tes ini hanya memeriksa satu properti dasar. Auditor tetap menambahkan tes yang menyerang kontrak dengan penerima berbahaya pada lingkungan lokal, serta invariant test pada tingkat sistem. Untuk fungsi view yang dipakai protokol lain, pertimbangkan juga read-only reentrancy.

Struktur Laporan Audit yang Profesional

  • Ringkasan eksekutif: kesimpulan, jumlah temuan per tingkat keparahan, dan penilaian umum.
  • Ruang lingkup: repositori, hash commit, berkas, nSLOC, dan hal yang dikecualikan.
  • Metodologi: fase kerja, alat yang dipakai, dan durasi.
  • Ringkasan temuan: tabel atau daftar ringkas seluruh temuan beserta statusnya.
  • Rincian temuan: setiap temuan memuat ID (misalnya H-01), judul, tingkat keparahan beserta dampak dan kemungkinan, lokasi (berkas, fungsi, baris pada commit), deskripsi, dampak, skenario atau bukti konsep dari lingkungan lab, rekomendasi, serta status dan tanggapan tim.
  • Risiko sentralisasi dan asumsi kepercayaan.
  • Cakupan pengujian dan hasil alat.
  • Verifikasi perbaikan: status akhir per temuan pada hash commit akhir.
  • Disclaimer: batasan audit dan penegasan bahwa laporan bukan jaminan.

Model Penugasan Keamanan

  • Audit privat oleh firma atau auditor independen: kedalaman dan akuntabilitas tinggi, biaya dan antrean jadwal lebih besar.
  • Audit kompetitif (contest): banyak peninjau dalam waktu singkat, dengan kualitas dan kedalaman yang bervariasi sehingga perlu triase yang baik.
  • Bug bounty pasca-deploy: menjaring temuan secara berkelanjutan dengan imbalan hanya untuk temuan valid, tetapi bukan pengganti audit sebelum peluncuran.
  • Verifikasi formal: membuktikan properti terspesifikasi, sangat kuat namun menuntut spesifikasi yang ketat.
  • Pendekatan berlapis: tinjauan internal, audit privat, kontes opsional, bug bounty, lalu pemantauan dan respons insiden.

Faktor yang Menentukan Durasi dan Biaya

Biaya dan durasi tidak dapat ditetapkan tanpa melihat kodenya. Faktor penentunya:

  • Jumlah baris kode sumber dan kompleksitas logika, terutama aritmetika dan mekanisme ekonomi baru.
  • Jumlah integrasi eksternal dan ketergantungan pada protokol lain.
  • Ada tidaknya upgradeability, lintas rantai, atau tata kelola on-chain.
  • Kualitas dokumentasi, spesifikasi, dan suite tes.
  • Kebutuhan verifikasi formal dan jumlah auditor yang dilibatkan.
  • Tenggat yang ketat dan jumlah putaran verifikasi perbaikan.

Durasi audit umumnya berkisar dari beberapa hari hingga beberapa minggu, bergantung pada faktor di atas.

Keterbatasan Audit dan Manajemen Risiko Residual

  • Audit bersifat point-in-time dan tidak menjamin ketiadaan kerentanan.
  • Risiko ekonomi dan teori permainan, kegagalan oracle, kompromi kunci, dan risiko tata kelola dapat berada di luar cakupan.
  • Komponen off-chain seperti antarmuka web, backend, dan pengelolaan kunci memerlukan penilaian tersendiri.
  • Risiko pasar dan likuiditas tidak dapat dihilangkan oleh audit.

Kontrol residual yang lazim: timelock pada perubahan kritis, multisig dengan pemisahan tugas, batas nilai pada fase awal, mekanisme jeda darurat, pemantauan on-chain, bug bounty, dan rencana respons insiden.

Pertanyaan yang Sering Diajukan

Apakah audit menjamin kontrak bebas bug?

Tidak. Audit mengurangi risiko dengan menemukan sebanyak mungkin kerentanan pada ruang lingkup dan commit tertentu, tetapi tidak dapat membuktikan ketiadaan bug.

Kapan waktu terbaik melakukan audit?

Setelah fitur lengkap dan kode dibekukan, sebelum peluncuran mainnet. Lakukan audit ulang setiap kali ada perubahan signifikan pada logika atau integrasi.

Apa perbedaan audit, bug bounty, dan verifikasi formal?

Audit adalah tinjauan terstruktur sebelum peluncuran pada versi kode tertentu. Bug bounty adalah insentif berkelanjutan bagi peneliti untuk melaporkan kerentanan setelah peluncuran. Verifikasi formal membuktikan properti yang dispesifikasikan secara matematis. Ketiganya saling melengkapi.

Apakah perlu audit ulang setelah perbaikan?

Perbaikan atas temuan diperiksa melalui verifikasi perbaikan pada selisih commit. Perubahan yang melampaui perbaikan, misalnya fitur baru, memerlukan peninjauan ulang.

Apakah kode hasil fork dari proyek yang sudah diaudit otomatis aman?

Tidak. Konfigurasi, parameter, integrasi, dan modifikasi pada fork dapat memunculkan kerentanan baru, sehingga kode tersebut tetap perlu ditinjau.

Bagaimana cara mempersiapkan proyek agar audit efisien?

Bekukan kode, lengkapi dokumentasi dan invarian, pastikan tes lulus, kunci dependensi, dan jalankan analisis statis dasar. Daftar lengkapnya ada pada bagian kesiapan audit di atas.

Rujukan

Konsultasi Audit dan Keamanan

Butuh peninjauan keamanan smart contract, threat modeling, atau pendampingan kesiapan audit? Andika Putra, praktisi keamanan siber dan audit smart contract, menyediakan layanan konsultasi dan audit. Hubungi melalui WhatsApp: 0877-3013-9582.