---
title: "Cara membaca audit kontrak pintar"
description: "Audit kontrak pintar adalah pemeriksaan terbatas atas kode, build, deployment, asumsi, dan properti tertentu; temuan serta perbaikannya harus direkonsiliasi dengan sistem live."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Cara membaca audit kontrak pintar

> Hanya untuk tujuan edukasi; bukan merupakan nasihat investasi atau rekomendasi investasi. Investasi dapat mengakibatkan kerugian.

<a id="answer"></a>

## Jawaban langsung

Audit kontrak pintar adalah pemeriksaan terbatas atas persyaratan, kode sumber, input build, logika deployment, dan asumsi keamanan yang ditentukan selama periode tertentu. Penelaah memakai metode yang saling melengkapi untuk menemukan cacat, menunjukkan jalur eksploitasi, menilai dampak, dan memeriksa usulan perbaikan. Kesimpulannya hanya berlaku pada snapshot penugasan dan bukti yang dijelaskan dalam laporan.

Snapshot harus menetapkan repositori dan commit atau tree hash, submodule dan dependency lock, compiler beserta pengaturannya, kode hasil generasi, skrip deployment, chain dan alamat tujuan, proxy, implementation atau beacon, data constructor atau initializer, library, administrator, timelock, serta blok atau waktu. Pengecualian sama pentingnya dengan cakupan: frontend, keeper, oracle, bridge, proses governance, atau penanda tangan off-chain dapat mendominasi risiko meski berada di luar audit.

Audit memerlukan threat model dan spesifikasi. Identifikasi aset, pelaku, peran berprivilege, batas kepercayaan, kemampuan penyerang, asumsi ordering dan reorganisasi, dependensi eksternal, transisi state, serta properti safety dan liveness yang tepat. Invarian tanpa unit, prasyarat, kuantor, dan pengecualian dapat menguji atau membuktikan perilaku yang keliru dengan sempurna.

Gunakan empat buku besar: scope serta identitas build dan deployment; persyaratan, ancaman, dan invarian; temuan, bukti, dan pengujian ulang; serta risiko residual, penerimaan, dan pengungkapan. Laporan tanpa temuan `critical` bukan sertifikat keamanan, temuan berstatus `resolved` belum tentu sudah diterapkan, dan pembuktian hanya mencakup properti yang dikodekan, model, serta asumsinya.

<a id="mechanism"></a>

## Cara kerjanya

Penelaahan manual menelusuri arsitektur, aliran dana, state lintas fungsi, dan maksud ekonomi. Analisis statis menemukan pola dan aliran data, tetapi dapat menghasilkan false positive dan false negative. Pengujian unit, integrasi, fork, dan diferensial membandingkan perilaku konkret. Stateful fuzzing dan pengujian invarian menjelajahi urutan yang dihasilkan, tetapi hasilnya bergantung pada handler, selector, seed, corpus, jumlah run, depth, dan lingkungan yang dimodelkan.

Eksekusi simbolik dan verifikasi formal dapat menetapkan pernyataan tertentu dalam semantik serta asumsi yang didukung. Hasil solver `unknown`, timeout, atau perilaku yang tidak didukung bukan pembuktian. Bahkan properti yang terbukti dapat mengabaikan ekonomi oracle, governance, konfigurasi deployment, perilaku chain, atau persyaratan yang sebenarnya dimaksudkan tim. Penelaah manusia bertanggung jawab atas spesifikasi dan interpretasi; pengamatan buatan AI bukan metode assurance tersendiri.

Setiap temuan perlu menyebut artefak dan deployment terdampak, prasyarat, bukti minimum, jalur eksploitasi, reachability, privilege, modal penyerang, keterulangan, dampak ekonomi, rubrik severity, dan rekomendasi. Exploitability atau likelihood dan impact merupakan dimensi terpisah. Nilai maksimum teoretis, nama kerentanan, atau label alat tidak membuktikan kerugian yang dapat dieksekusi.

Status seperti `open`, `acknowledged`, `risk accepted`, `partially fixed`, `resolved`, dan `retested` bukan standar universal. Penutupan yang dapat dipertanggungjawabkan mengikat masalah awal ke commit perbaikan yang tepat, mencatat jalur yang diubah dan jalur terkait yang diuji, serta menyatakan siapa menguji ulang apa dan kapan. Risiko yang diterima tetaplah risiko, dan retest terbatas tidak memperluas scope awal ke seluruh kode baru.

Deployment yang dapat di-upgrade memerlukan rekonsiliasi khusus. Tetapkan proxy, implementation atau beacon dan admin slot; periksa perilaku initializer dan reinitializer, penguncian implementation, kompatibilitas storage, otorisasi upgrade, timelock atau bypass darurat, migrasi, dan rollback. Reproduksi creation dan runtime bytecode dari build yang diaudit, lalu bandingkan linked library, parameter, role, dan state terinisialisasi pada setiap chain.

Laporan akhir perlu menyebut revisi, auditor dan tanggal, scope persis, metode dan konfigurasi, keterbatasan, temuan, bukti, status remediasi, risiko terbuka atau diterima, dan ketentuan disclosure. Setelah rilis, pantau implementation hash, role, parameter, dependensi, dan insiden. Setiap perubahan material menciptakan delta baru yang perlu ditelaah; lencana laporan lama tidak otomatis mengikuti kode masa depan.

Gunakan alur kerja berikut:

1. Bekukan manifest penugasan: repositori, commit, dependensi, compiler dan setting, kode hasil generasi dan deployment, chain, alamat, proxy stack, parameter, blok, revisi laporan, cakupan, dan pengecualian.
2. Definisikan aset, pelaku, peran berprivilege, batas kepercayaan, kemampuan penyerang, siklus hidup, asumsi ordering dan liveness, dependensi eksternal, serta invarian terukur.
3. Reproduksi build dan petakan arsitektur, storage, data, dana, dan kontrol; rekonsiliasi sumber, artefak, library, creation/runtime bytecode, initializer, role, dan deployment live.
4. Jalankan metode manual, statis, unit, integrasi, fork, diferensial, fuzz, invarian, simbolik, atau formal yang saling melengkapi dengan versi alat, konfigurasi, seed, corpus, coverage, timeout, dan hasil tidak pasti yang tercatat.
5. Catat artefak terdampak, prasyarat, bukti, exploitability, impact, metode severity, exposure deployment, rekomendasi, dan bukti rahasia tiap masalah tanpa menganggap label alat sebagai penilaian.
6. Bekukan commit perbaikan lalu uji ulang masalah, jalur terkait, dan invarian; validasi proxy storage, initialization, migration, rollback, reproducible build, dan receipt deployment sebelum menetapkan status berbasis bukti.
7. Publikasikan scope, metode, batasan, dan risiko residual; rekonsiliasi artefak yang diaudit dengan setiap chain live dan perbarui monitoring, disclosure, incident response, serta bug bounty seiring perubahan sistem.

<a id="example"></a>

## Contoh

- **Jalur inflasi vault memerlukan buku besar lengkap.** Penyerang menyetor `1 asset` melalui cabang setoran pertama dan menerima `1 share`, lalu mendonasikan `1,000,000 assets`; total menjadi `1,000,001 assets` dan `1 share`. Korban menyetor `500,000 assets`, dan pembulatan ke bawah yang tidak aman menghasilkan `floor(500,000 * 1 / 1,000,001) = 0 shares`. Jika setoran nol share diterima, vault menampung `1,500,001 assets`; penyerang menebusnya dan memperoleh `500,000 assets` di atas kontribusi `1,000,001-asset`. Jika implementasi me-revert nol share, jalur kerugian ini tidak dapat dieksekusi.
- **Cakupan file bukan cakupan deployment.** Manifest berisi `24 source units`, `4 deployment scripts`, dan `3 keeper services`, atau `31 items`. Penugasan mencakup `20 source units` dan `2 scripts`, sehingga cakupan jumlahnya `22 / 31 = 70.96774194%`; `9 items` lainnya dikecualikan. Jika proxy live menunjuk ke implementation yang dibangun dari unit yang dikecualikan, cakupan implementation live itu `0%` meski headline-nya `70.96774194%`.
- **Observasi fuzz bukan bukti ketiadaan.** Sebuah stateful run menjalankan `2,000 sequences * 64 calls = 128,000 calls`; invarian gagal dalam `3 sequences`, yaitu `3 / 2,000 = 0.15%` dari urutan hasil generator yang diamati. Setelah perbaikan, `10,000 sequences * 64 calls = 640,000 calls` menghasilkan nol kegagalan. Itu nol dalam corpus ini, bukan pembuktian; dengan asumsi pengajaran berupa independensi dan generator stabil, perkiraan batas atas rule-of-three pada `95%` adalah `3 / 10,000 = 0.03%` per urutan.
- **Penutupan temuan dan identitas deployment bersifat independen.** Laporan memiliki `12 findings`: `2 critical`, `3 high`, `4 medium`, dan `3 low`. Retest menutup `2 + 2 + 3 + 2 = 9`, sehingga tingkat penutupan `9 / 12 = 75%`; satu high, satu medium, dan satu low tersisa. Runtime hash yang diaudit adalah `H1`, tetapi implementation live `H2`, sehingga verifikasi deployment gagal berapa pun tingkat penutupannya. Menggantinya dengan `H1` yang persis serta mencocokkan proxy slot, initializer, dan role hanya membuktikan identitas pada blok yang diperiksa.

<a id="risks"></a>

## Risiko

- Repositori, commit, submodule, atau sumber hasil generasi usang atau ambigu.
- Versi compiler, optimizer setting, library, atau dependensi tidak ditetapkan.
- Skrip deployment, constructor data, initializer, atau CREATE2 salt dikecualikan.
- Chain, alamat, proxy, beacon, atau implementation yang salah diperiksa.
- Sumber, artefak, creation bytecode, dan runtime bytecode tidak dapat direkonsiliasi.
- Threat model mengabaikan pelaku, privilege, aset, atau batas kepercayaan.
- Spesifikasi atau invarian memiliki unit, prasyarat, atau pengecualian yang salah.
- Jalur admin, guardian, timelock, pause, upgrade, atau migration terlewat.
- Asumsi oracle, token, bridge, keeper, governance, atau chain gagal.
- Analisis statis menghasilkan false positive yang tidak ditriase.
- Penelaahan manual, pengujian, atau fuzzing melewatkan jalur yang tidak dihasilkan.
- Fuzz harness, selector, seed, corpus, depth, atau model state bias.
- Solver timeout, semantik tidak didukung, atau `unknown` dianggap sebagai bukti.
- Pembuktian yang benar memformalkan persyaratan yang salah atau sistem yang tidak lengkap.
- Severity bertumpu pada nama kerentanan, bukan exploitability dan impact.
- Nilai risiko teoretis disamakan dengan kerugian terjangkau atau laba penyerang.
- Perbaikan menimbulkan regresi terkait atau merusak invarian ekonomi.
- Proxy storage, initializer, upgrade, atau migration merusak state live.
- Lencana lulus audit menyembunyikan masalah yang diterima, terbuka, atau hanya diperbaiki sebagian.
- Laporan dianggap sebagai asuransi, sertifikasi, kompensasi, atau cakupan permanen.

<a id="misconceptions"></a>

## Kesalahpahaman umum

- **"Tidak ada temuan kritis berarti kontrak aman."** Itu hanya menggambarkan temuan dalam scope, waktu, dan metode terbatas, bukan semua cacat yang mungkin ada.
- **"Coverage tinggi atau nol kegagalan fuzz membuktikan tidak ada bug."** Keduanya mengukur kode dan jalur hasil generator yang dipilih, bukan bukti ketiadaan.
- **"Verifikasi formal membuktikan seluruh protokol aman."** Verifikasi membuktikan properti model yang dikodekan berdasarkan asumsi; spesifikasi dan sistem sekitar masih dapat keliru.
- **"Resolved berarti semua deployment live telah diperbaiki."** Penutupan memerlukan retest independen serta rekonsiliasi build, bytecode, proxy, parameter, dan role untuk tiap deployment.
- **"Auditor bereputasi menjamin kompensasi atau upgrade mendatang."** Tanggung jawab bergantung pada kontrak penugasan, pengguna mungkin bukan penerima manfaat, dan kode atau konfigurasi berikutnya berada di luar snapshot lama.

<a id="related"></a>

## Topik terkait

- [Kontrak pintar](/id/crypto/smart-contract/)
- [Kontrak yang dapat di-upgrade](/id/crypto/upgradeable-contract/)
- [Bug bounty](/id/crypto/bug-bounty/)

<a id="sources"></a>

## Sumber

- [OWASP Smart Contract Security Verification Standard (SCSVS)](https://scs.owasp.org/SCSVS/) - OWASP (diakses: 2026-08-13)
- [Security Considerations](https://docs.soliditylang.org/en/latest/security-considerations.html) - Solidity (diakses: 2026-08-13)
- [Slither, the smart contract static analyzer](https://github.com/crytic/slither) - Crytic (diakses: 2026-08-13)
- [Invariant Testing](https://www.getfoundry.sh/guides/invariant-testing) - Foundry (diakses: 2026-08-13)
- [Certora User's Guide](https://docs.certora.com/en/latest/docs/user-guide/index.html) - Certora (diakses: 2026-08-13)
- [ERC-1967: Proxy Storage Slots](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (diakses: 2026-08-13)
- [Writing Upgradeable Contracts](https://docs.openzeppelin.com/upgrades-plugins/writing-upgradeable) - OpenZeppelin (diakses: 2026-08-13)
- [Contract Metadata](https://docs.soliditylang.org/en/latest/metadata.html) - Solidity (diakses: 2026-08-13)

Source: https://wiki.fcontext.com/id/crypto/contract-audit/index.mdx