Menyiapkan pemindaian dependensi

Pemindaian dependensi di GitHub Advanced Security untuk Azure DevOps mendeteksi komponen sumber terbuka yang digunakan dalam kode sumber Anda dan mendeteksi apakah ada kerentanan terkait. Setiap kerentanan yang ditemukan dari komponen sumber terbuka ditandai sebagai pemberitahuan. Anda akan memerlukan GitHub Advanced Security untuk Azure DevOps atau, jika Anda menggunakan pengalaman mandiri, GitHub Code Security untuk Azure DevOps diaktifkan.

GitHub Advanced Security untuk Azure DevOps berfungsi dengan Azure Repos. Untuk menggunakan GitHub Advanced Security dengan repositori GitHub, lihat GitHub Advanced Security.

Prasyarat

Kategori	Persyaratan
Izin	- Untuk melihat ringkasan semua peringatan untuk repositori: izin Kontributor untuk repositori. - Untuk mengabaikan peringatan di Advanced Security: izin administrator proyek . - Untuk mengelola izin di Keamanan Tingkat Lanjut: Anggota grup Administrator Koleksi Proyek atau Pengaturan Keamanan Lanjutan: mengelola pengaturan dengan izin yang diatur pada Izinkan.
Tugas alur	- Dalam Pengaturan organisasi>Alur kerja>>, pastikan Nonaktifkan tugas Marketplace dinonaktifkan. Pemindaian kode dan pemindaian dependensi bergantung pada tugas Azure Pipelines yang didistribusikan melalui Visual Studio Marketplace. Jika Anda menonaktifkan tugas Marketplace, penyiapan default tidak dapat menjalankan pemindaian, dan alur penyiapan tingkat lanjut mungkin melaporkan bahwa tugas hilang. Untuk informasi selengkapnya, lihat Manajemen tugas.

Kategori

Persyaratan

Izin

- Untuk melihat ringkasan semua peringatan untuk repositori: izin Kontributor untuk repositori.
- Untuk mengabaikan peringatan di Advanced Security: izin administrator proyek .
- Untuk mengelola izin di Keamanan Tingkat Lanjut: Anggota grup Administrator Koleksi Proyek atau Pengaturan Keamanan Lanjutan: mengelola pengaturan dengan izin yang diatur pada Izinkan.

Tugas alur

- Dalam Pengaturan organisasi>Alur kerja>>, pastikan Nonaktifkan tugas Marketplace dinonaktifkan. Pemindaian kode dan pemindaian dependensi bergantung pada tugas Azure Pipelines yang didistribusikan melalui Visual Studio Marketplace. Jika Anda menonaktifkan tugas Marketplace, penyiapan default tidak dapat menjalankan pemindaian, dan alur penyiapan tingkat lanjut mungkin melaporkan bahwa tugas hilang. Untuk informasi selengkapnya, lihat Manajemen tugas.

Untuk informasi selengkapnya tentang izin Keamanan Tingkat Lanjut, lihat Mengelola izin Keamanan Tingkat Lanjut.

Tentang pemindaian dependensi

Pemindaian dependensi menghasilkan pemberitahuan untuk komponen sumber terbuka apa pun, langsung atau transitif, yang ditemukan rentan yang bergantung pada kode Anda. Kerentanan langsung adalah pustaka yang langsung digunakan oleh kode Anda. Dependensi transitif adalah pustaka atau perangkat lunak lain yang digunakan oleh dependensi langsungnya.

Ketahui tentang pendeteksian pemindaian dependensi

Rekam jepret baru komponen Anda disimpan setiap kali grafik dependensi untuk repositori berubah, dan setelah alur yang berisi tugas pemindaian dependensi dijalankan.

Untuk setiap komponen rentan yang terdeteksi sedang digunakan, komponen dan kerentanannya dicantumkan dalam log build dan ditampilkan sebagai peringatan di tab Keamanan Lanjutan. Hanya advisori yang ditinjau oleh GitHub dan ditambahkan ke GitHub Advisory Database yang akan membuat peringatan pemindaian dependensi. Log build berisi tautan ke peringatan individual untuk investigasi lebih lanjut. Untuk informasi selengkapnya tentang detail peringatan, lihat Memperbaiki peringatan pemindaian dependensi.

Log build juga berisi informasi dasar tentang setiap kerentanan yang terdeteksi. Detail ini termasuk tingkat keparahan, komponen yang terpengaruh, judul kerentanan, dan CVE terkait.

Note

Pemindaian dependensi mengharuskan menjalankan alur yang dikonfigurasi dengan AdvancedSecurity-Dependency-Scanning@1 tugas atau menjalankan alur di repositori dengan pengaturan default pemindaian dependensi diaktifkan. Mengaktifkan Keamanan Tingkat Lanjut atau Keamanan Kode tidak menjalankan pemindaian dependensi secara otomatis.

Untuk daftar ekosistem dan versi komponen yang didukung, lihat Ekosistem paket yang didukung.

Pelajari tentang peringatan pemindaian dependensi

Tab Keamanan Tingkat Lanjut di Repositori di Azure DevOps adalah hub untuk melihat pemberitahuan keamanan Anda, yang secara default menunjukkan pemberitahuan pemindaian dependensi. Anda dapat memfilter menurut cabang, alur, paket, tingkat keparahan, cakupan dependensi, dan persentil Sistem Penilaian Prediksi Eksploitasi (EPSS). Anda dapat memilih pemberitahuan untuk detail selengkapnya, termasuk panduan remediasi. Saat ini, pusat peringatan tidak menampilkan peringatan untuk pemindaian yang telah diselesaikan pada cabang PR.

Ketika paket yang rentan terdeteksi di repositori Anda, memperbaiki pemberitahuan pemindaian dependensi biasanya melibatkan peningkatan ke versi paket yang lebih tinggi atau menghapus paket yang menyinggung. Saran ini berlaku untuk dependensi langsung dan transitif (atau tidak langsung). Tampilan bawaan di tab Keamanan Tingkat Lanjut adalah peringatan aktif untuk cabang bawaan repositori Anda.

Tidak ada efek pada hasil jika pipeline atau cabang diubah namanya - mungkin dibutuhkan waktu hingga 24 jam sebelum nama baru ditampilkan.

Memprioritaskan pemberitahuan berdasarkan cakupan dependensi

Cakupan dependensi menunjukkan apakah dependensi yang rentan digunakan pada runtime atau hanya selama pengembangan. Pada halaman Pemberitahuan , gunakan filter Cakupan pilihan tunggal untuk menampilkan pemberitahuan dependensi Runtime atau Pengembangan .

Dependensi khusus pengembangan menampilkan lencana Pengembangan dalam daftar pemberitahuan. Detail pemberitahuan juga menampilkan cakupan dependensi saat hasil pemindaian menyertakan metadata ini. Jika metadata lingkup tidak tersedia, Advanced Security tidak menampilkan lencana dan detail lingkup tanpa mengubah perilaku peringatan lainnya.

Cakupan berlaku untuk hasil dependensi tertentu, bukan untuk paket secara global. Paket yang sama dapat memiliki cakupan yang berbeda ketika terdeteksi di jalur atau proyek dependensi lain.

Memprioritaskan pemberitahuan dengan EPSS

Sistem Penilaian Prediksi Eksploitasi (EPSS) memperkirakan kemungkinan kerentanan perangkat lunak akan dieksploitasi di alam liar. EPSS memberikan skor dan persentil; Keamanan Tingkat Lanjut menampilkan persentil untuk pemberitahuan pemindaian dependensi. Persentil yang lebih tinggi menunjukkan bahwa kerentanan tersebut memiliki peringkat yang lebih tinggi dalam kemungkinan eksploitasi yang diperkirakan dibandingkan dengan kerentanan lain yang telah dinilai.

Gunakan persentil EPSS bersama dengan tingkat keparahan saat Anda memprioritaskan remediasi. Tingkat keparahan mencerminkan dampak potensial dari kerentanan, sementara EPSS membantu Anda menilai seberapa besar kemungkinan eksploitasi. Pada halaman Pemberitahuan , gunakan filter persentil EPSS untuk menentukan rentang persentil dan fokus pada pemberitahuan dependensi yang memenuhi rentang. Batas rentang bersifat inklusif dan digabungkan dengan filter lain yang Anda terapkan.

Filter persentil EPSS mengelompokkan kerentanan ke dalam kategori berikut:

Persentil EPSS	Kategori
90-100%	Sangat tinggi
70-90%	Tinggi
50-70%	Menengah
0-50%	Kurang Penting

Data EPSS tidak tersedia untuk setiap advisori. Saat pemberitahuan tidak memiliki metadata EPSS, Keamanan Tingkat Lanjut tidak menampilkan persentil EPSS dalam detail pemberitahuan. Metadata yang hilang tidak memengaruhi tingkat keparahan, status, atau panduan remediasi peringatan.

Status pemberitahuan secara otomatis diperbarui ke Closed ketika komponen yang rentan tidak lagi terdeteksi dalam build terbaru untuk alur apa pun tempat tugas pemindaian dependensi diinstal. Untuk melihat pemberitahuan yang diselesaikan, gunakan State filter di toolbar utama dan pilih Closed.

Jika Anda menonaktifkan Keamanan Tingkat Lanjut untuk repositori, Anda akan kehilangan akses ke hasil di tab Keamanan Tingkat Lanjut dan tugas build. Tugas build tetap berhasil, tetapi hasil apa pun dari build yang dijalankan dengan tugas saat Keamanan Tingkat Lanjut dimatikan akan disembunyikan dan tidak dipertahankan.

Detail peringatan

Anda juga dapat menelusuri detail tentang pemberitahuan dengan mengklik pemberitahuan tertentu, dan panduan remediasi.

Bagian	Penjelasan
Ruang lingkup	Cakupan menunjukkan apakah dependensi yang rentan digunakan pada runtime atau hanya selama pengembangan. Informasi ini hanya muncul ketika metadata cakupan dependensi tersedia untuk hasilnya.
Persentil EPSS	Persentil EPSS menunjukkan peringkat kerentanan berdasarkan kemungkinan eksploitasi yang diprediksi relatif terhadap kerentanan lain yang dinilai. Baris ini hanya muncul jika metadata EPSS tersedia untuk advisori tersebut.
Rekomendasi	Teks rekomendasi berasal langsung dari penyedia data kerentanan kami, Database Penasihat GitHub. Biasanya, panduan menyarankan peningkatan komponen yang diidentifikasi ke versi yang tidak rentan.
Lokasi	Bagian Lokasi merinci jalur tempat tugas pemindaian dependensi menemukan komponen yang rentan digunakan. Jika file dapat ditelusuri dari build scan yang mendasarinya ke file sumber yang telah dikomitkan, kartu Lokasi akan muncul sebagai tautan yang dapat diklik. Jika file dihasilkan sebagai bagian dari build (misalnya, artefak build), tautannya tidak dapat diklik. Tinjau log build untuk lebih memahami bagaimana komponen dibawa ke dalam build.
Deskripsi	Deskripsi ini diambil dari advisori GitHub.

Deteksi

Alur yang tercantum di bawah tab Deteksi adalah alur tempat komponen rentan ditemukan. Setiap baris menampilkan rincian build terbaru dari pipeline yang terpengaruh dan tanggal paket pertama kali diperkenalkan. Jika paket yang rentan diperbaiki di beberapa alur tetapi tidak semua, Anda akan melihat sebagian baris tetap.

Setelah pemberitahuan diselesaikan, pemberitahuan secara otomatis berpindah ke Closed status dan alur eksekusi terbaru di bawah tab Deteksi menampilkan tanda centang hijau, yang berarti bahwa kode yang berisi komponen yang diperbarui dijalankan dalam alur tersebut:

Tingkat keparahan

Database Penasihat GitHub menyediakan skor CVSS, yang kemudian diterjemahkan ke dalam tingkat keparahan rendah, sedang, tinggi, atau kritis untuk pemberitahuan melalui panduan berikut:

Skor CVSS	Tingkat keparahan
1.0 < Skor < 4.0	Kurang Penting
4.0 < Skor < 7.0	Menengah
7.0 < Skor < 9.0	Tinggi
Skor >= 9,0	Kritis

Mencari detail

Dua bagian biasanya terdapat di bawah Detail temuan: paket yang rentan dan dependensi akar. Paket yang rentan adalah komponen yang berpotensi rentan. Bagian dependensi akar berisi komponen tingkat atas yang bertanggung jawab atas rantai dependensi yang mengarah pada kerentanan.

Jika paket yang rentan hanya direferensikan sebagai dependensi langsung, Anda hanya melihat bagian "paket yang rentan".

Jika paket yang rentan direferensikan baik sebagai dependensi langsung dan transitif, paket ditampilkan di bagian "paket rentan" dan "dependensi akar".

Jika paket yang rentan hanya dirujuk sebagai dependensi transitif, paket ditampilkan di bagian "paket rentan", dan dependensi akar yang mereferensikan paket yang rentan ditampilkan di bagian "dependensi akar".

Mengelola pemberitahuan pemindaian dependensi

Menampilkan pemberitahuan untuk repositori

Secara default, halaman pemberitahuan menunjukkan hasil pemindaian dependensi untuk cabang default repositori.

Status peringatan mencerminkan keadaan pada cabang default dan pipeline yang terakhir dijalankan, bahkan jika peringatan tersebut ada pada cabang dan pipeline lain.

Pembersihan otomatis peringatan dari konfigurasi jalur kedaluarsa

Pembersihan otomatis menyembunyikan hasil pemindaian lama saat konfigurasi pipeline mereka berhenti berjalan. Ini tidak menyembunyikan pemberitahuan hanya karena pemberitahuan atau cabangnya berusia lebih dari 90 hari. Perilaku ini berlaku untuk pemindaian kode dan pemberitahuan pemindaian dependensi.

Apa yang membuat konfigurasi kedaluarsa?

Pembersihan menggunakan waktu penyelesaian terbaru dari fase pipeline yang terkait dengan konfigurasi pemindaian. Fase menjadi kedaluwarsa ketika waktu penyelesaian tersebut lebih dari 90 hari yang lalu, secara bawaan.

Keamanan Tingkat Lanjut menandai rekaman fase alur sebagai tidak aktif tetapi mempertahankan hasilnya. Kemudian, tampilan pemberitahuan menyembunyikan pemberitahuan hanya ketika semua hasil terbaru yang terkait dengan pemberitahuan tersebut berasal dari konfigurasi kedaluarsa. Jika salah satu hasil tersebut berasal dari konfigurasi aktif, pemberitahuan masih dapat muncul.

Tanggal atau aktivitas	Digunakan untuk pembersihan selama 90 hari?
Ketika pemberitahuan pertama kali terdeteksi	No
Waktu pemberitahuan terakhir terdeteksi	No
Saat cabang terakhir kali dipindai	Tidak secara independen. Cleanup melacak fase pipeline terkait, yang dapat dibagikan di seluruh cabang.
Waktu penyelesaian terbaru dari fase pipeline terkait	Yes

Mengapa deteksi cabang lama dapat tetap terlihat atau muncul kembali?

Cabang yang berbeda dapat berbagi catatan aktivitas fase pipeline yang sama. Ketika fase tersebut berjalan lagi di cabang lain, Advanced Security memperbarui waktu penyelesaiannya dan mengaktifkan kembali konfigurasi terkait. Akibatnya, deteksi lama pada cabang yang belum berjalan baru-baru ini dapat tetap terlihat atau muncul kembali.

Misalnya, pertimbangkan urutan ini:

Fase pipeline mendeteksi kerentanan pada develop.
Fase tersebut tidak berjalan di branch mana pun selama lebih dari 90 hari. Setelah pembersihan menandainya tidak aktif, Advanced Security menyembunyikan pemberitahuan jika tidak memiliki hasil terbaru dari konfigurasi aktif lainnya.
Fase yang sama berjalan di feature/update-build. Advanced Security mengaktifkan kembali konfigurasi terkaitnya, sehingga deteksi versi lama develop dapat muncul lagi.

Pemindaian pada feature/update-build tidak memindai develop. Ini mengubah status aktivitas fase alur bersama, yang mengontrol apakah Advanced Security menunjukkan hasil yang lebih lama.

Untuk alasan ini, pemberitahuan dapat muncul dengan tanggal pertama kali terlihat atau terakhir kali terlihat yang lama. Tanggal tersebut menunjukkan deteksi pada cabang, bukan status aktivitas fase pipeline. Mengaktifkan kembali konfigurasi tidak membuat hasil yang lebih lama menjadi deteksi baru atau memerlukan tanggal aslinya yang terlihat pertama kali untuk berubah.

Apa yang harus Anda periksa?

Ketika deteksi lama tetap terlihat, tinjau run dari fase pipeline yang sama di seluruh cabang, bukan hanya cabang yang ditampilkan dalam pemberitahuan. Untuk memeriksa apakah kerentanan masih ada di cabang tersebut, jalankan pemindaian pada cabang tersebut.

Important

Pembersihan otomatis menyembunyikan hasil. Ini tidak memperbaiki kerentanan atau mengabaikan peringatan. Jika konfigurasi terkait menjadi aktif lagi, pemberitahuan terbuka yang sebelumnya tersembunyi dapat kembali sebagai pemberitahuan terbuka.

Memperbaiki peringatan pemindaian dependensi

Dependensi langsung adalah komponen yang Anda miliki di repositori Anda. Dependensi transitif atau tidak langsung adalah komponen yang digunakan oleh dependensi langsung. Proyek Anda masih rentan terlepas dari apakah kerentanan ditemukan dalam dependensi langsung atau transitif.

Memperbaiki dependensi transitif yang rentan biasanya mengambil bentuk mengesampingkan versi komponen yang rentan secara eksplisit yang digunakan untuk setiap dependensi langsung yang diidentifikasi. Setelah dependensi akar meningkatkan penggunaan komponen yang rentan ke versi yang aman, Anda dapat meningkatkan setiap dependensi akar alih-alih melakukan beberapa penggantian individual.

Memperbarui dependensi untuk Yarn/Npm

Secara hipotetis, mengatakan paket ini memiliki dua kerentanan. Yang satu adalah untuk axios, yaitu dependensi langsung, dan yang satu lagi adalah untuk acorn, yaitu dependensi transitif (juga dikenal sebagai dependensi tidak langsung atau dependensi dari dependensi lain).

{
 "name": "my-package",
 "version": "1.0.0",
 "dependencies": {
   "axios": "0.18.0",
   "eslint": "5.16.0",
 }
}

Versi saat ini dari axios memiliki kerentanan penolakan layanan (DoS) dan direkomendasikan untuk memperbarui ke v0.18.1 atau yang lebih tinggi. Karena ini merupakan dependensi langsung, Anda dapat mengendalikan versi axios yang digunakan; yang perlu Anda lakukan hanyalah memperbarui versi axios yang Anda gunakan. Tampilan yang diperbarui package.json mirip dengan:

{
  "name": "my-package",
  "version": "1.0.0",
  "dependencies": {
    "axios": "0.19.2",
    "eslint": "5.16.0",
  }
}

Sekarang, versi eslint dalam package.json yang ditampilkan bergantung pada versi acorn yang merupakan kerentanan "Re-DoS" (denial of service ekspresi reguler) dengan rekomendasi untuk memperbarui ke versi 5.7.4, 6.4.1, 7.1.1 atau yang lebih tinggi. Jika Anda menerima peringatan dari alat pemindaian dependensi, peringatan tersebut seharusnya memberi tahu Anda dependensi akar yang memerlukan dependensi yang rentan.

Benang

Jika Anda menggunakan Yarn, Anda dapat menggunakan perintah `yarn why` untuk menemukan seluruh rantai dependensi.

> $ yarn why acorn
 yarn why v1.22.4
 [1/4] Why do we have the module "acorn"...?
 [2/4] Initialising dependency graph...
 [3/4] Finding dependency...
 [4/4] Calculating file sizes...
 => Found "acorn@6.4.0"
 info Reasons this module exists
   - "eslint#espree" depends on it
   - Hoisted from "eslint#espree#acorn"
 info Disk size without dependencies: "1.09MB"
 info Disk size with unique dependencies: "1.09MB"
 info Disk size with transitive dependencies: "1.09MB"
 info Number of shared dependencies: 0
 Done in 0.30s.

Rantai dependensi penuh adalah eslint>espree>acorn. Setelah Anda mengetahui rantai dependensi, Anda dapat menggunakan fitur lain dari Yarn, resolusi dependensi selektif, untuk mengambil alih versi acorn yang akan digunakan.

Gunakan kolom `resolutions` dalam package.json untuk menetapkan penggantian versi. Tiga metode berbeda untuk mengambil alih paket ditampilkan, dalam urutan terburuk ke terbaik:

{
  "name": "yarn-resolutions",
  "version": "1.0.0",
  "license": "MIT",
  "dependencies": {
    "axios": "0.19.2",
    "eslint": "5.16.0"
  },
  "resolutions": {
    // DO NOT USE!
    "**/acorn": "6.4.1",
    // BETTER
    "eslint/**/acorn": "6.4.1",
    // BEST
    "eslint/espree/acorn": "6.4.1"
  }
}

Menggunakan pola**/acorn tersebut akan menimpa semua penggunaan paket acorn di seluruh dependensi. Ini berbahaya, dan rusak saat runtime, jadi kami menghapusnya di Yarn v2.

Dengan menggunakan pola eslint/**/acorn, semua penggunaan paket acorn dalam paket eslint, serta dalam paket apa pun yang menjadi dependensinya, akan ditimpa. Ini lebih aman daripada mengesampingkan paket untuk semua dependensi, tetapi masih memiliki beberapa risiko jika grafik dependensi untuk paket besar. Pola ini direkomendasikan ketika ada banyak subpaket yang menggunakan paket rentan dan menetapkan penimpaan untuk masing-masing subpaket tidak praktis.

Menggunakan pola eslint/espree/acorn hanya mengesampingkan penggunaan acorn dalam paket espree di paket eslint. Ini secara khusus menargetkan rantai dependensi yang rentan, dan merupakan cara yang disarankan untuk mengesampingkan versi paket.

npm

Jika Anda menggunakan npm 8.3 atau yang lebih tinggi, Anda dapat menggunakan field overrides dalam package.json

Tambahkan override jika Anda perlu melakukan perubahan tertentu pada dependensi transitif. Misalnya, Anda mungkin perlu mengambil alih versi dependensi dengan masalah keamanan yang diketahui, mengganti dependensi yang ada dengan fork, atau memastikan bahwa versi paket yang sama digunakan di mana-mana.

{
  "name": "npm-overrides",
  "version": "1.0.0",
  "license": "MIT",
  "dependencies": {
    "axios": "0.19.2",
    "eslint": "5.16.0"
  },
   "overrides":{
       "eslint": {
        "espree": {
          "acorn": "6.4.1"
        }
    }
   }
}

Contoh override yang ditampilkan menunjukkan cara npm menyatakan “hanya override penggunaan acorn pada paket espree di dalam paket eslint.” Ini secara khusus menargetkan rantai dependensi yang rentan dan merupakan cara yang direkomendasikan untuk melakukan override pada versi paket. Overrides adalah fitur bawaan npm. Ini menyediakan cara untuk mengganti paket di pohon dependensi Anda dengan versi lain, atau paket lain sepenuhnya.

Setelah mengatur penimpaan, Anda harus menghapus package-lock.json dan node_modules, lalu menjalankan npm install lagi.

Anda mungkin tidak menetapkan penimpaan untuk paket yang Anda andalkan secara langsung kecuali baik dependensi maupun penimpaan itu sendiri memiliki spesifikasi yang persis sama. Misalnya, katakanlah axios: "0.18.0" rentan dan kami berencana untuk meningkatkan ke axios: "0.19.2". Ubah langsung versi dependensi alih-alih menggunakan penimpaan.

{
  "name": "npm-overrides",
  "version": "1.0.0",
  "license": "MIT",
  "dependencies": {
    "axios": "0.18.0"
  },
  "overrides": {
    // BAD, will throw an EOVERRIDE error
    // "axios": "0.19.2",
  }
}

Perbarui versi dependensi tanpa mengatur penimpaan:

{
  "name": "npm-overrides",
  "version": "1.0.0",
  "license": "MIT",
  "dependencies": {
    "axios": "0.19.2"
  }
}

Memperbarui dependensi untuk Maven

Mekanisme resolusi dependensi tidak se canggih seperti yang digunakan di Yarn. Akibatnya, Anda hanya dapat memiliki satu versi dependensi dalam proyek. Untuk mengatasi masalah ini, Maven menggunakan algoritma "kemenangan terdekat". Artinya, ia menggunakan versi dependensi terdekat dengan proyek Anda di pohon dependensi.

Misalnya, Anda memiliki grafik dependensi berikut:

your-project --- A:1.0.0 --- B:2.0.0
      \
       \__ B:1.0.0

your-project tergantung pada A:1.0.0, yang pada gilirannya bergantung pada B:2.0.0 tetapi proyek Anda juga memiliki dependensi langsung pada B:1.0.0. Jadi, Anda memiliki dua versi dependensi B yang berbeda dalam grafik dependensi Anda, tetapi dependensi versi 1.0.0 menang karena "terdekat" dengan proyek Anda.

Dalam beberapa kasus, skenario ini mungkin berfungsi jika versi kompatibel. Namun, jika A:1.0.0 bergantung pada beberapa fitur B yang hanya tersedia dalam versi 2.0.0 maka perilaku ini tidak berfungsi. Dalam skenario terburuk, proyek ini mungkin masih dikompilasi tetapi gagal pada runtime.

Mari kita lihat contoh dunia nyata.

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.microsoft.customer360</groupId>
  <artifactId>maven-dependencies</artifactId>
  <packaging>jar</packaging>
  <version>1.0-SNAPSHOT</version>
  <name>maven-dependencies</name>
  <url>http://maven.apache.org</url>
  <dependencies>
    <dependency>
      <groupId>com.fasterxml.jackson.jaxrs</groupId>
      <artifactId>jackson-jaxrs-json-provider</artifactId>
      <version>2.10.3</version>
    </dependency>
</project>

Misalkan versi com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider yang Anda gunakan bergantung pada versi com.fasterxml.jackson.core:jackson-databind yang memiliki kerentanan deserialisasi data yang tidak tepercaya.

Anda dapat memverifikasi dependensi ini dengan menggunakan plugin dependensi Maven. Dalam hal ini Anda akan menjalankan mvn dependency:tree -Dincludes=com.fasterxml.jackson.core:jackson-databind dan mendapatkan output berikut:

> $ mvn dependency:tree -Dincludes=com.fasterxml.jackson.core:jackson-databind
 [INFO] Scanning for projects...
 [INFO]
 [INFO] ------------< com.microsoft.customer360:maven-dependencies >------------
 [INFO] Building maven-dependencies 1.0-SNAPSHOT
 [INFO] --------------------------------[ jar ]---------------------------------
 [INFO]
 [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ maven-dependencies ---
 [INFO] com.microsoft.customer360:maven-dependencies:jar:1.0-SNAPSHOT
 [INFO] \- com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider:jar:2.10.3:compile
 [INFO]    \- com.fasterxml.jackson.jaxrs:jackson-jaxrs-base:jar:2.10.3:compile
 [INFO]       \- com.fasterxml.jackson.core:jackson-databind:jar:2.10.3:compile
 [INFO] ------------------------------------------------------------------------
 [INFO] BUILD SUCCESS
 [INFO] ------------------------------------------------------------------------
 [INFO] Total time:  0.928 s
 [INFO] Finished at: 2020-04-27T14:30:55+02:00
 [INFO] ------------------------------------------------------------------------

Pertama, periksa apakah ada versi com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider baru yang tidak bergantung pada versi yang rentan dari com.fasterxml.jackson.core:jackson-databind. Jika demikian, Anda dapat meningkatkan com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider dan cukup sampai di situ. Jika tidak, timpa versi yang ada dari com.fasterxml.jackson.core:jackson-databind.

Seperti yang ditunjukkan dalam cuplikan kode, saat menggunakan Maven, yang terdekat yang diutamakan. Oleh karena itu, solusinya adalah menambahkan dependensi langsung ke com.fasterxml.jackson.core:jackson-databind yang akan memperbaiki kerentanan tersebut.

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.microsoft.customer360</groupId>
  <artifactId>maven-dependencies</artifactId>
  <packaging>jar</packaging>
  <version>1.0-SNAPSHOT</version>
  <name>maven-dependencies</name>
  <url>http://maven.apache.org</url>
  <dependencies>
    <dependency>
      <groupId>com.fasterxml.jackson.jaxrs</groupId>
      <artifactId>jackson-jaxrs-json-provider</artifactId>
      <version>2.10.3</version>
    </dependency>
    <!-- Dependency resolutions -->
    <!-- jackson-jaxrs-json-provider -->
    <dependency>
      <groupId>com.fasterxml.jackson.core</groupId>
      <artifactId>jackson-databind</artifactId>
      <version>2.9.10.4</version>
    </dependency>
  </dependencies>
</project>

Anda dapat memverifikasi bahwa resolusi berfungsi dengan menjalankan mvn dependency:tree -Dincludes=com.fasterxml.jackson.core:jackson-databind lagi.

$ mvn dependency:tree -Dincludes=com.fasterxml.jackson.core:jackson-databind
[INFO] Scanning for projects...
[INFO]
[INFO] ------------< com.microsoft.customer360:maven-dependencies >------------
[INFO] Building maven-dependencies 1.0-SNAPSHOT
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ maven-dependencies ---
[INFO] com.microsoft.customer360:maven-dependencies:jar:1.0-SNAPSHOT
[INFO] \- com.fasterxml.jackson.core:jackson-databind:jar:2.9.10.4:compile
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  0.827 s
[INFO] Finished at: 2020-04-27T14:32:42+02:00
[INFO] ------------------------------------------------------------------------

Kami sarankan Anda menambahkan komentar di dekat resolusi dependensi, sehingga siapa pun yang datang nanti tahu mengapa dependensi ada di sana. Ini dapat dihapus setelah dependensi akar menggunakan versi baru; jika tidak, dependensi akan menumpuk.

Dalam proyek nyata, tambahkan dependensi setingkat mungkin rantai. Misalnya, Anda dapat menambahkan resolusi dalam file POM induk, alih-alih satu per satu di setiap file POM proyek.

Memperbarui dependensi untuk NuGet

Algoritma resolusi dependensi yang digunakan dalam NuGet mirip dengan Maven, karena hanya satu versi dependensi yang dapat digunakan. Namun, NuGet tidak mengunci versi dependensi.

Misalnya, jika Anda memiliki dependensi <PackageReference Include="A" Version="1.2.3" />, Anda mungkin mengharapkan paket ini setara dengan = 1.2.3, tetapi sebenarnya berarti >= 1.2.3. Untuk menetapkan versi tertentu secara tepat, Anda harus menggunakan Version="[1.2.3]". Untuk informasi selengkapnya, lihat dokumentasi rentang versi NuGet.

Selain perilaku rentang default, NuGet memulihkan versi terendah yang berlaku untuk memenuhi rentang. Perilaku ini berarti bahwa dalam banyak kasus Anda harus menentukan rentang.

Mari kita lihat proyek sampel ini, yang memiliki dependensi pada Microsoft.AspNetCore.App:

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <RootNamespace>NuGet.Dependencies</RootNamespace>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.App" Version="2.1.14" />
  </ItemGroup>
</Project>

Ini tergantung pada versi Microsoft.AspNetCore.Http.Connections yang rentan terhadap kerentanan eksekusi kode jarak jauh (RCE).

Pertama, Anda harus memeriksa untuk melihat apakah ada versi Microsoft.AspNetCore.App yang diperbarui tergantung pada versi yang lebih baru dari Microsoft.AspNetCore.Http.Connections. Jika demikian, Anda dapat meningkatkan Microsoft.AspNetCore.App dan berhenti di sini. Jika tidak, Anda harus mengganti versi Microsoft.AspNetCore.Http.Connections yang menjadi dependensinya.

NuGet tidak memiliki padanan bawaan untuk `yarn why` atau `mvn dependency:tree`, jadi salah satu cara termudah untuk melihat pohon dependensi sering kali adalah dengan mengunjungi nuget.org. Jika Anda mengunjungi halaman NuGet untuk Microsoft.AspNetCore.App, Anda akan melihat bahwa paket tersebut bergantung pada Microsoft.AspNetCore.Http.Connectionsversion >= 1.0.4 && < 1.1.0. Atau, dalam rentang versi NuGet, sintaks perwakilannya adalah [1.0.4,1.1.0).

Kerentanan RCE dalam Microsoft.AspNetCore.Http.Connections telah diperbaiki pada versi 1.0.15, jadi Anda perlu mengganti rentang versi menjadi[1.0.15, 1.1.0).

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <RootNamespace>NuGet.Dependencies</RootNamespace>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.App" Version="2.2.8" />
  </ItemGroup>

  <ItemGroup Label="Dependency Resolutions">
    <!-- Microsoft.AspNetCore.App -->
    <PackageReference Include="Microsoft.AspNetCore.Http.Connections" Version="[1.0.15,1.1.0)" />
  </ItemGroup>
</Project>

Kami sarankan Anda menambahkan komentar di dekat resolusi dependensi sehingga siapa pun yang datang nanti tahu mengapa dependensi ada di sana. Ini dapat dihapus setelah dependensi akar menggunakan versi baru. Jika tidak, Anda mengakumulasi dependensi.

Bagaimana jika tidak ada perbaikan yang tersedia?

Ketika tidak ada perbaikan yang diketahui tersedia, opsi berikut tersedia sebagai metode remediasi lain hingga komponen yang ditingkatkan tersedia:

Berhenti menggunakan komponen dan hapus dari kode Anda - penghapusan ini terdeteksi pada build Anda berikutnya dengan tugas pemindaian dependensi terinstal
Berkontribusi perbaikan pada komponen itu sendiri. Jika organisasi Anda memiliki panduan khusus sekeliling kontribusi sumber terbuka, ikuti panduan tersebut.
Mengabaikan peringatan. Namun, pemberitahuan tanpa perbaikan yang diketahui masih dapat menimbulkan ancaman keamanan bagi organisasi Anda. Kami menyarankan agar Anda tidak menutup pemberitahuan hanya karena tidak ada perbaikan yang diketahui.

Menutup pemberitahuan pemindaian dependensi

Untuk menutup pemberitahuan, lakukan langkah-langkah berikut:

Pergi ke peringatan yang ingin Anda tutup dan pilih peringatan tersebut.
Pilih drop-down Tutup pemberitahuan.
Jika belum dipilih, pilih Risiko diterima atau Positif salah sebagai alasan penutupan.
Tambahkan komentar opsional ke dalam kotak teks Komentar .
Pilih Tutup untuk mengirimkan dan menutup pemberitahuan.
Status pemberitahuan berubah dari Buka menjadi Tertutup dan menampilkan alasan pemecatan Anda.

Tindakan ini menghapus peringatan untuk seluruh cabang. Cabang lain yang berisi kerentanan yang sama juga akan diberhentikan. Setiap pemberitahuan yang sebelumnya diberhentikan dapat dibuka kembali secara manual.

Mengelola pemberitahuan pemindaian dependensi pada permintaan pull

Jika pemberitahuan dibuat untuk perubahan kode baru dalam permintaan pull, pemberitahuan dilaporkan sebagai anotasi di bagian komentar tab Gambaran Umum dari permintaan pull dan sebagai pemberitahuan di tab repositori Keamanan Tingkat Lanjut . Entri pemilih cabang baru tersedia untuk cabang permintaan pull.

Anda dapat melihat manifes paket yang terpengaruh, melihat ringkasan temuan, dan mengatasi anotasi di bagian Gambaran Umum.

Untuk menutup peringatan pull request, Anda harus membuka tampilan detail peringatan untuk menutup peringatan tersebut dan menyelesaikan anotasinya. Jika tidak, hanya mengubah status komentar (1) menyelesaikan anotasi tetapi tidak menutup atau memperbaiki pemberitahuan yang mendasarinya.

Untuk melihat seluruh kumpulan hasil untuk cabang permintaan pull Anda, navigasi ke Repositori>Advanced Security dan pilih cabang permintaan pull Anda. Memilih Perlihatkan detail selengkapnya (2) pada anotasi mengarahkan Anda ke tampilan detail pemberitahuan di tab Keamanan Tingkat Lanjut.

Petunjuk / Saran

Anotasi hanya akan dibuat ketika baris kode yang terpengaruh sepenuhnya unik terhadap perbedaan dalam permintaan pull dibandingkan dengan cabang target.

Saran dan Komentar

Apakah halaman ini membantu?

Terakhir diperbarui pada 2026-10-12