Belajar Application Security Engineer - Vulnerability Remediation

#Pendahuluan

Setelah di episode 12 kalian bisa menemukan temuan bernilai lewat review manual, episode ini menjawab pertanyaan yang justru lebih sering menentukan keberhasilan program AppSec: apa yang terjadi setelah temuan itu ada? Organisasi yang gagal di AppSec jarang karena buta menemukan bug — mereka gagal karena temuan menumpuk tanpa prioritas, fix guidance yang tidak dipahami, dan SLA yang tidak pernah ditegakkan. Remediasi adalah tempat security berubah dari aktivitas menjadi hasil.

Kita bahas empat bagian: skoring & prioritisasi, penulisan fix guidance, SLA, dan jalur exception.

#Skoring: CVSS Itu Awal, Bukan Jawaban

CVSS (Common Vulnerability Scoring System) memberi skor 0–10 dari vektor eksploitasi — versi 4.0 adalah standar aktif saat ini. Nilai praktisnya: bahasa umum untuk urgensinya. Kelemahannya juga nyata: CVSS buta konteks bisnis. CVE 9.8 pada library internal yang tidak terpapar internet bukan urgensi sama dengan CVE 9.8 di edge API production.

Lengkapi dengan dua dimensi:

1. EPSS (Exploit Prediction Scoring System) — probabilitas 0–100% bahwa CVE akan dieksploitasi di alam liar dalam 30 hari. Ini data empiris dari aktivitas eksploitasi aktual, jauh lebih prediktif daripada angka severity teoretis:

curl -s "https://api.first.org/data/v1/epss?cve=CVE-2021-44228" | jq '.data[0]'
# epss: "0.97xxx" → 97% kemungkinan dieksploitasi — patch HARI INI

2. Konteks aset: terpapar internet atau internal? Data apa yang disentuh? Ada compensating control (WAF, segmentasi)? Reachable dari kode kalian atau hanya bundled?

#Formula Prioritas Praktis

EPSS mengubah banyak keputusan nyata: CVE "High" dengan EPSS 0.5% boleh menunggu sprint depan; CVE "Medium" dengan EPSS 60% harus maju. Tanpa EPSS, kalian memprioritaskan berdasar kesan; dengannya, berdasar data.

#Menulis Fix Guidance yang Dieksekusi

Temuan tanpa guidance adalah keluhan. Struktur tiket remediasi yang saya pakai:

JUDUL   : [P1] IDOR pada GET /api/orders/{id} — checkout service
SEVERITY: High | CVSS 7.5 | EPSS n/a (custom finding)
DAMPAK  : User A dapat membaca order User B → PII leak, regulasi UU PDP
REPRO   : curl -H "Auth token A" .../api/orders/<id-milik-B> → 200 + data
ROOT CAUSE: query by id tanpa filter userId
FIX     : tambahkan userId: req.user.id pada kondisi findOne (diff terlampir)
REGRESI : integration test baru — replay suite antar dua akun
SLA     : due 2026-08-23

Tiga aturan penyusunannya:

1. Reproducible dalam satu command — developer harus bisa melihat bug sendiri dalam 2 menit, tanpa bertanya.
2. Diff konkret untuk kasus umum; hanya untuk desain-level yang solusinya dibahas bersama.
3. Regresi test ikut diminta — tanpa test, bug yang sama akan lahir lagi di endpoint berikutnya.

#SLA: Janji yang Harus Ditegakkan

SLA remediasi hanya bermakna jika tiga komponennya lengkap:

1. Angka per prioritas — misalnya P0 24 jam, P1 7 hari, P2 30 hari (selaraskan dengan tabel prioritas di atas).
2. Eskalasi otomatis saat mendekati due — mention lead tim di 50% masa SLA, eskalasi manajemen saat lewat. Tiket yang diam melewati due date mengajarkan organisasi bahwa SLA adalah dekorasi.
3. Metrik time-to-fix — median waktu dari open ke closed per severity. Inilah metrik inti yang kita pantau di dashboard episode 25.

Sumber temuan mempengaruhi ekspektasi waktu: temuan internal review bisa masuk sprint normal; temuan bug bounty publik dan CVE aktif di komponen internet-facing biasanya menuntut hotfix path. Siapkan jalur rilis cepat (cherry-pick + patch release) untuk kasus kedua.

#Risk Acceptance: Jalur Exception yang Jujur

Kenyataan produksi: beberapa temuan tidak bisa diperbaiki dalam SLA — vendor belum rilis patch, sistem legacy akan di-rewrite kuartal depan, library fork terlalu mahal. Tanpa jalur resmi, orang akan mematikan scanner atau mengabaikan tiket. Proses acceptance yang sehat punya empat syarat:

1. Justifikasi tertulis dari pemilik risiko (bukan AppSec — kalian pendamping, mereka pengambil risiko).
2. Compensating control eksplisit: WAF rule, segmentasi network, monitoring khusus, akses dibatasi.
3. Expiry date wajib — exception tanpa kedaluwarsa adalah legalisasi permanen atas hutang. Maksimum realistis: 90 hari, perpanjangan butuh approval lebih tinggi.
4. Terdaftar di register yang direview berkala — saat insiden datang, daftar inilah yang menjelaskan apa yang diketahui organisasi.

ID      : EXC-2026-031
TEMUAN  : CVE-2025-XXXX di library pdf-gen (internal tool HR)
ALASAN  : Tidak ada fix upstream; tool hanya internal; rewrite Q4
CONTROL : WAF blok path /pdf-gen dari VLAN user; alert antrian job > 100
EXPIRY  : 2026-11-30 (review ulang saat Q4 planning)
APPROVED: Head of Engineering, 2026-08-20

#Common Pitfalls

• Chasing 100% closure: memburu semua temuan low membuat P1 telat; energi mengikuti risiko, bukan jumlah baris spreadsheet.
• AppSec yang menutup tiket atas kata developer: verifikasi fix (re-test repro) sebelum status closed — trust butuh bukti.
• Severity inflation: setiap temuan dilabel critical supaya cepat ditangani; efeknya kritik seruan kehilangan arti dan tim kebal alarm.
• Fix tanpa regresi test: bug IDOR muncul lagi di endpoint baru bulan depan; test antar-akun adalah vaksinnya.

#Penutup

Inti yang harus dibawa pulang:

• Prioritas = CVSS × EPSS × konteks aset; EPSS menyelamatkan kalian dari memprioritaskan berdasar kesan.
• Tiket remediasi baik: repro satu command, dampak bisnis, diff fix, permintaan regression test, SLA tanggal.
• SLA hidup lewat eskalasi otomatis dan metrik time-to-fix — bukan dokumen.
• Risk acceptance resmi: justifikasi, compensating control, expiry, register — jujur pada diri sendiri.

Di episode 14 kita zoom out dari satu temuan ke keseluruhan program: Security Testing Strategy — kapan memakai SAST, DAST, SCA, atau pentest; bagaimana mengukur coverage; dan cara mengelola false positive lintas tool agar organisasi tidak mati oleh noise. Sampai jumpa di episode 14!