TL; DR
Menemukan kerentanan paket npm itu mudah. npm audit Melakukannya dalam empat detik dan memberikan Anda 400 temuan. Bagian tersulit adalah dua pertanyaan berikutnya: mana di antara keduanya yang sebenarnya dapat dijangkau dalam aplikasi Anda, dan peningkatan mana yang memperbaiki masalah tanpa merusak proses build.
- Sebagian besar hal dalam daftar itu bukan masalah Anda. Menerapkan keterjangkauan dan konteks waktu eksekusi pada temuan "kritis" menyisakan sebagian kecil yang tetap kritis. Analisis grafik panggilan adalah yang memberi tahu Anda mana yang masih kritis.
npm audit fix --forcebukanlah strategi perbaikan. Sistem ini menyelesaikan peringatan dengan melompati versi utama, yang merupakan penyebab tugas keamanan menjadi gangguan.- Ketergantungan transisi adalah tempat volume tersebut berada. Anda tidak memilihnya, Anda seringkali tidak dapat meningkatkannya secara langsung, dan mereka mendominasi jumlah temuan.
- Perbaiki sebelum penggabungan, bukan setelah rilis. Sebuah gerbang di CI dan sebuah sistem otomatis. pull request membutuhkan waktu beberapa menit. Perbaikan sementara (patch) produksi membutuhkan waktu satu akhir pekan.
Mengapa Jumlah Temuan Bukanlah Masalahnya?
Setiap proyek Node yang melewati tahun pertamanya menghasilkan pengalaman yang sama. Anda menjalankan pemindaian, Anda mendapatkan ratusan kerentanan paket npm, dan daftarnya sangat panjang sehingga respons yang rasional adalah menutup terminal.
Reaksi itu benar, dan itulah bagian yang tidak nyaman. Hampir tiga perempat basis kode membawa komponen sumber terbuka berisiko tinggi, dan sebagian besar yang dilaporkan oleh pemindai pada hari tertentu memang benar-benar ada di pohon dependensi Anda. Daftarnya akurat. Hanya saja itu bukan antrian pekerjaan.
Perbedaan antara daftar yang akurat dan daftar yang dapat ditindaklanjuti terletak pada konteks, dan semuanya bermuara pada beberapa pertanyaan.
- Apakah kode yang rentan tersebut benar-benar dapat diakses dari aplikasi saya?
- Apakah ada yang memanfaatkan celah ini di lapangan?
- Apakah hal yang terpengaruh itu penting bagi bisnis?
Pemindai yang tidak dapat menjawab pertanyaan-pertanyaan tersebut memberikan Anda inventaris dan menyebutnya sebagai laporan.
Cara Memeriksa Kerentanan pada Paket npm
Ada empat cara praktis untuk memeriksa kerentanan pada paket npm, dan masing-masing menjawab pertanyaan yang berbeda.
Mulailah dengan npm audit Karena tidak memerlukan biaya dan hanya membutuhkan beberapa detik. Jangan berhenti di situ, karena jawaban yang diberikannya adalah "inilah semuanya", dan semuanya bukanlah sebuah rencana.
Satu hal yang perlu diketahui jika Anda mengandalkan umpan saran: Basis Data Saran GitHub memuat saran malware untuk ekosistem npm, tetapi Dependabot sengaja tidak memberikan peringatan untuk itu, karena pengguna hilir biasanya tidak dapat menyelesaikannya dengan melakukan peningkatan versi. Itu adalah celah struktural, bukan pengaturan yang dapat Anda aktifkan. Paket berbahaya membutuhkan kontrol yang berbeda: deteksi pada saat publikasi, bukan setelah pengungkapan. Xygeni's Peringatan Dini Malware Menganalisis paket-paket yang baru diterbitkan di npm, PyPI, Maven, dan registri lainnya pada saat paket tersebut muncul, menggunakan analisis perilaku dan anomali daripada menunggu tanda tangan, dan fitur ini termasuk dalam paket Developer gratis. Kami membahasnya di jahat paket npm.
Filter yang Mengubah 400 Temuan Menjadi Daftar Pendek
Inilah bagian yang mengubah cara kerja sebuah tim.
| Filter | Pertanyaan yang dijawabnya | Apa yang biasanya dihilangkan |
|---|---|---|
| Jangkauan | Apakah eksekusi dalam aplikasi saya benar-benar dapat mencapai fungsi yang rentan? | Potongan terbesar. Sebagian besar peringatan terdapat dalam kode yang tidak pernah dipanggil oleh aplikasi. |
| Ketersediaan eksploitasi | Apakah ada celah keamanan publik yang berfungsi, dan apakah celah keamanan ini sedang dimanfaatkan di lapangan saat ini? | Memisahkan risiko teoretis dari risiko yang dimanfaatkan sebagai senjata. Temuan dengan celah keamanan publik akan didahulukan, terlepas dari skor tingkat keparahannya. |
| Eksploitasi kemungkinan (EPSS) | Seberapa besar kemungkinan eksploitasi di alam liar dalam 30 hari ke depan? | Temuan dengan tingkat keparahan tinggi yang tidak dimanfaatkan siapa pun, yang jarang menjadi fokus pekerjaan minggu ini. |
| Konteks bisnis | Apakah layanan yang terpengaruh itu penting, dan apakah layanan tersebut rentan? | Temuan yang mudah dijangkau dan dimanfaatkan dalam sistem yang tidak menimbulkan risiko berarti. |
| Ketersediaan perbaikan | Apakah ada versi yang dapat mengatasi masalah ini tanpa membuat saya kesulitan? | Memisahkan apa yang dapat Anda selesaikan hari ini dari apa yang membutuhkan solusi alternatif. |
- Jangkauan Ini adalah pemotongan pertama dan terbesar. Kerentanan dalam paket yang Anda andalkan hanya dapat dieksploitasi jika eksekusi benar-benar dapat mencapai fungsi yang rentan. Pelacakan grafik panggilan menjawab hal itu pada tingkat fungsi daripada menebak dari manifes, dan membedakan komponen yang benar-benar Anda gunakan dari komponen yang hanya ada. Analisis keterjangkauan Xygeni mengurangi false positive hingga 70%.
Ketersediaan eksploitasi Ini adalah poin kedua, dan ini adalah fakta, bukan ramalan. Eksploitasi publik yang aktif, atau eksploitasi yang terkonfirmasi di lapangan, mengubah prioritas temuan terlepas dari skor keparahannya. Perbedaan itu telah berhenti menjadi praktik yang baik dan menjadi kewajiban: berdasarkan Undang-Undang Ketahanan Siber, produsen yang mengetahui adanya kerentanan yang dieksploitasi secara aktif dalam produknya memiliki tenggat waktu pelaporan 24 jam. Program yang tidak dapat memisahkan "dieksploitasi secara aktif" dari "CVSS tinggi" tidak dapat memenuhi tenggat waktu tersebut.
Kemungkinan eksploitasi adalah yang ketiga, dan ini adalah pertanyaan yang sama dengan prediksi yang dimasukkan kembali. EPSS menilai probabilitas bahwa kerentanan akan dieksploitasi di dunia nyata dalam 30 hari ke depan, yang merupakan pertanyaan yang sangat berbeda dari seberapa buruk dampaknya jika hal itu terjadi. Skor CVSS yang tinggi dengan skor EPSS yang dapat diabaikan jarang terjadi dalam waktu singkat.
- Konteks bisnis adalah yang ketiga, dan ini adalah yang tidak dapat disediakan oleh umpan generik mana pun. Kerentanan yang dapat dijangkau dan dieksploitasi dalam layanan pembayaran yang menghadap internet bukanlah temuan yang sama dengan CVE yang sama dalam alat pelaporan internal.
Jika diterapkan bersama-sama, filter-filter tersebut secara rutin mengubah daftar yang tidak dibaca siapa pun menjadi daftar yang diselesaikan oleh seseorang. Konteks waktu eksekusi dan ketersediaan biasanya hanya menyisakan sebagian kecil temuan "kritis" yang masih kritis. Xygeni memperlakukan ketersediaan, ketersediaan eksploitasi, EPSS, dan konteks bisnis sebagai tahapan yang dapat dikonfigurasi dalam saluran prioritas, hingga delapan tahapan, sehingga "dapat dijangkau dan dieksploitasi secara aktif" menjadi antrian tetap daripada kueri yang dijalankan seseorang secara manual.
Memperbaiki Kerentanan Paket npm Tanpa Merusak Proses Build
Menemukan celah keamanan adalah bagian yang mudah. Alasan mengapa kerentanan paket npm tetap tidak teratasi selama berbulan-bulan adalah karena memperbaikinya membawa risiko tersendiri, dan para pengembang mengetahuinya.
Pertanyaan terpenting sebelum melakukan peningkatan versi bukanlah "apakah ini menambal CVE". Melainkan tiga pertanyaan sekaligus: kerentanan mana yang hilang dengan versi ini, kerentanan baru apa yang muncul bersamanya, dan apakah lompatan versi ini merusak kode saya.
Xygeni Menampilkan ketiga opsi tersebut untuk setiap dependensi yang rentan, sehingga pilihannya adalah antara opsi yang terlihat, bukan lompatan. Kemudian Autofix menghasilkan pull request Dengan versi yang telah diperbaiki, remediasi massal menerapkan beberapa perbaikan dalam satu tindakan, dan Xygeni Bot berjalan sesuai permintaan. pull requests atau setiap hari, sehingga tumpukan pekerjaan yang tertunda menyusut tanpa perlu dijadwalkan.
Untuk dependensi transisi, di mana Anda tidak dapat begitu saja menaikkan versi yang tidak Anda pilih, output yang berguna adalah jalur peningkatan terpendek dalam pohon yang menyelesaikan peringatan tersebut, bukan peringatan yang memberi tahu Anda bahwa paket empat tingkat di bawahnya rentan.
Sebelum Dikirim: Di Mana Cek Harus Disimpan?
“Sebelum dikirim” adalah klaim penjadwalan, dan itu bermuara pada tiga penempatan.
- Di dalam IDEJadi, pengembang melihat masalah tersebut saat memilih dependensi, yang merupakan momen paling murah untuk mengubahnya.
- pada pull requestDi mana bot memberikan komentar tentang perubahan yang terjadi dan membuka perbaikan, dan di mana gerbang keamanan dapat menggagalkan build jika ditemukan kesalahan di atas ambang batas tertentu. Pembatasan berdasarkan tingkat keparahan saja yang membuat tim menonaktifkan gerbang tersebut. Pembatasan berdasarkan temuan yang dapat dijangkau dan dieksploitasi adalah yang membuat mereka tetap mengaktifkannya.
- Terus menerus setelah dirilis, Karena dependensi yang bersih saat penggabungan menjadi rentan pada hari diterbitkannya pemberitahuan kerentanan. Pemantauan berkelanjutan di seluruh registri adalah cara untuk mendeteksi hal itu, tanpa seseorang harus mengingat untuk melakukan pemindaian ulang.
Dan hasil dari ketiga hal tersebut harus dimasukkan ke dalam satu antrian prioritas bersama dengan milik Anda. SAST, rahasia, dan temuan kontainer, termasuk yang diambil dari alat yang sudah Anda jalankan. A daftar kerentanan Daftar yang tersimpan di konsol tersendiri itu bersaing memperebutkan perhatian dengan pekerjaan yang seharusnya diinformasikan oleh daftar tersebut.
Kirimkan Perbaikannya, Bukan Temuannya
Pemindai yang memberikan Anda 400 kerentanan paket npm belum menyelesaikan pekerjaan. Ia hanya memindahkan pekerjaan tersebut.
Xygeni mempersempit temuan ketergantungan berdasarkan jangkauan, kemungkinan eksploitasi, dan konteks bisnis, menunjukkan apa yang diperbaiki oleh setiap peningkatan dan apa yang mungkin dirusaknya, serta membuka pull request dengan versi yang sudah diperbaiki. Ini berjalan di komputer Anda. pipeline, menghasilkan SBOM dan output VDR di SPDX dan CycloneDX, bukti yang diminta oleh CRA, NIS2, dan DORA, serta menempatkan temuan ketergantungan dalam antrian prioritas yang sama dengan risiko Anda lainnya, termasuk temuan dari pemindai yang tidak Anda ganti.
Mulai gratis dan memindai repositori, atau lihat bagaimana jangkauan mengubah daftar.
FAQ (Pertanyaan Umum)
Bagaimana cara saya memeriksa kerentanan pada paket npm?
Run npm audit Untuk mendapatkan gambaran instan, gunakan alat dengan analisis jangkauan untuk mempersempit daftar temuan di mana kode yang rentan benar-benar dapat dipanggil. Basis data saran seperti OSV dan GitHub Advisory Database berguna untuk memeriksa paket dan versi tertentu.
Is npm audit fix Apakah aman untuk dijalankan?
Versi yang tidak dipaksakan biasanya aman, karena tetap berada dalam rentang yang kompatibel dengan semver. npm audit fix --force Bukan begitu: sistem melakukan peningkatan versi secara bertahap untuk mengatasi pemberitahuan masalah, dan di situlah muncul perubahan yang merusak.
Mengapa saya memiliki begitu banyak kerentanan paket npm?
Karena sebagian besar bersifat transitif. Anda menginstal sejumlah kecil dependensi langsung dan mewarisi ratusan dependensi tidak langsung, masing-masing dengan riwayat saran tersendiri. Volumenya normal. Yang hilang adalah proses triase-nya.
Apa itu analisis keterjangkauan?
Menentukan apakah eksekusi dalam aplikasi Anda benar-benar dapat mencapai fungsi yang rentan dalam sebuah dependensi. Ini adalah pengurangan kebisingan terbesar yang tersedia dalam keamanan dependensi, karena sebagian besar kerentanan yang dilaporkan berada dalam kode yang tidak pernah dipanggil oleh aplikasi Anda.
Apakah saya harus menggunakan CVSS atau EPSS untuk menentukan prioritas?
Keduanya, untuk hal yang berbeda. CVSS menjelaskan seberapa parah kerentanan jika dieksploitasi. EPSS memperkirakan seberapa besar kemungkinan eksploitasi dalam 30 hari ke depan. Tingkat keparahan tanpa kemungkinan akan menghasilkan antrian yang diurutkan berdasarkan sumbu yang salah.
Seberapa sering saya harus memeriksa paket npm untuk kerentanan?
Terus menerus, bukan berdasarkan jadwal. Pemindaian bersih pada hari Senin tidak berarti apa-apa pada hari Rabu jika ada peringatan pada paket yang sudah Anda kirim.
