Apa itu siklus hidup pengembangan perangkat lunak yang aman?

Pengembangan perangkat lunak pada umumnya mengikuti jalur linier: rencanakan, kodekan, uji, terapkan. Selama beberapa dekade, keamanan hanya dipertimbangkan selama fase pengujian—setelah penulisan ribuan baris kode.

SSDLC menantang pendekatan tradisional ini dengan menanamkan keamanan ke semua fase siklus hidup pengembangan perangkat lunak (SDLC) sejak awal. SSDLC sering disusun menjadi sembilan fase: persyaratan, analisis, perencanaan, desain, pengembangan, dokumentasi, pengujian, penerapan, dan pemeliharaan.

Tim memulai dengan membahas masalah keamanan di samping persyaratan fungsional, sementara pengembang menulis kode aman dengan menggunakan input yang divalidasi dan standar autentikasi. Pengujian berjalan terus-menerus, tidak hanya sebelum rilis, sering kali melalui peninjauan kode otomatis.

Pendekatan"shift left" ini—memindahkan keamanan lebih awal dalam proses pengembangan—dapat membantu mengubah cara organisasi membangun perangkat lunak. Alih-alih bertanya "Apakah ini aman?" selama pengujian, tim bertanya "Bagaimana kita membuatnya aman?" sebelum menulis baris kode pertama.

Misalnya, pertimbangkan aplikasi perbankan. Pengembangan tradisional mungkin menemukan kerentanan injeksi SQL selama pengujian prapeluncuran yang mengharuskan pengembang untuk menulis ulang interaksi basis data di ratusan file. Dengan SSDLC, tim jauh lebih mungkin untuk mendeteksi kerentanan itu lebih awal karena pemeriksaan keamanan berjalan di seluruh desain, pembuatan, dan pengujian.

Data terbaru membantu menunjukkan mengapa pendekatan proaktif ini penting. Menurut sebuah studi keamanan rantai pasokan baru-baru ini, serangan rantai pasokan perangkat lunak meningkat 1.300% hanya dalam tiga tahun.¹

SSDLC dapat membantu melindungi organisasi dari serangan siber ini dan lainnya dengan mendeteksi kerentanan lebih awal—ketika perbaikan paling sederhana dan paling murah. Hal ini juga dapat membantu menjaga kepatuhan terhadap peraturan seperti Peraturan Perlindungan Data Umum (GDPR) dan Undang-Undang Portabilitas dan Akuntabilitas Asuransi Kesehatan (HIPAA).

Umumnya ada sembilan fase SSDLC yang sangat menyerupai model SDLC, kecuali bahwa setiap fase juga menggabungkan pertimbangan keamanan:

• Persyaratan
• Analisis
• Perencanaan
• Desain
• Pengembangan
• Dokumentasi
• Pengujian
• Deployment
• Pemeliharaan

Tim mendiskusikan kemampuan perangkat lunak yang sudah selesai, menentukan persyaratan keamanan bersama persyaratan fungsional sejak awal—misalnya, menerapkan enkripsi untuk bidang data sensitif dan menetapkan kontrol akses berbasis peran (RBAC). Diskusi ini melibatkan peninjauan potensi risiko keamanan serta persyaratan kepatuhan seperti standar perlindungan data GDPR.

Organisasi mengukur potensi kerentanan dan memetakan lingkungan ancaman mereka, merencanakan skenario terburuk ketimbang membuat asumsi kasus terbaik. Misalnya, aplikasi perawatan kesehatan dapat menganalisis risiko pelanggaran data pasien, serangan ransomware, dan ancaman orang dalam— merencanakan respons untuk tiap peristiwa.

Tim keamanan dan pemangku kepentingan menetapkan peran, mengalokasikan sumber daya, dan menentukan patokan yang dapat diterima berdasarkan dampak bisnis potensial. Perencanaan ini memungkinkan pemrioritasan kerentanan berisiko tinggi sambil tetap memenuhi tenggat waktu pengembangan. Hal ini juga memungkinkan mereka untuk menganggarkan alat keamanan dan pelatihan sebelum pengodean dimulai.

Fase desain melibatkan pemodelan ancaman— analisis sistematis pada potensi kerentanan keamanan dalam arsitektur yang direncanakan. Praktik ini membantu memastikan bahwa desain yang aman dibangun ke dalam cetak biru sistem—dari platform terbaik hingga UI ideal—alih-alih ditambahkan sebagai retrofit yang mahal.

Pengembang menerapkan praktik pengodean aman berdasarkan standar pengodean aman yang ditetapkan oleh organisasi seperti Proyek Keamanan Aplikasi Web Terbuka (OWASP). Standar ini dapat mencakup validasi semua input, menerapkan teknik autentikasi, menggunakan panggilan API yang tepat, memindai repositori, dan menangani kesalahan dengan aman.

Para pengembang sering kali menggunakan lingkungan pengembangan terpadu (IDE) dengan plug-in keamanan untuk membantu menangkap masalah lebih awal.

Tim mengevaluasi dependensi perangkat lunak untuk mengurangi risiko keamanan, dengan pengujian keamanan dimulai selama pengembangan. Misalnya, modul pemrosesan pembayaran akan menjalani pengujian keamanan saat dibangun, bukan setelah integrasi. 

Tim mendokumentasikan kontrol dan proses keamanan untuk audit, pemeriksaan kepatuhan, dan peninjauan keamanan, sehingga memungkinkan respons insiden yang cepat dan kepatuhan terhadap peraturan yang berkelanjutan.

Pengujian menggabungkan peninjauan kode dengan pengujian keamanan. Tim memvalidasi fungsionalitas dan keamanan sebelum penerapan.

Pengujian mencakup analisis statis—seperti pengujian keamanan aplikasi statis (SAST)—untuk menganalisis kode sumber tanpa menjalankan program, dan pengujian keamanan aplikasi dinamis (DAST) untuk menguji aplikasi saat berjalan.

Pengujian lanjutan dapat mencakup peretas etis yang menantang kode, uji penetrasi yang memvalidasi keamanan data, dan simulasi yang menggunakan API. Analisis komposisi perangkat lunak (SCA) juga dapat dijalankan secara paralel untuk membantu mengidentifikasi ketergantungan sumber terbuka yang rentan dan masalah lisensi.

Tim mengamankan lingkungan penerapan—server, konfigurasi, dan middleware—sebelum merilis perangkat lunak. Hal ini membantu mencegah munculnya kerentanan akibat konfigurasi infrastruktur yang salah.

Banyak tim juga mengumpulkan telemetri perangkat lunak—metrik, log, dan jejak—untuk melihat bagaimana kode berperilaku di lingkungan nyata. OpenTelemetry (OTel) adalah proyek sumber terbuka dari Cloud Native Computing Foundation (CNCF) yang memungkinkan pengumpulan dan pengiriman metrik, log, dan jejak yang netral vendor, membantu memastikan sinyal yang konsisten di seluruh layanan, saluran, dan lingkungan.

Pemantauan berkelanjutan dapat membantu mendeteksi ancaman dan kerentanan lebih awal, memungkinkan remediasi cepat sepanjang siklus hidup perangkat lunak. Fase ini bisa sangat penting untuk mencegah eksploitasi zero-day dan menanggapi kerentanan yang baru ditemukan.

Organisasi biasanya memulai siklus pengembangan perangkat lunak yang aman dengan kerangka kerja yang telah ditetapkan: metodologi komprehensif yang mencakup tolok ukur keamanan, praktik terbaik keamanan, dan alat penilaian risiko. Beberapa kerangka kerja yang paling umum meliputi:

Institut Standar dan Teknologi Nasional menyediakan praktik dan tolok ukur yang didukung pemerintah khusus pengembangan aman, termasuk Kerangka Kerja Pengembangan Perangkat Lunak Aman, NIST SP 800-218.

Kerangka kerja ini membantu organisasi menetapkan persyaratan keamanan dasar di semua tim pengembangan. Dibandingkan dengan kerangka kerja lain, ini memberikan standar federal yang lebih preskriptif, sering membuatnya ideal untuk kontraktor pemerintah dan industri yang diatur. Organisasi yang bekerja dengan lembaga federal sering harus mematuhi standar NIST sebagai persyaratan kontrak.

Proyek Keamanan Aplikasi Web Terbuka (OWASP) menawarkan kerangka kerja terbuka: Model Kematangan Jaminan Perangkat Lunak (SAMM).

SAMM OWASP membantu organisasi menilai praktik keamanan perangkat lunak yang ada dan membangun program peningkatan berulang yang disesuaikan dengan profil risiko spesifik mereka. 

Oleh karena itu, pendekatan ini sering kali lebih disukai oleh organisasi yang mencari pendekatan fleksibel berbasis kematangan daripada persyaratan kepatuhan yang kaku. Sebagai contoh, sebuah perusahaan rintisan bisa memulai dengan praktik keamanan dasar di area penting seperti autentikasi, kemudian secara bertahap memperluas ke pengujian keamanan komprehensif seiring dengan bertambahnya tim dan anggaran.

Pedoman DevSecOps OWASP memerinci implementasi saluran dengan alat pengujian keamanan terintegrasi: SAST, DAST, SCA (analisis komposisi perangkat lunak), dan IAST (pengujian keamanan aplikasi interaktif). Mengikuti pedoman ini dapat membantu mempermudah penanaman pengujian keamanan ke dalam saluran continuous integration and continuous delivery (CI/CD) yang ada tanpa mengganggu alur kerja pengembangan.

Akibatnya, organisasi yang ingin mengotomatiskan keamanan tanpa memperlambat siklus rilis mungkin lebih menyukai Pedoman DevSecOps OWASP—seperti perusahaan fintech yang menerapkan pembaruan setiap hari sambil mempertahankan kepatuhan PCI DSS.

Banyak organisasi menerapkan SSDLC melalui praktik DevOps dan DevSecOps, yang mengotomatiskan pengujian keamanan dan mengintegrasikannya ke dalam saluran CI/CD—mempercepat pengembangan sekaligus mempertahankan standar keamanan. Menggunakan teknik DevSecOps, tim pengembangan bertanggung jawab atas keamanan aplikasi selain desain, pembangunan, operasi, dan pemeliharaan yang aman. Untuk mengulang dengan cepat dan menghindari kemacetan, mereka sering kali menggunakan otomatisasi untuk pengujian keamanan.

SLSA ('salsa') adalah kerangka kerja komunitas—awalnya diusulkan oleh Google dan sekarang berada di bawah OpenSSF—untuk melindungi rantai pasokan perangkat lunak. 

Pedomannya membantu organisasi mencegah gangguan, memverifikasi integritas artefak, dan mengotomatiskan verifikasi proses pembuatan dan dependensi. Organisasi yang ingin mengoptimalkan keamanan rantai pasokan dan membangun riwayat mungkin menerapkan SLSA untuk membuktikan perangkat lunak mereka tidak dirusak selama proses pembuatan. Misalnya, vendor perangkat lunak yang mendistribusikan aplikasi perusahaan perlu membuktikan kepada pelanggan bahwa rilis mereka autentik dan tidak dirusak.

SSDLC dapat memberikan beberapa manfaat penting bagi organisasi. 

Pendekatan “shift left” pada SSDLC membantu organisasi mendeteksi dan memperbaiki kerentanan ketika kerentanan sering kali paling mudah dan paling murah untuk diatasi: selama desain dan pengembangan, bukan setelah penerapan.

Misalnya, peninjauan pada fase desain mungkin menemukan bahwa arsitektur yang direncanakan akan mengekspos data pelanggan yang sensitif melalui titik akhir API yang tidak aman. Mendeteksi masalah ini lebih awal memungkinkan arsitektur yang lebih aman sejak awal, menghindari potensi kerusakan akibat pelanggaran data dan retrofit kontrol keamanan yang mahal.

Organisasi juga dapat mengalami pengurangan biaya ketika terjadi pelanggaran keamanan. Menurut Laporan Biaya Pelanggaran Data, pendekatan DevSecOps (termasuk SSDLC) adalah faktor nomor satu dalam mengurangi biaya pelanggaran data. Organisasi yang menggunakan pendekatan ini membayar biaya USD 227.192 lebih rendah per pelanggaran data.

SSDLC dapat membantu mencegah waktu henti sistem dengan mengidentifikasi masalah keamanan sebelum penerapan, berpotensi menghindari perbaikan darurat dan meningkatkan stabilitas perangkat lunak. Pemodelan ancaman dan peninjauan kode terperinci di semua tahap juga dapat meningkatkan stabilitas ini.

SSDLC membantu melindungi rantai pasokan perangkat lunak, yang mencakup semua infrastruktur dan orang yang mengerjakan kode dari pengembangan melalui saluran CI/CD hingga penerapan. Sistem ini menggabungkan praktik manajemen risiko (seperti pemodelan ancaman dan pemindaian dependensi) dengan kontrol keamanan siber (seperti pembatasan akses dan penandatanganan kode) untuk mencegah kerentanan di seluruh siklus hidup.

Misalnya, SSDLC dapat membantu organisasi mengimplementasikan software bills of material (SBOM) untuk melacak semua komponen dan dependensi. Pendekatan ini lebih memudahkan identifikasi dan memperbaiki kerentanan saat ditemukan di pustaka pihak ketiga.

SSDLC membantu organisasi mempertahankan kepatuhan dengan membangun kontrol keamanan dan dokumentasi ke dalam setiap fase pengembangan. Proses ini sangat penting bagi organisasi yang perlu secara konsisten memenuhi standar keamanan khusus industri seperti Peraturan Perlindungan Data Umum (GDPR), Undang-Undang Portabilitas dan Akuntabilitas Asuransi Kesehatan (HIPAA), dan California Consumer Privacy Act (CCPA). Kepatuhan yang lebih andal dapat membantu memastikan lebih sedikit masalah hukum dan potensi denda. 

Saat menerapkan SSDLC, tim pengembangan, operasi, dan keamanan harus sering bekerja sama dengan erat untuk memunculkan berbagai sudut pandang dalam pengembangan perangkat lunak. Kolaborasi yang diperlukan ini dapat membantu memecah silo antara departemen dan mencegah masalah keamanan yang mungkin menjadi mahal nantinya.

Meskipun banyak manfaatnya, beberapa tantangan dapat muncul ketika organisasi beralih untuk mengadopsi SSDLC. 

Pemangku kepentingan yang menginginkan waktu penyiapan produk yang lebih cepat sering dapat memandang persyaratan keamanan sebagai hambatan pada kecepatan pengembangan. Mereka bahkan mungkin meminta untuk menunda pengujian keamanan hingga fase selanjutnya. 

Meskipun pendekatan ini dapat mempercepat pengembangan awal, ini sering menyebabkan penundaan yang lebih mahal ketika kerentanan muncul setelah penerapan.

Melewatkan pemodelan ancaman selama desain, misalnya, dapat membuat jalur serangan penting terbuka. Tanpa analisis ancaman yang sistematis, tim mungkin kehilangan celah keamanan dalam sistem otorisasi, kontrol akses data, atau integrasi layanan pihak ketiga—kerentanan yang dengan cepat menjadi semakin mahal untuk diperbaiki dalam produksi.

Karena lingkungan ancaman terus berkembang, tim pengembangan harus mempertahankan pengetahuan keamanan terkini. Organisasi tanpa keahlian keamanan khusus mungkin memerlukan lebih banyak pelatihan, staf khusus, atau konsultan eksternal untuk menerapkan SSDLC secara efektif.

Sebagai contoh, pengembang yang baru mengenal pengodean aman mungkin tidak tahu kapan harus menggunakan alat analisis statis atau bagaimana menginterpretasikan temuan mereka. Tanpa pelatihan yang tepat, alat ini mungkin menandai kerentanan penting yang tidak ditangani, atau menghasilkan positif palsu yang membuang waktu pengembangan. Bahkan pengembang yang berpengalaman pun sering kali membutuhkan pendidikan berkelanjutan untuk tetap mengikuti perkembangan ancaman dan praktik keamanan yang muncul.

Arsitektur perangkat lunak yang kompleks dengan beberapa integrasi terkadang memerlukan alat dan proses keamanan yang canggih, berpotensi meningkatkan waktu dan biaya pengembangan. Misalnya, mengintegrasikan perangkat IoT yang menggunakan format data dan protokol komunikasi yang berbeda dapat menciptakan permukaan serangan lain yang harus diamankan oleh tim.

Pertimbangkan implementasi API enkripsi, di mana API harus beroperasi dengan hak akses minimal sekaligus mendukung berbagai contoh penggunaan. Beberapa layanan mungkin memerlukan kemampuan enkripsi tanpa hak dekripsi. Proses ini dapat memerlukan perencanaan yang cermat seputar kontrol akses, autentikasi, dan keamanan lapisan transportasi (TLS), menambah kompleksitas di sekitar setiap titik integrasi yang harus ditangani tim tanpa mengorbankan keamanan atau fungsionalitas.