Apa itu pengodean aman?

Pengodean aman, juga disebut sebagai pemrograman aman, adalah praktik penulisan kode sumber yang memberikan perlindungan terhadap serangan siber dari aktor ancaman. Menanamkan keamanan ke dalam kode membantu membatasi kerentanan, dengan menciptakan perangkat lunak yang cukup kuat dan tangguh untuk melawan ancaman siber.

Pemrograman aman adalah bagian penting dari siklus proses pengembangan perangkat lunak aman (secure software development life cycle, SSDLC). Berbeda dengan SDLC tradisional, di mana keamanan hanya berperan selama fase pengujian, SSDLC memasukkan keamanan siber di setiap tahap proses pengembangan perangkat lunak. Keamanan kode bukan hanya fitur tambahan, add-on opsional, atau aspek terpisah, melainkan elemen penting dalam membangun perangkat lunak yang aman.

Pengodean aman juga termasuk dalam lingkup yang lebih luas, yaitu keamanan aplikasi. Pemrograman aman berfokus mengintegrasikan keamanan siber ke dalam kode, sementara keamanan aplikasi mencakup berbagai macam tindakan keamanan—mulai dari perlindungan perangkat keras hingga pertahanan berbasis perangkat lunak—dan melingkupi seluruh SDLC.

Eksploitasi kerentanan telah menjadi penyebab utama serangan, menurut X-Force Threat Intelligence Index 2026 dari IBM. Beralih ke pendekatan yang lebih proaktif dan preventif seperti pengodean aman dapat mendeteksi ancaman sebelum meningkat.

Pemrograman aman menawarkan keunggulan berikut:

• Efisiensi biaya: Memperbaiki celah keamanan sebelum penerapan jauh lebih murah daripada melakukannya setelah perangkat lunak dirilis.

• Keamanan data: Perlindungan untuk data sensitif diterapkan pada tingkat kode sumber, yang mendukung kepatuhan terhadap peraturan perlindungan data.

• Deteksi dan pencegahan dini: Kerentanan ditemukan dan dieliminasi selama pengembangan untuk mencegahnya menyebar ke tahap produksi.

• Penghematan waktu dan tenaga: Kode aman dapat membantu menghindari pemborosan waktu dan upaya yang terkait dengan respons insiden dan remediasi untuk sistem yang sedang berjalan.

Kerentanan keamanan pada kode umumnya berasal dari kesalahan desain dan arsitektur perangkat lunak, kesalahan konfigurasi, atau kesalahan pemrograman, dan masih banyak lagi. Pihak yang berniat jahat sering mengeksploitasi kerentanan ini sebagai titik masuk untuk melakukan serangan.

Berikut adalah beberapa kerentanan umum yang ingin diatasi oleh pemrograman aman, berdasarkan daftar risiko keamanan aplikasi web dari Open Worldwide Application Security Project (OWASP):

• Kegagalan autentikasi

• Kontrol akses yang rusak

• Kegagalan kriptografi

• Serangan injeksi

• Desain yang tidak aman

• Kegagalan pencatatan dan peringatan

• Kesalahan konfigurasi keamanan

• Kegagalan integritas perangkat lunak atau data

Penjahat siber memanfaatkan kelemahan dalam mekanisme autentikasi untuk mencuri kredensial pengguna dan melakukan aktivitas jahat. Kegagalan autentikasi mencakup kebijakan kata sandi yang lemah, kurangnya metode autentikasi yang kuat, manajemen sesi yang tidak tepat, dan perlindungan yang tidak memadai terhadap skema peretasan kata sandi seperti serangan brute force yang menemukan kata sandi yang benar melalui metode coba-coba atau penjejalan kredensial (credential stuffing) untuk mendapatkan akses ke akun pengguna menggunakan pasangan nama pengguna dan kata sandi yang dibobol.

Kontrol akses menentukan siapa saja yang diizinkan mengakses data atau sumber daya dan tindakan apa yang boleh mereka lakukan. Kontrol yang rusak atau tidak diterapkan dengan benar dapat menyebabkan akses tidak sah dan penyalahgunaan hak istimewa. Ancamannya dapat berupa pengubahan permintaan API dan parameter URL untuk membobol pemeriksaan kontrol akses atau referensi objek langsung yang tidak aman yang memungkinkan perujukan data atau sumber daya secara langsung menggunakan pengidentifikasi uniknya tanpa memverifikasi izin.

Kelemahan dalam metodologi kriptografi dapat mengekspos data sensitif dan mengakibatkan pelanggaran data. Kegagalan kriptografi mencakup algoritma enkripsi yang usang atau lemah, protokol manajemen kunci yang buruk, penggunaan kunci yang di-hardcode, dan pengiriman atau penyimpanan data tanpa enkripsi yang sesuai.

Serangan injeksi adalah salah satu jenis kerentanan keamanan yang paling umum. Input berbahaya—baik itu kode, perintah, kueri, maupun skrip—dimasukkan ke dalam program atau halaman web untuk meluncurkan malware, memodifikasi data, mencuri informasi pribadi, atau tindakan jahat lainnya. Pembuatan skrip lintas situs, pemalsuan permintaan lintas situs, dan pemalsuan permintaan sisi server adalah beberapa serangan injeksi yang populer.

Pembuatan skrip lintas situs (cross-site scripting, XSS) menerapkan kode atau skrip yang tidak tepercaya di situs web tepercaya, yang kemudian dijalankan oleh pengguna yang tidak menaruh curiga. Ini biasanya terjadi ketika aplikasi gagal menghindari, memfilter, menyanitasi, atau memvalidasi data yang disediakan pengguna.

Pemalsuan permintaan lintas situs (cross-site request forgery, CSRF atau XSRF) mengirimkan permintaan yang tidak sah ke situs web dari pengguna terautentikasi. Kerentanan ini memanfaatkan kepercayaan yang dimiliki situs pada browser web pengguna terautentikasi, dengan menggunakan tautan atau skrip yang mengelabui browser agar mengirim permintaan berbahaya ke situs target.

Pemalsuan permintaan sisi server (server-side request forgery, SSRF) memanipulasi URL yang dikirim ke server. Ketika server menerima permintaan yang dimanipulasi tanpa terlebih dahulu memvalidasi URL, permintaan tersebut dapat digunakan untuk terhubung ke layanan internal seperti database atau untuk membaca file, konfigurasi server, dan metadata lainnya.

Desain yang tidak aman terkait dengan kerentanan yang disebabkan oleh kelemahan dalam logika bisnis atau arsitektur aplikasi. Ini terjadi lebih awal pada SDLC selama fase perencanaan ketika menentukan persyaratan dan memetakan cetak biru sistem. Faktor-faktor seperti tidak adanya penilaian risiko, terbatasnya penggunaan pola desain aman dan arsitektur referensi, dan terbatasnya pemodelan ancaman untuk secara sistematis menganalisis potensi kerentanan keamanan dalam arsitektur yang direncanakan dapat menyebabkan desain yang tidak aman.

Peringatan dan log yang tidak memadai atau tidak efektif dapat menyebabkan serangan dan pelanggaran yang tidak terdeteksi, sehingga aktor ancaman menimbulkan masalah serius. Beberapa contoh kegagalan pencatatan dan peringatan meliputi peristiwa penting yang tidak dicatat atau yang dicatat secara tidak konsisten, penyimpanan log yang tidak aman sehingga rentan terhadap manipulasi atau akses tidak sah, peringatan yang tidak memadai atas serangan aktif real-time atau hampir real-time, pesan log yang tidak jelas atau tidak memiliki detail atau konteks yang cukup, serta log yang berisi data sensitif tanpa disamarkan atau dibersihkan.

Kerentanan ini terjadi ketika pengaturan keamanan untuk tumpukan aplikasi—termasuk layanan cloud, database, kerangka kerja, pustaka, sistem operasi, dan server web—dikonfigurasi dengan benar. Kesalahan konfigurasi keamanan dapat berupa penonaktifan pembaruan keamanan, izin yang terlalu luas, kredentif default yang tidak berubah, dan pengaktifan fitur yang tidak perlu.

Kegagalan ini terkait dengan kurangnya perlindungan terhadap penerimaan atau pemrosesan data yang tidak valid atau tidak tepercaya dari sumber eksternal. Contohnya antara lain penerapan pembaruan perangkat lunak secara otomatis tanpa memvalidasi integritasnya, penggunaan sumber yang tidak tepercaya untuk dependensi seperti pustaka dan plugin pihak ketiga, dan pipeline CI/CD yang mengambil kode atau artefak pengembangan perangkat lunak lainnya tanpa melalui proses verifikasi.

Beberapa teknologi AI generatif dapat membantu mewujudkan pemrograman yang aman. Sebagai contoh, platform pengodean AI agen seperti Claude Code dan IBM Bob dapat memunculkan kerentanan dan menyarankan perbaikan atas kode tidak aman secara real time. Alat pembuatan kode AI juga dapat membantu memfaktorkan ulang kode guna meningkatkan keamanan.

Meskipun =dapat mengotomatiskan dan mempercepat pengembangan perangkat lunak, asisten pengodean AI masih membutuhkan arahan agar dapat menghasilkan kode yang aman. Pemrogram harus memberikan prompt yang jelas, yang menentukan fungsionalitas sekaligus persyaratan keamanan. Misalnya, prompt umum seperti “buat fungsi login” dapat diperluas menjadi “buat fungsi login yang memeriksa input pengguna untuk format dan panjang yang diharapkan” agar menyertakan instruksi pengodean aman. Panduan dari Open Source Security Foundation berisi contoh instruksi untuk membantu asisten AI mempertimbangkan keamanan kode.

Tim rekayasa perangkat lunak juga dapat memberikan konteks yang mengarahkan AI generatif agar menghasilkan kode yang lebih aman. Retrieval-augmented generation (RAG) menghubungkan alat developer berteknologi AI dengan standar pengodean aman internal. Untuk tim tanpa pedoman yang jelas, aturan keamanan AI dari Secure Code Warrior berguna sebagai titik awal untuk menghasilkan kode buatan AI yang lebih aman.

Seperti halnya asisten AI, agen pengodean AI juga memerlukan panduan. Project CodeGuard menawarkan seperangkat aturan dan kerangka kerja keterampilan yang menyematkan praktik pengodean aman langsung ke dalam alur kerja agen. Agen pengodean AI dapat menggunakan aturan dan keterampilan ini selama fase perencanaan sebagai bagian dari tujuannya dan selama fase eksekusi saat menulis kode.

Kode yang dihasilkan oleh kecerdasan buatan sendiri dapat menimbulkan kerentanan, sehingga keputusan akhir terkait akurasi dan keamanan tetap berada di tangan pemrogram manusia. Langkah-langkah AI generatif juga harus dikombinasikan dengan praktik terbaik pengodean aman berikut untuk membangun beberapa lapisan perlindungan.

Praktik terbaik dalam pengodean aman mencakup berbagai strategi pemrograman defensif untuk memperkuat keamanan perangkat lunak. Perusahaan mungkin kesulitan saat menyeimbangkan pengodean aman dengan kecepatan pengiriman. Namun, banyak dari praktik ini mengintegrasikan keamanan ke dalam kode tanpa mengorbankan pengiriman cepat, misalnya menggabungkan keamanan ke dalam fase desain, menetapkan pedoman pengodean aman, melatih pengembang sehingga mereka diperlengkapi untuk mengidentifikasi dan memperbaiki kelemahan keamanan selama pembuatan kode, dan mengotomatiskan analisis kode dan pengujian untuk menemukan kerentanan.

Meskipun mustahil untuk menyebutkan semua praktik terbaik pengodean aman yang ada, daftar ini dapat menjadi titik awal. Selain itu, Anda dapat mengombinasikan praktik-praktik berikut untuk meningkatkan postur keamanan organisasi:

• Mengikuti standar pengodean aman

• Mengintegrasikan keamanan ke dalam desain

• Memvalidasi dan menyanitasi input serta mengenkode output

• Menerapkan protokol kriptografi yang kuat

• Melakukan autentikasi dan otorisasi

• Menyediakan pencatatan yang kuat dan mekanisme penanganan kesalahan yang aman

• Melakukan pengujian keamanan secara menyeluruh

• Menambahkan keamanan sebagai bagian dari tinjauan kode

Standar ini berfungsi sebagai panduan dasar untuk mengintegrasikan teknik pengodean aman secara efektif ke dalam alur kerja pengembangan yang ada. Standar ini juga menyediakan dasar bersama untuk pemrograman yang aman di berbagai proyek perangkat lunak.

OWASP Developer Guide adalah referensi bagi pemrogram untuk membantu mereka menavigasi dan membuat kode sumber yang aman. Panduan ini menguraikan praktik pengodean aman yang tidak bergantung pada teknologi, dengan poin-poin keamanan kode utama disorot dalam daftar periksa yang diambil dari arsip OWASP Secure Coding Practices Quick Reference Guide.

OWASP juga menyediakan serangkaian daftar referensi untuk menerapkan prinsip-prinsip pengodean yang aman dan memerangi berbagai macam kerentanan kode.

Diciptakan oleh Carnegie Mellon University’s Software Engineering Institute, SEI CERT Coding Standards memberikan panduan pemrograman aman dalam bahasa pemrograman Android, C, C++, Java, dan Perl sebagai bahasa pemrograman. Standar ini berisi aturan, rekomendasi, dan contoh kode yang sesuai dan tidak sesuai. Aturan dan rekomendasi memiliki penilaian risiko terkait yang dikategorikan menurut tingkat keparahan, kemungkinan, dan biaya remediasi untuk membantu tim rekayasa perangkat lunak memprioritaskan upaya mereka.

Selain Cybersecurity Framework untuk manajemen risiko keamanan informasi dan manajemen risiko keamanan siber, National Institute of Standards and Technology (NIST) juga telah menerbitkan Secure Software Development Framework. Kerangka kerja ini terdiri dari praktik pengembangan perangkat lunak yang aman, berbasis hasil, dan berstandar tinggi, menjadikannya sebagai pelengkap ideal bagi standar OWASP dan SEI CERT yang lebih teknis.

Membangun desain yang aman ke dalam cetak biru sistem selaras dengan pendekatan “shift left” untuk memindahkan keamanan di awal proses pengembangan perangkat lunak. Pendekatan ini mempertimbangkan cara untuk mengamankan perangkat lunak, bahkan sebelum baris pertama kode ditulis.

Penilaian risiko yang komprehensif dan pemodelan ancaman dapat membantu memunculkan potensi kerentanan keamanan dalam arsitektur perangkat lunak. Tahap desain yang aman juga harus menghadirkan tim keamanan dalam kolaborasi langsung serta memberikan panduan tentang persyaratan keamanan dan cara menanganinya di tingkat kode sumber.

Untuk mendapatkan informasi lebih lanjut tentang integrasi keamanan ke dalam desain, tim dapat mengakses daftar referensi OWASP tentang desain produk yang aman dan pemodelan ancaman serta Secure by Design Framework.

Prinsip pengodean aman inti adalah: jangan pernah mempercayai input apa pun, contohnya dalam serangan injeksi. Validasi dan sanitasi sisi server membantu memastikan input tidak menimbulkan risiko keamanan sebelum diproses.

Tim rekayasa perangkat lunak dapat menempatkan semua logika validasi dan sanitasi dalam file atau lokasi pusat yang aman untuk menjaga konsistensi serta mempercepat dan mempermudah akses dan pembaruan. Mereka juga dapat menggunakan modul validasi dan sanitasi yang diintegrasikan ke dalam bahasa pemrograman dan kerangka kerja. Akan tetapi, modul ini harus diperbarui secara teratur untuk mengatasi kerentanan yang baru ditemukan.

Validasi input memeriksa apakah jenis data, format, panjang, rentang, ukuran, dan batasan lainnya sudah benar. Hal ini mungkin melibatkan pencocokan input dengan pola yang disetujui atau membandingkannya dengan serangkaian karakter atau nilai yang diizinkan.

Sanitasi input memerlukan pembersihan dan pengubahan input menjadi bentuk yang aman. Tindakan ini harus disesuaikan dengan bahasa pemrograman atau kerangka kerja yang relevan.

Dalam HTML, misalnya, menghindari karakter khusus seperti &, <, >, “, dan ‘ dapat membantu mencegah XSS. Pustaka seperti DOMPurify dapat membantu sanitasi HTML.

Untuk database, menggabungkan kueri parameter dengan pernyataan yang disiapkan dapat membantu mencegah serangan injeksi SQL karena input diperlakukan sebagai data, bukan sebagai kode SQL yang dapat dijalankan secara tidak sengaja. Kueri yang diparameterisasi pertama-tama menetapkan semua kode SQL, dengan placeholder untuk input atau parameter, kemudian meneruskan setiap parameter ke kueri pada langkah selanjutnya. Pernyataan yang disiapkan adalah pernyataan SQL yang telah dikompilasi sebelumnya. Ini berarti bahwa perintah SQL yang diinjeksikan tidak dapat mengubah maksud kueri atau cara menjalankannya.

Enkode output memungkinkan data ditampilkan dengan aman sebagai teks sehingga tidak akan ditafsirkan sebagai kode. Banyak kerangka kerja dilengkapi dengan perlindungan enkode output default atau fungsi enkode dan penghindaran otomatis. OWASP Java Encoder mendukung enkode output kontekstual untuk berbagai konteks, misalnya menempatkan variabel ke dalam URL, CSS inline, atau JavaScript inline, dan memasukkan variabel ke dalam nilai atribut HTML, properti CSS, atau di antara dua tag HTML.

Jika diterapkan dengan benar, kriptografi melindungi kerahasiaan, integritas, dan ketersediaan informasi.

Pemrogram harus menggunakan algoritma yang kuat dan terkini saat mengenkripsi data yang sedang dikirim dan data yang sedang disimpan. AES dianggap sebagai standar emas untuk enkripsi simetris, dengan mode terautentikasi dan kunci 256-bit yang memberikan keamanan tingkat tinggi. Untuk enkripsi asimetris, ECC dengan kurva aman atau RSA dengan padding acak diaktifkan dan setidaknya kunci 2048-bit memberikan keamanan yang kuat.

Untuk melindungi kata sandi, algoritma hashing harus diterapkan dan salt—string unik yang dibuat secara acak—ditambahkan ke kata sandi sebagai bagian dari proses hashing. Algoritma hashing adalah fungsi matematika satu arah yang mengubah data menjadi nilai panjang yang unik, lebih pendek, dan berukuran tetap, yang tidak dapat didekodekan atau direkayasa balik. Algoritma hashing modern mencakup Argon2id dan scrypt.

Alih-alih membuat sendiri, pengembang harus mengadopsi implementasi pustaka kriptografi yang andal, didukung, dan terpelihara, seperti Bouncy Castle, Libsodium, OpenSSL dan Tink.

Kunci tidak boleh di-hardcode ke dalam kode sumber, dimasukkan ke dalam sistem kontrol versi, disimpan dalam variabel lingkungan, atau diekspos dalam log. Solusi dan teknologi manajemen kunci dapat membantu mengotomatiskan siklus proses manajemen kunci—mulai dari pembuatan, distribusi, dan penyimpanan hingga penggunaan, rotasi, pencabutan, dan penghancuran.

Dalam hal perlindungan lapisan transport, tim rekayasa perangkat lunak harus menggunakan protokol seperti Hypertext Transfer Protocol Secure (HTTPS) atau HTTP Strict Transport Security (HSTS) dan TLS versi terbaru. Caching data sensitif harus dinonaktifkan, dan penyimpanan data sensitif yang tidak perlu harus dihindari.

Autentikasi dan otorisasi adalah praktik pengodean aman yang penting untuk memverifikasi identitas suatu entitas dan memastikan bahwa entitas tersebut memiliki tingkat akses yang tepat.

Autentikasi multifaktor (multifactor authentication, MFA) adalah salah satu pertahanan terbaik terhadap serangan terkait kata sandi. Mekanisme lain termasuk pembatasan (throttling) login untuk mencegah peretas menebak kata sandi terlalu sering dan penguncian akun untuk menghentikan upaya login dalam jangka waktu tertentu setelah sejumlah login gagal.

Untuk autentikasi tanpa kata sandi, pengembang dapat mempertimbangkan protokol seperti OpenID Connect (OIDC) dan Security Assertion Markup Language (SAML). FIDO dan FIDO2 adalah standar terbuka yang memfasilitasi autentikasi tanpa kata sandi melalui kunci sandi (passkey) serta dapat digunakan untuk mengautentikasi aplikasi, layanan online, dan situs web.

Setelah sesi terautentikasi berhasil dibuat, sesi tersebut harus dipertahankan melalui ID atau token sesi yang aman. ID sesi harus dibuat menggunakan generator nomor pseudorandom yang kuat dan aman secara kriptografis. Seperti halnya input pengguna lainnya, ID atau token sesi harus divalidasi sebelum diproses, dan nilai yang tidak valid dihilangkan.

Menetapkan batas waktu kedaluwarsa untuk setiap sesi akan membatasi durasi pembajakan sesi aktif dan peluncuran serangan oleh pihak yang berniat jahat. Tim rekayasa perangkat lunak dapat menggunakan fungsionalitas manajemen sesi bawaan yang disediakan oleh kerangka kerja pengembangan web.

Pemrogram dapat menggunakan protokol otorisasi seperti OAuth, yang beroperasi bersamaan dengan protokol autentikasi OIDC. Dalam hal kontrol akses, kontrol akses berbasis peran (role-based access control, RBAC) adalah model yang populer. Dengan RBAC, pengguna diberikan akses berdasarkan peran yang telah ditentukan sebelumnya. Opsi lain yang bisa lebih kuat dan mendukung izin yang lebih mendetail adalah kontrol akses berbasis atribut (attribute-based access control, ABAC) dan kontrol akses berbasis hubungan (relationship-based access control, ReBAC). ABAC menganalisis atribut tindakan, objek, dan pengguna—contohnya nama pengguna, jenis sumber daya, dan waktu—untuk menentukan apakah akses akan diberikan. ReBac memberikan akses berdasarkan hubungan antara sumber daya.

Meskipun protokol dan model kontrol akses sudah ada, izin tetap harus divalidasi untuk setiap permintaan dan pemeriksaan kontrol akses harus dilakukan untuk setiap objek yang ingin diakses oleh entitas. Menolak akses secara default dan menerapkan hak istimewa terendah juga merupakan prinsip pengodean aman yang penting dalam otorisasi.

Log dan pesan kesalahan dapat menjadi sumber informasi berguna bagi pihak yang berniat jahat untuk merancang serangan. Ini berarti log dan kesalahan harus ditangani dengan hati-hati.

Kesalahan aplikasi, peristiwa sistem yang terkait dengan perubahan konfigurasi dan tindakan admin atau hak istimewa, dan peristiwa kegagalan di bidang autentikasi, otorisasi, validasi input, dan manajemen sesi harus dicatat karena dapat mengindikasikan upaya pelanggaran. Sertakan cukup informasi, seperti detail pengguna (identitas, peran, dan izin) dan konteks kesalahan atau peristiwa (target, tindakan, dan hasil), untuk membantu analisis dan debugging.

Log harus ditulis ke media hanya baca dan disimpan di lokasi yang aman dengan akses terbatas dan deteksi gangguan bawaan. Jika log perlu dikirim ke sistem lain, protokol transmisi yang aman harus digunakan.

Data sensitif tidak boleh dicatat dan harus dibersihkan (scrubbing) atau dihapus dari log. Informasi lain yang dianggap penting, seperti string koneksi database, jalur file, nama dan alamat jaringan internal, serta ID atau token sesi harus dienkripsi, di-hash, atau disamarkan.

Pustaka pencatatan harus diperbarui secara berkala demi memastikan kelemahan keamanan ditambal. Contohnya adalah kerentanan Log4Shell yang berdampak pada pustaka pencatatan sumber terbuka, Log4j, sehingga memungkinkan peretas menjalankan hampir semua kode yang mereka inginkan pada sistem yang terdampak.

Penanganan kesalahan dijalankan bersamaan dengan pencatatan karena informasi tentang kesalahan biasanya muncul di log. Selain itu, kesalahan yang tidak tertangani dapat berfungsi sebagai port masuk bagi aktor ancaman.

Pengembang dapat mempertimbangkan untuk membuat pengendali kesalahan global yang menampilkan respons umum atau kode kesalahan untuk kesalahan yang tidak terduga, kemudian mencatat detail lebih lanjut tentang kesalahan di sisi server. Hal ini dapat menghindari kebocoran informasi kepada peretas sekaligus menangani kesalahan dengan aman, serta menyediakan temuan yang diperlukan pemrogram untuk penyelidikan lebih lanjut.

Semua tindakan keamanan yang disematkan ke dalam kode sumber harus diverifikasi. Tim QA dan pengembangan dapat menggunakan Web Security Testing Guide dan Application Security Verification Standard dari OWASP sebagai dasar pengujian keamanan kode. Alat otomatis juga dapat membantu proses ini.

Pengujian keamanan aplikasi statis (static application security testing, SAST) menerapkan aturan yang telah ditentukan untuk menemukan pola dalam kode yang menunjukkan kemungkinan kerentanan. SAST terkadang disebut pengujian “kotak putih”, sementara alat SAST juga dikenal sebagai penganalisis kode statis karena alat ini dapat memindai kode tanpa perlu menjalankan aplikasi.

Alat SAST unggul untuk menandai kerentanan kode umum dan dapat menentukan nomor baris dan file kerentanan yang ditemukannya. Alat ini juga terintegrasi dengan mulus dengan sebagian besar IDE dan lingkungan CI/CD. Namun, SAST cenderung menghasilkan positif palsu.

Pengujian keamanan aplikasi dinamis (dynamic application security testing, DAST) mengambil pendekatan dari luar ke dalam, dengan mengevaluasi aplikasi di lingkungan waktu prosesnya menggunakan serangan simulasi untuk meniru tindakan aktor ancaman di dunia nyata. Dengan demikian, DAST sering disebut sebagai pengujian kotak hitam karena penguji tidak perlu mengetahui atau mengakses cara kerja internal atau kode sumber sistem. DAST biasanya menghasilkan positif palsu yang lebih rendah daripada SAST.

Penggabungan SAST dan DAST dapat mengungkap gambaran yang lebih lengkap tentang potensi kerentanan. Untuk pengujian keamanan yang lebih komprehensif, SAST dan DAST dapat dikombinasikan dengan metode lain, seperti pengujian keamanan aplikasi interaktif (interactive application security testing, IAST) yang menilai konteks kode dan perilaku waktu proses untuk melaporkan kerentanan secara real time dan analisis komposisi perangkat lunak (software composition analysis, SCA) yang menganalisis perangkat lunak guna memastikan komponennya aman dan terkini.

Sebagian besar tinjauan kode berfokus pada kualitas, dengan memeriksa kepatuhan kode terhadap pedoman gaya, masalah logis, alur optimal, serta pengujian dan cakupan kasus ekstrem. Namun, keamanan juga harus menjadi bagian dari proses tinjauan kode.

Tinjauan kode yang aman merupakan garis pertahanan berikutnya setelah penganalisis kode statis. Peninjau kode manusia memiliki keahlian domain, pertimbangan, dan wawasan tentang kerentanan keamanan kode yang sering dilewatkan oleh alat otomatis.

Untuk pendekatan yang lebih terstruktur, peninjau kode dapat membaca lembar referensi tinjauan kode aman dari OWASP.