Kebijakan Siklus Hidup Pengembangan Perangkat Lunak yang Aman
1. Tujuan
Menetapkan persyaratan untuk mengintegrasikan keamanan di seluruh siklus hidup pengembangan perangkat lunak guna mencegah, mendeteksi, dan meremediasi kerentanan keamanan dalam aplikasi yang dikembangkan dan diperoleh [ORGANIZATION].
2. Ruang Lingkup
Kebijakan ini berlaku untuk seluruh perangkat lunak yang dikembangkan, dikustomisasi, atau diperoleh oleh [ORGANIZATION], termasuk aplikasi in-house, aplikasi web, API, aplikasi seluler, dan skrip yang diterapkan di lingkungan produksi.
3. Kebijakan
3.1 Persyaratan Keamanan SDLC
[ORGANIZATION] harus mengintegrasikan aktivitas keamanan ke dalam setiap fase siklus hidup pengembangan perangkat lunak: Persyaratan (persyaratan keamanan, pemodelan ancaman), Desain (tinjauan arsitektur aman, pola desain keamanan), Pengembangan (standar pengkodean aman, tinjauan kode oleh rekan), Pengujian (pengujian keamanan, pemindaian kerentanan), Penerapan (prosedur penerapan yang aman, tinjauan konfigurasi), dan Pemeliharaan (manajemen patch, pemantauan berkelanjutan).
Proses SDLC yang aman harus didokumentasikan dan dikomunikasikan kepada seluruh tim pengembangan.
Persyaratan keamanan harus didefinisikan untuk setiap aplikasi berdasarkan klasifikasi data dan penilaian risiko.
3.2 Praktik Pengkodean Aman
Pengembang harus mengikuti standar pengkodean aman yang terdokumentasi berdasarkan OWASP, CERT, atau pedoman yang setara untuk bahasa pemrograman mereka.
Kode harus dikembangkan untuk mencegah kelas kerentanan umum termasuk: serangan injeksi (SQL, perintah, LDAP), cross-site scripting (XSS), cross-site request forgery (CSRF), deserialisasi yang tidak aman, autentikasi yang rusak, dan paparan data sensitif.
Pustaka dan komponen pihak ketiga harus dilacak dalam software bill of materials (SBOM) dan dipantau untuk kerentanan yang diketahui.
Kredensial yang dikodekan secara tetap, kunci API, dan rahasia dilarang dalam kode sumber. Rahasia harus dikelola melalui solusi manajemen rahasia yang disetujui.
3.3 Pengujian Keamanan
Static Application Security Testing (SAST) harus diintegrasikan ke dalam pipeline CI/CD dan dilakukan pada seluruh kode sebelum penggabungan ke cabang utama.
Dynamic Application Security Testing (DAST) harus dilakukan pada seluruh aplikasi web setidaknya [CUSTOMIZE: triwulanan/bulanan] dan sebelum setiap rilis utama.
Analisis komposisi perangkat lunak (SCA) harus digunakan untuk mengidentifikasi kerentanan dalam komponen dan pustaka pihak ketiga.
Pengujian penetrasi harus dilakukan pada aplikasi kritis setidaknya [CUSTOMIZE: tahunan] oleh penguji yang berkualifikasi.
Kerentanan keamanan yang teridentifikasi melalui pengujian harus diremediasi sesuai dengan SLA Kebijakan Manajemen Kerentanan.
3.4 Keamanan Penerapan
Penerapan produksi harus mengikuti proses terdokumentasi yang dapat diulang menggunakan otomatisasi CI/CD bila memungkinkan.
Pengembang tidak boleh memiliki akses langsung ke lingkungan produksi. Penerapan harus dilakukan melalui pipeline otomatis atau oleh personel operasi yang ditunjuk.
Lingkungan produksi harus terpisah dari lingkungan pengembangan, pengujian, dan staging tanpa kredensial yang dibagikan.
Prosedur rollback penerapan harus didokumentasikan dan diuji untuk setiap aplikasi kritis.
4. Kepatuhan
Kepatuhan terhadap kebijakan ini wajib bagi seluruh personel dalam cakupannya. Kepatuhan akan dipantau melalui audit berkala, kontrol otomatis, dan tinjauan manajemen.
Pengecualian terhadap kebijakan ini harus didokumentasikan dengan justifikasi bisnis, disetujui oleh [CUSTOMIZE: CISO/Tim Keamanan], dan ditinjau setidaknya setiap tahun.
5. Penegakan
Pelanggaran terhadap kebijakan ini dapat mengakibatkan tindakan disipliner hingga dan termasuk pemutusan hubungan kerja atau kontrak, dan dapat mengakibatkan sanksi perdata atau pidana jika hukum yang berlaku telah dilanggar.
[ORGANIZATION] berhak mengaudit kepatuhan terhadap kebijakan ini kapan saja, dengan atau tanpa pemberitahuan.
6. Tinjauan dan Revisi
Kebijakan ini harus ditinjau setidaknya setiap tahun oleh [CUSTOMIZE: CISO/Pemilik Kebijakan] dan diperbarui seperlunya untuk mencerminkan perubahan dalam lanskap ancaman, persyaratan regulasi, atau struktur organisasi.
Semua revisi harus didokumentasikan dengan nomor versi, tanggal, penulis, dan deskripsi perubahan.
Persetujuan Kebijakan
Disetujui Oleh
Jabatan
Tanggal
Kontrol Dokumen