Belajar Application Security Engineer - Security Testing Strategy

#Pendahuluan

Sepanjang episode 7–13 kita membangun tiap instrumen testing secara individual: SAST, DAST, SCA, review manual, dan remediasi. Episode ini merakit semuanya menjadi satu strategi — karena masalah organisasi nyata bukan "tool mana yang bagus", melainkan "tool mana di tahap mana, dengan budget dan waktu siapa". Strategi yang salah menghasilkan dua kemungkinan sama buruknya: temuan bocor ke production, atau developer mati oleh noise dan mematikan semua scanner.

Di akhir episode kalian akan punya kerangka untuk menjawab pertanyaan klasik manajer: "apakah aplikasi kita sudah cukup dites?" — dengan jawaban yang bisa dibuktikan, bukan perasaan.

#Memetakan Instrumen ke Fase dan Target

Setiap teknik menemukan kelas bug berbeda pada biaya berbeda. Matriks keputusannya:

Dua prinsip komposisi yang penting:

1. Murah dan cepat di kiri; mahal dan mendalam di kanan. Scanner harian menangkap reguler; pentest tahunan menangkap rantai serangan kreatif. Tidak ada tool yang menggantikan yang lain.
2. Tiap layer menutup blind spot layer lain. DAST buta business logic → dilengkapi review manual. Review manual buta skala → dilengkapi scanner.

#Coverage: Mengukur yang Benar

Pertanyaan "sudah cukup dites?" butuh definisi terukur. Metrik coverage yang saya rekomendasikan, dari paling penting:

1. Asset coverage: % service/repository aktif yang terdaftar di program testing. Repo yang tidak kena scan mana pun = nol visibilitas — dan biasanya justru yang lama dan rapuh.
2. Pipeline coverage: % repo dengan gate otomatis aktif (SAST+SCA+secret). Target realistis tahun pertama: >90% repo production.
3. Auth surface coverage: % endpoint terautentikasi yang pernah di-scan authenticated (DAST) atau direview authz-nya.
4. Depth signal: jumlah temuan valid per 1000 LOC atau per release — bukan metrik kebaikan, tapi detektor area gelap: modul dengan temuan tinggi butuh review lebih dalam.

Hindari metrik vanity seperti "jumlah scan dijalankan" — scan yang berjalan tanpa triase hanyalah listrik mahal.

#Mengelola False Positive Lintas Tool

Noise adalah pembunuh program testing nomor satu. Pengelolaannya harus sistemik, bukan heroik:

1. Tuning per tool sebelum rollout (prinsip dari episode 7): audit rule set di seluruh codebase, matikan rule dengan rasio false positive > 70%, sempitkan konteks rule bermasalah.

2. Deduplikasi lintas tool: SQL injection yang sama akan dilaporkan Semgrep, ZAP, dan pentester. Tanpa dedup, satu bug = tiga tiket = kepercayaan runtuh. Solusi pragmatis: normalisasi temuan ke satu format (repo + file/endpoint + kategori CWE) sebelum masuk tracker.

3. Routing berbeda untuk noise level berbeda:

High confidence (taint confirmed)  → tiket + gate PR langsung
Medium confidence                  → dashboard triase mingguan AppSec
Low confidence (pattern only)      → report bulanan, tidak masuk tracker

4. Umpan balik permanen: setiap kali kalian memvalidasi false positive, tulis alasannya di konfigurasi suppression. Enam bulan kemudian orang lain akan membaca alasan itu alih-alih mengulang investigasi.

#Menyusun Dokumen Strategi Satu Halaman

Strategi yang tidak muat satu halaman tidak akan dibaca siapa pun. Struktur yang saya pakai:

1. Tujuan & scope: aplikasi mana, lingkungan mana, apa definisi "cukup aman".
2. Matriks instrumen (seperti tabel awal episode ini) — versi organisasi kalian.
3. Gate policy: apa yang memblokir merge/rilis vs masuk backlog.
4. SLA remediasi: angka per severity, merujuk proses episode 13.
5. Ritme: nightly scan, mingguan triase, kuartalan pentest/review mendalam.
6. Metrik: coverage + time-to-fix + escape rate.
7. Kebutuhan resource: siapa mengerjakan apa, berapa jam.

Contoh keputusan konkret yang harus tertulis — dan yang paling sering diperdebatkan tim:

• PR gate: fail hanya CRITICAL-with-fix (SCA) + ERROR baru (SAST) + secret. Sisanya dashboard.
• DAST full hanya nightly di staging; baseline passive boleh per PR.
• Pentest eksternal: sekali setahun + sebelum rilis mayor fitur pembayaran/auth.

#Common Pitfalls

• Tool-first strategy: beli platform enterprise dulu, pikirkan proses belakangan — hasilnya shelfware mahal.
• Semua harus blocking: pipeline merah terus membuat tim belajar me-rebase untuk menghindari gate; proporsi itu kunci.
• Coverage diukur dari jumlah scan: 100% scan pada 60% aset berarti 40% gelap; ukur dari sisi aset.
• Pentest sebagai checkbox: laporan pentest yang tidak masuk tracker remediasi adalah formalitas audit yang memberi ilusi keamanan.

#Penutup

Inti yang harus dibawa pulang:

• Setiap teknik punya blind spot; strategi = komposisi berlapis sesuai fase: murah-cepat di kiri, mahal-mendalam di kanan.
• Coverage diukur dari sisi aset (% service tercakup), bukan jumlah scan.
• False positive dikelola sistemik: tuning, dedup, routing berdasarkan confidence, umpan balik tertulis.
• Strategi satu halaman dengan keputusan eksplisit lebih berharga daripada dokumen 40 halaman.

Di episode 15 kita bawa strategi ini ke arsitektur modern: AppSec in Cloud-Native — keamanan serverless, hardening aplikasi di Kubernetes, dan runtime detection dengan Falco untuk menangkap perilaku abnormal saat produksi berjalan. Sampai jumpa di episode 15!