Praktik terbaik bagi rantai pasokan perangkat lunak yang aman
Open Source ada di mana-mana. Ini ada di banyak basis kode kepemilikan dan proyek komunitas. Untuk organisasi dan individu, pertanyaan hari ini bukan apakah Anda atau tidak menggunakan kode sumber terbuka, tetapi kode sumber terbuka apa yang Anda gunakan, dan berapa banyak.
Jika Anda tidak mengetahui apa yang ada dalam rantai pasokan perangkat lunak Anda, kerentanan hulu di salah satu dependensi Anda bisa fatal, membuat Anda, dan pelanggan Anda, rentan terhadap potensi kompromi. Dalam dokumen ini, kami akan mendalami lebih dalam apa arti istilah "rantai pasokan perangkat lunak", mengapa itu penting, dan bagaimana Anda dapat membantu mengamankan rantai pasokan proyek Anda dengan praktik terbaik.
Dependensi
Istilah rantai pasokan perangkat lunak digunakan untuk merujuk ke semua yang masuk ke perangkat lunak Anda dan dari mana asalnya. Ini adalah dependensi dan properti dependensi Anda yang bergantung pada rantai pasokan perangkat lunak Anda. Dependensi adalah apa yang perlu dijalankan perangkat lunak Anda. Ini bisa berupa kode, biner, atau komponen lain, dan dari mana mereka berasal, seperti repositori atau manajer paket.
Ini termasuk siapa yang menulis kode, ketika dikontribusikan, bagaimana kode tersebut ditinjau untuk masalah keamanan, kerentanan yang diketahui, versi yang didukung, informasi lisensi, dan hampir semua yang menyentuhnya pada setiap titik proses.
Rantai pasokan Anda juga mencakup bagian lain dari tumpukan Anda di luar satu aplikasi, seperti skrip build dan pengemasan Anda atau perangkat lunak yang menjalankan infrastruktur yang diandalkan aplikasi Anda.
Kerentanan
Saat ini, dependensi perangkat lunak bersifat pervasif. Sangat umum bagi proyek Anda untuk menggunakan ratusan dependensi sumber terbuka untuk fungsionalitas yang tidak perlu Anda tulis sendiri. Ini mungkin berarti bahwa sebagian besar aplikasi Anda terdiri dari kode yang tidak Anda tulis.
Kemungkinan kerentanan dalam dependensi pihak ketiga atau sumber terbuka Anda, mungkin dependensi yang tidak dapat Anda kontrol seketat kode yang Anda tulis, yang dapat menciptakan potensi risiko keamanan dalam rantai pasokan Anda.
Jika salah satu dependensi ini memiliki kerentanan, kemungkinan Anda juga memiliki kerentanan. Ini bisa menakutkan karena salah satu dependensi Anda dapat berubah tanpa Anda sadari. Bahkan jika kerentanan ada dalam dependensi saat ini, tetapi tidak dapat dieksploitasi, itu dapat dieksploitasi di masa depan.
Mampu memanfaatkan pekerjaan ribuan pengembang sumber terbuka dan penulis pustaka berarti bahwa ribuan orang asing dapat secara efektif berkontribusi langsung ke kode produksi Anda. Produk Anda, melalui rantai pasokan perangkat lunak Anda, dipengaruhi oleh kerentanan yang tidak dikirim, kesalahan yang tidak bersalah, atau bahkan serangan berbahaya terhadap dependensi.
Penyusupan rantai pasokan
Definisi tradisional dari rantai pasokan berasal dari manufaktur; itu adalah rantai proses yang diperlukan untuk membuat dan menyediakan sesuatu. Ini termasuk perencanaan, pasokan bahan, manufaktur, dan ritel. Rantai pasokan perangkat lunak serupa, kecuali alih-alih bahan, itu adalah kode. Alih-alih manufaktur, ini adalah pengembangan. Alih-alih menggali bijih dari tanah, kode bersumber dari pemasok, komersial atau sumber terbuka, dan, secara umum, kode sumber terbuka berasal dari repositori. Menambahkan kode dari repositori berarti produk Anda mengambil dependensi pada kode tersebut.
Salah satu contoh serangan rantai pasokan perangkat lunak terjadi ketika kode berbahaya sengaja ditambahkan ke dependensi, menggunakan rantai pasokan dependensi tersebut untuk mendistribusikan kode kepada korbannya. Serangan rantai pasokan nyata. Ada banyak metode untuk menyerang rantai pasokan, mulai dari memasukkan kode berbahaya secara langsung sebagai kontributor baru, hingga mengambil alih akun kontributor tanpa memperhatikan orang lain, atau bahkan membahmi kunci penandatanganan untuk mendistribusikan perangkat lunak yang secara resmi bukan bagian dari dependensi.
Serangan rantai pasokan perangkat lunak masuk dan dari dirinya sendiri jarang menjadi tujuan akhir, melainkan ini adalah awal dari kesempatan bagi penyerang untuk memasukkan malware atau menyediakan backdoor untuk akses di masa depan.
Perangkat lunak yang tidak dipaketkan
Penggunaan sumber terbuka saat ini signifikan dan diperkirakan tidak akan melambat dalam waktu dekat. Mengingat bahwa kita tidak akan berhenti menggunakan perangkat lunak sumber terbuka, ancaman terhadap keamanan rantai pasokan adalah perangkat lunak yang belum dikirim. Mengetahui hal itu, bagaimana Anda dapat mengatasi risiko bahwa dependensi proyek Anda memiliki kerentanan?
- Mengetahui apa yang ada di lingkungan Anda. Ini mengharuskan menemukan dependensi Anda dan dependensi transitif apa pun untuk memahami risiko dependensi tersebut seperti kerentanan atau pembatasan lisensi.
- Mengelola dependensi Anda. Ketika kerentanan keamanan baru ditemukan, Anda harus menentukan apakah Anda terpengaruh, dan jika demikian, perbarui ke versi terbaru dan patch keamanan yang tersedia. Ini sangat penting untuk meninjau perubahan yang memperkenalkan dependensi baru atau mengaudit dependensi yang lebih lama secara teratur.
- Pantau rantai pasokan Anda. Ini dengan mengaudit kontrol yang Anda miliki untuk mengelola dependensi Anda. Ini akan membantu Anda memberlakukan kondisi yang lebih ketat untuk dipenuhi untuk dependensi Anda.
Kami akan membahas berbagai alat dan teknik yang disediakan NuGet dan GitHub, yang dapat Anda gunakan hari ini untuk mengatasi potensi risiko di dalam proyek Anda.
Mengetahui apa yang ada di lingkungan Anda
Paket dengan kerentanan yang diketahui
📦 Konsumen Paket | 📦🖊 Pembuat Paket
.NET 8 dan Visual Studio 17.8 menambahkan NuGetAudit, yang akan memperingatkan tentang paket langsung dengan kerentanan yang diketahui selama pemulihan. .NET 9 dan Visual Studio 17.12 mengubah default untuk memperingatkan tentang paket transitif juga.
NuGetAudit memerlukan sumber untuk menyediakan database kerentanan yang diketahui, jadi jika Anda tidak menggunakan nuget.org sebagai sumber paket, Anda harus menambahkannya sebagai sumber audit.
Pada saat NuGet memperingatkan Anda, kerentanan diketahui secara publik. Penyerang dapat menggunakan pengungkapan publik ini untuk mengembangkan serangan bagi target yang belum menambal aplikasi mereka. Oleh karena itu, ketika Anda mendapatkan peringatan bahwa paket yang digunakan proyek Anda memiliki kerentanan yang diketahui, Anda harus dengan cepat mengambil tindakan.
Grafik dependensi NuGet
📦 Konsumen Paket
Anda dapat melihat dependensi NuGet di proyek Anda dengan melihat langsung file proyek masing-masing.
Ini biasanya ditemukan di salah satu dari dua tempat:
packages.config– Terletak di akar proyek.<PackageReference>– Terletak di file proyek.
Bergantung pada metode apa yang Anda gunakan untuk mengelola dependensi NuGet, Anda juga dapat menggunakan Visual Studio untuk melihat dependensi Anda langsung di Penjelajah Solusi atau NuGet Package Manager.
Untuk lingkungan CLI, Anda dapat menggunakan dotnet list package perintah untuk mencantumkan dependensi proyek atau solusi Anda.
Anda juga dapat menggunakan dotnet nuget why perintah untuk memahami mengapa paket transitif (yang tidak direferensikan langsung oleh proyek Anda) disertakan dalam grafik paket proyek Anda.
Untuk informasi selengkapnya tentang mengelola dependensi NuGet, lihat dokumentasi berikut ini.
Grafik dependensi GitHub
📦 Konsumen Paket | 📦🖊 Pembuat Paket
Anda dapat menggunakan grafik dependensi GitHub untuk melihat paket yang bergantung pada proyek Anda dan repositori yang bergantung padanya. Ini dapat membantu Anda melihat kerentanan apa pun yang terdeteksi dalam dependensinya.
Untuk informasi selengkapnya tentang dependensi repositori GitHub, lihat dokumentasi berikut.
Versi dependensi
📦 Konsumen Paket | 📦🖊 Pembuat Paket
Untuk memastikan rantai pasokan dependensi yang aman, Anda ingin memastikan bahwa semua dependensi &alat Anda diperbarui secara teratur ke versi stabil terbaru karena mereka akan sering menyertakan fungsionalitas terbaru dan patch keamanan ke kerentanan yang diketahui. Dependensi Anda dapat menyertakan kode yang Anda andalkan, biner yang Anda gunakan, alat yang Anda gunakan, dan komponen lainnya. Ini mungkin termasuk:
Mengelola dependensi Anda
Dependensi NuGet yang tidak digunakan lagi dan rentan
📦 Konsumen Paket | 📦🖊 Pembuat Paket
Anda dapat menggunakan CLI dotnet untuk mencantumkan dependensi yang diketahui tidak digunakan lagi atau rentan yang mungkin Anda miliki di dalam proyek atau solusi Anda.
Anda dapat menggunakan perintah dotnet list package --deprecated atau dotnet list package --vulnerable untuk memberi Anda daftar penghentian atau kerentanan yang diketahui.
NuGetAudit dapat memperingatkan Anda tentang dependensi rentan yang diketahui, dan diaktifkan secara default ketika sumber menyediakan database kerentanan.
Dependensi rentan GitHub
📦 Konsumen Paket | 📦🖊 Pembuat Paket
Jika proyek Anda dihosting di GitHub, Anda dapat memanfaatkan GitHub Security untuk menemukan kerentanan dan kesalahan keamanan dalam proyek Anda dan Dependabot akan memperbaikinya dengan membuka permintaan pull terhadap basis kode Anda.
Menangkap dependensi yang rentan sebelum diperkenalkan adalah salah satu tujuan dari gerakan "Shift Left" . Mampu memiliki informasi tentang dependensi Anda seperti lisensi mereka, dependensi transitif, dan usia dependensi membantu Anda melakukan hal itu.
Untuk informasi selengkapnya tentang pemberitahuan Dependabot & pembaruan keamanan, lihat dokumentasi berikut ini.
Umpan NuGet
📦 Konsumen Paket
Gunakan sumber paket yang Anda percayai. Saat menggunakan beberapa umpan sumber NuGet publik & privat, paket dapat diunduh dari salah satu umpan. Untuk memastikan build Anda dapat diprediksi dan aman dari serangan yang diketahui seperti Kebingungan Dependensi, mengetahui umpan spesifik apa yang berasal dari paket Anda adalah praktik terbaik. Anda dapat menggunakan umpan tunggal atau umpan privat dengan kemampuan upstreaming untuk perlindungan.
Untuk informasi selengkapnya untuk mengamankan umpan paket Anda, lihat 3 Cara untuk Mengurangi Risiko Saat Menggunakan Umpan Paket Privat.
Saat menggunakan umpan privat, lihat praktik terbaik keamanan untuk mengelola kredensial.
Kebijakan kepercayaan klien
📦 Konsumen Paket
Ada kebijakan yang dapat Anda pilih di mana Anda memerlukan paket yang Anda gunakan untuk ditandatangani. Ini memungkinkan Anda mempercayai penulis paket, selama penulis ditandatangani, atau mempercayai paket jika dimiliki oleh pengguna atau akun tertentu yang ditandatangani oleh NuGet.org.
Untuk mengonfigurasi kebijakan kepercayaan klien, lihat dokumentasi berikut.
Kunci file
📦 Konsumen Paket
Kunci file yang menyimpan hash konten paket Anda. Jika hash konten paket yang ingin Anda instal cocok dengan file kunci, itu akan memastikan pengulangan paket.
Untuk mengaktifkan file kunci, lihat dokumentasi berikut.
Pemetaan Sumber Paket
📦 Konsumen Paket
Pemetaan Sumber Paket memungkinkan Anda untuk secara terpusat mendeklarasikan sumber mana yang harus dipulihkan setiap paket dalam solusi Anda dalam file nuget.config Anda.
Untuk mengaktifkan pemetaan sumber paket, lihat dokumentasi berikut.
Mengamankan komputer
Izin direktori
📦 Konsumen Paket
Di Windows dan Mac, dan beberapa distribusi Linux, direktori beranda akun pengguna bersifat pribadi secara default. Namun, beberapa distribusi Linux membuat direktori pengguna dapat dibaca oleh akun lain di komputer yang sama secara default. Selain itu, ada beberapa opsi konfigurasi untuk mengalihkan folder paket global NuGet dan cache HTTP ke lokasi non-default. Solusi, proyek, dan repositori mungkin juga dibuat di luar direktori beranda pengguna.
Jika Anda menggunakan paket apa pun yang tidak ada di nuget.org, maka jika ada akun lain di komputer dapat membaca paket global NuGet atau direktori cache HTTP, atau direktori output build proyek, maka paket ini mungkin diungkapkan kepada orang-orang yang seharusnya tidak memiliki akses ke paket tersebut.
Di Linux, dotnet nuget update source akan mengubah izin file nuget.config untuk membuatnya hanya dapat dibaca oleh pemilik file.
Namun, jika Anda mengedit file nuget.config dengan cara lain, dan file berada di lokasi yang dapat dibaca akun lain, mungkin ada pengungkapan informasi tentang URL sumber paket atau kredensial sumber paket.
Anda harus memastikan file nuget.config tidak dapat dibaca oleh pengguna lain dari komputer yang sama.
Solusi dalam direktori unduhan
📦 Konsumen Paket
Perawatan ekstra harus diambil jika mengerjakan solusi atau proyek di direktori unduhan Anda. NuGet akan mengakumulasi pengaturan dari beberapa file konfigurasi, dan MSBuild biasanya akan mengimpor Directory.Build.props, Directory.NuGet.props, Directory.Build.targets, dan berpotensi file lainnya, dari direktori induk apa pun, hingga akar sistem file.
Folder unduhan memiliki risiko tambahan, karena biasanya lokasi default browser web akan mengunduh file dari internet
Membangun Agen
📦 Konsumen Paket
Agen build (agen CI) yang tidak diatur ulang ke status awal setelah setiap build memiliki beberapa risiko yang harus dipertimbangkan.
Untuk mempelajari cara aman mengelola kredensial, lihat dokumen tentang mengonsumsi paket dari umpan terautentikasi.
Untuk mempelajari tentang memodifikasi direktori tempat NuGet menyimpan data, lihat dokumen tentang mengelola paket global, cache, dan folder sementara. Direktori ini harus dikonfigurasi ke direktori yang dibersihkan agen CI setelah setiap build.
Perhatikan bahwa paket apa pun yang digunakan oleh proyek Anda mungkin tersisa di direktori output build proyek Anda. Jika proyek Anda menggunakan paket dari sumber terautentikasi, maka pengguna lain dari agen CI yang sama mungkin mendapatkan akses tidak sah ke rakitan paket. Oleh karena itu, Anda juga harus membersihkan repositori di akhir build Anda, bahkan ketika build gagal atau dibatalkan.
Memantau rantai pasokan Anda
Pemindaian rahasia GitHub
📦🖊 Pembuat Paket
GitHub memindai repositori untuk kunci NUGet API untuk mencegah penggunaan rahasia penipuan yang tidak sengaja dilakukan.
Untuk mempelajari selengkapnya tentang pemindaian rahasia, lihat Tentang pemindaian rahasia.
Penandatanganan Paket Penulis
📦🖊 Pembuat Paket
Penandatanganan penulis memungkinkan penulis paket untuk memberi stempel identitas mereka pada paket dan bagi konsumen untuk memverifikasi bahwa itu berasal dari Anda. Ini melindungi Anda dari perusakan konten dan berfungsi sebagai satu sumber kebenaran tentang asal paket dan keaslian paket. Ketika dikombinasikan dengan kebijakan kepercayaan klien, Anda dapat memverifikasi paket berasal dari penulis tertentu.
Untuk menulis menandatangani paket, lihat Menandatangani paket.
Build yang Dapat Direproduksi
📦🖊 Pembuat Paket
Build yang dapat direproduksi membuat biner yang identik byte-for-byte setiap kali Anda membangunnya, dan berisi tautan kode sumber dan metadata kompilator yang memungkinkan konsumen paket untuk membuat ulang biner secara langsung dan memvalidasi bahwa lingkungan build belum disusupi.
Untuk mempelajari selengkapnya tentang build yang dapat direproduksi, lihat Membuat Paket dengan Tautan Sumber dan spesifikasi Validasi Build yang Dapat Direproduksi.
Autentikasi Dua Faktor (2FA)
📦🖊 Pembuat Paket
Setiap akun di nuget.org mengaktifkan 2FA. Ini menambahkan lapisan keamanan tambahan saat masuk ke akun GitHub atau akun NuGet.org Anda.
Reservasi prefiks ID paket
📦🖊 Pembuat Paket
Untuk melindungi identitas paket Anda, Anda dapat memesan awalan ID paket dengan namespace layanan Anda masing-masing untuk mengaitkan pemilik yang cocok jika awalan ID paket Anda benar termasuk dalam kriteria yang ditentukan.
Untuk mempelajari tentang memesan awalan ID, lihat Reservasi awalan ID paket.
Menghentikan dan membatalkan daftar paket yang rentan
📦🖊 Pembuat Paket
Untuk melindungi ekosistem paket .NET ketika Anda mengetahui kerentanan dalam paket yang telah Anda tulis, lakukan yang terbaik untuk menghentikan dan membatalkan daftar paket sehingga tersembunyi dari pengguna yang mencari paket. Jika Anda mengkonsumsi paket yang tidak digunakan lagi dan tidak terdaftar, Anda harus menghindari penggunaan paket.
Untuk mempelajari cara menghentikan dan membatalkan daftar paket, lihat dokumentasi berikut tentang paket yang tidak digunakan lagi dan tidak masuk daftar.
Pertimbangkan juga untuk melaporkan yang diketahui ke Database Penasihat GitHub.
Ringkasan
Rantai pasokan perangkat lunak Anda adalah apa pun yang masuk atau memengaruhi kode Anda. Meskipun kompromi rantai pasokan nyata dan tumbuh dalam popularitas, mereka masih jarang; jadi hal terpenting yang dapat Anda lakukan adalah melindungi rantai pasokan Anda dengan menyadari dependensi Anda, mengelola dependensi Anda dan memantau rantai pasokan Anda.
Anda belajar tentang berbagai metode yang disediakan NuGet dan GitHub yang tersedia untuk Anda saat ini agar lebih efektif dalam melihat, mengelola, dan memantau rantai pasokan Anda.
Untuk informasi selengkapnya tentang mengamankan perangkat lunak dunia, lihat Laporan Keamanan Status Octoverse 2020.