Pengembangan aplikasi yang aman: threat modeling sampai rilis

Kapan pekerjaan keamanan dimulai?

Mulai saat tim memutuskan fitur, data, dan hak aksesnya. Menunggu pentest setelah semua kode selesai dapat membuat masalah desain baru terlihat ketika perubahan sudah mahal.

NIST SSDF v1.1, atau Secure Software Development Framework, membahas kesiapan organisasi, perlindungan perangkat lunak, pengembangan, dan respons terhadap kerentanan. Panduan ini memakai publikasi final tersebut sebagai rujukan praktik, bukan sertifikat atau kewajiban hukum Indonesia.

Apa itu threat modeling?

Threat modeling adalah pembahasan terstruktur tentang apa yang dibangun, apa yang bisa salah, bagaimana menguranginya, dan bagaimana memeriksa hasilnya. Mulai dari alur data serta batas kepercayaan: bagian tempat identitas, izin, atau informasi dari pihak lain perlu dinilai.

Contoh fiktif: fitur ekspor pesanan menerima permintaan pengguna, membuat berkas di latar belakang, lalu menyediakan tautan unduh. Tim perlu memikirkan izin saat meminta ekspor dan saat berkas diunduh, termasuk jika hak pengguna berubah di antara keduanya.

Risiko pada contoh	Keputusan desain	Kriteria pemeriksaan
Pengguna meminta ekspor perusahaan lain	Periksa organisasi dan hak ekspor di server	Permintaan lintas perusahaan ditolak
Tautan berkas tersebar	Tentukan izin unduh dan masa ketersediaan	Orang tanpa izin tidak mendapat berkas
Hak pengguna dicabut setelah permintaan	Tentukan perilaku saat unduh	Hasil mengikuti keputusan pencabutan yang disepakati
Berkas lama menumpuk	Tentukan masa simpan dan penghapusan	Sampel berkas kedaluwarsa ditangani sesuai jadwal

Ini contoh rancangan pemeriksaan, bukan hasil pengujian aplikasi tertentu. Tim masih perlu membuktikan perilakunya pada versi dan lingkungan yang diizinkan.

Apa beda SAST, DAST, SCA, dan code review?

Pemeriksaan	Apa yang diperiksa	Batas utama
SAST (static application security testing)	Kode atau artefak tanpa menjalankan aplikasi seperti pengguna	Hasil bergantung pada bahasa, aturan, dan bagian yang dianalisis
DAST (dynamic application security testing)	Perilaku aplikasi yang berjalan	Tidak mencakup fungsi yang tidak dijangkau alat atau akun uji
SCA (software composition analysis)	Komponen pihak ketiga dan kerentanan yang diketahui	Daftar komponen perlu sesuai versi yang benar-benar dirilis
Code review	Perubahan kode dan keputusan implementasi oleh pemeriksa	Mutu bergantung pada lingkup, konteks, dan kemampuan pemeriksa

Gabungkan metode sesuai risiko. Status “tidak ada temuan” dari satu alat tidak membuktikan seluruh alur bisnis aman. Catat konfigurasi dan keterbatasan pemeriksaan, lalu tindak lanjuti temuan yang telah dikonfirmasi.

Apa gunanya SBOM?

SBOM (software bill of materials) adalah daftar komponen perangkat lunak. Daftar ini membantu mencari rilis yang menggunakan komponen tertentu ketika ada pemberitahuan kerentanan.

Simpan hubungan antara komponen, versi, asal, dan rilis produk. SBOM yang tidak diperbarui setelah perubahan hanya menggambarkan keadaan lama. Daftar tersebut bukan sertifikat aman dan tidak menggantikan penilaian apakah kerentanan benar-benar memengaruhi aplikasi.

Bagaimana melindungi proses CI/CD?

CI/CD adalah rangkaian otomatis untuk memeriksa, membangun, dan mengirim perubahan. Ia memiliki akses yang dapat memengaruhi produk, sehingga perlu pembatasan hak, perlindungan secret, pengendalian perubahan, dan jejak rilis.

Pisahkan lingkungan pengembangan, pengujian, dan produksi sesuai risiko. Tentukan siapa boleh mengubah alur otomatis, menyetujui rilis, serta mengambil artefak yang akan dipasang. Jangan memberikan rahasia produksi kepada pekerjaan pengujian yang tidak membutuhkannya.

Contoh urutan kerja satu rilis

Untuk fitur ekspor tadi, pemilik produk menulis batas akses dan masa simpan. Pengembang mendokumentasikan desain, membuat perubahan, lalu meminta pemeriksaan kode. Tim menjalankan pemeriksaan otomatis dan kasus akses dengan data fiktif. Temuan dinilai sebelum pihak berwenang menyetujui rilis.

Setelah rilis, simpan identitas artefak, keputusan, hasil pemeriksaan, dan rencana pemulihan. Pantau masalah serta kerentanan komponen. Jika batas akses gagal, hentikan persetujuan fitur tersebut sampai perbaikannya dibuktikan; jangan mengganti bukti dengan banyaknya alat yang sudah dijalankan.

Gunakan register kerentanan untuk penanggung jawab, tenggat, pengecualian, dan hasil uji ulang. Bagi pembeli aplikasi, minta bukti yang sesuai lingkup kontrak melalui checklist serah terima.

Sebelum mengirim komponen pihak ketiga, periksa juga lisensi open source dan bukti atribusinya.

Sebelum perubahan masuk produksi, gunakan alur persetujuan rilis untuk memeriksa versi, bukti uji, dan jalan kembali.

Pilih bukti untuk tiap tahap rilis

Mulai dengan lembar pemetaan ancaman untuk mencatat batas akses dan keputusan desain. Saat membangun rilis, gunakan panduan SBOM untuk menelusuri komponen dan pengamanan CI/CD untuk memeriksa siapa dapat mengubah serta menerbitkan artefak. Ketiganya memberi bukti berbeda; hasil pemindaian saja tidak menunjukkan siapa menyetujui rilis.

Contoh threat modeling sebelum membangun ekspor

Tim SaaS fiktif menggambar alur: browser pelanggan → API → antrean pekerjaan → pekerja ekspor → penyimpanan → tautan unduh. Batas kepercayaan berubah ketika masukan browser diterima API, pekerjaan diambil dari antrean, dan berkas dikirim kembali ke pengguna.

Tim tidak menganggap ID organisasi dari browser sebagai bukti keanggotaan. Keputusan desainnya: izin diperiksa di server, konteks organisasi pada tugas dijaga, dan pekerja ekspor serta jalur unduh memeriksa batas akses yang sesuai. Jika pemeriksaan tidak dapat dilakukan, berkas tidak diberikan.

Ujinya memakai pelanggan A dan B dengan data buatan, termasuk percobaan mengambil hasil pekerjaan pihak lain. Pemilik produk mencatat dampak dan kebutuhan penggunaan yang sah; pengembang mencatat kontrol serta bukti uji pada lembar pemetaan ancaman. Tinjau lagi ketika alur antrean atau penyimpanan berubah. Ini membantu menangani insecure design sebelum hanya mengandalkan pengujian setelah fitur selesai.

Pahami risiko di balik pemeriksaan

Baca Injection, penanganan kondisi gagal untuk memahami konsep dan contoh kegagalannya. Gunakan langkah di halaman ini untuk pekerjaan penerapan.

Pemeriksaan fitur terkait

Untuk menetapkan hasil uji per fitur, gunakan pencegahan XSS, kueri berparameter dan SQL injection, serta keamanan upload file. Panduan tersebut melengkapi proses rilis ini dengan contoh dan kriteria penerimaan.

Langkah penerapan berikutnya

Gunakan perbandingan SAST, DAST, dan SCA untuk menentukan masukan, cakupan, serta batas setiap pemeriksaan. Setelah alat selesai, ikuti verifikasi temuan scan sebelum menutup atau mengecualikan hasil.