Audit Keamanan Otomatis

Diskusi industri soal keamanan kode sering terjebak pada abstraksi. Fokus perdebatan biasanya hanya berkisar pada efisiensi pencarian celah.

Para praktisi jarang menyentuh mekanisme pembuktiannya di dunia nyata.

Padahal masalah utamanya bukan sekadar menemukan kerentanan. Tantangan terbesarnya adalah membuktikan bahwa finding itu valid tanpa membebani manusia.

Pendekatan Cloudflare memberikan gambaran konkret soal penyelesaian masalah ini.

Pada 18 Juni 2026, mereka membuka repositori cloudflare/security-audit-skill. Repositori ini menggunakan lisensi MIT. Sampai 14 September 2026, proyek ini mendapat sekitar 8.800 bintang dan 481 fork.

Deskripsi resminya cukup lugas. Repositori ini adalah sebuah “A coding-agent skill for multi-phase security audits with independently verified, machine-readable findings”.

Menurut dokumentasi, proyek ini berawal dari harness pencarian kerentanan internal Cloudflare. Hal ini pernah dibahas panjang di blog mereka “Build your own vulnerability harness”.

Sekarang harness itu sudah tumbuh menjadi infrastruktur yang lebih masif. Repositori skill ini adalah titik awalnya.

Enam Fase Pencarian

Sistem ini tidak membiarkan agent bekerja liar. Ia membagi pekerjaannya secara teratur dalam enam fase berurutan.

Langkah pertamanya adalah reconnaissance. Fase awal ini menghasilkan file architecture.md dan coverage-ledger.json.

Ledger tersebut sangat penting untuk manajemen tugas. Fungsinya membagi pekerjaan secara spesifik ke setiap hunter.

Mereka juga menempatkan satu agent khusus yang bertindak sebagai critic. Tugasnya hanya mencari bagian kode yang belum tersentuh pencari lain.

Setelah itu ada fase pencarian yang sepenuhnya berbasis ledger. Kemudian dilanjutkan dengan fase validasi kandidat finding.

Hasil validasi masuk ke fase output terstruktur. Sistem kemudian menjalankan verifikasi independen terhadap data tersebut.

Langkah terakhirnya adalah pembuatan laporan.

Proses audit berikutnya didesain agar terus bersifat menambah. Ledger dan finding lama akan selalu dipakai lagi.

Tujuannya untuk menandai bagian sistem yang belum selesai diinspeksi. Audit baru juga wajib memeriksa ulang kode yang berubah.

Aturannya sangat kaku soal validasi. Pekerjaan lama yang belum tuntas sama sekali tidak dihitung selesai.

Verifikasi Tanpa Kompromi

Saya paling tertarik pada aturan ketat untuk para verifier. Bagi saya, ini bagian paling krusial dari seluruh repositori.

Instruksinya sangat tegas dan tidak memberi ruang untuk kompromi.

“You did not write this candidate. Try to refute it from repository source and bounded local evidence.”

Aturan di sekitar prompt ini juga sangat mengikat. Verifier harus berwujud agent baru yang tidak ikut mencari kerentanan.

Ia dilarang menerima kesimpulan dari verifier lain begitu saja. Agent verifikasi ini wajib membaca ulang setiap baris kode yang dikutip.

Syarat untuk mencapai status confirmed sangat berat. Verifier harus mengulang sendiri seluruh pemeriksaan yang menentukan kesimpulan.

Status confirmed hanya boleh dipakai kalau landasannya sangat solid. Kombinasi bukti kode dan pemeriksaan lokal harus menjelaskan seluruh jalur.

Hasil dari jalur tersebut juga harus terjelaskan dengan tuntas.

Terkadang ada fakta yang belum tersedia di repositori. Ini bisa berupa detail soal deployment, provider, platform, atau runtime.

Jika satu saja fakta ini hilang, nilainya harus needs_validation. Syarat untuk level menengah ini juga tidak main-main.

Agent harus menulis spesifik tentang informasi apa yang hilang. Lalu ia wajib membuat pemeriksaan aman yang bisa menutup celah itu.

Sementara itu, status rejected dipakai untuk kandidat yang berhasil dibantah.

Kedalaman Konteks Target

Pola audit ini menunjukkan kedalaman pemahaman konteks target. Sistem tidak hanya mencari kecocokan teks semata.

Kutipan dari dokumen kelas serangan bagian kontrol akses menunjukkan hal tersebut.

“Go beyond checking whether permission checks exist - verify they check the right permission for the right resource via the right mechanism.”

Repositori ini bukan sekadar kumpulan prompt pendek. File SKILL.md di dalamnya memuat sekitar 22 ribu karakter.

Ada 11 dokumen kelas serangan spesifik yang mendampinginya. Topiknya meliputi memory safety, AI/LLM, web/auth, client-side, dan supply chain.

Kelompok lainnya adalah cloud, RPC, resource exhaustion, dan data isolation. Mereka juga menyertakan kategori desktop/mobile dan attack classes umum.

Setiap dokumen mengarahkan fokus ke target yang tepat. Sasaran audit disusun rapi berdasarkan jenis lingkungannya.

Untuk aplikasi web, targetnya meliputi query SQL, HTML, shell, template, redirect, dan deserialisasi.

Target aplikasi CLI dibatasi pada perintah shell dan alamat file. Bagian agent dan MCP server juga mendapat perhatian khusus.

Sasarannya mencakup pencemaran konteks, identitas tool, dan pengikatan aksi.

Seluruh hasil akhirnya ditulis ke findings.json. File output ini diperiksa validitasnya menggunakan report-schema.json.

Setiap catatan diwajibkan punya nilai fingerprint tersendiri. Schema menjelaskannya sebagai penanda unik dari kode sumber.

Nilai ini menjamin pelacakan yang konsisten. Kodenya tetap terikat meski status akhirnya berganti nanti.

Repositori ini didukung oleh infrastruktur pengujian mandiri. Terdapat dua validator tanpa dependency yang dikirim bersama kode.

Keduanya sudah dilengkapi dengan test yang siap dijalankan.

Batasan Implementasi

Tentu saja ada beberapa catatan penting soal rancangan ini. Saya belum menjalankan audit penuh dari repositori tersebut.

Alur enam fase tadi mensyaratkan lingkungan yang terkontrol. Prosesnya butuh sandbox khusus yang ditegakkan langsung oleh sistem operasi.

Validator bawaan repo ini juga punya keterbatasan teknis. Skrip tersebut hanya bertugas memeriksa bentuk dan struktur data.

Sebuah finding bisa saja lolos schema dengan sempurna. Namun itu tidak menjamin masalahnya penting secara keamanan.

Pihak Cloudflare sendiri cukup realistis. Mereka secara terbuka menyebut repositori ini hanya sebagai titik awal.

Ini bukan produk lengkap yang siap pakai untuk segala situasi. Namun, fondasi yang mereka buka sangat berharga untuk dipelajari.

Kerangka kerja ini memaksa mesin beroperasi secara transparan. Proses verifikasi berlapis membuat setiap kesimpulan bisa diuji kembali.