Bagian
Seri: Referensi Cybersecurity 2025–2026
Topik: OWASP & Keamanan Aplikasi
Artikel: 4 dari 7
Ketika organisasi memutuskan untuk serius dalam keamanan aplikasi, salah satu kebingungan pertama yang muncul adalah: "Ada begitu banyak standar dan kerangka OWASP — mana yang harus kami gunakan?"
Jawabannya bukan memilih salah satu dan mengabaikan yang lain. Setiap kerangka OWASP dirancang untuk tujuan berbeda, audiens berbeda, dan fase berbeda dalam perjalanan keamanan sebuah organisasi. Memahami perbedaan ini adalah langkah pertama dalam membangun program keamanan aplikasi yang terstruktur dan efisien.
Artikel ini membahas empat kerangka OWASP utama — Top 10, ASVS, WSTG, dan SAMM — dan bagaimana memilih kombinasi yang tepat berdasarkan kematangan organisasi, konteks regulasi, dan tujuan strategis.
Analogi sederhana: jika keamanan aplikasi adalah sebuah bangunan, Top 10 adalah daftar sepuluh kelemahan struktural paling umum yang harus dihindari, ASVS adalah kode bangunan lengkap yang harus dipenuhi, WSTG adalah panduan inspeksi teknis untuk menemukan masalah, dan SAMM adalah metodologi untuk menilai dan meningkatkan kapabilitas tim arsitek dan kontraktornya.
OWASP Top 10 adalah daftar sepuluh kategori risiko keamanan aplikasi web yang paling kritis, diperbarui setiap empat tahun. Edisi terbaru adalah OWASP Top 10:2025, dirilis November 2025.
Aksesibilitas
Dapat dipahami oleh non-teknis sekalipun. CEO dan CFO dapat membaca Top 10 dan memahami implikasi bisnisnya tanpa perlu latar belakang keamanan.
Kesederhanaan yang disengaja
Kategorisasinya sengaja dibuat luas dan tingkat tinggi. Ini bukan kelemahan — ini fitur. Tujuannya adalah kesadaran dan diskusi, bukan checklist teknis.
Pengakuan global
Direferensikan oleh hampir semua standar keamanan (PCI-DSS, ISO 27001, NIST), regulasi (GDPR, UU PDP, POJK), dan kontrak pengadaan.
Baseline yang defensible
Menjadi standar minimum yang dapat dipertahankan di hadapan auditor, regulator, dan dewan direksi.
Top 10 bukan checklist pengujian — ia tidak menjelaskan bagaimana menguji atau seberapa dalam sebuah kontrol harus diimplementasikan. Ia tidak menjawab pertanyaan seperti: "Seberapa kuat autentikasi yang harus kami terapkan untuk aplikasi perbankan kami?"
Top 10 juga tidak cukup sebagai standar pengembangan — tidak cukup granular untuk dijadikan panduan bagi tim pengembang dalam menulis kode yang aman.
Sebagai komunikasi risiko kepada manajemen dan dewan direksi
Sebagai baseline penilaian vendor dalam proses procurement
Sebagai referensi awal dalam kebijakan keamanan aplikasi
Sebagai kriteria minimum dalam kontrak pengembangan software
Sebagai tolok ukur audit awal
ASVS (Application Security Verification Standard) adalah kerangka komprehensif yang mendefinisikan persyaratan keamanan fungsional dan non-fungsional untuk aplikasi web. Versi terkini adalah ASVS 4.0, dengan versi 5.0 dalam pengembangan aktif oleh komunitas.
ASVS mencakup lebih dari 280 persyaratan keamanan yang diorganisasi dalam 14 area kontrol, mulai dari arsitektur dan desain, autentikasi, manajemen sesi, akses kontrol, validasi input, kriptografi, penanganan error, perlindungan data, komunikasi, kode berbahaya, konfigurasi HTTP, file dan resource, API, dan konfigurasi.
ASVS menggunakan sistem tiga level yang memungkinkan organisasi memilih kedalaman kontrol berdasarkan profil risiko aplikasi mereka:
Level 1 — Oportunistik Kontrol dasar yang dapat diverifikasi secara otomatis menggunakan tools DAST (Dynamic Application Security Testing). Cocok untuk aplikasi dengan risiko bisnis rendah-menengah. Ini adalah level minimum yang seharusnya dipenuhi oleh semua aplikasi yang menghadap publik.
Contoh persyaratan Level 1: Semua halaman login harus menggunakan HTTPS. Sesi harus berakhir setelah periode tidak aktif yang ditentukan. Cookie sensitif harus memiliki flag HttpOnly dan Secure.
Level 2 — Standar Kontrol komprehensif yang membutuhkan kombinasi pengujian otomatis dan manual. Cocok untuk sebagian besar aplikasi bisnis, termasuk yang memproses data sensitif, transaksi keuangan, atau informasi kesehatan.
Contoh persyaratan Level 2: Mekanisme autentikasi harus tahan terhadap credential stuffing. Semua input pengguna harus divalidasi dan di-sanitize sebelum diproses. Log keamanan harus mencakup waktu, sumber, dan detail kejadian yang cukup untuk forensik.
Level 3 — Lanjutan Kontrol tertinggi untuk aplikasi kritis yang membutuhkan tingkat jaminan keamanan tertinggi. Membutuhkan pengujian penetrasi mendalam dan review arsitektur komprehensif.
Contoh persyaratan Level 3: Analisis ancaman formal harus dilakukan selama fase desain. Semua komponen kriptografi harus menggunakan implementasi yang telah divalidasi dan bukan implementasi kustom. Aplikasi harus mampu mendeteksi dan merespons serangan secara aktif.
ASVS dan Top 10 saling melengkapi secara langsung. Setiap kategori dalam Top 10 terhubung ke satu atau lebih area dalam ASVS. Jika Top 10 menyatakan "Broken Access Control adalah risiko #1", ASVS menjelaskan secara detail persyaratan apa saja yang harus dipenuhi agar kontrol akses dianggap memadai — dengan tingkat kedalaman yang berbeda untuk setiap level.
ASVS mulai digunakan sebagai referensi dalam:
Audit keamanan aplikasi perbankan
Didorong ketentuan OJK tentang pengujian keamanan sistem
Pengadaan software pemerintah
Terutama untuk sistem yang menangani data sensitif warga
Sertifikasi aplikasi fintech
Sebagai persyaratan tidak formal dari beberapa mitra perbankan
Saat menyusun persyaratan keamanan untuk pengembangan aplikasi baru
Saat melakukan audit keamanan aplikasi yang lebih dari sekadar compliance check
Saat mendefinisikan kriteria penerimaan (acceptance criteria) keamanan dalam kontrak pengembangan
Saat membangun program bug bounty yang membutuhkan scope yang terdefinisi
Saat menyiapkan aplikasi untuk sertifikasi atau due diligence keamanan
WSTG (Web Security Testing Guide) adalah panduan teknis komprehensif untuk menguji keamanan aplikasi web. Ini adalah dokumen paling teknis di antara keempat kerangka yang dibahas — berisi metodologi pengujian, teknik, dan prosedur spesifik untuk setiap jenis kerentanan.
Versi terkini adalah WSTG 4.2, dengan pembaruan reguler oleh komunitas.
WSTG mencakup metodologi pengujian untuk:
Pengumpulan informasi (information gathering)
Pengujian konfigurasi dan manajemen deployment
Pengujian manajemen identitas
Pengujian autentikasi dan otorisasi
Pengujian manajemen sesi
Pengujian validasi input (termasuk semua jenis injection)
Pengujian penanganan error
Pengujian kriptografi
Pengujian logika bisnis (business logic testing)
Pengujian sisi klien
Meski WSTG adalah dokumen teknis yang tidak perlu dibaca eksekutif secara langsung, pemimpin bisnis perlu memahami eksistensinya karena dua alasan:
Pertama, sebagai standar kualitas penetration testing. Ketika Anda menyewa perusahaan penetration testing, salah satu pertanyaan yang layak diajukan adalah: "Apakah metodologi pengujian Anda mengacu pada OWASP WSTG?" Ini adalah sinyal tentang kualitas dan kelengkapan pengujian yang akan dilakukan.
Kedua, sebagai referensi untuk mengevaluasi laporan penetration test. Laporan penetration testing yang baik akan memetakan temuan ke metodologi standar seperti WSTG — memudahkan perbandingan lintas waktu dan lintas vendor.
Sebagai standar metodologi untuk tim internal security testing
Sebagai kriteria evaluasi vendor penetration testing
Sebagai referensi teknis untuk tim pengembang yang ingin memahami bagaimana aplikasi mereka diuji
Sebagai panduan dalam menyusun scope dan rules of engagement untuk penetration test
SAMM (Software Assurance Maturity Model) adalah kerangka untuk menilai, merencanakan, dan meningkatkan program keamanan perangkat lunak secara keseluruhan. Berbeda dari ketiga kerangka sebelumnya yang berfokus pada apa yang harus dipenuhi atau bagaimana menguji, SAMM berfokus pada seberapa matang kapabilitas organisasi dalam mengintegrasikan keamanan ke dalam siklus pengembangan software.
Versi terkini adalah SAMM 2.0.
SAMM mengorganisasi keamanan software ke dalam lima fungsi bisnis yang mencerminkan siklus hidup pengembangan software:
1. Governance — Bagaimana organisasi mengelola keamanan secara strategis
Strategi & Metrik: mendefinisikan tujuan keamanan dan mengukur kemajuan
Kebijakan & Kepatuhan: memastikan kepatuhan internal dan eksternal
Pendidikan & Panduan: membangun kapabilitas tim melalui pelatihan
2. Design — Bagaimana keamanan diintegrasikan dalam fase desain
Threat Assessment: mengidentifikasi dan menganalisis ancaman potensial
Security Requirements: mendefinisikan persyaratan keamanan berbasis risiko
Secure Architecture: merancang arsitektur yang inherently secure
3. Implementation — Bagaimana keamanan diterapkan dalam kode
Secure Build: mengamankan proses build dan dependency
Secure Deployment: mengamankan proses deployment dan konfigurasi
Defect Management: mengelola dan menangani kelemahan yang ditemukan
4. Verification — Bagaimana keamanan diverifikasi
Architecture Assessment: menilai keamanan arsitektur secara formal
Requirements-driven Testing: pengujian berbasis persyaratan keamanan
Security Testing: pengujian teknis komprehensif
5. Operations — Bagaimana keamanan dijaga dalam operasi
Incident Management: mengelola dan merespons insiden keamanan
Environment Management: mengamankan lingkungan operasi
Operational Management: mengelola aspek keamanan operasional
Setiap praktik dinilai dalam tiga level kematangan:
Level 0 — Tidak ada praktik formal yang berjalan Level 1 — Praktik ad-hoc, inisiatif individual, tidak terstandarisasiLevel 2 — Praktik terstandarisasi, terdokumentasi, diterapkan secara konsisten Level 3 — Praktik dioptimasi, diukur, dan terus ditingkatkan secara proaktif
Dengan 15 praktik dan 3 level, SAMM menghasilkan profil kematangan yang sangat granular — memungkinkan organisasi mengidentifikasi dengan tepat di mana gap-nya dan memprioritaskan area improvement berdasarkan risiko bisnis.
SAMM adalah satu-satunya kerangka OWASP yang secara eksplisit dirancang untuk manajemen dan eksekutif, bukan hanya untuk tim teknis. Ia menjawab pertanyaan strategis yang tidak dijawab oleh Top 10, ASVS, atau WSTG:
"Seberapa matang program keamanan software kita saat ini?"
"Di mana gap terbesar kita dibanding industri?"
"Apa roadmap realistis untuk meningkatkan kematangan keamanan kita dalam 12 bulan ke depan?"
"Bagaimana kita mengukur kemajuan program keamanan dari waktu ke waktu?"
"Berapa anggaran yang dibutuhkan untuk naik dari Level 1 ke Level 2 dalam area X?"
Saat memulai program keamanan software dari nol atau merombak yang sudah ada
Saat baseline assessment sebelum investasi besar di bidang keamanan
Saat menyusun roadmap keamanan jangka menengah untuk presentasi ke dewan direksi
Saat due diligence akuisisi atau merger yang melibatkan penilaian kematangan keamanan
Saat benchmarking dengan industri atau kompetitor
Langkah 1: Gunakan SAMM untuk baseline assessment — pahami di mana posisi Anda sekarang.
Langkah 2: Gunakan Top 10 untuk komunikasi risiko ke manajemen dan sebagai prioritas awal.
Langkah 3: Gunakan ASVS Level 1 sebagai standar minimum untuk semua aplikasi baru.
Langkah 4: Gunakan WSTG sebagai referensi saat melakukan atau memesan penetration test pertama.
Prioritas: ASVS Level 2 untuk semua aplikasi yang menghadap nasabah, ASVS Level 3 untuk aplikasi core banking.
Pendukung: Top 10 sebagai komunikasi ke dewan komisaris, SAMM untuk roadmap peningkatan, WSTG sebagai standar metodologi pengujian tahunan.
Prioritas: WSTG sebagai standar metodologi untuk mengevaluasi vendor penetration testing.
Pendukung: ASVS untuk mendefinisikan scope dan kriteria penerimaan hasil pengujian.
Prioritas: SAMM untuk baseline, gap analysis, dan target state definition.
Pendukung: Top 10 dan ASVS sebagai referensi target teknis, WSTG untuk validasi kemajuan.
Berbeda dengan beberapa yurisdiksi yang secara eksplisit mewajibkan standar tertentu, regulasi Indonesia lebih bersifat principle-based dalam hal keamanan aplikasi. Namun terdapat pemetaan yang kuat:
UU PDP (UU No. 27 Tahun 2022) mewajibkan perlindungan data pribadi dalam sistem elektronik — yang secara langsung berkaitan dengan kontrol dalam ASVS terkait data protection, enkripsi, dan akses kontrol.
POJK No. 11/POJK.03/2022 dan peraturan OJK terkait mensyaratkan pengujian keamanan berkala untuk sistem perbankan digital — yang dalam praktiknya mengacu pada metodologi WSTG dan standar ASVS Level 2–3.
Permenkominfo tentang Sistem Elektronik Strategis mensyaratkan audit keamanan yang komprehensif — di mana SAMM dapat digunakan sebagai kerangka penilaian kematangan.
BSSN (Badan Siber dan Sandi Negara) dalam beberapa panduan teknisnya mereferensikan OWASP sebagai standar industri yang diakui.
Pertanyaan yang tepat bukan "Mana yang harus kami pilih?" melainkan "Kombinasi apa yang tepat untuk fase dan konteks organisasi kami sekarang?"
Untuk sebagian besar organisasi di Indonesia, titik masuk yang ideal adalah:
Top 10 sebagai bahasa bersama antara bisnis dan teknologi, SAMM sebagai kompas strategis untuk memahami posisi dan arah, ASVS sebagai standar teknis yang konkret dan terukur, dan WSTG sebagai panduan metodologi untuk pengujian yang berkualitas.
Keempat kerangka ini bukan kompetitor — mereka adalah lapisan yang saling melengkapi dalam membangun program keamanan aplikasi yang komprehensif, terukur, dan dapat dipertanggungjawabkan.
Bagian
Seri: Referensi Cybersecurity 2025–2026
Topik: OWASP & Keamanan Aplikasi
Artikel: 4 dari 7
Ketika organisasi memutuskan untuk serius dalam keamanan aplikasi, salah satu kebingungan pertama yang muncul adalah: "Ada begitu banyak standar dan kerangka OWASP — mana yang harus kami gunakan?"
Jawabannya bukan memilih salah satu dan mengabaikan yang lain. Setiap kerangka OWASP dirancang untuk tujuan berbeda, audiens berbeda, dan fase berbeda dalam perjalanan keamanan sebuah organisasi. Memahami perbedaan ini adalah langkah pertama dalam membangun program keamanan aplikasi yang terstruktur dan efisien.
Artikel ini membahas empat kerangka OWASP utama — Top 10, ASVS, WSTG, dan SAMM — dan bagaimana memilih kombinasi yang tepat berdasarkan kematangan organisasi, konteks regulasi, dan tujuan strategis.
Analogi sederhana: jika keamanan aplikasi adalah sebuah bangunan, Top 10 adalah daftar sepuluh kelemahan struktural paling umum yang harus dihindari, ASVS adalah kode bangunan lengkap yang harus dipenuhi, WSTG adalah panduan inspeksi teknis untuk menemukan masalah, dan SAMM adalah metodologi untuk menilai dan meningkatkan kapabilitas tim arsitek dan kontraktornya.
OWASP Top 10 adalah daftar sepuluh kategori risiko keamanan aplikasi web yang paling kritis, diperbarui setiap empat tahun. Edisi terbaru adalah OWASP Top 10:2025, dirilis November 2025.
Aksesibilitas
Dapat dipahami oleh non-teknis sekalipun. CEO dan CFO dapat membaca Top 10 dan memahami implikasi bisnisnya tanpa perlu latar belakang keamanan.
Kesederhanaan yang disengaja
Kategorisasinya sengaja dibuat luas dan tingkat tinggi. Ini bukan kelemahan — ini fitur. Tujuannya adalah kesadaran dan diskusi, bukan checklist teknis.
Pengakuan global
Direferensikan oleh hampir semua standar keamanan (PCI-DSS, ISO 27001, NIST), regulasi (GDPR, UU PDP, POJK), dan kontrak pengadaan.
Baseline yang defensible
Menjadi standar minimum yang dapat dipertahankan di hadapan auditor, regulator, dan dewan direksi.
Top 10 bukan checklist pengujian — ia tidak menjelaskan bagaimana menguji atau seberapa dalam sebuah kontrol harus diimplementasikan. Ia tidak menjawab pertanyaan seperti: "Seberapa kuat autentikasi yang harus kami terapkan untuk aplikasi perbankan kami?"
Top 10 juga tidak cukup sebagai standar pengembangan — tidak cukup granular untuk dijadikan panduan bagi tim pengembang dalam menulis kode yang aman.
Sebagai komunikasi risiko kepada manajemen dan dewan direksi
Sebagai baseline penilaian vendor dalam proses procurement
Sebagai referensi awal dalam kebijakan keamanan aplikasi
Sebagai kriteria minimum dalam kontrak pengembangan software
Sebagai tolok ukur audit awal
ASVS (Application Security Verification Standard) adalah kerangka komprehensif yang mendefinisikan persyaratan keamanan fungsional dan non-fungsional untuk aplikasi web. Versi terkini adalah ASVS 4.0, dengan versi 5.0 dalam pengembangan aktif oleh komunitas.
ASVS mencakup lebih dari 280 persyaratan keamanan yang diorganisasi dalam 14 area kontrol, mulai dari arsitektur dan desain, autentikasi, manajemen sesi, akses kontrol, validasi input, kriptografi, penanganan error, perlindungan data, komunikasi, kode berbahaya, konfigurasi HTTP, file dan resource, API, dan konfigurasi.
ASVS menggunakan sistem tiga level yang memungkinkan organisasi memilih kedalaman kontrol berdasarkan profil risiko aplikasi mereka:
Level 1 — Oportunistik Kontrol dasar yang dapat diverifikasi secara otomatis menggunakan tools DAST (Dynamic Application Security Testing). Cocok untuk aplikasi dengan risiko bisnis rendah-menengah. Ini adalah level minimum yang seharusnya dipenuhi oleh semua aplikasi yang menghadap publik.
Contoh persyaratan Level 1: Semua halaman login harus menggunakan HTTPS. Sesi harus berakhir setelah periode tidak aktif yang ditentukan. Cookie sensitif harus memiliki flag HttpOnly dan Secure.
Level 2 — Standar Kontrol komprehensif yang membutuhkan kombinasi pengujian otomatis dan manual. Cocok untuk sebagian besar aplikasi bisnis, termasuk yang memproses data sensitif, transaksi keuangan, atau informasi kesehatan.
Contoh persyaratan Level 2: Mekanisme autentikasi harus tahan terhadap credential stuffing. Semua input pengguna harus divalidasi dan di-sanitize sebelum diproses. Log keamanan harus mencakup waktu, sumber, dan detail kejadian yang cukup untuk forensik.
Level 3 — Lanjutan Kontrol tertinggi untuk aplikasi kritis yang membutuhkan tingkat jaminan keamanan tertinggi. Membutuhkan pengujian penetrasi mendalam dan review arsitektur komprehensif.
Contoh persyaratan Level 3: Analisis ancaman formal harus dilakukan selama fase desain. Semua komponen kriptografi harus menggunakan implementasi yang telah divalidasi dan bukan implementasi kustom. Aplikasi harus mampu mendeteksi dan merespons serangan secara aktif.
ASVS dan Top 10 saling melengkapi secara langsung. Setiap kategori dalam Top 10 terhubung ke satu atau lebih area dalam ASVS. Jika Top 10 menyatakan "Broken Access Control adalah risiko #1", ASVS menjelaskan secara detail persyaratan apa saja yang harus dipenuhi agar kontrol akses dianggap memadai — dengan tingkat kedalaman yang berbeda untuk setiap level.
ASVS mulai digunakan sebagai referensi dalam:
Audit keamanan aplikasi perbankan
Didorong ketentuan OJK tentang pengujian keamanan sistem
Pengadaan software pemerintah
Terutama untuk sistem yang menangani data sensitif warga
Sertifikasi aplikasi fintech
Sebagai persyaratan tidak formal dari beberapa mitra perbankan
Saat menyusun persyaratan keamanan untuk pengembangan aplikasi baru
Saat melakukan audit keamanan aplikasi yang lebih dari sekadar compliance check
Saat mendefinisikan kriteria penerimaan (acceptance criteria) keamanan dalam kontrak pengembangan
Saat membangun program bug bounty yang membutuhkan scope yang terdefinisi
Saat menyiapkan aplikasi untuk sertifikasi atau due diligence keamanan
WSTG (Web Security Testing Guide) adalah panduan teknis komprehensif untuk menguji keamanan aplikasi web. Ini adalah dokumen paling teknis di antara keempat kerangka yang dibahas — berisi metodologi pengujian, teknik, dan prosedur spesifik untuk setiap jenis kerentanan.
Versi terkini adalah WSTG 4.2, dengan pembaruan reguler oleh komunitas.
WSTG mencakup metodologi pengujian untuk:
Pengumpulan informasi (information gathering)
Pengujian konfigurasi dan manajemen deployment
Pengujian manajemen identitas
Pengujian autentikasi dan otorisasi
Pengujian manajemen sesi
Pengujian validasi input (termasuk semua jenis injection)
Pengujian penanganan error
Pengujian kriptografi
Pengujian logika bisnis (business logic testing)
Pengujian sisi klien
Meski WSTG adalah dokumen teknis yang tidak perlu dibaca eksekutif secara langsung, pemimpin bisnis perlu memahami eksistensinya karena dua alasan:
Pertama, sebagai standar kualitas penetration testing. Ketika Anda menyewa perusahaan penetration testing, salah satu pertanyaan yang layak diajukan adalah: "Apakah metodologi pengujian Anda mengacu pada OWASP WSTG?" Ini adalah sinyal tentang kualitas dan kelengkapan pengujian yang akan dilakukan.
Kedua, sebagai referensi untuk mengevaluasi laporan penetration test. Laporan penetration testing yang baik akan memetakan temuan ke metodologi standar seperti WSTG — memudahkan perbandingan lintas waktu dan lintas vendor.
Sebagai standar metodologi untuk tim internal security testing
Sebagai kriteria evaluasi vendor penetration testing
Sebagai referensi teknis untuk tim pengembang yang ingin memahami bagaimana aplikasi mereka diuji
Sebagai panduan dalam menyusun scope dan rules of engagement untuk penetration test
SAMM (Software Assurance Maturity Model) adalah kerangka untuk menilai, merencanakan, dan meningkatkan program keamanan perangkat lunak secara keseluruhan. Berbeda dari ketiga kerangka sebelumnya yang berfokus pada apa yang harus dipenuhi atau bagaimana menguji, SAMM berfokus pada seberapa matang kapabilitas organisasi dalam mengintegrasikan keamanan ke dalam siklus pengembangan software.
Versi terkini adalah SAMM 2.0.
SAMM mengorganisasi keamanan software ke dalam lima fungsi bisnis yang mencerminkan siklus hidup pengembangan software:
1. Governance — Bagaimana organisasi mengelola keamanan secara strategis
Strategi & Metrik: mendefinisikan tujuan keamanan dan mengukur kemajuan
Kebijakan & Kepatuhan: memastikan kepatuhan internal dan eksternal
Pendidikan & Panduan: membangun kapabilitas tim melalui pelatihan
2. Design — Bagaimana keamanan diintegrasikan dalam fase desain
Threat Assessment: mengidentifikasi dan menganalisis ancaman potensial
Security Requirements: mendefinisikan persyaratan keamanan berbasis risiko
Secure Architecture: merancang arsitektur yang inherently secure
3. Implementation — Bagaimana keamanan diterapkan dalam kode
Secure Build: mengamankan proses build dan dependency
Secure Deployment: mengamankan proses deployment dan konfigurasi
Defect Management: mengelola dan menangani kelemahan yang ditemukan
4. Verification — Bagaimana keamanan diverifikasi
Architecture Assessment: menilai keamanan arsitektur secara formal
Requirements-driven Testing: pengujian berbasis persyaratan keamanan
Security Testing: pengujian teknis komprehensif
5. Operations — Bagaimana keamanan dijaga dalam operasi
Incident Management: mengelola dan merespons insiden keamanan
Environment Management: mengamankan lingkungan operasi
Operational Management: mengelola aspek keamanan operasional
Setiap praktik dinilai dalam tiga level kematangan:
Level 0 — Tidak ada praktik formal yang berjalan Level 1 — Praktik ad-hoc, inisiatif individual, tidak terstandarisasiLevel 2 — Praktik terstandarisasi, terdokumentasi, diterapkan secara konsisten Level 3 — Praktik dioptimasi, diukur, dan terus ditingkatkan secara proaktif
Dengan 15 praktik dan 3 level, SAMM menghasilkan profil kematangan yang sangat granular — memungkinkan organisasi mengidentifikasi dengan tepat di mana gap-nya dan memprioritaskan area improvement berdasarkan risiko bisnis.
SAMM adalah satu-satunya kerangka OWASP yang secara eksplisit dirancang untuk manajemen dan eksekutif, bukan hanya untuk tim teknis. Ia menjawab pertanyaan strategis yang tidak dijawab oleh Top 10, ASVS, atau WSTG:
"Seberapa matang program keamanan software kita saat ini?"
"Di mana gap terbesar kita dibanding industri?"
"Apa roadmap realistis untuk meningkatkan kematangan keamanan kita dalam 12 bulan ke depan?"
"Bagaimana kita mengukur kemajuan program keamanan dari waktu ke waktu?"
"Berapa anggaran yang dibutuhkan untuk naik dari Level 1 ke Level 2 dalam area X?"
Saat memulai program keamanan software dari nol atau merombak yang sudah ada
Saat baseline assessment sebelum investasi besar di bidang keamanan
Saat menyusun roadmap keamanan jangka menengah untuk presentasi ke dewan direksi
Saat due diligence akuisisi atau merger yang melibatkan penilaian kematangan keamanan
Saat benchmarking dengan industri atau kompetitor
Langkah 1: Gunakan SAMM untuk baseline assessment — pahami di mana posisi Anda sekarang.
Langkah 2: Gunakan Top 10 untuk komunikasi risiko ke manajemen dan sebagai prioritas awal.
Langkah 3: Gunakan ASVS Level 1 sebagai standar minimum untuk semua aplikasi baru.
Langkah 4: Gunakan WSTG sebagai referensi saat melakukan atau memesan penetration test pertama.
Prioritas: ASVS Level 2 untuk semua aplikasi yang menghadap nasabah, ASVS Level 3 untuk aplikasi core banking.
Pendukung: Top 10 sebagai komunikasi ke dewan komisaris, SAMM untuk roadmap peningkatan, WSTG sebagai standar metodologi pengujian tahunan.
Prioritas: WSTG sebagai standar metodologi untuk mengevaluasi vendor penetration testing.
Pendukung: ASVS untuk mendefinisikan scope dan kriteria penerimaan hasil pengujian.
Prioritas: SAMM untuk baseline, gap analysis, dan target state definition.
Pendukung: Top 10 dan ASVS sebagai referensi target teknis, WSTG untuk validasi kemajuan.
Berbeda dengan beberapa yurisdiksi yang secara eksplisit mewajibkan standar tertentu, regulasi Indonesia lebih bersifat principle-based dalam hal keamanan aplikasi. Namun terdapat pemetaan yang kuat:
UU PDP (UU No. 27 Tahun 2022) mewajibkan perlindungan data pribadi dalam sistem elektronik — yang secara langsung berkaitan dengan kontrol dalam ASVS terkait data protection, enkripsi, dan akses kontrol.
POJK No. 11/POJK.03/2022 dan peraturan OJK terkait mensyaratkan pengujian keamanan berkala untuk sistem perbankan digital — yang dalam praktiknya mengacu pada metodologi WSTG dan standar ASVS Level 2–3.
Permenkominfo tentang Sistem Elektronik Strategis mensyaratkan audit keamanan yang komprehensif — di mana SAMM dapat digunakan sebagai kerangka penilaian kematangan.
BSSN (Badan Siber dan Sandi Negara) dalam beberapa panduan teknisnya mereferensikan OWASP sebagai standar industri yang diakui.
Pertanyaan yang tepat bukan "Mana yang harus kami pilih?" melainkan "Kombinasi apa yang tepat untuk fase dan konteks organisasi kami sekarang?"
Untuk sebagian besar organisasi di Indonesia, titik masuk yang ideal adalah:
Top 10 sebagai bahasa bersama antara bisnis dan teknologi, SAMM sebagai kompas strategis untuk memahami posisi dan arah, ASVS sebagai standar teknis yang konkret dan terukur, dan WSTG sebagai panduan metodologi untuk pengujian yang berkualitas.
Keempat kerangka ini bukan kompetitor — mereka adalah lapisan yang saling melengkapi dalam membangun program keamanan aplikasi yang komprehensif, terukur, dan dapat dipertanggungjawabkan.