Apa itu Secure Software Development Life Cycle (SSDLC)?

Pendahuluan

Selain memberikan kenyamanan atau manfaat dari penggunaan aplikasi, pengembang juga harus memastikan bahwa aplikasi yang dibuatnya itu aman. Hal ini dilakukan untuk meningkatkan kepercayaan pengguna dan menghindari kerugian bisnis.

Dalam proses pengembangan aplikasi, biasanya pengembang menggunakan kerangka kerja yang disebut SDLC (Software Development Life Cycle) untuk memastikan pengembangan sesuai dengan kebutuhan bisnis.

Namun, SDLC hanya berfokus pada proses pengembangan tanpa memperhatikan aspek keamanan. Karena keamanan adalah aspek penting dalam pengembangan aplikasi, muncullah istilah Secure-SDLC (SSDLC), di mana tim keamanan membantu pengembang untuk menanamkan praktik keamanan di setiap tahapan SDLC.

Dari informasi ini, dapat diketahui bahwa pemahaman tentang SSDLC ini sangat penting, baik untuk tim keamanan internal (Application Security Engineer / Security Engineer) maupun eksternal (Cyber Security Consultant).

Sebelum membahas SSDLC, kita akan membahas sedikit tentang SDLC terlebih dahulu.

Apa itu SDLC?

SDLC (Software Development Life Cycle) adalah kerangka kerja yang digunakan untuk merancang, mengembangkan, dan memelihara aplikasi. Tujuannya adalah untuk memastikan bahwa aplikasi yang dikembangkan memenuhi kebutuhan bisnis/pengguna dan dikembangkan secara efisien.

Metode SDLC yang umum digunakan adalah:

• Waterfall
• Agile

Tetapi secara keseluruhan setiap metode memiliki tahapan utama berikut:

1. Perencanaan

Sebagai ilustrasi untuk lebih mengetahui SDLC, bayangkan sebuah perusahaan software house mendapatkan proyek untuk membuat aplikasi absensi.

Kliennya adalah perusahaan yang ingin karyawannya bisa absen secara online melalui aplikasi mobile. Aplikasi mobile ini memiliki fitur check-in, check-out, dan rekap laporan bulanan.

Proyek ini pun dimulai mengikuti tahapan SDLC.

Pada tahap Perencanaan, proyek dimulai dengan melakukan kick-off meeting antara tim internal dan klien.

Di sini, tim internal dan klien akan berdiskusi tentang ruang lingkup dan ekspektasi dari proyek yang akan berjalan.

Berikut adalah contoh pertanyaan umum yang ditanyakan kepada klien:

• “Apa ruang lingkup proyek?”
• “Apa ekspektasi dari klien?”
• “Apakah ada deadline dan batasan anggaran?”
• “Apakah ada sistem lain yang akan terintegrasi?”

Setelah itu, tim internal (PM, dev, QA, dan desain) berdiskusi dan menyusun:

• Timeline proyek
• Estimasi biaya
• Struktur tim
• Identifikasi risiko awal

Dokumen dari hasil tahap ini bisa berupa:

• Project Charter, penjelasan resmi proyek yang menjelaskan apa tujuan proyek, siapa yang terlibat, dan apa batasannya.
• High-Level Scope, menjelaskan apa yang akan dan tidak dikerjakan dalam proyek.
• Risk Register (Awal), daftar risiko potensial yang sudah teridentifikasi sejak awal proyek, misalnya risiko keterlambatan akibat integrasi dengan sistem lama yang tidak terdokumentasi dengan baik.
• Rencana Komunikasi dengan Stakeholder, menentukan siapa yang harus dihubungi, kapan, untuk urusan apa, dan lewat media apa.

2. Analisis Kebutuhan

Setelah tahap perencanaan selesai dan ruang lingkup umum disepakati, proyek berlanjut ke tahap Analisis Kebutuhan.

Di tahap ini, fokus utamanya adalah menggali detail kebutuhan secara fungsional maupun non-fungsional dari sisi pengguna.

Tim business analyst akan berdiskusi lebih dalam dengan klien untuk menjawab pertanyaan, seperti:

• “Bagaimana jam kerja dan aturan absensi perusahaan ini?”
• “Apakah perusahaan memiliki sistem shift?”
• “Siapa saja pengguna sistem? Apakah ada perbedaan role (HR, karyawan, manajer)?”
• “Bagaimana format laporan rekap yang diinginkan?”

Semua jawaban ini akan dirangkum menjadi dokumen formal, yang bisa berbeda tergantung budaya kerja tim:

• Product Requirements Document (PRD), berisi gambaran kebutuhan dari sudut pandang pengguna dan bisnis.
• Functional Requirements Document (FRD), berisi uraian teknis fungsi sistem secara rinci (input, output, validasi, aturan logika).
• Request for Comment (RFC), berisi proposal fitur, user journey, arsitektur, dan hal-hal yang masih perlu didiskusikan.

Dokumen ini akan menjadi dasar untuk proses desain di tahap berikutnya.

3. Desain Sistem

Pada tahap Desain Sistem, fokus utama adalah menerjemahkan dokumen kebutuhan (PRD/FRD/RFC) menjadi arsitektur teknis yang dapat diimplementasikan oleh tim pengembang.

Berikut adalah beberapa contoh kontribusi dari beberapa peran:

• Desainer UI/UX mulai membuat mockup dan user flow untuk tampilan aplikasi mobile.
  Misalnya: halaman login, tampilan check-in, riwayat absensi, dan halaman laporan.

• System Architect menyusun arsitektur aplikasi, seperti:

  • Bagaimana frontend berkomunikasi dengan backend
  • Bagaimana API dibangun
  • Penggunaan middleware atau autentikasi

• Database engineer merancang struktur basis data, misalnya:

  • Tabel user, attendance, shift, dan log,
  • Relasi antar tabel dan indeks yang dibutuhkan untuk efisiensi.

Semua hasil desain ini disusun ke dalam dokumen spesifikasi teknis, yang biasanya mencakup:

• System Architecture Diagram
• Database Schema / ERD
• API Specification (endpoint, input/output, status code)
• UI Wireframe atau Mockup

Dokumen ini akan menjadi pedoman utama bagi tim pengembang di tahap implementasi berikutnya.

4. Implementasi

Pada tahap ini, tim pengembang mulai menulis kode program sesuai spesifikasi teknis yang telah disusun sebelumnya.

Berikut adalah contoh aktivitas yang dilakukan:

• Frontend Developer membuat tampilan aplikasi mobile sesuai dengan mockup yang telah dibuat.

• Backend Developer membuat sistem aplikasi di sisi server, seperti: autentikasi, API, dan penyimpanan data absensi.

5. Pengujian

Setelah aplikasi berhasil dibuat, proyek memasuki tahap Pengujian.

Di tahap ini, tim Quality Assurance (QA) bertugas untuk memastikan bahwa semua fitur berjalan sesuai dengan kebutuhan yang telah disepakati.

QA biasanya melakukan pengujian berdasarkan skenario, contohnya:

• Fungsional:
  “Apakah pengguna hanya bisa check-in dalam jam kerja yang valid?"
  "Apakah tombol check-out aktif setelah check-in berhasil?”

• Logika absensi:
  “Apakah waktu absen tercatat dengan benar di laporan?"
  "Apakah pengguna dapat login di perangkat lain (multi-device?)”

• Kondisi ekstrem:
  “Apa yang terjadi jika koneksi internet lambat atau putus?”

Berikut adalah contoh bug yang ditemukan oleh QA:

• Tombol check-out muncul sebelum waktunya
• Laporan tidak terurut secara kronologis
• Crash saat pengguna absen dua kali berturut-turut

Semua temuan ini dicatat dan dikembalikan ke tim pengembang untuk diperbaiki, lalu diuji kembali oleh QA hingga aplikasi dianggap stabil dan siap untuk dirilis.

6. Penerapan dan Pemeliharaan

Pada tahap ini, aplikasi dipindahkan dari lingkungan pengujian ke lingkungan production, dan mulai digunakan oleh karyawan klien.

Tim infrastruktur atau DevOps biasanya akan:

• Menyiapkan server production,
• Melakukan konfigurasi domain, sertifikat SSL, dan basis data,
• Melakukan build dan release aplikasi ke store.

Setelah rilis, aplikasi tetap memerlukan pemeliharaan, seperti:

• Pembaruan fitur,
• Perbaikan bug,
• Pemantauan sistem,
• Dan lain-lain.

Proses ini sering dikaitkan dengan model CI/CD, yang memungkinkan pembaruan dilakukan secara lebih cepat dan otomatis.

Itu lah gambaran umum tentang proses SDLC yang akan menjadi bekal pembahasan materi SSDLC.

Apa itu Secure-SDLC?

Setelah mempelajari konsep SDLC, kita tahu bahwa konsep tersebut hanya fokus pada pengembangan dan pengujian fungsi aplikasi, tanpa secara eksplisit memperhatikan aspek keamanan.

Padahal, seperti yang kita tahu bahwa keamanan adalah aspek penting yang harus dimiliki oleh aplikasi.

Inilah alasan munculnya konsep Secure Software Development Life Cycle (SSDLC).

Secure Software Development Life Cycle (SSDLC) adalah konsep di mana tim keamanan membantu tim pengembang untuk menanamkan aspek keamanan pada setiap tahap SDLC.

Dengan adanya SSDLC, keamanan bukan lagi menjadi sesuatu yang dipikirkan belakangan, melainkan menjadi bagian terencana sejak awal proses pengembangan.

Penerapan SSDLC tidak hanya meningkatkan keamanan aplikasi, tetapi membantu perusahaan untuk memenuhi standar keamanan seperti ISO 27001:2022 dan juga regulasi keamanan seperti SEOJK 21 MRTI.

Berikut adalah tahapan umum pada SSDLC:

1. Perencanaan

Pada tahap ini, tim keamanan belum melakukan aktivitas apa pun. Tim hanya menunggu rencana proyek masuk dan menyiapkan keterlibatan pada tahap berikutnya.

2. Analisis Kebutuhan

Pada tahap ini, tim keamanan mulai terlibat untuk memastikan bahwa aspek keamanan sudah dipikirkan sejak awal.

Saat tim business analyst merumuskan kebutuhan pengguna, tim keamanan membantu dengan mengajukan pertanyaan, seperti:

• “Apakah data absensi tergolong sebagai data pribadi?”
• “Siapa yang boleh mengakses data laporan?”
• “Aksi seperti absensi dan login perlu dicatat dalam audit log, bagaimana kebijakan perusahaan terkait pelacakan aktivitas ini?”
• “Apakah aplikasi perlu mematuhi standar atau regulasi keamanan tertentu (misalnya GDPR, PCI-DSS, BI, OJK, atau lainnya)”

Dari diskusi ini, tim keamanan menyusun kebutuhan keamanan dasar, misalnya:

• Wajib login untuk akses fitur utama
• Data absensi harus disimpan terenkripsi
• Aksi absensi harus dicatat di audit log
• Persyaratan keamanan disesuaikan jika proyek tunduk pada standar atau regulasi tertentu

Semua poin ini dimasukkan ke dalam dokumen PRD/FRD/RFC.

3. Desain Sistem

Pada tahap ini, tim internal mulai menyusun desain arsitektur aplikasi. Di sini, tim keamanan akan membantu memeriksa desain dengan cara:

• Threat Modelling:
  Mengidentifikasi potensi ancaman terhadap proses bisnis, seperti:

  • Apakah laporan kehadiran bisa dimanipulasi oleh pengguna?
  • Apakah seorang pengguna dapat melakukan kehadiran atas nama pengguna lain?

• Security Design Review:
  Melakukan pemeriksaan terhadap komponen desain teknis, seperti:

  • Arsitektur komunikasi frontend dan backend
  • Mekanisme autentikasi dan sesi
  • Desain API dan parameter sensitif
  • Perlindungan data pada saat transit dan saat disimpan

Dari hasil pemeriksaan ini, tim keamanan akan memberikan rekomendasi jika ditemukan potensi celah keamanan, sehingga desain bisa disempurnakan sebelum ke tahap implementasi.

4. Implementasi

Selanjutnya, tim pengembang akan mulai melakukan coding aplikasi sesuai desain dan spesifikasi yang telah disepakati.

Pada tahap ini, tim keamanan akan melakukan beberapa aktivitas, seperti:

• Secure Code Guideline:
  Tim keamanan menyediakan panduan coding yang aman yang harus diikuti oleh pengembang. Ini mencakup hal-hal seperti:

  • Validasi input pengguna
  • Menghindari hardcode kredensial
  • Menggunakan versi library yang aman
  • Menangani error dan log dengan benar

• SAST (Static Application Security Testing):
  Menganalisis source code untuk mendeteksi kerentanan (seperti XSS, SQLi).
  Contoh tools yang digunakan:

  • Semgrep
  • SonarQube
  • Fortify
  • Checkmarx
  • MobSF

• Secret Scanning:
  Mendeteksi API key, password, atau token yang tidak sengaja ditulis ke dalam repositori.
  Contoh tools yang digunakan:

  • GitGuardian
  • TruffleHog
  • Gitleaks

• SCA (Software Composition Analysis):
  Mengecek library open source yang digunakan: apakah ada versi yang rentan.
  Contoh tools yang digunakan:

  • Snyk
  • OWASP Dependency Check
  • Mend (WhiteSource)

• Container / IaC Security:
  Jika menggunakan Docker/Terraform, dilakukan juga analisis terhadap konfigurasi dan image base.
  Contoh tools yang digunakan:

  • Trivy
  • Dockle
  • Checkov
  • tfsec

Celah keamanan yang ditemukan dan telah divalidasi akan diperbaiki oleh tim pengembang.

5. Pengujian

Pada tahap ini tim keamanan akan melakukan pengujian setelah aplikasi lulus dari pengujian tim QA. Pengujian yang tim keamanan lakukan adalah:

• DAST (Dynamic Application Security Testing):
  Melakukan pengujian aplikasi secara dinamis untuk mendeteksi kerentanan (seperti XSS, SQLi). Contoh tools yang digunakan:

  • MobSF
  • Burp Suite
  • OWASP ZAP

• Penetration Testing: Melakukan pengujian manual dan menyeluruh untuk menemukan serta memvalidasi celah keamanan yang tidak terdeteksi oleh DAST.

6. Penerapan & Pemeliharaan

Setelah lolos validasi internal, tahap berikutnya adalah merilis aplikasi ke lingkungan production. Tim keamanan akan tetap terlibat untuk memastikan aplikasi tetap aman selama operasional.

Aktivitasnya yang dilakukan antara lain:

• Monitoring Keamanan:
  Memantau kerentanan baru dari dependency atau komponen pihak ketiga menggunakan scanner otomatis dan advisory feeds.

• Implementasi WAF:
  Menggunakan WAF untuk mengidentifikasi serangan real-time terhadap aplikasi di lingkungan production.

• Bug Bounty & VDP (Vulnerability Disclosure Program):
  Mengelola laporan dari peneliti keamanan eksternal melalui program bug bounty publik atau privat serta jalur VDP resmi.

• Patch & Incident Response:
  Menangani insiden keamanan, merespons laporan, serta menerapkan patch dengan cepat jika ditemukan kerentanan.

• Security Regression Testing:
  Pengujian keamanan ulang saat ada perubahan besar (fitur baru, refactor, dsb) untuk mencegah kebocoran keamanan lama muncul kembali.

Manfaat Secure-SDLC

Dari penjelasan di atas, kita tahu bahwa Secure-SDLC memberikan manfaat, seperti:

• Mengurangi biaya untuk memperbaiki kerentanan dengan mengidentifikasinya lebih awal.
• Membantu memastikan kepatuhan terhadap satu regulasi atau standar keamanan.
• Membangun security awareness pada tim internal.
• Meningkatkan kepercayaan pengguna dan mengurangi risiko pelanggaran.

Penutup

Itulah seluruh tahapan dan manfaat dari Secure-SDLC. Dengan menerapkan konsep ini, kita memastikan bahwa aplikasi tidak hanya berfungsi dengan baik, tetapi juga memiliki keamanan yang memumpuni.