SDLC Aman, Alat SAST, dan DAST

Siklus Hidup Pengembangan Perangkat Lunak yang Aman (SSDLC) mengintegrasikan aktivitas Security ke setiap fase pengembangan perangkat lunak — mulai dari requirement, design, coding, pengujian, deployment, hingga pemeliharaan. SDLC tradisional memperlakukan Security sebagai gerbang tahap akhir, yang mahal dan tidak efektif. Filosofi SSDLC yang aman adalah menemukan dan memperbaiki kerentanan sedini mungkin, karena cacat yang ditemukan saat design jauh lebih murah untuk diperbaiki daripada cacat yang ditemukan di lingkungan produksi.

Shift left berarti memindahkan Security ke tahap yang lebih awal (ke sebelah kiri pada lini masa pengembangan), bukan menambahkannya secara tergesa-gesa di akhir. Dalam praktiknya, hal ini berarti memasukkan requirement Security ke dalam user story, melakukan pemodelan ancaman selama design, melakukan tinjauan kode dan SAST selama pengembangan, serta menjalankan DAST sebelum rilis. Team yang menerapkan shift left menemukan kerentanan saat biaya perbaikannya paling rendah — selama pengembangan, bukan di lingkungan produksi.

Pemodelan ancaman secara sistematis mengidentifikasi dan mendokumentasikan ancaman Security selama fase design. Model STRIDE mengategorikan ancaman menjadi: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, dan Elevation of Privilege. PASTA (Process for Attack Simulation and Threat Analysis) adalah metodologi yang berfokus pada risiko dan menyimulasikan tujuan Attacker. Model ancaman menghasilkan mitigasi yang diprioritaskan sebelum satu baris kode pun ditulis.

SAST (pengujian kotak putih) menganalisis kode sumber, bytecode, atau biner tanpa menjalankan aplikasi, untuk mencari pola coding yang terkait dengan kerentanan yang telah diketahui. Alat SAST dapat memindai seluruh basis kode dengan cepat dan melaporkan masalah seperti kredensial yang di-hardcode, titik injeksi SQL, serta deserialisasi yang tidak aman. Alat ini berjalan di dalam IDE atau pipeline CI dan melaporkan temuan beserta nomor file dan baris, sehingga perbaikannya mudah dilakukan.

Keterbatasan utama SAST adalah kecenderungannya menghasilkan positif palsu — menandai kode sebagai rentan padahal sebenarnya aman. Kelelahan akibat peringatan ini menyebabkan pengembang mengabaikan temuan tanpa menyelidikinya. Alat SAST juga tidak dapat mendeteksi masalah konfigurasi saat runtime, kelemahan Authentication yang bergantung pada perilaku runtime, atau kerentanan dalam pemanggilan API pihak ketiga. SAST paling efektif jika dipadukan dengan pelatihan pengembang agar temuan dapat diprioritaskan dan ditangani secara akurat.

DAST (pengujian kotak hitam) menguji aplikasi yang sedang berjalan dengan mengirimkan muatan serangan ke endpoint HTTP-nya dan menganalisis respons untuk mencari indikator kerentanan. DAST tidak memerlukan akses ke kode sumber — aplikasi diuji sebagaimana Attacker mengujinya. DAST sangat efektif menemukan masalah saat runtime seperti bypass Authentication, XSS yang tercermin dalam respons, dan kesalahan konfigurasi Server. Alat DAST mencakup OWASP ZAP, Burp Suite, dan Netsparker.

SAST dan DAST saling melengkapi, bukan bersaing. SAST menemukan masalah pada tingkat kode sejak awal dan terintegrasi dengan IDE, tetapi tidak memiliki visibilitas terhadap perilaku runtime. DAST menemukan kerentanan saat runtime dan tidak memerlukan kode sumber, tetapi tidak dapat memindai jalur kode yang tidak dipicu oleh probe otomatisnya. Penggunaan keduanya secara bersamaan — SAST dalam pipeline CI dan DAST terhadap lingkungan staging — memaksimalkan cakupan kerentanan di seluruh SDLC.

IAST menggabungkan aspek SAST dan DAST dengan menginstrumentasikan aplikasi saat runtime. Agen IAST berjalan di dalam aplikasi (pada Server), mengamati eksekusi kode saat lalu lintas pengujian mengalir melaluinya. IAST dapat menghubungkan input pengguna yang tercemar melalui jalur kode ke titik tujuan sensitif — sehingga menemukan kerentanan dengan tingkat positif palsu yang lebih rendah daripada SAST murni. IAST sangat efektif pada aplikasi Java dan .NET serta terintegrasi secara alami ke dalam pelaksanaan pengujian fungsional.

Analisis Komposisi Perangkat Lunak (SCA) mengidentifikasi pustaka sumber terbuka dan Dependency pihak ketiga dalam aplikasi, lalu memeriksanya terhadap basis data kerentanan (NVD, OSV). Karena aplikasi modern dapat menarik ratusan Dependency — banyak di antaranya secara transitif — alat SCA seperti OWASP Dependency-Check, Snyk, dan Renovate sangat penting untuk menemukan CVEs yang telah diketahui sebelum dieksploitasi oleh Attacker dalam rantai pasokan Anda.

Mengintegrasikan alat Security ke dalam pipeline CI/CD memastikan tidak ada kode yang mencapai lingkungan produksi tanpa melewati gerbang Security. Pipeline DevSecOps yang umum menjalankan: SAST pada setiap commit, SCA saat Dependency berubah, pemindaian image Container sebelum dikirim ke registry, pemindaian IaC untuk Terraform/CloudFormation, serta DAST terhadap deployment staging. Check Security yang gagal akan memblokir build dan menegakkan budaya Security secara default.

Alat otomatis tidak dapat menggantikan tinjauan kode oleh manusia yang berfokus pada logika Security. Tinjauan oleh rekan kerja harus memverifikasi bahwa: Check Authentication dan otorisasi berada di tempat yang tepat, penanganan error tidak membocorkan Information sensitif, fungsi kriptografi menggunakan algoritme dan parameter yang disetujui, serta logika bisnis tidak dapat dilewati. Security champion dalam Team pengembangan — pengembang yang telah mendapat pelatihan Security — menjembatani kesenjangan antara Team Security dan Engineering.

Uji pemahaman Anda tentang konsep CompTIA Security+ (SY0-701) dari lesson ini.

Dalam lesson ini Anda mempelajari: SSDLC yang aman mengintegrasikan Security di seluruh fase pengembangan, bukan menambahkannya secara tergesa-gesa di akhir, SAST menganalisis kode tanpa eksekusi, sedangkan DAST menguji aplikasi yang sedang berjalan, serta SCA mengidentifikasi Dependency sumber terbuka yang rentan dan gerbang Security CI/CD menerapkan temuan secara otomatis. Berikutnya kita akan membahas layanan Directory dengan LDAP dan Active Directory.