SAST, DAST, dan SCA: cara memilih serta membaca hasilnya

Apa bedanya SAST, DAST, dan SCA?

SAST memeriksa kode atau artefak, DAST memeriksa aplikasi yang berjalan, dan SCA memeriksa komponen pihak ketiga. Ketiganya membantu mencari masalah; hasil bersih dari satu metode tidak menjamin seluruh aplikasi aman.

Metode	Masukan yang disiapkan	Batas yang perlu ditanyakan
SAST	Versi kode, bahasa, aturan, dan konfigurasi analisis	Apakah bagian kode penting ikut dianalisis?
DAST	Alamat lingkungan yang diizinkan, akun uji, dan alur yang dijangkau	Apakah alat berhasil login dan mencapai fungsi setelah login?
SCA	Dependensi, versi, serta artefak yang benar-benar dirilis	Apakah komponen langsung dan tidak langsung terpetakan?

SAST adalah static application security testing, DAST adalah dynamic application security testing, dan SCA adalah software composition analysis.

NIST SSDF v1.1 membahas analisis kode, pengujian perangkat lunak, serta pencatatan masalah. Ia menjadi rujukan proses teknis di sini, bukan ketentuan bahwa setiap perusahaan harus membeli tiga alat tertentu.

Contoh: perubahan fitur unggah lampiran

Tim fiktif mengganti pustaka pengolah berkas dan menambah endpoint unggah. Rencana pengujiannya mencatat tiga pekerjaan berikut.

• SCA memeriksa versi pustaka dan dependensinya pada paket rilis.
• SAST membantu meninjau alur masukan berkas sampai pemrosesan dan penyimpanan.
• DAST memeriksa perilaku endpoint pada lingkungan uji dengan akun yang sesuai.

Tim juga menambahkan kasus manual: pelanggan A tidak boleh mengunduh lampiran pelanggan B. Alat yang tidak memahami pembagian pelanggan belum tentu menemukan kesalahan izin ini. Hasil setiap metode ditautkan ke versi yang sama agar laporan lama tidak dipakai untuk menyetujui paket baru.

Apa yang disiapkan sebelum menjalankan alat?

Sepakati target, jam, batas laju, tindakan yang dilarang, serta pihak yang dapat menghentikan pengujian. DAST aktif bisa membuat data, memicu notifikasi, atau mengganggu layanan. Dahulukan lingkungan terisolasi dan data buatan. Pengujian produksi membutuhkan izin serta pengendalian dampak yang jelas.

Jangan memberikan rahasia akses produksi, seperti token atau kata sandi, kepada proses scan yang tidak membutuhkannya. Periksa apakah kode atau hasil dipindahkan keluar lingkungan organisasi, siapa dapat membacanya, dan kapan dihapus.

Membaca hasil tanpa terpaku pada jumlah

Laporan perlu menyebut versi aplikasi, waktu, aturan, cakupan, kegagalan alat, dan bagian yang dikecualikan. “Nol temuan” setelah alat gagal login berbeda dari “nol temuan pada alur yang berhasil diuji”.

Untuk SCA, bedakan keberadaan komponen rentan dengan kesimpulan bahwa kondisi eksploitasi berlaku. Penilaian tersebut perlu bukti versi, konfigurasi, dan penggunaan. Ketidakpastian dicatat sebagai pekerjaan verifikasi, bukan langsung diberi label aman.

Apa langkah setelah pemindaian?

Gunakan pemeriksaan temuan scan untuk konfirmasi dan false positive. Temuan yang berlaku masuk ke register kerentanan, dengan penanggung jawab serta pemeriksaan ulang. Simpan hasil bersama bukti persetujuan rilis, termasuk batas pemeriksaan yang belum terjawab.