SAST, DAST, dan IAST: Memilih Pengujian Keamanan yang Tepat
SAST, DAST, dan IAST melihat bukti yang berbeda. SAST memeriksa kode tanpa eksekusi; DAST menguji perilaku aplikasi berjalan; IAST menginstrumentasi aplikasi berjalan. Tidak satu pun menemukan semua cacat bisnis atau konfigurasi.
Pilih berdasarkan pertanyaan
Gunakan SAST untuk menandai penggunaan API tidak aman sebelum merge. Gunakan DAST untuk menguji autentikasi, header, dan route yang dapat dijangkau pada deployment. Gunakan IAST saat coverage runtime dan konteks kode sama-sama diperlukan. Contoh: SAST dapat menemukan SQL yang dibangun dari string pada kode dorman; DAST dapat menemukan otorisasi hilang hanya dengan akun uji nyata.
Tabel pemilihan
| Kebutuhan | Pilihan | Batasan |
|---|---|---|
| feedback kode awal | SAST | jalur mungkin tidak dieksekusi |
| perilaku runtime terekspos | DAST | tidak melihat semua kode |
| kode dan jalur yang dijalankan | IAST | perlu instrumentasi |
| abuse workflow | uji manual | perlu konteks produk |
NIST SSDF dan OWASP source analysis/WSTG menjadi dasar perbandingan.
Aturan keputusan: aktifkan atau beli tool hanya bila temuannya punya owner, jalur triage, dan cakupan uji yang diharapkan.
Operasionalkan
Jalankan baseline kecil, tuning rule berdasarkan hasil terkonfirmasi, simpan suppression beserta alasan, dan pertahankan review manual untuk otorisasi serta logika bisnis. Output tool adalah bukti untuk diselidiki, bukan sertifikat rilis. Pengujian web memberi validasi runtime.
Pilih bukti sebelum tool
Pilih SAST bila pertanyaannya feedback tingkat source sebelum merge; pilih DAST terautentikasi bila pertanyaannya perilaku aplikasi berjalan yang dapat dijangkau; pilih IAST bila jalur yang dieksekusi memerlukan konteks kode runtime. Tidak satu pun menggantikan review manual untuk otorisasi, alur bisnis, atau keputusan deployment. Mulai dari cakupan bahasa dan framework yang didukung, lingkungan terkontrol, penanganan data jelas, dan owner yang dapat mentriage temuan.
Kalibrasikan dengan kasus aman dan tidak aman yang diketahui. Catat commit, ruleset, environment, cakupan route, identifier temuan, status reproduksi, owner triage, alasan suppression, dan retest. Jangan jadikan volume tanpa review sebagai metrik rilis. Owner: pemilik tooling keamanan. Lulus: scope tool menjawab pertanyaan yang dinyatakan dan temuan punya penanganan deterministik. Gagal: cakupan tidak didukung dianggap jaminan, credential memengaruhi produksi, atau suppression tanpa alasan. Pengecualian mencakup scope terbatas, uji kompensasi, approver, remediasi, dan kedaluwarsa.
Jaga environment tetap aman
DAST dan IAST memerlukan akun, seed data, dan batas instrumentasi yang dibuat untuk pengujian. Gunakan lingkungan terisolasi, identitas sintetis, laju scan terbatas, dan rencana reset. Output SAST perlu identitas rule dan lokasi kode untuk reproduksi. Akhiri perbandingan dengan pilot representatif serta antrean remediasi yang dijaga, bukan checklist fitur vendor.
Dossier pemilihan tooling
Output yang diharapkan: versi tool, commit, bahasa didukung, environment uji, scope autentikasi, cakupan route, ID temuan, owner triage, alasan suppression. Bukti ini menghubungkan scope tool dengan hasil triage yang tercatat.
Kegagalan teruji: Peringatan SAST muncul pada generated code di luar analisis didukung. Tandai celah cakupan; jangan klaim scan membersihkan komponen itu.
Kasus tepi: Akun DAST terautentikasi dapat mengubah data uji. Beri privilege minimum dan jalur reset agar uji liar tidak memengaruhi layanan bersama.
Uji penutupan: Bandingkan reproduksi temuan pilot dengan cakupan diharapkan. Penutupan lulus bila tool terpilih menjawab pertanyaan yang dinyatakan dan celah tersisa punya owner manual.
Desain pilot dan penanganan hasil
Pilot pemilihan memerlukan pertanyaan tetap dan outcome diharapkan yang diketahui. Untuk SAST, seed atau identifikasi pola aman dan tidak aman representatif pada kode didukung. Untuk DAST, tentukan route terautentikasi, tindakan destruktif yang dikecualikan, laju scan, dan reset data uji. Untuk IAST, dokumentasikan penempatan agent, anggaran performa, dan jalur yang dieksekusi menghasilkan trace. Bandingkan false positive, kasus diketahui yang terlewat, beban setup, dan bukti yang dapat dibaca developer.
Temuan memerlukan siklus hidup terpisah dari severity pemasaran tool. Triage menetapkan hasil confirmed, tidak dapat direproduksi, pengecualian diterima, duplikat, atau di luar scope dengan alasan. Suppression harus mengidentifikasi rule, lokasi kode, owner, dan tanggal review. Ekspor atau simpan hasil tool mentah agar upgrade berikutnya dapat menilai ulang keputusan lama. Outage scanner juga kondisi: putuskan apakah pipeline memblokir, memberi peringatan, atau mengarahkan ke bukti manual sebelum hal itu terjadi.
Dokumentasikan pencabutan autentikasi scanner dan cleanup data setelah pilot. Uji credential DAST tidak dapat mengakses route destruktif administrator kecuali scope uji secara eksplisit memerlukannya. Trace IAST harus menghilangkan secret dan data pribadi dari bukti yang disimpan.
Scope tool harus diungkapkan kepada developer di tempat temuan muncul. Nyatakan bahasa tidak didukung, direktori dikecualikan, route tanpa autentikasi, dan blind spot instrumentasi. Build hijau berarti pemeriksaan terkonfigurasi selesai; itu tidak berarti semua kelas kerentanan diuji. Saat pilot, ukur waktu dari temuan ke triage dan apakah lokasi kode atau bukti HTTP memungkinkan owner mereproduksi hasil. Pilih lebih sedikit tool ketika buktinya tumpang tindih tanpa menambah nilai keputusan berbeda.