Hari 55: Laporan Audit, Data DefectDojo Ternyata Basi

Hari ke-55 dari challenge 60 Days DevSecOps. Topiknya: menyusun laporan audit keamanan dari data DefectDojo — dashboard yang mengumpulkan semua temuan dari scanner.

Tujuannya sederhana: buat executive summary yang bisa dibawa ke manajemen. Tapi begitu saya lihat datanya, ada kejutan: datanya basi. Dan scan ulang mengubah seluruh cerita laporannya. Mari saya ceritakan.

Apa itu DefectDojo?

DefectDojo adalah dashboard yang mengumpulkan hasil scan dari banyak tools — Semgrep, Trivy, Checkov, OWASP ZAP — jadi satu tempat. Bayangkan inbox semua alert keamanan. Di proyek ini, saya upload report dari berbagai scanner ke DefectDojo sejak beberapa minggu lalu.

Masalahnya: Data Basi

Ketika saya buka DefectDojo, ada 52 temuan, termasuk 1 Critical dan 7 High. Terlihat menyeramkan. Tapi tunggu — temuan itu di-import kapan? Ternyata mayoritas dari minggu lalu, sebelum saya memperbaiki banyak hal.

Contoh: ada temuan "S3 bucket public" dengan severity High. Tapi di Day 23 dan Day 51, saya sudah memperbaiki isu S3 tersebut. Masalahnya laporan di DefectDojo tetap menyimpan snapshot lama.

Ini bahaya. Kalau saya langsung tulis laporan dari data basi itu, manajemen akan percaya aplikasi "masih punya 7 temuan High" padahal sebenarnya sudah diperbaiki. Laporan yang menyesatkan.

Solusinya: Scan Ulang

Solusi paling jujur adalah menjalankan ulang semua scanner lalu upload ulang ke DefectDojo. Alih-alih berkata "kayaknya sudah aman", saya tunjukkan angkanya sekarang.

trivy fs --scanners vuln securebank-api/
trivy config securebank-api/terraform/
trivy image securebank:v1
semgrep --config "p/golang" .

Lalu upload semuanya:

bash securebank-api/security/defectdojo/upload-scans.sh

Hasilnya benar-benar mengubah cerita:

Area	Sebelum	Sesudah scan ulang
IaC (S3, Security Group)	14 temuan (1 Critical + 6 High)	2 Low
K8s manifest	16 misconfig	0
Dependensi Go	beberapa CVE	0 Critical/High

Remediasi selama berminggu-minggu itu terbukti bekerja — tapi hanya terlihat kalau data di-refresh dulu.

Bonus Temuan Baru

Scan ulang juga menemukan hal baru yang belum sempat ter-remediasi:

• [HIGH] CVE-2026-39822 di stdlib Go v1.26.4 — image aplikasi dibangun dengan Go lama; ada kerentanan yang sudah diperbaiki di versi lebih baru. Aksi: rebuild image.
• [MEDIUM] API tanpa TLS — endpoint jalan plain HTTP.
• [LOW] S3 bucket logging mati — sebaiknya diaktifkan.
• [INFO] openpgp deprecated — dependency yang menyeret paket tidak di-maintain.

Jadi laporannya jadi lebih jujur: 6 temuan tersisa (0 Critical, 1 High, 2 Medium, 2 Low, 1 Info) — bukan cerita usang ber-1-Critical.

Caveat Teknis

Ada beberapa trik selama proses:

• trivy fs di lokal men-scan seluruh file termasuk yang di-gitignore (private key, file .env) — jadi saya jalankan dengan --scanners vuln saja supaya report-nya bersih tanpa secret.
• Checkov di macOS Python 3.14 tidak jalan, dan imagen Docker-nya tidak ada — jadi coverage IaC saya andalkan ke Trivy config yang akurat.
• Re-import DefectDojo membuat test duplikat (tidak mencob menggabungkan antar run) — jadi di laporan saya tandai id test baru sebagai "state terkini".

Kesimpulan

Pelajaran paling besar hari ini: laporan audit sebaiknya tidak dibangun dari data yang bisa saja basi. Sebelum menyimpulkan "masih banyak kerentanan" atau "sudah bersih", selalu periksa kapan data di-scan. Scan ulang itu bukti remediasi yang paling jujur — bukan sekedar narasi.

Saya juga menyadari bahwa aggregate DefectDojo (jumlah total temuan lama) berbeda jauh dari state terkini. Laporan eksekutif yang baik harus memisahkan "riwayat" dari "kondisi sekarang".

Draf laporannya ada di repo: chalange-devsecops — lihat securebank-api/security/audit-reports/draft-q3.md.

Besok: menyelesaikan dokumen eksekutif lengkap (PDF) dari draf ini.