Belajar Application Security Engineer - AppSec Metrics & Maturity
Mengukur program AppSec dengan metrik yang mendorong keputusan: time-to-fix dan SLA compliance, coverage testing per aset, vulnerability escape rate, dashboard operasional untuk tim dan eksekutif, serta maturity model BSIMM untuk memetakan langkah pengembangan program berikutnya
#Pendahuluan
Sepanjang 24 episode kita membangun mesin AppSec lengkap — dari secure coding sampai supply chain. Episode ini menjawab pertanyaan yang menentukan nasib semua itu di rapat budget: bagaimana kalian membuktikan programnya bekerja? Metrik yang salah menciptakan insentif destruktif (mengejar jumlah temuan → triase asal-asalan); metrik yang benar membuat keputusan investasi jelas.
Kita bahas: metrik inti yang wajib ada, anti-metrik yang harus dihindari, desain dashboard dua audiens (tim & eksekutif), dan maturity model BSIMM sebagai peta jangka panjang program.
#Metrik Inti Program AppSec
Lima metrik yang saya anggap fondasi — semuanya bisa diekstrak dari proses yang sudah kita bangun:
#1. Time-to-Fix (MTTR Remediation)
Median hari dari temuan open hingga verified closed, dipisah per severity. Inilah metrik paling jujur tentang apakah remediasi (episode 13) benar-benar bekerja. Pantau juga persentase dalam SLA — median bisa bagus sementara tail-nya (temuan P1 lewat 90 hari) menyembunyikan bencana.
P0 : median 0.8 hari | in-SLA 100% (n=3)
P1 : median 5.2 hari | in-SLA 92% (n=26)
P2 : median 18 hari | in-SLA 84% (n=141)Perhatikan n — volume penting; median P1 dari tiga tiket bukan statistik, itu anekdot.
#2. Coverage Testing
Dari episode 14: % aset production tercakup tiap instrumen (SAST/SCA/DAST/review). Metrik ini menjawab "di mana area gelap kita" — biasanya repo lama tanpa pipeline.
#3. Vulnerability Escape Rate
Berapa kerentanan ditemukan di production (oleh bug bounty episode 17, pentest, atau lebih buruk: insiden) dibanding total temuan. Escape rate tinggi = kontrol kiri (SAST/review) tidak menutup kelas bug yang relevan — sinyal untuk rebalancing strategi testing.
#4. Fix Backlog Health
Distribusi umur temuan open + tren arah (tumbuh/menyusut) + jumlah exception expired. Backlog yang tumbuh konsisten adalah utang yang berbunga — metrik ini alarm dini sebelum meledak.
#5. Pipeline Gate Adoption
% repo dengan gate aktif per jenis (secret scan, SCA, image verify dari episode 23). Sederhana tapi kuat: adoption rendah = program hanya melindungi sebagian sistem.
Note
Semua lima metrik lahir otomatis jika prosesnya benar: tracker tiket punya timestamp open/close, CI menghasilkan laporan scan bertag commit, registry menyimpan verification status. Kalian tidak perlu tim data — kalian perlu disiplin data dari awal.
#Anti-Metrik yang Harus Dihindari
Metrik ini populer tapi merusak:
| Anti-Metrik | Insentif Salah yang Tercipta |
|---|---|
| Jumlah kerentanan ditemukan | Triase asal jadi; scanner dituning agar banyak bunyi |
| Jumlah scan dijalankan | Cron job sia-sia demi angka cantik |
| Skor severity rata-rata | Inflasi/deflasi skor demi grafik |
| Jumlah training dihadiri | Absensi ≠ kompetensi |
Aturan pembedanya: metrik baik mengukur hasil (bug tertutup cepat, production bersih), bukan aktivitas (scan jalan, training hadir). Saat sebuah metrik mulai dimainkan (Goodhart's law), ganti atau pasangkan dengan penyeimbangnya.
#Dashboard Dua Audiens
Dashboard yang sama tidak cocok untuk developer dan CISO. Desain dua layer:
Layer tim engineering — operasional, actionable:
├─ Temuan open by severity & age (drill-down ke tiket)
├─ PR security-review queue (siapa nunggu apa)
├─ Gate failures minggu ini (dengan root cause)
└─ Exception mendekati expiry (< 14 hari)Layer leadership — tren dan risiko:
├─ Time-to-fix trend per severity (6 bulan)
├─ Coverage % per instrumen (target vs real)
├─ Escape rate (production findings ratio)
├─ Risk acceptance register summary (jumlah, expiry mendekat)
└─ Top 3 risiko sistemik + rekomendasi (narasi, bukan angka saja)Praktik penyajiannya: narasi satu paragraf per metrik ("time-to-fix P1 turun 40% setelah champion triase lokal") selalu mengalahkan grafik telanjang — eksekutif membeli cerita kausal, bukan pixel.
#BSIMM: Memetakan Maturity Program
Untuk peta jangka panjang, industri memakai BSIMM (Building Security In Maturity Model): studi empiris atas praktik nyata 120+ organisasi, dikelompokkan dalam empat domain dan 12 practices:
| Domain | Practices |
|---|---|
| Governance | Strategy & Metrics, Compliance & Policy, Training |
| Intelligence | Attack Models, Security Features & Design, Standards & Requirements |
| SSDL Touchpoints | Architecture Analysis, Code Review, Security Testing |
| Deployment | Penetration Testing, Software Environment, Configuration Ops & Vulnerability Mgmt |
Cara pakai yang sehat: BSIMM bukan checklist kompetisi ("kita harus level 3!"), melainkan benchmark: lihat apa yang dilakukan organisasi sekelas kalian pada practice tertentu, pilih aktivitas berikutnya yang memberi lompatan risiko terbesar. Contoh urutan natural untuk organisasi yang baru matang:
- Governance: metrik dasar (episode ini) + policy ringkas.
- Intelligence: threat modeling standar (ep. 2) + secure coding standard.
- SSDL: SAST+SCA gates (ep. 7, 9) → review prioritas (ep. 12).
- Deployment: pentest berkala + incident feedback loop.
Perhatikan: urutan itu persis alur series ini — bukan kebetulan, karena series dirancang mengikuti kurva maturity yang realistis.
#Common Pitfalls
- Metrik vanity di board deck: "5000 vulnerabilities found!" terdengar produktif padahal artinya backlog raksasa; framing yang benar adalah closure rate dan risk trend.
- Membandingkan tim via metrik mentah: tim payment pasti punya temuan lebih banyak dari tim landing page — bandingkan tren per-tim terhadap dirinya sendiri, bukan antar-tim beda konteks.
- Dashboard tanpa owner: angka basi tiga bulan meruntuhkan kepercayaan semua metrik lain; tiap panel butuh pemilik + freshness check.
- Chasing perfect data: menunggu tracking sempurna sebelum mulai mengukur = tidak pernah mengukur; mulai dari data jelek yang konsisten, perbaiki bertahap.
#Penutup
Inti yang harus dibawa pulang:
- Lima metrik fondasi: time-to-fix (+SLA compliance), coverage, escape rate, backlog health, gate adoption — semuanya otomatis dari proses yang benar.
- Hindari metrik aktivitas; ukur hasil, dan waspadai Goodhart's law.
- Dua dashboard: operasional untuk tim (actionable), tren+narasi untuk leadership (keputusan).
- BSIMM sebagai benchmark empiris untuk memilih aktivitas pengembangan berikutnya, bukan kompetisi level.
Di episode 26 kita zoom out melihat lanskap: Ekosistem & Tren Modern 2026 — shift-left sebagai standar, AI-assisted AppSec mainstream, OWASP LLM Top 10, supply chain regulation, security champions, cloud-native AppSec, dan bagaimana semua benang dari series ini menyatu dalam praktik organisasi saat ini. Sampai jumpa di episode 26!