Program Menghilangkan Sensor Pada Video
Sibyl Piccuillo
Publikasi pemerintah Amerika Serikat NISTIR 8397: Pedoman tentang Standar Minimum untuk Verifikasi Pengembang Perangkat Lunak berisi panduan yang sangat baik tentang cara membangun perangkat lunak yang andal dan aman dalam bahasa pemrograman apa pun.
Pemodelan ancaman harus menjadi salah satu bagian dari Siklus Hidup Pengembangan Keamanan (SDL) dinamis Anda. Kami menyarankan bahwa untuk produk Anda secara keseluruhan, untuk fitur tertentu, atau untuk perubahan desain atau implementasi utama:
Pertama, pahami pendekatan pengembangan tim. Untuk tim dengan alur kerja pengembangan tangkas yang mendorong puluhan perubahan ke produksi setiap hari, tidak praktis atau masuk akal untuk memerlukan pembaruan model ancaman untuk setiap perubahan fungsional. Sebagai gantinya, sejak awal saat menulis persyaratan fungsional fitur, pertimbangkan untuk menyertakan kuesioner persyaratan keamanan. Kuesioner harus berfokus pada pertanyaan spesifik tentang fitur untuk menentukan aspek masa depan SDL Anda. Misalnya:
Hasil kuesioner keamanan menginformasikan teknik SDL mana yang akan diikat ke unit pengembangan mana. Ini juga menginformasikan mitra pengembangan garis waktu SDL fitur, sehingga mereka dapat berkolaborasi pada waktu yang tepat.
Kedua, pertahankan inventaris aset yang kuat dari produk yang anda tugaskan untuk menilai. Produk tumbuh dalam kompleksitas. Adalah umum untuk menulis perangkat lunak untuk perangkat yang terhubung yang memiliki:
Dalam produk yang kompleks seperti itu, pemodelan ancaman sangat penting. Memiliki inventori aset yang kuat memungkinkan Anda melihat seluruh tumpukan produk untuk melihat gambar lengkap, dan untuk melihat tempat-tempat utama yang perlu dievaluasi tentang bagaimana fitur baru atau yang diubah memengaruhi keamanan produk.
Pertahankan sistem inventaris aset yang tepat yang menangkap dan mempertahankan artefak keamanan dan output tinjauan model ancaman. Memiliki inventori yang jelas memungkinkan Anda mengevaluasi output ulasan untuk pola, dan membuat keputusan cerdas tentang cara menyempurnakan program keamanan produk secara teratur.
Cobalah untuk menggabungkan kuesioner keamanan fase persyaratan, hasil pemodelan ancaman, hasil penilaian keamanan, dan hasil dari alat otomatis. Menggabungkannya memungkinkan Anda mengotomatiskan sudut pandang risiko relatif dari produk tertentu, idealnya sebagai "dasbor," untuk memberi tahu tim keamanan Anda apa yang harus difokuskan untuk mendapatkan nilai terbaik dari pemodelan ancaman.
Pengujian otomatis adalah cara penting untuk memastikan kualitas dan keamanan kode Anda. Ini adalah bagian integral dalam mendukung area lain yang disebutkan dalam dokumen ini, seperti Pemodelan Ancaman. Ketika dipasangkan dengan praktik pengodean aman lainnya, mereka membantu melindungi dari bug dan kerentanan yang dimasukkan ke dalam basis kode.
Pengujian harus dapat diandalkan, konsisten, dan terisolasi. Pengujian ini harus mencakup sebanyak mungkin kode. Semua fitur baru dan perbaikan bug harus memiliki pengujian yang sesuai untuk memastikan keamanan jangka panjang dan keandalan kode jika memungkinkan. Jalankan pengujian otomatis secara teratur dan di lingkungan sebanyak mungkin, untuk memastikan pengujian dijalankan dan mencakup semua area:
Keandalan pengujian adalah bagian penting untuk menjaga efektivitas rangkaian pengujian. Kegagalan pengujian harus ditetapkan dan diselidiki, dengan potensi masalah keamanan mendapatkan prioritas tinggi dan diperbarui dalam jangka waktu yang diminta dan ditentukan sebelumnya. Mengabaikan kegagalan pengujian seharusnya bukan praktik umum, tetapi harus memerlukan pembenaran dan persetujuan yang kuat. Kegagalan pengujian karena masalah dalam rangkaian pengujian itu sendiri harus diperlakukan sama dengan kegagalan lain, untuk mencegah selang dalam cakupan di mana masalah produk dapat terlewatkan.
Ada beberapa jenis pengujian otomatis, dan meskipun tidak semua berlaku untuk semua aplikasi, rangkaian pengujian yang baik berisi pilihan beberapa jenis yang berbeda. Kasus Pengujian Berbasis Kode seperti pengujian unit adalah yang paling umum dan paling integral, berlaku untuk semua aplikasi dan sengaja mencakup jalur kode sebanyak mungkin untuk kebenaran. Pengujian ini harus kecil, cepat, dan tidak memengaruhi status mesin, sehingga rangkaian lengkap pengujian dapat dijalankan dengan cepat dan sering. Jika memungkinkan, jalankan pengujian pada banyak komputer yang memiliki pengaturan perangkat keras yang berbeda untuk menangkap masalah yang tidak dapat direproduksi pada satu jenis komputer.
Visual Studio Test Explorer secara asli mendukung banyak kerangka kerja pengujian C++ paling populer, dan memiliki opsi untuk menginstal ekstensi untuk kerangka kerja lainnya. Fleksibilitas ini berguna untuk menjalankan subset pengujian yang mencakup kode yang sedang Anda kerjakan, dan memudahkan untuk men-debug kegagalan pengujian saat muncul. Visual Studio juga memudahkan untuk menyiapkan rangkaian pengujian baru untuk proyek yang ada, dan menyediakan alat bermanfaat seperti CodeLens untuk mempermudah pengelolaan pengujian ini. Untuk informasi selengkapnya tentang menulis, menjalankan, dan mengelola pengujian C/C++ dengan Visual Studio, lihat Menulis pengujian unit untuk C/C++ - Visual Studio (Windows).
Pengujian yang melakukan verifikasi lebih dalam dan membutuhkan waktu lebih lama untuk dijalankan, seperti analisis statis, deteksi komponen, dan sebagainya, adalah kandidat yang baik untuk pengujian permintaan pull atau pengujian integrasi berkelanjutan. Azure DevOps dan GitHub Actions memudahkan untuk menjalankan validasi secara otomatis dan memblokir pemeriksaan kode jika validasi gagal. Penegakan otomatis membantu memastikan bahwa semua kode yang dicek masuk aman berdasarkan pemeriksaan yang lebih ketat ini yang dijalankan. Azure Pipelines dan Validasi Build Azure DevOps dijelaskan di sini:
Ringkasan Analisis kode statis/biner harus diaktifkan secara default, agar aman secara default. Analisis statis menganalisis program untuk kebijakan keselamatan dan keamanan yang diperlukan pada saat sedang dibangun, bukan pada waktu eksekusi ketika eksploitasi dapat terjadi pada komputer pelanggan. Analisis statis dapat menganalisis program dalam bentuk kode sumber atau dalam bentuk yang dapat dieksekusi yang dikompilasi.
Di Azure dan GitHub CI/CD Microsoft merekomendasikan untuk selalu mengaktifkan kode sumber dan analisis statis biner dalam skenario CI/CD rilis. Jalankan analisis sumber segera pada komputer pengembang lokal, atau setidaknya untuk setiap permintaan penerapan atau penarikan, untuk menangkap bug sumber sedini mungkin dan meminimalkan biaya keseluruhan. Bug tingkat biner cenderung diperkenalkan lebih lambat, sehingga mungkin cukup untuk menjalankan analisis biner dalam skenario CI/CD prarilis yang lebih jarang (seperti build malam atau mingguan).
Jangan hardcode rahasia dalam perangkat lunak. Anda dapat menemukan dan menghapus rahasia dari kode sumber secara efisien dengan menggunakan alat andal yang dapat memindai seluruh basis kode sumber Anda. Setelah Anda menemukan rahasia, pindahkan ke tempat yang aman mengikuti pedoman untuk penyimpanan yang aman dan penggunaan rahasia.
"Rahasia" berarti entitas yang menetapkan identitas dan menyediakan akses ke sumber daya, atau yang digunakan untuk menandatangani atau mengenkripsi data sensitif. Contohnya termasuk kata sandi, kunci penyimpanan, string koneksi, dan kunci privat. Sangat menggoda untuk menyimpan rahasia dalam produk perangkat lunak sehingga mereka dapat dengan mudah diperoleh ketika diperlukan oleh perangkat lunak. Namun, rahasia hardcoded ini dapat menyebabkan insiden keamanan yang parah atau bencana karena mudah ditemukan dan dapat digunakan untuk membahayakan layanan dan data Anda.
Rahasia yang dikodekan secara permanen dalam kode sumber (sebagai teks biasa atau blob terenkripsi) adalah kerentanan keamanan. Berikut adalah panduan umum tentang cara menghindari rahasia dalam kode sumber:
Komponen warisan produk Anda mungkin berisi rahasia hardcoded tersembunyi dalam kode sumbernya. Terkadang rahasia dari komputer desktop pengembang dapat merayap ke cabang jarak jauh dan bergabung ke cabang rilis, membocorkan rahasia secara tidak sengaja. Untuk menemukan rahasia yang mungkin bersembunyi di kode sumber, Anda dapat menggunakan alat yang dapat memindai kode Anda untuk rahasia yang dikodekan secara permanen:
Ketika kredensial ditemukan dalam kode sumber Anda, kebutuhan mendesak segera adalah untuk membatalkan kunci yang terekspos dan melakukan analisis risiko berdasarkan paparan. Bahkan jika sistem Anda perlu tetap berjalan, Anda dapat mengaktifkan manajer rahasia untuk remediasi menggunakan langkah-langkah berikut:
Hapus rahasia yang sekarang tidak valid dari kode sumber Anda, dan ganti dengan metode alternatif yang tidak mengekspos rahasia langsung dalam kode sumber Anda. Cari peluang untuk menghilangkan rahasia jika memungkinkan dengan menggunakan alat seperti Microsoft Azure ACTIVE Directory. Anda dapat memperbarui metode autentikasi untuk memanfaatkan identitas terkelola melalui Azure Active Directory). Hanya gunakan penyimpanan yang disetujui untuk menyimpan dan mengelola rahasia seperti Azure Key Vault (AKV). Untuk informasi selengkapnya, lihat:
Pengguna AzDO dapat memindai kode mereka melalui GitHub Advanced Security untuk Azure DevOps (GHAzDO). GHAzDO juga memungkinkan pengguna untuk mencegah paparan rahasia dengan mengaktifkan Perlindungan Push pada repositori mereka, menangkap potensi paparan sebelum mereka pernah bocor. Untuk informasi selengkapnya tentang cara mendeteksi rahasia yang dikodekan secara permanen dalam kode di Azure DevOps, lihat Pemindaian Rahasia untuk Github Advanced Security untuk Azure DevOps di setiap tautan berikut:
GitHub Advanced Security untuk Azure DevOps membawa solusi pemindaian rahasia, pemindaian dependensi, dan pemindaian kode CodeQL yang sama yang sudah tersedia untuk pengguna GitHub dan secara asli mengintegrasikannya ke Azure DevOps untuk melindungi Azure Repos and Pipelines Anda.
7fc3f7cf58