Proyek software dikerjakan banyak orang dengan keahlian berbeda. Deck menyebut delapan peran:

Perhatikan bahwa developer juga bertugas menguji unit, bukan hanya menulis kode. Dan stakeholder bukan penonton: mereka memberi kebutuhan, masukan, dan persetujuan di sepanjang proyek.

Satu Orang, Banyak Peran

Di tim kecil, satu orang bisa memegang beberapa peran sekaligus. Pada aplikasi kas kelas dengan tim tiga orang, pembagiannya mungkin seperti ini:

• Rina: Project Manager sekaligus Business Analyst. Ia yang mewawancarai bendahara dan menjaga jadwal.
• Bima: System Architect sekaligus Developer. Ia merancang tabel dan menulis sebagian besar kode.
• Sari: UI/UX Designer sekaligus QA. Ia membuat wireframe dan menyusun test case.
• Bendahara kelas: Stakeholder dan pengguna utama.

Yang penting bukan jumlah orangnya, tetapi setiap tanggung jawab punya pemilik yang jelas.

Setiap tahap menghasilkan dokumen. Berikut peta lengkapnya:

Kamu tidak perlu menghafal tabel ini kata per kata. Cara mudahnya, tanyakan "tahap ini menghasilkan apa?" Perencanaan menghasilkan rencana, analisis menghasilkan daftar kebutuhan, desain menghasilkan rancangan, implementasi menghasilkan kode, pengujian menghasilkan hasil tes, penerapan menghasilkan panduan rilis, dan pemeliharaan menghasilkan catatan perubahan serta insiden.

Traceability

Dokumen membuat pengetahuan proyek terlacak (traceability): dari kebutuhan, ke desain, ke kode, ke test case. Artinya setiap kebutuhan bisa ditelusuri sampai ke kode yang mewujudkannya dan tes yang membuktikannya.

Contoh pada kas kelas:

const jejak = {
  kebutuhan: "F-03: Wali kelas dapat mencetak laporan bulanan",
  desain: "SDD bagian 4.2: modul laporan",
  kode: "laporan.js: fungsi buatLaporanBulanan",
  testCase: ["TC-11: laporan berisi semua iuran bulan itu", "TC-12: total sama dengan saldo"],
};

const terlacak = jejak.testCase.length > 0;
console.log(terlacak); // true

Kalau suatu saat ada kebutuhan yang tidak punya test case, kamu langsung tahu ada celah. Kalau ada kode yang tidak terhubung ke kebutuhan mana pun, kamu bisa bertanya apakah kode itu memang diperlukan.

Banyak tim menganggap keamanan cukup diuji di akhir, sesaat sebelum rilis. Masalahnya, celah keamanan yang ditemukan di akhir sama mahalnya dengan cacat lain yang ditemukan terlambat. Bahkan bisa lebih mahal kalau celahnya sudah dieksploitasi.

Secure SDLC memakai prinsip shift-left: aktivitas keamanan disisipkan ke setiap tahap, bukan hanya diuji di akhir. Disebut "shift-left" karena kalau tahapan SDLC digambar dari kiri ke kanan, aktivitas keamanan digeser ke kiri, ke tahap yang lebih awal.

Aktivitas Keamanan per Tahap

Beberapa istilah yang perlu kamu pahami:

• Abuse case: kebalikan dari use case. Kalau use case menjelaskan cara pengguna memakai sistem dengan benar, abuse case menjelaskan cara orang jahat menyalahgunakannya. Contoh: "Siswa mencoba mengubah catatan iurannya sendiri menjadi lunas."
• Threat modeling: memetakan ancaman terhadap desain sebelum dibangun.
• SAST: analisis kode sumber untuk mencari celah, tanpa menjalankan program.
• DAST: pengujian keamanan terhadap aplikasi yang sedang berjalan.
• Hardening: memperketat konfigurasi server dan aplikasi.
• Manajemen secret: menyimpan kata sandi dan kunci rahasia dengan aman, bukan ditulis langsung di kode.

Untuk kas kelas, abuse case tadi langsung menghasilkan kebutuhan keamanan: hanya bendahara yang boleh mengubah data iuran. Kebutuhan ini lalu diuji di tahap pengujian.

Rujukan dan Regulasi

Rujukan Secure SDLC yang disebut di deck: NIST SSDF (SP 800-218), OWASP SAMM, OWASP Top 10, dan ISO/IEC 27001. Di Indonesia, perlindungan data pribadi diatur oleh UU No. 27 Tahun 2022 (UU PDP), sehingga kepatuhan terhadapnya masuk ke kebutuhan sejak perencanaan.

DevSecOps

DevSecOps adalah DevOps ditambah keamanan yang terotomatisasi di pipeline. Misalnya setiap kali kode digabung, pipeline otomatis menjalankan SAST dan scan dependensi. Kalau ditemukan celah serius, pipeline berhenti, sama seperti saat tes biasa gagal.

• Menganggap keamanan urusan tahap pengujian saja. Prinsip shift-left menyisipkannya ke semua tahap.
• Menulis kata sandi atau kunci API langsung di kode. Ini yang dicegah oleh manajemen secret.
• Membiarkan peran tanpa pemilik di tim kecil. Kalau tidak ada yang memegang peran QA, pengujian sering terlewat.
• Menulis dokumen yang tidak saling terhubung. Tanpa traceability, sulit tahu kebutuhan mana yang sudah diuji.