Cara Membaca Report Keamanan AISG: Risk Score, Temuan, dan Langkah Perbaikan

Anda baru saja selesai menjalankan scan keamanan. Dashboard menampilkan "Risk Score: 72/100 — ELEVATED" dan 34 temuan. Pertanyaan yang hampir selalu muncul berikutnya: "terus, yang harus saya kerjakan dari mana?"

Report yang baik bukan sekadar deretan angka. Report yang baik menjawab tiga pertanyaan: apa yang sebenarnya diperiksa, seberapa parah masalahnya, dan — yang paling penting — harus mulai dari mana. Artikel ini membedah isi report AISG blok per blok, supaya Anda bisa membacanya seperti membaca laporan dari konsultan keamanan.

1. Konteks scan — apa yang sebenarnya diperiksa

Report AISG dibuka dengan KONTEKS SCAN: nama dan jenis target (kode lokal, URL, atau aplikasi LLM), lokasi folder atau alamat URL, model LLM yang dipakai, serta status kunci API. Kunci tersebut disimpan terenkripsi dan tidak pernah keluar — report hanya menampilkan status "terkonfigurasi" atau "tidak".

Kenapa ini penting? Temuan tanpa konteks tidak bisa dinilai. Yang lebih jarang ditemukan di vendor lain: report AISG juga menuliskan apa yang tidak diperiksa — misalnya folder dependensi (node_modules, storage, uploads) yang sengaja di-mask demi performa scan. Transparansi cakupan ini menentukan apakah Anda bisa memercayai kesimpulannya.

2. Risk score — bukan nilai rapor, tapi prioritas darurat

Banyak yang salah memahami risk score. 100/100 bukan berarti "aplikasi Anda jelek", dan 30/100 bukan berarti aman. Risk score adalah sinyal prioritas: seberapa mendesak Anda harus bertindak.

Rumusnya transparan dan tercetak di dalam PDF report:

• Setiap temuan diberi bobot sesuai severity: critical 90 · high 40 · medium 15 · low 2 · info 0.
• Severity mengikuti semantik CVSS v3.1 (critical ≥ 9.0, high 7.0–8.9, medium 4.0–6.9, low 0.1–3.9).
• Skor dibatasi ceiling 100 / 75 / 50 / 30 mengikuti severity tertinggi yang ditemukan.
• Risk bands: 0–30 LOW · 31–70 ELEVATED · 71–100 CRITICAL.

Artinya: satu temuan critical saja bisa menyentuh 100 — dan 92 temuan low tidak akan pernah meng-inflasi skor sampai 100. Hitungan nyata laporan Anda (bobot × jumlah temuan per severity) ditampilkan di dalam kotak metodologi, jadi angkanya bisa Anda audit sendiri. Bukan kotak hitam.

3. Temuan — lengkap dengan prioritas dan cara perbaikan

Di bagian FINDINGS, setiap temuan menampilkan: severity, sensor yang menemukan, rule + kode CWE, lokasi persis (file:baris), dan atribusi MITRE ATT&CK. Tapi daftar saja tidak cukup — report AISG menyediakan tiga lapis bantuan:

• TOP ACTIONS — maksimal 5 langkah pertama yang harus dikerjakan, diurutkan berdasarkan severity. Mulai dari sini.
• FIX GUIDANCE — untuk temuan critical/high/medium: kenapa berisiko, langkah perbaikan, dan contoh kode sebelum → sesudah. Report berfungsi seperti panduan perbaikan, bukan sekadar daftar tuduhan.
• REMEDIATION SLA — patokan waktu penyelesaian umum (critical ≤ 24 jam, high ≤ 7 hari, medium ≤ 30 hari) supaya tim punya target.

4. Yang "bersih" juga dilaporkan

Report menampilkan daftar sensor yang berjalan (SENSORS RUN) — termasuk yang di-skip karena keterbatasan, misalnya butuh Docker atau endpoint LLM yang belum dikonfigurasi. Tidak ada yang disembunyikan.

Yang jarang dilakukan vendor lain: bagian VERIFIED CLEAN menuliskan sensor yang berjalan tanpa temuan — "tidak ada secret di riwayat git", "tidak ada jailbreak terdeteksi", dan seterusnya. Bukti ketiadaan masalah juga merupakan evidence.

5. Perubahan antar scan — bukti progres

Kalau target pernah di-scan sebelumnya, report membandingkannya: temuan baru (NEW) dan yang sudah diperbaiki (FIXED). Tim bisa menunjukkan progres ke manajemen atau klien — bukan sekadar snapshot yang statis.

6. Batasan yang ditulis jujur

Bagian yang paling sering dihilangkan vendor lain justru ada di report AISG:

• Hasil bersifat indikatif dan memerlukan review manusia sebelum dijadikan dasar keputusan.
• Atribusi ATT&CK bersifat heuristic (pemetaan kata kunci) — indikasi, bukan klaim eksploitasi yang terverifikasi.
• Item checklist yang belum ter-cover ditampilkan sebagai gap — AISG tidak mengklaim apa yang tidak diperiksa.

Kejujuran tentang batasan inilah yang membuat report bisa dipertanggungjawabkan.

Kesimpulan — mulai dari langkah pertama

Report AISG dirancang seperti laporan konsultan: konteks → skor yang bisa diaudit → prioritas → cara perbaiki → batasan yang jujur. Tujuannya satu: Anda tahu kondisi aplikasi Anda sebelum orang lain menemukannya.

Plan Community tersedia gratis — scan berjalan di mesin Anda sendiri, dan kode tidak pernah meninggalkan perangkat Anda.