Transisi ke segmen digital bank, ritel, obat-obatan dan cabang-cabang vital lainnya dari produksi dan jasa telah memicu banyak ancaman keamanan. Saat ini, di seluruh dunia, aktivitas penyerang terus tumbuh, dan masalah melindungi data pengguna dan perusahaan dari pencurian dan kerusakan yang disengaja semakin menjadi topik diskusi oleh para profesional.Bagaimana benar bisnis dan TI mengintegrasikan keamanan ke dalam proses pengembangan, alat apa yang paling baik digunakan untuk ini, bagaimana ini semua jatuh pada praktik implementasi aktual. Kami berbagi pendekatan dari Rostelecom, M. Video-Eldorado, DD Planet, AGIMA.Yaroslav Aleksandrov, Kepala Pengembangan, Solar appScreener di Rostelecom, tentang cara mengintegrasikan SAST ke dalam pembangunan
Dengan pertumbuhan perusahaan dan peningkatan jumlah pengembang, memeriksa kerentanan produk “secara manual” menjadi semakin sulit. Anda harus menggunakan SAST - pengujian keamanan aplikasi statis (Pengujian Keamanan Aplikasi Statis). Dalam Solar appScreener, keamanan informasi dibangun berdasarkan produk internal. Produk menganalisis kode sumber. Saat ini, 26 bahasa pemrograman didukung, sumber yang dapat dianalisis kerentanannya, dan mendukung semua format populer dan sistem manajemen proyek.
Bagaimana cara memilih SAST?
Bahkan kerentanan sederhana tidak dapat ditemukan menggunakan algoritma primitif. Saat ini di pasaran ada banyak solusi SAST, baik berbayar maupun gratis. Yang paling populer di antaranya adalah AppScan dari IBM Security, Synopsys, Veracode, Inspektur Aplikasi, Micro Focus, Appercut, Checkmarks.
Efektivitas proses pengembangan tergantung pada pilihan alat. Keuntungan utama dari solusi berbayar:
- Fokus pada keamanan: algoritma spesifik dan basis aturan yang besar.
- Dukungan untuk banyak bahasa pemrograman.
- Antarmuka yang ramah pengguna.
- Ketersediaan plugin dan API.
- Ketersediaan dukungan teknis untuk alat ini.
Alat gratis dan antarmuka web seringkali lebih rendah daripada yang dibayar, karena mengandung algoritma yang lebih sederhana, dan basis aturan kurang lengkap. Tugas utama mereka adalah menemukan kesalahan dalam kode. Spesialisasi dan fungsionalitas dari solusi semacam itu biasanya sangat sempit.
Setelah solusi SAST dipilih, Anda perlu mengintegrasikannya ke dalam proses pengembangan. Opsi integrasi dapat mencakup: menanamkan alat dalam repositori, lingkungan pengembangan, server CI / CD, sistem pelacakan tugas. Alat yang baik dapat berhasil diintegrasikan ke dalam semua kelas sistem yang terdaftar.
Catatan : API SAST terbuka termasuk API JSON dan CLI dan memberikan banyak peluang untuk integrasi dan otomatisasi tambahan.
Untuk memilih alat yang paling memenuhi tujuan dan sasaran pengembang, Anda perlu melakukan perbandingan fungsional dan perbandingan kualitas.
Perbandingan fungsional dilakukan berdasarkan beberapa parameter: mereka menganalisis kenyamanan antarmuka dan kenyamanan integrasi dengan alat mereka sendiri. Pada saat yang sama, penting untuk melakukan verifikasi pada kode Anda sendiri.
Langkah selanjutnya adalah perbandingan kualitas: mereka menganalisis kerentanan dan positif palsu dalam kaitannya dengan kode mereka sendiri.
Nuansa dan kehalusan analisis kode
Semakin cepat kerentanan ditemukan, semakin murah untuk pengembang dan pelanggan. Ini berarti bahwa produk tersebut harus secara berkala diperiksa kerentanannya selama proses pengembangan dan tambahan melakukan pemeriksaan kontrol sebelum dirilis.
Kecepatan dan sumber daya : biasanya diharapkan alat akan bekerja dengan cepat; berjalan di setiap perubahan; tunjukkan dengan cepat siapa dan kapan memperkenalkan kerentanan. Faktanya, SAST menganalisis kode setidaknya selama 8 jam, sulit untuk menjalankannya pada setiap perubahan; sulit untuk mengidentifikasi pembuat kerentanan; kesalahan positif terjadi. Jadi, muncul pertanyaan: cara mengkonfigurasi DevSecOps.
Ini sangat penting di sini:
- Hitung waktu dan sumber daya untuk menganalisis kode Anda.
- Identifikasi pemicu untuk memicu pemindaian berdasarkan hasil.
- Perlu diingat bahwa daya akan perlu dihitung ulang secara berkala.
- Lebih baik menggunakan analisis tambahan, tetapi ini harus dilakukan dengan hati-hati, karena kerentanan dapat hilang.

Misalnya, Anda dapat menjalankan pengujian menggunakan SAST ketika pengembang mengajukan tugas untuk ditinjau. Anda juga dapat mulai memindai pada akhir hari kerja.
Masalah lain adalah positif palsu dan mendapatkan informasi tentang berbagai kerentanan dalam laporan. Dalam hal ini, pengembang disarankan: untuk memfilter dalam analisis statis berdasarkan kerentanan dan file. Anda dapat mengecualikan perpustakaan, menganalisis kekritisan, menambahkan pengecualian untuk parameter tertentu. Cukup dengan melakukan pekerjaan seperti itu hanya sekali, sehingga di masa depan informasi tentang false positive tidak termasuk dalam laporan. Penting juga untuk memastikan bahwa tidak ada kerentanan baru muncul dan secara bertahap membongkar database kerentanan yang ada di latar belakang.
Ketika bekerja mengintegrasikan SAST ke dalam proses pengembangan, penting untuk menerapkan proses secara bertahap tanpa memblokir rilis. Alur proses dapat sebagai berikut:
- Pemilihan alat.
- Deskripsi proses (pembuatan peraturan).
- Deskripsi solusi teknis.
- Pekerjaan implementasi.
- Operasi percobaan.
Lebih baik memulai dengan sistem yang paling kritis: penting untuk menghilangkan kerentanan baru, melakukan desain, menerapkan peraturan dan solusi teknis.
Peraturan tersebut harus mengindikasikan:
- Langkah-langkah untuk memeriksa kode untuk kerentanan.
- Bertanggung jawab untuk memulai pemindaian.
- Peran dan hasil.
- Bagaimana proses komunikasi dibentuk.
- Perjanjian Tingkat Layanan.
- Bertanggung jawab atas kontrol proses.
- Urutan menambahkan sistem baru ke proses.
Pendekatan ini memungkinkan implementasi SAST dalam proses pengembangan dalam satu tahun kalender. Penting untuk mempertimbangkan semua perubahan dan risiko.
Rekomendasi akhir:
- Gunakan SAST di setiap tahap pengembangan.
- Sesuaikan integrasi dengan kode Anda dan proses Anda.
- Mulailah dengan memperbaiki kerentanan baru.
- Secara bertahap menghilangkan kerentanan lama.
- Buat proses berdasarkan SAST.
- Menyebarkan secara bertahap, mulai tanpa dampak pada rilis.
Vladimir Sadovsky, Kepala Tim Pemantauan dan Tanggap Insiden Keamanan Informasi M.Video-Eldorado, tentang cara membangun proses pemrograman yang aman
Ide dasar di balik konsep pemrograman aman bermula untuk membantu bisnis; mempercepat proses; meminimalkan risiko masalah yang terkait dengan kerentanan dalam produk.
Pendekatan klasik untuk keamanan dapat divisualisasikan sebagai berikut:

Masalah utamanya terkait dengan tingginya biaya perbaikan yang diperlukan untuk memastikan keamanan. Selain itu, penting untuk menyediakan protokol enkripsi data, enkripsi protokol transfer bus integrasi, dan sebagainya.
Adapun situs e-commerce, mereka diserang lebih sering daripada yang lain. Tujuan dari serangan semacam itu adalah upaya untuk memperoleh keuntungan finansial tertentu (untuk menipu program dan membeli barang-barang mahal secara gratis), atau untuk merebut data pribadi pelanggan. Sayangnya, sementara beberapa masalah tidak dapat ditutup menggunakan pemindai kerentanan klasik. Misalnya, jika aplikasi memiliki pemindai otorisasi sidik jari, tidak ada analisis statis tunggal yang akan menunjukkan kesalahan fungsi tersebut dalam aplikasi. Ini meningkatkan risiko insiden terkait dengan penetrasi penyusup ke dalam akun pengguna aplikasi. Pada saat yang sama, semakin dekat aplikasi pengecer ke rilis, semakin mahal akan memperbaiki kerentanan dan bug.
Skema untuk menggunakan alat pengujian keamanan kode untuk platform ecommerce mungkin terlihat sebagai berikut:

Ini jelas menunjukkan tim mana yang terlibat dalam implementasi fungsi aplikasi tertentu. Jika kesalahan atau kerentanan terdeteksi, fungsionalitas akan ditujukan untuk menyelesaikan tim khusus ini. Akibatnya, waktu yang dihabiskan untuk memperbaiki bug dan masalah berkurang, karena pengembang langsung tahu kode mereka lebih baik.
Selanjutnya, pengujian akhir diluncurkan, di mana seluruh kode produk akhir dianalisis dan "dibersihkan" sisa bug.
Ancaman Keamanan Ritel
Penggerak utama untuk ritel adalah penjualan - baik itu toko offline, internet, pemasaran, database pelanggan. Semuanya bertujuan untuk sedekat mungkin dengan pengguna. Selain itu, ritel modern berupaya untuk menjual produk mereka menggunakan omnichannel; Meluncurkan berbagai kampanye dan program pemasaran. Semua ini menarik tidak hanya bagi konsumen, tetapi juga bagi para penyusup. Penilaian keamanan tambahan muncul di sini - potensi kerusakan. Analisis ini dirancang untuk mengidentifikasi bug di situs, kesalahan logis dan masalah keamanan klasik yang kemudian diderita konsumen nyata.
Penting juga untuk memahami bahwa potensi kerusakan dimulai dengan fase pengujian. Itu terjadi bahwa lingkungan di mana ia diproduksi sangat terintegrasi dengan produktif, sehingga perubahan yang dilakukan selama fase pengujian dapat menyebabkan insiden dan masalah. Untuk menghindari hal ini, penting untuk mengembangkan peta proses dan mengambil langkah-langkah yang tepat sebelum dimulainya pembangunan.
Jika kontraktor eksternal terlibat dalam pengembangan, penting untuk menilai apakah ia mampu memenuhi persyaratan keselamatan yang diperlukan. Untuk ini, perlu dilakukan penilaian berkala atas kompetensi pengembang dan tingkat perusahaan pelaksana dalam hal keamanan Internet. Kontrak harus mencakup poin untuk sertifikasi pengembang; catat siapa yang bertanggung jawab atas kesalahan yang menyebabkan kerusakan. Penting untuk secara teratur melatih tim pengembangan dan memberikan perlindungan kekayaan intelektual yang komprehensif.
Juga sangat penting untuk menyediakan kontrol akses, mengatur lingkungan yang tepercaya, dan mengkonfigurasi alat pemantauan dan pencegahan kebocoran data. Kami juga harus merumuskan persyaratan terperinci dan kebijakan untuk pemrograman yang aman, memperbaiki semua versi Open Source dan perpustakaan eksternal.
Pada tahap desain, masuk akal untuk menggunakan pendekatan skenario, membangun model ancaman dan melakukan analisis risiko pada beberapa tahap. Ketika tugas baru datang ke pengembang, penting untuk memahami proses bisnis apa yang akan memengaruhi dan mengevaluasi inisiatif dalam hal kemungkinan skenario penipuan di tingkat persyaratan bisnis. Setiap risiko dipertimbangkan dalam kerangka tiga kemungkinan: penilaian optimis, rata-rata dan pesimistis. Bot dikirim ke situs atau aplikasi. Setiap sepersepuluh dari mereka berbahaya. Berdasarkan tiga skenario, potensi kerusakan pada bisnis dihitung.
Ada berbagai analisis statis dan dinamis yang memungkinkan Anda mengidentifikasi masalah dan memperbaikinya tepat waktu. Tugas departemen TI adalah memverifikasi bahwa rantai kode berfungsi dengan benar dari sudut pandang persyaratan teknis. Tugas departemen keamanan adalah memeriksa kode untuk kerentanan keamanan.
Pencarian untuk kerentanan keamanan dalam logika bisnis bermuara pada aspek-aspek berikut:
- Penerapan tes mandiri keamanan saat menguji aplikasi.
- Membuat aturan kostum untuk penganalisa statis dengan mengacu pada proses bisnis penting dan integrasi.
- Analisis manual dari bagian kode yang dimodifikasi, dalam konteks fungsional yang memiliki kekritisan tinggi berdasarkan risiko.
- Proses menemukan bookmark dalam kode, audit berkala perpustakaan eksternal.
Tidak semua masalah keamanan dapat ditemukan dihilangkan pada kode dan tingkat pengembangan. Tugas departemen keamanan adalah membangun dan menetapkan proses yang efektif untuk mengelola kerentanan dan insiden. Untuk melakukan ini, Anda perlu terus menganalisis perilaku pengguna, membuat profil mereka, memantau perilaku tersebut. Jika menyimpang dari pola bisnis yang biasa, Anda harus menganggap ini sebagai insiden dan segera merespons.
Menganalisis perilaku pengguna membantu:
- Bekerja dengan Big Data dan membangun model perilaku abnormal dan abnormalitas.
- Proses pemantauan dan audit skrip JS. Situs modern tidak berfungsi tanpa skrip JS. Seringkali mereka diambil dari sumber daya eksternal. Oleh karena itu, penting untuk memahami fungsinya, dan jenis ancaman JS-skrip untuk situs ini.
- Cari kerentanan berdasarkan layanan analitik dan metrik Google dan Yandex.
- Pengujian keamanan rutin terhadap proyek secara keseluruhan.
- Menggunakan Bug Bounty untuk mengidentifikasi kerentanan baru.
- Integrasi WAF untuk melindungi aplikasi dan secara efektif merespons masalah.
Penting untuk terus mengumpulkan dan menganalisis data untuk mengidentifikasi kasus abnormal baru.
Dmitry Nikulchev, DD Planet - tentang cara melindungi data pengguna layanan web dan seluler
Pemrograman yang aman di DD Planet didasarkan pada beberapa prinsip. Yang pertama adalah keandalan. Kinerja produk harus dapat diprediksi, benar, dan bebas masalah. Bahkan jika data awal dimasukkan secara tidak benar (sengaja atau tidak sengaja sebagai bagian dari serangan terhadap suatu produk).
Yang kedua adalah keamanan. Kemampuan untuk melindungi terhadap ancaman eksternal, serangan, dan mempertahankan operabilitas setelah refleksi dan eliminasi.
Yang ketiga adalah privasi. Memastikan pekerjaan yang aman dan benar dengan data pribadi. Ini sangat penting ketika mengembangkan aplikasi perusahaan dan kustom.
Misalnya, layanan Zhivu.RF, yang dikembangkan dan didukung oleh DD Planet, adalah jejaring sosial pribadi untuk tetangga dan berisi banyak data pribadi. Profil pengguna dikonfirmasi dengan bantuan layanan publik, dan milik alamat tertentu (lingkungan) - ekstrak USRN dari Rosreestra. Ini membebankan kewajiban serius pengembang terkait dengan perlindungan informasi pribadi.
Penyimpanan dan pemrosesan data pengguna
Kami menyimpan semua data pribadi di ISPDn (Sistem Informasi Data Pribadi). Mereka terkandung dalam jaringan virtual yang terisolasi dengan infrastruktur TI yang aman. Alat deteksi intrusi, analisis keamanan dan server pencarian kerentanan, serta server cadangan diintegrasikan ke dalam jaringan virtual.
Untuk mengidentifikasi kerentanan, kami menggunakan "pendekatan manual" dan mengandalkan analisis ahli. Prinsip ini tidak menyiratkan penggunaan alat otomatis: penelitian dilakukan oleh spesialis yang berpengalaman, dan ketika mengidentifikasi kerentanan, ia berfokus pada pengetahuannya sendiri. Jelas bahwa teknik ini memerlukan banyak waktu dan membutuhkan kehadiran spesialis berkualifikasi tinggi di perusahaan. Namun, itu dianggap yang paling efektif dalam hal akurasi dan kelengkapan cakupan data selama verifikasi.
Keseriusan dalam memperjuangkan produk yang sempurna
Dalam pengembangan klien, penting untuk membuat rilis tepat waktu, sementara aplikasi harus bebas bug dan menjamin keamanan pengguna. Mengikuti prinsip ini, selama pengujian produk, kami menggunakan prinsip mengevaluasi tugas berdasarkan prioritas - Tingkat Permasalahan. Artinya, kami memberi peringkat semua tugas untuk menghilangkan bug tergantung pada tingkat dampak negatif pada produk cacat.
Prioritas dalam menyelesaikan bug di DD Planet adalah sebagai berikut:
- Pertama-tama, kami mengidentifikasi dan menghilangkan pemblokir atau kesalahan di mana pengguna tidak memiliki kesempatan untuk melakukan tindakan target. Misalnya, pengunjung tidak dapat mendaftar di situs atau dalam aplikasi; masuk ke akun Anda; Akses data target atau bagian aplikasi.
- Selanjutnya, kami memantau dan memperbaiki bug penting - masalah keamanan, pembekuan sistem, proses bisnis yang tidak berfungsi, dan crash aplikasi berkala.
- Kemudian kami menganalisis masalah tingkat menengah - kami menemukan kesalahan yang hanya muncul dalam situasi spesifik tertentu.
- Langkah terakhir adalah perubahan kecil - kami menghilangkan bug kecil, mengerjakan komentar pada antarmuka, dan sebagainya.
Urutan ini membantu kita dengan cepat menghilangkan bug, dengan fokus pada aspek-aspek kunci bagi pengguna.
Pelepasan produk berlangsung dalam beberapa tahap. Pertama, ini diterbitkan pada lingkungan pengujian untuk mengidentifikasi bug. Lalu ada perbaikan bug prioritas dengan tingkat Severity 1 dan 2. Setelah itu, kami membuat rilis untuk produksi. Untuk beberapa waktu setelah rilis, bagian dari tim terlibat dalam memperbaiki bug dengan prioritas 3 dan 4. Beberapa hari kemudian ada pembaruan lain dalam prod setelah memperbaiki masalah yang tersisa.
Untuk memastikan keamanan produk maksimum:
- Gunakan kueri parameterisasi ke basis data.
- Singkirkan konstruksi permintaan di dalam aplikasi untuk menghindari injeksi sql.
- Hubungkan ke database hanya di bawah akun kabel khusus dengan set minimum hak yang diperlukan.
- Simpan log keamanan secara teratur.
Jangan percayai input pengguna: data apa pun dari klien (pengguna) harus diperiksa di server. Ini akan mencegah lewatnya skrip atau kode hex berbahaya. Data pengguna sering diberikan sebagai parameter untuk memanggil kode lain di server dan, jika tidak diperiksa, dapat membahayakan keamanan sistem. Itulah mengapa sangat penting untuk memeriksa dengan benar semua data input untuk kebenaran.Andrey Ryzhkin dan Alexey Klinov dari AGIMA - tentang bagaimana dan mengapa mengontrol keamanan aplikasi dalam pengembangan kustom
Keamanan arsitektur digital dari produk apa pun adalah atribut penting untuk bisnis dan pengguna. Ini adalah indikator tambahan kualitas dan keandalan, yang harus dipertahankan pada semua tahap produksi dan pengoperasian aplikasi.Setiap organisasi memiliki informasi berharga, yang meliputi:- Data pribadi karyawan dan pelanggan.
- Akses data ke bank klien.
- Data pelanggan perusahaan.
- Gambar produksi.
- Dokumentasi proyek.
- Dan lainnya
Data ini terlokalisasi dalam sistem yang berbeda, dan keamanannya cukup sulit untuk dikendalikan. Dan pencurian atau penyajian yang keliru dari informasi semacam itu menimbulkan kerugian finansial yang besar, penurunan reputasi organisasi, kehilangan pelanggan dan mitra utama, dan gangguan transaksi dan proyek.Namun demikian, ada banyak cara perlindungan informasi di pasar:
Dan sangat mungkin untuk mengatur perlindungan komprehensif yang baik - akan ada keinginan dan cara.Bagaimana dengan keamanan aplikasi?
Bisnis membutuhkan aplikasi yang berfungsi dan stabil dengan fungsi yang efektif yang dapat menghasilkan pengembalian finansial. Tetapi tidak peduli seberapa ideal aplikasi tersebut dalam hal fungsionalitas, mungkin ada artefak yang terkait dengan kerentanan. Biasanya mereka tidak memikirkannya, karena artefak ini tidak memanifestasikan dirinya hingga saat tertentu - sampai pesaing atau peretas yang penasaran membutuhkannya. Kerentanan dapat dieksploitasi dengan tujuan untuk mencoba menyusup ke infrastruktur organisasi melalui situs web atau aplikasi atau untuk mendapatkan akses ke data berharga yang diproses atau disimpan oleh aplikasi ini. Akibatnya, bisnis bisa terkena dampak serius.Sayangnya, analisis keamanan masih jarang untuk pengembangan kustom. Alasannya adalah keunikan proyek. Mereka semua terlalu berbeda, dan masing-masing memiliki kebutuhan sendiri. Ini memengaruhi biaya analisis. Mengingat margin bisnis yang rendah, menempatkan proses pada aliran dalam pengembangan kustom tidak selalu mungkin. Namun demikian, lebih baik untuk tidak mengabaikan prosesnya.Bagaimana mencegah pencurian data dari aplikasi?
Sejak awal pengembangan aplikasi seluler atau web, masuk akal untuk memperkenalkan analisis kode produk untuk keamanan.Anda tidak dapat hanya mengandalkan WAF (firewall) dalam hal perlindungan: aturan mungkin tidak berhasil, konfigurasi yang salah atau tanda tangan yang ketinggalan zaman dapat digunakan. Hanya serangkaian tindakan: penggunaan analisis statis kode sumber selama proses pengembangan, analisis instrumental dalam lingkungan pertempuran, uji-pena, WAF dan perlindungan terhadap DDoS akan membantu memastikan tingkat keamanan aplikasi yang tinggi.Scanner instrumental dan uji-pena akan mendeteksi kerentanan yang tidak dapat diidentifikasi dengan menganalisis kode selama pengembangan.Bagaimana cara mengatur proses pengujian untuk kerentanan?
AGIMA mengimplementasikan beberapa pendekatan untuk analisis kode keamanan:- Integrasi penuh selama pengembangan CI / CD.
- Audit keamanan di pos-pos pemeriksaan.
- Audit keamanan situasional atau satu kali.
Pilihan ideal adalah mengintegrasikan analisis keamanan ke dalam proses pengembangan. Pendekatan ini sangat relevan untuk proyek-proyek yang telah lama dikembangkan oleh pengembang yang sama.Opsi kedua adalah audit keamanan di pos pemeriksaan. Metode ini cocok jika produk memiliki rilis langka dan juga bisa menjadi tambahan yang bagus untuk analisis terintegrasi.Masuk akal untuk menerapkan audit situasional atau satu kali jika proyek cukup sederhana, atau jika telah ditransfer dari pengembang lain. Dalam kasus kedua, penting untuk menentukan utang teknis produk - jumlah bug dan kerentanan yang ada. Setelah itu, Anda perlu membuat peta jalan untuk menghilangkannya. Terkadang semuanya bisa diperbaiki di tahap pertama. Jika ada banyak masalah, Anda harus berurusan dengan mereka dalam proses pengembangan lebih lanjut. Pertama, hilangkan yang kritis, dan yang kurang berbahaya.Pendekatan, gabungan dari tiga versi yang tercantum di atas, memungkinkan Anda untuk: mengurangi jumlah kerentanan potensial pada rilis, meminimalkan utang teknis produk dan mempersingkat waktu yang dibutuhkan untuk aplikasi untuk dijual ke prod.Hasil analisis keamanan yang diterapkan pada tahap awal pengembangan adalah:Alih-alih sebuah kesimpulan
Saat ini, pencarian kerentanan dalam produk perangkat lunak, aplikasi seluler, dan web menjadi bidang aktivitas penting bagi semua pengembang terkemuka. Beberapa orang menganggap analisis kerentanan ahli sebagai andal dan pengujian kepercayaan untuk spesialis internal. Lainnya menggunakan tes pena, pemindai kerentanan, dan penganalisa kode. Yang lain mengintegrasikan alat SAST ke dalam proses pengembangan. Selain itu, direkomendasikan untuk membuat model ancaman dan menganalisis risiko potensial yang terkait dengan pencurian dan distorsi data penting sebelum mulai bekerja.Jangan hanya mengandalkan firewall dan fitur keamanan gratis. Cara yang paling dapat diandalkan adalah dengan menggunakan pendekatan terintegrasi, secara teratur dan teliti memeriksa kode untuk bug dan kerentanan.