DevSecOps: مبادئ ومقارنة SCA. الجزء الأول

تتزايد أهمية تحليل مكونات برامج الطرف الثالث (Software Composition Analysis - SCA) في عملية التطوير حيث يتم إصدار التقارير السنوية حول نقاط الضعف في مكتبات المصدر المفتوح ، والتي يتم نشرها بواسطة Synopsys و Sonatype و Snyk و White Source. وفقًا لحالة الثغرات الأمنية مفتوحة المصدر لعام 2020زاد عدد نقاط الضعف التي تم تحديدها في المصدر المفتوح في عام 2019 بنحو 1.5 مرة مقارنة بالعام السابق ، بينما يتم استخدام مكونات المصدر المفتوح من 60٪ إلى 80٪ من المشاريع إذا لجأت إلى رأي مستقل ، فإن عمليات SCA هي ممارسة منفصلة لـ OWASP SAMM و BSIMM كمؤشر للنضج ، وفي النصف الأول من عام 2020 ، أصدرت OWASP معيار التحقق من مكونات البرامج (SCVS) ، والذي يوفر أفضل الممارسات للتحقق من مكونات الطرف الثالث في سلسلة التوريد بواسطة.







واحدة من أكثر الحالات التي تم الكشف عنها حدثت مع Equifax في مايو 2017. استولى مهاجمون مجهولون على معلومات عن 143 مليون أمريكي ، بما في ذلك الأسماء الكاملة والعناوين وأرقام الضمان الاجتماعي ورخص القيادة. في 209000 حالة ، تضمنت الوثائق أيضًا معلومات حول البطاقات المصرفية للضحايا. كان هذا التسرب بسبب استغلال ثغرة خطيرة في Apache Struts 2 (CVE-2017-5638) ، بينما تم إصدار الإصلاح مرة أخرى في مارس 2017. كان لدى الشركة شهرين لتثبيت التحديث ، لكن لم يكلف أحد عناء ذلك.



ستناقش هذه المقالة مسألة اختيار أداة لإجراء SCA من حيث جودة نتائج التحليل. ستكون هناك أيضًا مقارنة وظيفية للأدوات. سيتم ترك عملية التضمين في CI / CD وإمكانيات التكامل للمنشورات المستقبلية. تم تقديم قائمة واسعة من الأدوات بواسطة OWASP على موقعها على الإنترنت ، ولكن كجزء من المراجعة الحالية ، سنتطرق فقط إلى الأداة مفتوحة المصدر الأكثر شيوعًا Dependency Check ، وهي منصة مفتوحة المصدر أقل شهرة ، حل Dependency Track and Enterprise Sonatype Nexus IQ. سنكتشف أيضًا كيفية عمل هذه الحلول ونقارن النتائج التي تم الحصول عليها للإيجابيات الخاطئة.

مبدأ التشغيل

Dependency Check هي أداة مساعدة (CLI ، maven ، jenkins module ، ant) ​​تقوم بتحليل ملفات المشروع ، وتجمع أجزاء من معلومات التبعية (اسم الحزمة ، ومعرّف المجموعة ، وعنوان المواصفات ، والإصدار ...) ، وتبني خط CPE - (تعداد النظام الأساسي المشترك) ، الحزمة URL (PURL) ويكتشف نقاط الضعف لـ CPE / PURL من قواعد البيانات (NVD ، Sonatype OSS Index ، NPM Audit API ...) ، ثم ينشئ تقريرًا لمرة واحدة بتنسيق HTML و JSON و XML ...



دعونا نرى كيف يبدو CPE:

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

• الجزء: إشارة إلى أن المكون ينتمي إلى التطبيق (أ) ، نظام التشغيل (س) ، الأجهزة (ح) (عنصر إلزامي)
• البائع: اسم الشركة المصنعة للمنتج (مطلوب)
• المنتج: اسم المنتج (عنصر مطلوب)
• الإصدار: إصدار المكون (مهمل)
• التحديث: قم بتحديث الحزمة
• الإصدار: إصدار قديم (مهمل)
• اللغة: اللغة كما تم تعريفها في RFC-5646
• إصدار SW: إصدار البرنامج
• الهدف SW: بيئة البرنامج التي يتم فيها تشغيل المنتج
• الهدف HW: بيئة الأجهزة التي يتم تشغيل المنتج فيها
• أخرى: معلومات المورد أو المنتج

مثال CPE يبدو كالتالي:

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

يعني السطر أن CPE الإصدار 2.3 يصف أحد مكونات التطبيق من الشركة المصنعة pivotal_software باسم spring_frameworkالإصدار 3.0.0. إذا فتحنا ثغرة CVE-2014-0225 في NVD ، يمكننا أن نرى إشارة إلى CPE هذا. المشكلة الأولى التي يجب ملاحظتها على الفور هي أن CVE في NVD ، وفقًا لـ CPE ، تشير إلى وجود مشكلة في إطار العمل ، وليس في مكون معين. بمعنى ، إذا كان المطورون مرتبطين بإحكام بإطار العمل ، ولا تنطبق الثغرة الأمنية المحددة على تلك الوحدات النمطية التي يستخدمها المطورون ، فسيتعين على أخصائي الأمان بطريقة ما تفكيك CVE والتفكير في التحديث.



يتم استخدام عنوان URL أيضًا بواسطة أدوات SCA. تنسيق عنوان url للحزمة هو كما يلي:

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

• Sheme: سيكون هناك دائمًا "pkg" للإشارة إلى أن هذا عنوان url للحزمة (مطلوب)
• النوع: "نوع" الحزمة أو "بروتوكول" الحزمة ، مثل maven و npm و nuget و gem و pypi وما إلى ذلك. (شرط إلزامي)
• Namespace: بادئة اسم ما ، مثل معرف مجموعة Maven أو مالك صورة Docker أو مستخدم GitHub أو المؤسسة. اختياري ويعتمد على النوع.
• الاسم: اسم الحزمة (مطلوب)
• الإصدار: إصدار الحزمة
• المؤهلات: مؤهلات إضافية للحزمة ، مثل نظام التشغيل ، والهندسة المعمارية ، والتوزيع ، وما إلى ذلك. العنصر الاختياري والنوع المحدد.
• المسار الفرعي: مسار إضافي في الحزمة بالنسبة إلى جذر الحزمة

على سبيل المثال:

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 هو نظام أساسي على شبكة الإنترنت يقبل قائمة المواد الجاهزة (BOM) التي تم إنشاؤها بواسطة CycloneDX و SPDX ، أي المواصفات الجاهزة حول التبعيات الحالية. هذا ملف XML مع وصف التبعيات - الاسم ، التجزئة ، عنوان url للحزمة ، الناشر ، الترخيص. بعد ذلك ، يوزع مسار التبعية BOM ، وينظر في CVEs المتاحة للتبعيات المحددة من قاعدة بيانات الثغرات الأمنية (NVD ، Sonatype OSS Index ...) ، ثم يبني الرسوم البيانية ، ويحسب المقاييس ، ويحدث بانتظام بيانات حالة الثغرات الأمنية للمكون.



مثال لما قد يبدو عليه BOM في تنسيق 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>

يمكن استخدام قائمة مكونات الصنف ليس فقط كمعلمات إدخال لمسار التبعية ، ولكن أيضًا لجرد مكونات البرامج في سلسلة التوريد ، على سبيل المثال ، لتوفير البرامج للعميل. في عام 2014 ، تم اقتراح قانون الشفافية وإدارة سلسلة التوريد السيبراني لعام 2014 للنظر فيه في الولايات المتحدة ، والذي نص على أنه عند شراء برنامج ، أي دولة. يجب على المؤسسة أن تطلب BOM لمنع استغلال المكونات الضعيفة ، لكن القانون لم يدخل حيز التنفيذ أبدًا.



بالعودة إلى SCA ، فإن Dependency Track لديه تكامل خارج الصندوق مع منصات الإخطار مثل Slack وأنظمة إدارة الثغرات الأمنية مثل Kenna Security. يجب أن يقال أيضًا أن Dependency Track ، من بين أشياء أخرى ، يكتشف الإصدارات القديمة من الحزم ويوفر معلومات حول التراخيص (بسبب دعم SPDX).



إذا تحدثنا عن جودة SCA ، فهناك فرق جوهري.



لا يقبل مسار التبعية المشروع كمدخلات ، ولكنه يقبل قائمة المواد. هذا يعني أنه إذا أردنا التحقق من المشروع ، فسنحتاج أولاً إلى إنشاء bom.xml ، على سبيل المثال ، باستخدام CycloneDX. وبالتالي ، يعتمد مسار التبعية بشكل مباشر على CycloneDX. في نفس الوقت ، يسمح بالتخصيص. لذلك كتب فريق OZON وحدة CycloneDX لبناء ملفات BOM لمشاريع Golang لمزيد من المسح عبر مسار التبعية.



نيكزس آي كيوهو أحد حلول SCA التجارية من Sonatype ، وهو جزء من نظام Sonatype البيئي ، والذي يتضمن أيضًا Nexus Repository Manager. يمكن لـ Nexus IQ قبول كل من أرشيفات الحرب (لمشاريع جافا) باعتبارها بيانات إدخال عبر واجهة الويب أو واجهة برمجة التطبيقات ، و BOM ، إذا لم تتمكن مؤسستك من إعادة البناء من CycloneDX إلى حل جديد. على عكس الحلول مفتوحة المصدر ، لا يشير معدل الذكاء إلى CPE / PURL للمكون المحدد والثغرة الأمنية المقابلة في قاعدة البيانات ، ولكنه يأخذ أيضًا في الاعتبار البحث الخاص به ، على سبيل المثال ، اسم الوظيفة أو الفئة المعرضة للخطر. ستتم مناقشة آليات معدل الذكاء لاحقًا في تحليل النتائج.



دعنا نلخص بعض الميزات الوظيفية ، وننظر أيضًا في اللغات المدعومة للتحليل:





وظائف





فرص الاندماج

فحص التبعية

البداية الأولى

لنقم بتشغيل Dependency Check على تطبيق DVJA ضعيف بشكل متعمد .



للقيام بذلك ، سوف نستخدم برنامج Dependency Check Maven Plugin :

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

نتيجة لذلك ، سوف تظهر تبعية-check-report.html في الدليل الهدف.







لنفتح الملف. بعد المعلومات الموجزة حول العدد الإجمالي للثغرات الأمنية ، يمكننا رؤية معلومات حول نقاط الضعف بمستوى عالٍ من الخطورة والثقة ، تشير إلى الحزمة ، CPE ، رقم CVE.



يتبع ذلك معلومات أكثر تفصيلاً ، لا سيما ما استند إليه الدليل ، أي قائمة مواد معينة.







يأتي بعد ذلك وصف CPE و PURL و CVE. بالمناسبة ، لم يتم إرفاق توصيات الإصلاح بسبب غيابها في قاعدة بيانات NVD.







لمراجعة نتائج الفحص بشكل منهجي ، يمكنك تكوين Nginx مع الحد الأدنى من الإعدادات ، أو إرسال العيوب الناتجة إلى نظام إدارة العيوب الذي يدعم موصلات التحقق من التبعية. على سبيل المثال ، Defect Dojo.

مسار التبعية

التركيب

يعد Dependency Track ، بدوره ، نظامًا أساسيًا على الويب به مخططات عرض ، لذلك لا توجد مشكلة حادة في تخزين العيوب في حل جهة خارجية.

هناك البرامج النصية التالية المدعومة للتثبيت: Docker ، WAR ، Executable WAR.

البداية الأولى

انتقل إلى عنوان URL للخدمة قيد التشغيل. ندخل من خلال admin / admin ، ونغير اسم المستخدم وكلمة المرور ، ثم نصل إلى لوحة التحكم الرئيسية. الشيء التالي الذي سنفعله هو إنشاء مشروع لتطبيق اختبار Java في الصفحة الرئيسية / المشاريع → إنشاء مشروع . لنأخذ DVJA كمثال.







نظرًا لأن مسار التبعية لا يمكنه قبول قائمة مكونات الصنف إلا كمدخلات ، يجب استرداد قائمة مكونات الصنف. استخدام دعونا في CycloneDX مخضرم البرنامج المساعد :

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

نحصل على bom.xml ونقوم بتحميل الملف في المشروع الذي تم إنشاؤه DVJA → التبعيات → تحميل BOM .



دعنا ننتقل إلى الإدارة ← المحللات. نحن نتفهم أنه لدينا فقط محلل داخلي ممكّن ، بما في ذلك NVD. سنقوم أيضًا بتوصيل مؤشر Sonatype OSS.







وبالتالي ، سوف نحصل على الصورة التالية لمشروعنا:







أيضًا في القائمة ، يمكنك العثور على ثغرة واحدة تنطبق على Sonatype OSS:







خيبة الأمل الرئيسية هي أن Dependency Track لم يعد يقبل تقارير Dependency Check xml. كانت آخر الإصدارات المدعومة من تكامل Dependency Check 1.0.0 - 4.0.2 ، بينما اختبرت 5.3.2.



إليك مقطع فيديو ( والآن ) عندما كان لا يزال ممكنًا.

Nexus IQ

البداية الأولى

يتم تثبيت Nexus IQ من أرشيفات التوثيق ، لكننا قمنا بتجميع صورة Docker لهذا الغرض.



بعد تسجيل الدخول إلى وحدة التحكم ، تحتاج إلى إنشاء منظمة وتطبيق.















كما ترى ، يعد الإعداد في حالة معدل الذكاء أكثر تعقيدًا بعض الشيء ، لأننا نحتاج أيضًا إلى إنشاء سياسات قابلة للتطبيق على "المراحل" المختلفة (التطوير ، والبناء ، والمسرح ، والإصدار). يعد هذا ضروريًا لمنع المكونات الضعيفة أثناء تحركها على طول خط الأنابيب بالقرب من المنتج ، أو حظرها بمجرد دخولها إلى Nexus Repo عند تنزيلها بواسطة المطورين.



لتشعر بالفرق بين المصدر المفتوح والمؤسسة ، دعنا نجري نفس الفحص من خلال Nexus IQ بنفس الطريقة من خلال المكون الإضافي Maven ، بعد أن أنشأنا مسبقًا تطبيق اختبار في واجهة 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>

اتبع عنوان URL للتقرير الذي تم إنشاؤه في واجهة الويب الخاصة بـ IQ:







هنا يمكنك رؤية جميع انتهاكات السياسة بمستويات مختلفة من الأهمية (من المعلومات إلى الأمان الحرجة). يعني الحرف D الموجود بجوار المكون أن المكون هو تبعية مباشرة ، ويعني الحرف T الموجود بجوار المكون أن المكون تبعية انتقالية ، أي أنه متعد.



بالمناسبة ، أفاد تقرير Snyk's State of Open Source Security لعام 2020 أن أكثر من 70٪ من الثغرات الأمنية مفتوحة المصدر الموجودة في Node.js و Java و Ruby هي في تبعيات متعدية.



إذا فتحنا أحد انتهاكات سياسة Nexus IQ ، فيمكننا رؤية وصف المكون ، بالإضافة إلى مخطط الإصدار ، الذي يعرض موقع الإصدار الحالي على المخطط الزمني ، وكذلك في أي نقطة لم تعد الثغرة الأمنية عرضة للخطر. يوضح ارتفاع الشمعدانات على الرسم البياني مدى شعبية هذا المكون.







إذا انتقلت إلى قسم الثغرات الأمنية وكشفت عن CVE ، فيمكنك قراءة وصف لهذه الثغرة الأمنية ، وتوصيات للتخلص منها ، بالإضافة إلى سبب انتهاك هذا المكون ، أي وجود فئة DiskFileitem.class.











دعنا نلخص فقط مكونات Java التابعة لجهات خارجية ، مع إزالة مكونات js. بين قوسين ، سوف نشير إلى عدد تلك الثغرات الأمنية التي تم العثور عليها خارج NVD.



إجمالي نسبة الذكاء في Nexus:

• التبعيات الممسوحة ضوئيًا: 62
• التبعيات المستضعفة: 16
• تم العثور على ثغرات أمنية: 42 (8 سوناتيب ديسيبل)

فحص التبعية الإجمالية:

• التبعيات الممسوحة ضوئيًا: 47
• التبعيات المستضعفة: 13
• تم العثور على ثغرات أمنية: 91 (14 sonatype oss)

إجمالي مسار التبعية:

• التبعيات الممسوحة ضوئيًا: 59
• التبعيات المستضعفة: 10
• تم العثور على نقاط ضعف: 51 (1 sonatype Ooss)

في الخطوات التالية ، سنقوم بتحليل النتائج ومعرفة أي من هذه الثغرات هو عيب حقيقي وأيها إيجابي كاذب.

تنصل

هذه المراجعة ليست حقيقة لا يمكن إنكارها. لم يكن للمؤلف هدف لتمييز أداة منفصلة عن الآخرين. كان الهدف من المراجعة إظهار كيفية عمل أدوات SCA وكيفية التحقق من نتائجها.

مقارنة النتائج

الشروط:



إيجابية كاذبة للثغرات الأمنية في مكونات الطرف الثالث هي:

• عدم تطابق CVE مع المكون المحدد
• , 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.
• على سبيل المثال ، تم العثور على مكافحة التطرف العنيف في مكون ربيع الويب ، وبعد ذلك تشير SCA إلى نفس مكافحة التطرف العنيف في المكونات الأخرى لإطار الربيع ، في حين أن مكافحة التطرف العنيف لا علاقة لها بالمكونات الأخرى. في هذه الحالة ، ستكون موجبة كاذبة.

تم اختيار مشروع المصدر المفتوح DVJA ليكون موضوع البحث. اشتملت الدراسة على مكونات جافا فقط (بدون js).

نتائج موجزة

دعنا ننتقل مباشرة إلى نتيجة المراجعة اليدوية للثغرات الأمنية المحددة. يمكن العثور على التقرير الكامل لكل CVE في الملحق.



نتائج موجزة لجميع نقاط الضعف:



النتائج الموجزة حسب المكون:



دعونا نبني الرسوم البيانية المرئية لتقييم نسبة الإيجابية الزائفة والسلبية الزائفة إلى إجمالي عدد نقاط الضعف. يتم تمييز المكونات أفقيًا ، ويتم تمييز الثغرات التي تم تحديدها فيها عموديًا.















في المقابل ، أجرى فريق Sonatype دراسة مماثلة لاختبار 1،531 مكونًا باستخدام OWASP Dependency Check. كما نرى ، فإن نسبة الضوضاء إلى المشغلات الصحيحة يمكن مقارنتها بنتائجنا.





المصدر: www.sonatype.com/why-precision-matters-ebook



دعونا نلقي نظرة على بعض CVEs من نتائج الفحص لدينا لفهم سبب هذه النتائج.

المزيد من التفاصيل

# 1

دعونا نلقي نظرة على بعض النقاط المثيرة للاهتمام في Sonatype Nexus IQ أولاً.



يشير Nexus IQ إلى مشكلة إلغاء التسلسل مع القدرة على تنفيذ RCE في Spring Framework عدة مرات. CVE-2016-1000027 في spring-web: 3.0.5 لأول مرة ، و CVE-2011-2894 في سياق الربيع: 3.0.5 ونواة الربيع: 3.0.5. في البداية ، يبدو أن هناك ازدواجية في نقاط الضعف عبر العديد من مكافحة التطرف العنيف. إذا نظرت إلى CVE-2016-1000027 و CVE-2011-2894 في قاعدة بيانات NVD ، فيبدو أن كل شيء واضح





وصف CVE-2011-2894 من NVD :





وصف CVE-2016-1000027 من NVD :





CVE-2011-2894 نفسها مشهورة جدًا. صنف تقرير المصدر الأبيض لعام 2011 هذه التطرف العنيف على أنها من أكثر الحالات التي يتم مواجهتها بشكل متكرر. أوصاف CVE-2016-100027 ، من حيث المبدأ ، قليلة في NVD ، ويبدو أنها قابلة للتطبيق فقط لـ Spring Framework 4.1.4. ألق نظرة على المرجع وهنا يصبح أكثر أو أقل وضوحًا. نحن نفهم من مقالةRemoteInvocationSerializingExporter Tenable أنه بالإضافة إلى الثغرة الأمنية في CVE-2011-2894 ، تمت ملاحظة الثغرة الأمنية في HttpInvokerServiceExporter. هذا ما يخبرنا به Nexus IQ:







ومع ذلك ، لا يوجد شيء مثل هذا في NVD ، ولهذا السبب يتلقى فحص التبعية ومسار التبعية سلبية خاطئة.



أيضًا ، من وصف CVE-2011-2894 ، يمكنك أن تفهم أن الثغرة موجودة بالفعل في سياق الربيع: 3.0.5 والربيع الأساسي: 3.0.5. يمكن العثور على تأكيد لهذا في المقالة من الشخص الذي وجد هذه الثغرة الأمنية.

# 2

إذا قمنا بدراسة الثغرة الأمنية CVE-2016-4003 ، فسوف نفهم أنه تم إصلاحها في الإصدار 2.3.28 ، ومع ذلك فإن Nexus IQ يعلمنا بذلك. هناك ملاحظة في وصف الثغرة الأمنية:







أي أن الثغرة موجودة فقط بالاقتران مع نسخة قديمة من JRE ، والتي قرروا تحذيرنا بشأنها. ومع ذلك ، فإننا نعتبر هذا خطأ إيجابيًا ، على الرغم من أنه ليس الأسوأ.

رقم 3

إذا نظرنا إلى أوصاف CVE-2017-9804 و CVE-2017-7672 ، فسوف نفهم أن المشكلة هي URLValidator class، وتتبع CVE-2017-9804 من CVE-2017-7672. لا يحمل وجود الثغرة الأمنية الثانية أي حمولة ، باستثناء أن شدتها قد نمت إلى عالية ، لذلك يمكن اعتبار ذلك ضوضاء غير ضرورية.



بشكل عام ، لم يتم العثور على إيجابيات خاطئة أخرى لـ Nexus IQ.

# 4

هناك العديد من الأشياء التي تميز معدل الذكاء عن القرارات الأخرى.





تقول CVE في NVD إنها قابلة للتطبيق فقط للإصدارات 5.2.x حتى 5.2.3 و 5.1.x حتى 5.1.13 والإصدارات 5.0.x حتى 5.0.16 ، ومع ذلك ، إذا نظرنا إلى وصف CVE في Nexus IQ ، سنرى ما يلي:

إشعار إرشادي للانحراف: اكتشف فريق البحث الأمني ​​في Sonatype أن هذه الثغرة الأمنية قد تم تقديمها في الإصدار 3.0.2.RELEASE وليس 5.0.x كما هو مذكور في الاستشارة.



يتبع ذلك إثبات PoC لهذه الثغرة الأمنية ، والتي تفيد بوجودها في الإصدار 3.0.5.



يتم إرسال سلبية كاذبة إلى التحقق من التبعية ومسار التبعية.

# 5

لنلقِ نظرة على النتائج الإيجابية الخاطئة لفحص التبعية ومسار التبعية.



تبرز عملية التحقق من التبعية من حيث أنها تعكس تحديات التطرف العنيف التي تنطبق على إطار العمل بأكمله في NVD على تلك المكونات التي لا تنطبق عليها هذه التعقيدات. ينطبق هذا على CVE-2012-0394 ، CVE-2013-2115 ، CVE -porate114 ، CVE-2015-0899 ، CVE-2015-2992 ، CVE-2016-1181 ، CVE-2016-1182 ، والتي "تم تثبيتها" إلى الدعامات - تاجليب: 1.3.8 و الدعامات - البلاط - 1.3.8. لا علاقة لهذه المكونات بما هو موصوف في CVE - معالجة الطلب والتحقق من صحة الصفحة وما إلى ذلك. ويرجع ذلك إلى حقيقة أن العامل المشترك بين هذه مكافحة التطرف العنيف والمكونات هو إطار العمل فقط ، ولهذا السبب اعتبرته أداة التحقق من التبعية ثغرة أمنية.



نفس الوضع مع spring-tx: 3.0.5 ، وحالة مماثلة مع الدعامات الأساسية: 1.3.8. بالنسبة لـ struts-core ، وجد فحص التبعية ومسار التبعية الكثير من نقاط الضعف التي يمكن تطبيقها بالفعل على struts2-core ، والتي تعد في الأساس إطار عمل منفصل. في هذه الحالة ، فهم Nexus IQ الصورة بشكل صحيح وفي تلك CVEs التي أصدرها ، أشار إلى أن الدعامات الأساسية انتهت من عمرها وأنه كان من الضروري الانتقال إلى struts2-core.

# 6

في بعض الحالات ، من غير العدل تفسير خطأ صريح في فحص التبعية وتتبع التبعية. على وجه الخصوص CVE-2013-4152 ، CVE-2013-6429 ، CVE-2013-6430 ، CVE-2013-7315 ، CVE-2014-0054 ، CVE-2014-0225 ، CVE -25 ، وهي فحص التبعية ومسار التبعية يشير إلى Spring-core: 3.0.5 تشير في الواقع إلى Spring-web: 3.0.5. في الوقت نفسه ، تم العثور على بعض من هذه التطرف العنيف ، ومع ذلك ، حددها معدل الذكاء لمكون آخر. نظرًا لأن هذه الثغرات الأمنية لم يتم العثور عليها في Spring-core ، فلا يمكن القول إنها ليست في إطار العمل ، من حيث المبدأ ، وأن أدوات المصدر المفتوح أشارت بشكل صحيح إلى هذه الثغرات (لقد فاتتهم قليلاً).

الاستنتاجات

كما نرى ، فإن تحديد موثوقية الثغرات الأمنية التي تم تحديدها من خلال المراجعة اليدوية لا يعطي نتائج واضحة ، مما يسبب مشاكل مثيرة للجدل. النتائج هي أن حل Nexus IQ لديه أقل معدل موجب كاذب وأعلى دقة.



بادئ ذي بدء ، يرجع هذا إلى حقيقة أن فريق Sonatype قد وسع الوصف لكل ثغرة من ثغرات CVE من NVD في قواعد بياناتهم ، مع تحديد فئة أو وظيفة الثغرة الأمنية لإصدار معين من المكون ، وإجراء بحث إضافي (على سبيل المثال ، التحقق من نقاط الضعف على أقدم إصدارات البرامج).



تلعب نقاط الضعف تلك التي لم يتم تضمينها في NVD تأثيرًا مهمًا على النتائج ، ولكنها مع ذلك موجودة في قاعدة بيانات Sonatype بعلامة SONATYPE. وفقًا لحالة الثغرات الأمنية مفتوحة المصدر لعام 202045٪ من الثغرات الأمنية مفتوحة المصدر لم يتم إبلاغ NVD عنها. وفقًا لقاعدة بيانات WhiteSource ، يتم نشر 29٪ فقط من جميع الثغرات الأمنية مفتوحة المصدر التي تم الإبلاغ عنها خارج NVD ، وهذا هو سبب أهمية البحث في مكان آخر عن الثغرات أيضًا.



نتيجة لذلك ، يُنتج فحص التبعية الكثير من الضوضاء ، ويفقد بعض المكونات الضعيفة. تنتج Dependency Track ضوضاء أقل وتكشف عن عدد كبير من المكونات ، والتي لا تؤذي العين في واجهة الويب بصريًا.



ومع ذلك ، تُظهر الممارسة أن المصدر المفتوح هو الذي يجب أن يكون الخطوات الأولى على الطريق لنضج DevSecOps. أول شيء يجب التفكير فيه من أجل تضمين SCA في التنمية هو العمليات ، أي التفكير مع الإدارة والإدارات ذات الصلة حول الشكل الذي يجب أن تبدو عليه العمليات المثالية في مؤسستهم. قد يتضح أنه بالنسبة لمؤسستك ، في البداية ، سيغطي فحص التبعية أو تتبع التبعية جميع احتياجات العمل ، وستكون حلول المؤسسات استمرارًا منطقيًا بسبب التعقيد المتزايد للتطبيقات المطورة.