DevSecOps: Prinsip dan Perbandingan SCA. Bagian satu

Pentingnya analisis komponen perangkat lunak pihak ketiga (Analisis Komposisi Perangkat Lunak - SCA) dalam proses pengembangan semakin meningkat seiring dengan rilis laporan tahunan tentang kerentanan pustaka sumber terbuka, yang diterbitkan oleh Synopsys, Sonatype, Snyk, White Source. Menurut The State of Open Source Security Vulnerabilities 2020Jumlah kerentanan open source yang teridentifikasi pada tahun 2019 meningkat hampir 1,5 kali lipat dibandingkan tahun sebelumnya, sementara komponen open source digunakan dari 60% menjadi 80% proyek. Jika Anda beralih ke opini independen, proses SCA adalah praktik terpisah dari OWASP SAMM dan BSIMM sebagai ukuran kematangan, dan pada paruh pertama tahun 2020 OWASP merilis standar baru, OWASP Software Component Verification Standard (SCVS), yang memberikan praktik terbaik untuk memverifikasi komponen pihak ketiga dalam rantai pasokan. OLEH.







Salah satu kasus yang paling terbuka terjadi dengan Equifax pada Mei 2017. Penyerang tak dikenal menyita informasi dari 143 juta orang Amerika, termasuk nama lengkap, alamat, nomor jaminan sosial, dan surat izin mengemudi. Dalam 209.000 kasus, dokumen tersebut juga memuat informasi tentang kartu bank korban. Kebocoran ini terjadi karena eksploitasi kerentanan kritis di Apache Struts 2 (CVE-2017-5638), sedangkan perbaikannya dirilis kembali pada Maret 2017. Perusahaan memiliki waktu dua bulan untuk menginstal pembaruan, tetapi tidak ada yang peduli tentang itu.



Artikel ini akan membahas masalah pemilihan alat untuk melakukan SCA dalam hal kualitas hasil analisis. Juga akan ada perbandingan fungsional alat. Proses penyematan ke CI / CD dan kemungkinan integrasi akan ditinggalkan untuk publikasi mendatang. Daftar luas alat disajikan oleh OWASP di situs webnya , tetapi sebagai bagian dari ulasan saat ini, kami hanya akan menyentuh alat sumber terbuka paling populer Pemeriksaan Ketergantungan, Jalur Ketergantungan platform sumber terbuka yang sedikit kurang terkenal dan solusi Sonatype Nexus IQ Enterprise. Kami juga akan mencari tahu cara kerja solusi ini dan membandingkan hasil yang diperoleh untuk positif palsu.

Prinsip operasi

Pemeriksaan Ketergantungan adalah utilitas (CLI, maven, modul jenkins, ant) ​​yang menganalisis file proyek, mengumpulkan potongan informasi ketergantungan (nama paket, groupid, judul spesifikasi, versi ...), membangun jalur CPE - (Pencacahan Platform Umum), Paket URL (PURL) dan mendeteksi kerentanan untuk CPE / PURL dari database (NVD, Indeks Sonatype OSS, API Audit NPM ...), lalu membuat laporan satu kali dalam format HTML, JSON, XML ...



Mari kita lihat bagaimana CPE terlihat:

cpe:2.3:part:vendor:product:version:update:edition:language:sw_edition:target_sw:target_hw:other

• Bagian: Indikasi bahwa komponen tersebut milik aplikasi (a), sistem operasi (o), perangkat keras (h) (Item wajib)
• Vendor: Nama produsen produk (Wajib)
• Produk: Nama produk (Item yang dibutuhkan)
• Versi: Versi komponen (Item kedaluwarsa)
• Pembaruan: Perbarui paket
• Edisi: Versi lama (Tidak Berlaku Lagi)
• Bahasa: Bahasa seperti yang didefinisikan di RFC-5646
• Edisi SW: Versi perangkat lunak
• Target SW: Lingkungan perangkat lunak tempat produk beroperasi
• Target HW: Lingkungan perangkat keras tempat produk beroperasi
• Lainnya: Pemasok atau informasi produk

Contoh CPE terlihat seperti ini:

cpe:2.3:a:pivotal_software:spring_framework:3.0.0:*:*:*:*:*:*:*

Garis berarti CPE versi 2.3 menjelaskan komponen aplikasi dari pabrikan pivotal_software dengan nama spring_frameworkversi 3.0.0. Jika kita membuka kerentanan CVE-2014-0225 di NVD , CPE ini disebutkan. Masalah pertama yang harus segera diperhatikan adalah CVE di NVD, menurut CPE, melaporkan bahwa ada masalah di framework, bukan di komponen tertentu. Artinya, jika pengembang terikat erat dengan kerangka kerja, dan kerentanan yang teridentifikasi tidak berlaku untuk modul yang digunakan pengembang, spesialis keamanan harus membongkar CVE ini dan berpikir untuk memperbarui.



URL juga digunakan oleh alat SCA. Format url paket adalah sebagai berikut:

scheme:type/namespace/name@version?qualifiers#subpath

• Skema: Akan selalu ada 'pkg' yang menunjukkan bahwa ini adalah URL paket (Wajib)
• Jenis: "tipe" dari paket atau "protokol" dari paket tersebut, seperti maven, npm, nuget, gem, pypi, dll. (Klausa wajib)
• Namespace: Beberapa awalan nama, seperti ID grup Maven, pemilik gambar Docker, pengguna atau organisasi GitHub. Opsional dan bergantung pada tipenya.
• Name: Package name (Wajib)
• Versi: Versi paket
• Kualifikasi: Kualifikasi tambahan untuk paket, seperti OS, arsitektur, distribusi, dll. Item opsional dan khusus jenis.
• Subpath: Path tambahan dalam paket yang berhubungan dengan root paket

Misalnya:

pkg:golang/google.golang.org/genproto#googleapis/api/annotations
pkg:maven/org.apache.commons/io@1.3.4
pkg:pypi/django-package@1.11.1.dev1

Dependency Track adalah platform web lokal yang menerima Bill of Material (BOM) siap pakai yang dihasilkan oleh CycloneDX dan SPDX , yaitu spesifikasi siap pakai tentang dependensi yang ada. Ini adalah file XML yang menjelaskan ketergantungan - nama, hash, url paket, penerbit, lisensi. Selanjutnya, Dependency Track mengurai BOM, melihat CVE yang tersedia untuk dependensi yang teridentifikasi dari database kerentanan (NVD, Sonatype OSS Index ...), lalu membuat grafik, menghitung metrik, memperbarui data status kerentanan komponen secara teratur.



Contoh tampilan BOM dalam format XML:

<?xml version="1.0" encoding="UTF-8"?>
<bom xmlns="http://cyclonedx.org/schema/bom/1.2" serialNumber="urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79" version="1">
  <components>
    <component type="library">
      <publisher>Apache</publisher>
      <group>org.apache.tomcat</group>
      <name>tomcat-catalina</name>
      <version>9.0.14</version>
      <hashes>
        <hash alg="MD5">3942447fac867ae5cdb3229b658f4d48</hash>
        <hash alg="SHA-1">e6b1000b94e835ffd37f4c6dcbdad43f4b48a02a</hash>
        <hash alg="SHA-256">f498a8ff2dd007e29c2074f5e4b01a9a01775c3ff3aeaf6906ea503bc5791b7b</hash>
        <hash alg="SHA-512">e8f33e424f3f4ed6db76a482fde1a5298970e442c531729119e37991884bdffab4f9426b7ee11fccd074eeda0634d71697d6f88a460dce0ac8d627a29f7d1282</hash>
      </hashes>
      <licenses>
        <license>
          <id>Apache-2.0</id>
        </license>
      </licenses>
      <purl>pkg:maven/org.apache.tomcat/tomcat-catalina@9.0.14</purl>
    </component>
      <!-- More components here -->
  </components>
</bom>

BOM dapat digunakan tidak hanya sebagai parameter input untuk Dependency Track, tetapi juga untuk menginventarisir komponen perangkat lunak dalam rantai pasokan, misalnya, untuk menyediakan perangkat lunak kepada pelanggan. Pada 2014, Cyber ​​Supply Chain Management and Transparency Act of 2014 bahkan diusulkan untuk dipertimbangkan di Amerika Serikat , yang menyatakan bahwa ketika membeli perangkat lunak, negara bagian mana pun. lembaga harus meminta BOM untuk mencegah eksploitasi komponen yang rentan, tetapi undang-undang tersebut tidak pernah diberlakukan.



Kembali ke SCA, Dependency Track memiliki integrasi out-of-the-box dengan Notification Platforms seperti Slack, sistem manajemen kerentanan seperti Kenna Security. Juga harus dikatakan bahwa Dependency Track, antara lain, mendeteksi versi paket yang sudah kadaluwarsa dan memberikan informasi tentang lisensi (karena dukungan untuk SPDX).



Jika kita berbicara secara spesifik tentang kualitas SCA, maka ada perbedaan yang mendasar.



Dependency Track tidak menerima proyek sebagai input, melainkan BOM. Artinya jika kita ingin memeriksa proyek, maka pertama kita perlu membuat bom.xml, misalnya menggunakan CycloneDX. Jadi, Jalur Ketergantungan secara langsung bergantung pada CycloneDX. Pada saat yang sama, ini memungkinkan untuk penyesuaian. Jadi tim OZON menulis modul CycloneDX untuk membuat file BOM untuk proyek Golang untuk pemindaian lebih lanjut melalui Dependency Track.



Nexus IQAdalah solusi SCA komersial dari Sonatype, yang merupakan bagian dari ekosistem Sonatype, yang juga mencakup Nexus Repository Manager. Nexus IQ dapat menerima sebagai data masukan baik arsip perang (untuk proyek java) melalui antarmuka web atau API, dan BOM, jika organisasi Anda belum berhasil membangun kembali dari CycloneDX ke solusi baru. Tidak seperti solusi open source, IQ tidak hanya mengacu pada CPE / PURL untuk komponen yang diidentifikasi dan kerentanan yang sesuai dalam database, tetapi juga memperhitungkan penelitiannya sendiri, misalnya, nama fungsi atau kelas yang rentan. Mekanisme IQ akan dibahas nanti dalam analisis hasil.



Mari kita meringkas beberapa fitur fungsional, dan juga mempertimbangkan bahasa yang didukung untuk analisis:





Kegunaan





Peluang integrasi

Pemeriksaan Ketergantungan

Awal pertama

Mari jalankan Pemeriksaan Ketergantungan pada aplikasi DVJA yang sengaja rentan .



Untuk melakukan ini, kami akan menggunakan Plugin Dependency Check Maven :

mvn org.owasp:dependency-check-maven:check

Akibatnya, dependency-check-report.html akan muncul di direktori target.







Mari buka file tersebut. Setelah informasi ringkasan tentang jumlah total kerentanan, kita dapat melihat informasi tentang kerentanan dengan tingkat Severity dan Confidence tinggi, menunjukkan paket, CPE, nomor CVE.



Kemudian diikuti dengan informasi yang lebih rinci, khususnya berdasarkan apa bukti tersebut, yaitu BOM tertentu.







Berikutnya adalah deskripsi CPE, PURL dan CVE. Omong-omong, rekomendasi untuk perbaikan tidak dilampirkan karena tidak ada di database NVD.







Untuk meninjau hasil pemindaian secara sistematis, Anda dapat mengonfigurasi Nginx dengan pengaturan minimal, atau mengirim cacat yang dihasilkan ke sistem manajemen kerusakan yang mendukung konektor Pemeriksaan Ketergantungan. Misalnya, Defect Dojo.

Jalur Ketergantungan

Instalasi

Dependency Track, pada gilirannya, adalah platform web dengan bagan yang menampilkan, jadi tidak ada masalah akut dalam menyimpan cacat dalam solusi pihak ketiga.

Ada skrip yang didukung berikut untuk instalasi: Docker, WAR, Executable WAR.

Awal pertama

Buka URL dari layanan yang berjalan. Kami masuk melalui admin / admin, mengubah nama pengguna dan kata sandi, dan kemudian kami masuk ke Dashboard. Hal berikutnya yang akan kita lakukan adalah membuat proyek untuk aplikasi pengujian Java di Home / Projects → Create Project . Mari kita ambil DVJA sebagai contoh.







Karena Jalur Ketergantungan hanya dapat menerima BOM sebagai input, BOM ini harus diambil. Mari gunakan Plugin CycloneDX Maven :

mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom

Kami mendapatkan bom.xml dan mengunggah file di proyek yang dibuat DVJA → Dependensi → Unggah BOM .



Mari pergi ke Administrasi → Analisa. Kami memahami bahwa kami hanya mengaktifkan Penganalisis Internal, termasuk NVD. Kami juga akan menghubungkan Indeks OSS Sonatype.







Jadi, kami akan mendapatkan gambar berikut untuk proyek kami:







Juga dalam daftar Anda dapat menemukan satu kerentanan yang berlaku untuk Sonatype OSS:







Kekecewaan utama adalah bahwa Dependency Track tidak lagi menerima laporan Dependency Check xml. Versi integrasi Pemeriksaan Ketergantungan terakhir yang didukung adalah 1.0.0 - 4.0.2, sementara saya menguji 5.3.2.



Ini adalah video (dan sekarang ) ketika itu masih memungkinkan.

Nexus IQ

Awal pertama

Nexus IQ diinstal dari arsip dokumentasi , tetapi kami telah mengumpulkan gambar Docker untuk tujuan ini.



Setelah masuk ke konsol, Anda perlu membuat Organisasi dan Aplikasi.















Seperti yang Anda lihat, penyiapan dalam kasus IQ sedikit lebih rumit, karena kita juga perlu membuat kebijakan yang dapat diterapkan ke berbagai "tahapan" (dev, build, stage, release). Hal ini diperlukan untuk memblokir komponen yang rentan saat mereka bergerak di sepanjang jalur pipa mendekati produk, atau memblokir segera setelah masuk ke Nexus Repo saat diunduh oleh pengembang.



Untuk merasakan perbedaan antara open source dan perusahaan, mari lakukan pemindaian yang sama melalui Nexus IQ dengan cara yang sama melalui plugin Maven , setelah sebelumnya membuat aplikasi pengujian di antarmuka NexusIQ dvja-test-and-compare:

mvn com.sonatype.clm:clm-maven-plugin:evaluate -Dclm.applicationId=dvja-test-and-compare -Dclm.serverUrl=<NEXUSIQIP> -Dclm.username=<USERNAME> -Dclm.password=<PASSWORD>

Buka URL ke laporan yang dihasilkan di antarmuka web IQ:







Di sini Anda dapat melihat semua pelanggaran kebijakan dengan berbagai tingkat kepentingan (dari Info hingga Keamanan Penting). Huruf D di sebelah komponen berarti komponen itu Ketergantungan Langsung, dan huruf T di sebelah komponen berarti komponen itu Ketergantungan Transitif, yaitu transitif.



Omong-omong, Snyk State of Open Source Security Report 2020 melaporkan bahwa lebih dari 70% kerentanan open source yang ditemukan di Node.js, Java, dan Ruby berada dalam dependensi transitif.



Jika kita membuka salah satu pelanggaran kebijakan Nexus IQ, kita dapat melihat deskripsi komponen, serta Grafik Versi, yang menunjukkan lokasi versi saat ini di timeline, serta di titik mana kerentanan tidak lagi rentan. Ketinggian kandil pada grafik menunjukkan popularitas komponen ini.







Jika Anda pergi ke bagian kerentanan dan mengungkapkan CVE, Anda dapat membaca deskripsi kerentanan ini, rekomendasi untuk eliminasi, serta alasan mengapa komponen ini dilanggar, yaitu adanya kelas DiskFileitem.class.











Mari kita meringkas hanya komponen Java pihak ketiga, menghapus komponen js. Dalam tanda kurung, kami akan menunjukkan jumlah kerentanan yang ditemukan di luar NVD.



Total Nexus IQ:

• Dependensi yang Dipindai: 62
• Ketergantungan Rentan: 16
• Kerentanan Ditemukan: 42 (8 sonatype db)

Pemeriksaan Ketergantungan Total:

• Dependensi yang Dipindai: 47
• Ketergantungan Rentan: 13
• Kerentanan Ditemukan: 91 (14 sonatype oss)

Jalur Ketergantungan Total:

• Dependensi Dipindai: 59
• Ketergantungan Rentan: 10
• Kerentanan yang Ditemukan: 51 (1 sonatype oss)

Langkah selanjutnya adalah menganalisis hasil yang diperoleh dan mencari tahu kerentanan mana yang benar-benar cacat dan mana yang positif palsu.

Penolakan

Review ini bukanlah kebenaran yang tidak bisa disangkal. Penulis tidak memiliki tujuan untuk membuat instrumen terpisah menonjol dari yang lain. Inti dari tinjauan tersebut adalah untuk menunjukkan bagaimana alat SCA bekerja dan bagaimana memeriksa hasilnya.

Perbandingan hasil

Kondisi:



Positif palsu untuk kerentanan di komponen pihak ketiga adalah:

• CVE tidak cocok untuk komponen yang diidentifikasi
• , struts2, struts-tiles, , false positive
• CVE
• , python > 3.5 2.7 — false positive, 3.x
• CVE
• , SCA CVE, RCE, SCA CVE, Cisco, RCE. false positive.
• Misalnya, CVE ditemukan di komponen web pegas, setelah itu SCA menunjuk ke CVE yang sama di komponen Kerangka Pegas lainnya, sementara CVE tidak ada hubungannya dengan komponen lain. Dalam kasus ini, itu akan menjadi positif palsu.

Proyek open source DVJA dipilih sebagai objek penelitian. Studi ini hanya melibatkan komponen java (no js).

Hasil ringkasan

Mari langsung ke hasil tinjauan manual dari kerentanan yang teridentifikasi. Laporan lengkap untuk setiap CVE dapat ditemukan di Lampiran.



Hasil ringkasan untuk semua kerentanan:



Hasil ringkasan berdasarkan komponen:



Mari buat grafik visual untuk menilai rasio positif palsu dan negatif palsu terhadap jumlah total kerentanan. Komponen ditandai secara horizontal, dan kerentanan yang diidentifikasi di dalamnya ditandai secara vertikal.















Sebagai perbandingan, studi serupa dilakukan oleh tim Sonatype untuk menguji proyek 1.531 komponen menggunakan Pemeriksaan Ketergantungan OWASP. Seperti yang bisa kita lihat, rasio noise untuk mengoreksi pemicu sebanding dengan hasil kami.





Sumber: www.sonatype.com/why-precision-matters-ebook



Mari kita lihat beberapa CVE dari hasil pemindaian kami untuk memahami alasan hasil ini.

Keterangan lebih lanjut

# 1

Mari kita lihat beberapa poin menarik dari Sonatype Nexus IQ terlebih dahulu.



Nexus IQ menunjukkan masalah deserialisasi dengan kemampuan untuk mengeksekusi RCE di Spring Framework beberapa kali. CVE-2016-1000027 di web-pegas: 3.0.5 untuk pertama kalinya, dan CVE-2011-2894 dalam konteks pegas: 3.0.5 dan pegas-inti: 3.0.5. Pada awalnya, tampaknya ada kerentanan duplikat di beberapa CVE. Karena jika Anda melihat CVE-2016-1000027 dan CVE-2011-2894 di database NVD, maka tampaknya semuanya sudah jelas.





Deskripsi CVE-2011-2894 dari NVD :





Deskripsi CVE-2016-1000027 dari NVD :





CVE-2011-2894 sendiri cukup terkenal. Laporan Sumber Putih 2011 memberi peringkat CVE ini sebagai salah satu yang paling sering ditemui. Deskripsi untuk CVE-2016-100027, pada prinsipnya, sedikit menggunakan NVD, dan tampaknya hanya berlaku untuk Spring Framework 4.1.4. Lihatlah referensi dan di sini menjadi lebih atau kurang jelas. Kami memahami dari artikel Tenable bahwa selain kerentanan RemoteInvocationSerializingExporterdi CVE-2011-2894, kerentanan juga diamati di HttpInvokerServiceExporter. Inilah yang dikatakan Nexus IQ:







Meskipun demikian, tidak ada yang seperti ini di NVD, itulah sebabnya Pemeriksaan Ketergantungan dan Jalur Ketergantungan menerima negatif palsu.



Selain itu, dari uraian CVE-2011-2894, Anda dapat memahami bahwa kerentanan memang ada dalam konteks pegas: 3.0.5 dan pegas-inti: 3.0.5. Konfirmasi ini dapat ditemukan di artikel dari orang yang menemukan kerentanan ini.

# 2

Jika kami mempelajari kerentanan CVE-2016-4003, kami akan memahami bahwa itu telah diperbaiki pada versi 2.3.28, namun Nexus IQ memberi tahu kami tentang hal itu. Ada catatan dalam deskripsi kerentanan:







Artinya, kerentanan hanya ada dalam hubungannya dengan versi JRE yang sudah kedaluwarsa, yang mereka putuskan untuk diperingatkan kepada kami. Namun demikian, kami menganggap ini sebagai False Positive, meskipun bukan yang terburuk.

Nomor 3

Jika kita melihat deskripsi untuk CVE-2017-9804 dan CVE-2017-7672, kita akan memahami bahwa masalahnya adalah URLValidator class, dan CVE-2017-9804 mengikuti dari CVE-2017-7672. Keberadaan kerentanan kedua tidak membawa muatan apa pun, kecuali bahwa tingkat keparahannya telah meningkat ke Tinggi, jadi ini dapat dianggap sebagai kebisingan yang tidak perlu.



Secara keseluruhan, tidak ada kesalahan positif lain yang ditemukan untuk Nexus IQ.

# 4

Ada beberapa hal yang membedakan IQ dari keputusan lain.





CVE di NVD mengatakan bahwa itu hanya berlaku untuk versi 5.2.x hingga 5.2.3, 5.1.x hingga 5.1.13, dan versi 5.0.x hingga 5.0.16, namun, jika kita melihat deskripsi CVE di Nexus IQ, kita akan melihat yang berikut ini:

Pemberitahuan Deviasi Penasihat: Tim peneliti keamanan Sonatype menemukan bahwa kerentanan ini diperkenalkan pada versi 3.0.2.RELEASE dan bukan 5.0.x seperti yang dinyatakan dalam penasehat.



Ini diikuti oleh PoC untuk kerentanan ini, yang melaporkan bahwa ini ada di versi 3.0.5.



Negatif palsu dikirim ke Dependency Check dan Dependency Track.

# 5

Mari kita lihat positif palsu untuk Pemeriksaan Ketergantungan dan Pelacakan Ketergantungan.



Pemeriksaan Ketergantungan menonjol karena mencerminkan CVE yang berlaku untuk seluruh kerangka kerja di NVD ke komponen yang CVE tersebut tidak berlaku. Ini berlaku untuk CVE-2012-0394, CVE-2013-2115, CVE-2014-0114, CVE-2015-0899, CVE-2015-2992, CVE-2016-1181, CVE-2016-1182, yang Pemeriksaan Ketergantungan "disekrup" ke struts-taglib: 1.3.8 dan struts-tiles-1.3.8. Komponen ini tidak ada hubungannya dengan apa yang dijelaskan di CVE - pemrosesan permintaan, validasi halaman, dan sebagainya. Hal ini disebabkan oleh fakta bahwa kesamaan antara CVE ini dan komponennya hanyalah kerangka kerja, itulah sebabnya Dependency Check menganggapnya sebagai kerentanan.



Situasi yang sama dengan spring-tx: 3.0.5, dan situasi serupa dengan struts-core: 1.3.8. Untuk struts-core, Dependency Check dan Dependency Track telah menemukan banyak kerentanan yang sebenarnya dapat diterapkan pada struts2-core, yang pada dasarnya merupakan kerangka kerja terpisah. Dalam hal ini, Nexus IQ memahami gambar dengan benar dan dalam CVE yang dikeluarkannya, menunjukkan bahwa struts-core telah berakhir dan perlu menggunakan struts2-core.

# 6

Dalam beberapa situasi, tidak adil untuk menafsirkan kesalahan Pemeriksaan Ketergantungan dan Pelacakan Ketergantungan eksplisit. Khususnya CVE-2013-4152, CVE-2013-6429, CVE-2013-6430, CVE-2013-7315, CVE-2014-0054, CVE-2014-0225, CVE-2014-0225, yang merupakan Dependency Check dan Dependency Track mengacu pada pegas-inti: 3.0.5 sebenarnya mengacu pada pegas-web: 3.0.5. Pada saat yang sama, beberapa CVE ini ditemukan dan Nexus IQ, bagaimanapun, IQ mengidentifikasinya dengan benar untuk komponen lain. Karena kerentanan ini tidak ditemukan di spring-core, tidak dapat dikatakan bahwa mereka tidak ada dalam kerangka kerja, pada prinsipnya, dan alat open source dengan tepat menunjukkan kerentanan ini (mereka hanya melewatkan sedikit).

kesimpulan

Seperti yang bisa kita lihat, menentukan keandalan kerentanan yang teridentifikasi dengan tinjauan manual tidak memberikan hasil yang tidak ambigu, yang mengarah pada masalah kontroversial. Hasilnya sedemikian rupa sehingga solusi Nexus IQ memiliki rasio positif palsu terendah dan akurasi tertinggi.



Pertama-tama, hal ini disebabkan oleh fakta bahwa tim Sonatype telah memperluas deskripsi untuk setiap kerentanan CVE dari NVD di database mereka, menentukan, dengan keakuratan kelas atau fungsi kerentanan untuk versi komponen tertentu, melakukan penelitian tambahan (misalnya, memeriksa kerentanan pada versi lama versi perangkat lunak).



Pengaruh penting pada hasil dimainkan oleh kerentanan yang tidak disertakan dalam NVD, tetapi tetap ada dalam database Sonatype dengan tanda SONATYPE. Menurut The State of Open Source Security Vulnerabilities 202045% dari kerentanan open source yang ditemukan tidak dilaporkan ke NVD. Menurut database WhiteSource, hanya 29% dari semua kerentanan open source yang dilaporkan di luar NVD yang akhirnya dipublikasikan di sana, itulah mengapa penting untuk mencari kerentanan di tempat lain juga.



Akibatnya, Pemeriksaan Ketergantungan menghasilkan banyak kebisingan, kehilangan beberapa komponen yang rentan. Dependency Track menghasilkan lebih sedikit noise dan menampilkan banyak komponen, yang secara visual tidak melukai mata di antarmuka web.



Namun demikian, praktik menunjukkan bahwa itu adalah open source yang harus menjadi langkah pertama dalam perjalanan untuk mengembangkan DevSecOps. Hal pertama yang harus dipikirkan untuk menanamkan SCA ke dalam pengembangan adalah proses, yaitu berpikir bersama dengan manajemen dan departemen terkait tentang seperti apa seharusnya proses yang ideal dalam organisasi mereka. Mungkin untuk organisasi Anda pada awalnya, Dependency Check atau Dependency Track akan mencakup semua kebutuhan bisnis, dan solusi Enterprise akan menjadi kelanjutan logis karena kompleksitas yang berkembang dari aplikasi yang dikembangkan.