Keputusan ZAP di Baris Selesai
Papan selesai kini menuntut satu token keputusan ZAP per baris: rescan dengan path bukti atau none dengan alasan tertulis.
Ringkasan
Jadi begini, nge-scan pasif ZAP berulang buat tiap kartu selesai itu nggak ngebuktiin apa-apa. Solusinya, board validator sekarang mewajibkan token keputusan: ZAP:rescan plus path laporan, atau ZAP:none plus alasan tertulis. Hasilnya, utang keamanan jadi kelihatan, bisa ditrack, dan review fokus ngecek isi keputusan, bukan scan yang hasilnya sama terus.
Layar menampilkan papan Kanban KotaPortal setelah sesi tinjauan baseline OWASP ZAP pasca-implementasi RBAC. Baris "Selesai" memenuhi layar. Puluhan kartu dengan status tertutup, masing-masing mewakili modul yang sudah melewati review kode, merge, dan deploy. Tidak ada satu pun yang membawa catatan pemindaian keamanan aktif.
Asumsi awal sederhana: setiap issue yang ditutup memerlukan pemindaian ZAP-nya sendiri. Logikanya tampak masuk akal. Jika sebuah fitur menyelesaikan vulnerability tertentu, maka fitur tersebut perlu membuktikan bahwa vulnerability sudah benar-benar hilang melalui scan terpisah. Dengan pendekatan ini, board validator script akan memeriksa keberadaan laporan scan untuk setiap kartu yang berpindah ke kolom "Selesai".
Baseline ZAP pasif tidak bekerja seperti yang diperkirakan. Secara default, spider dibatasi waktu satu menit [1]. Tidak ada serangan aktif yang dilakukan. Alert default berstatus WARN, dapat dikonfigurasi ke FAIL atau IGNORE, dan cocok dijalankan bahkan di lingkungan CI/CD produksi [1]. Menjalankan baseline pasif berulang untuk setiap kartu selesai? Tidak membuktikan apa pun tentang keputusan keamanan yang diambil. Pemindaian pasif cepat dan murah untuk dijalankan ulang. Tetapi tidak dapat membedakan antara kartu yang menutup vulnerability nyata dengan kartu yang hanya menutup bug UI.
Validator Lint untuk Token Keputusan
Pendekatan yang lebih bermakna mengubah baris selesai dari sekadar status menjadi keputusan eksplisit. Board validator script KotaPortal kini memeriksa satu token keputusan pada setiap kartu yang berpindah ke kolom Selesai. Regex yang digunakan memiliki dua bentuk:
ZAP:rescan <path> — validator memeriksa apakah folder yang dirujuk benar-benar ada di repositori dan berisi laporan pemindaian ulang aktif.
ZAP:none - <reason> — validator mensyaratkan adanya alasan tertulis setelah tanda hubung. Tidak ada alasan berarti kartu ditolak oleh linter.
Setiap baris selesai harus membawa tepat satu token. Tidak boleh nol, tidak boleh dua. Aturan ini memastikan bahwa tim pengembang tidak dapat memindahkan kartu ke Selesai tanpa membuat keputusan sadar tentang hutang keamanan yang tersisa.
Paralel Deny-by-Default
Pendekatan ini mengikuti prinsip yang sama dengan authorization dalam OWASP Cheat Sheet. Aplikasi tidak boleh tetap netral ketika tidak ada aturan yang cocok; aplikasi harus memutuskan secara eksplisit antara deny atau permit [2]. Broken Access Control menempati posisi pertama dalam OWASP Top 10 2021 [2], dan keputusan netral sering menjadi penyebab celah keamanan yang paling sulit dilacak.
Dengan menerapkan logika yang sama pada board proyek, keputusan keamanan menjadi artefak yang dapat diaudit. Jika sebuah kartu ditutup tanpa scan aktif, alasan tertulis harus menjelaskan mengapa keputusan tersebut aman. Jika sebuah kartu membawa scan aktif, path ke laporan tersebut harus dapat diverifikasi. OWASP Logging Cheat Sheet menekankan bahwa audit trail merupakan use case keamanan yang sah, dengan peringatan agar tidak mencatat terlalu banyak atau terlalu sedikit [3]. Token keputusan pada baris selesai memberikan keseimbangan: cukup banyak untuk membuktikan bahwa keputusan dibuat, cukup sedikit untuk tidak membebani repositori dengan log yang tidak relevan.
Dampak pada Proses Tinjauan
Setelah implementasi lint validator, sesi tinjauan baseline ZAP berubah secara fundamental. Tim tidak lagi menghabiskan waktu menjalankan pemindaian pasif berulang untuk setiap kartu yang baru ditutup. Waktu yang sebelumnya habis untuk scan ulang yang hasilnya identik kini dialihkan ke memeriksa isi keputusan.
Sebagai gantinya, waktu tinjauan difokuskan pada validasi token keputusan: apakah alasan yang ditulis masuk akal secara teknis? Apakah path scan benar-benar ada dan berisi laporan yang relevan? Apakah ada kartu yang seharusnya membawa token rescan tetapi hanya membawa token none? Pertanyaan-pertanyaan ini lebih bermakna daripada sekadar memeriksa keberadaan laporan scan yang identik untuk setiap kartu.
Keputusan eksplisit ini membuat utang keamanan terlihat sebelum menjadi krisis. Kartu dengan ZAP:none - <reason> menandai area yang perlu ditinjau ulang ketika sumber daya tersedia. Kartu dengan ZAP:rescan <path> menyediakan bukti bahwa kerentanan tertentu telah diverifikasi telah tertutup. Setiap token menjadi kontrak antara pengembang dan reviewer tentang apa yang telah dan belum dilakukan.
Dalam konteks keamanan aplikasi, keputusan yang tidak tercatat sama berbahayanya dengan keputusan yang salah. Pendekatan token keputusan memastikan bahwa setiap baris selesai membawa bukti kesadaran, bukan sekadar indikator bahwa kode telah berpindah tempat. Token status ini bukan sekadar metadata, melainkan kontrak eksplisit tentang apa yang telah diverifikasi dan apa yang masih menjadi utang keamanan. Keputusan yang dipaksakan oleh linter mengubah utang keamanan dari risiko tersembunyi menjadi item yang dapat ditrack, diprioritaskan, dan diselesaikan secara sistematis.
Sumber
[1] Dokumentasi ZAP Baseline Scan