DevSecOps: Prinzipien und Vergleich von SCA. Teil eins

Die Bedeutung der Analyse von Softwarekomponenten von Drittanbietern (Software Composition Analysis - SCA) im Entwicklungsprozess nimmt zu, da die jährlichen Berichte über Schwachstellen von Open Source-Bibliotheken veröffentlicht werden, die von Synopsys, Sonatype, Snyk, White Source veröffentlicht werden. Laut dem Stand der Open Source-Sicherheitslücken 2020Die Anzahl der identifizierten Open Source-Schwachstellen stieg 2019 im Vergleich zum Vorjahr um fast das 1,5-fache, während Open Source-Komponenten von 60% auf 80% der Projekte verwendet werden. Wenn Sie sich einer unabhängigen Meinung zuwenden, sind SCA-Prozesse eine separate Praxis von OWASP SAMM und BSIMM als Indikator für die Reife. Im ersten Halbjahr 2020 hat OWASP den neuen OWASP-Standard zur Überprüfung von Softwarekomponenten (SCVS) veröffentlicht, der Best Practices für die Überprüfung von Komponenten von Drittanbietern in der Lieferkette enthält DURCH.







Einer der aufschlussreichsten Fälle ereignete sich im Mai 2017 mit Equifax. Unbekannte Angreifer beschlagnahmten Informationen über 143 Millionen Amerikaner, darunter vollständige Namen, Adressen, Sozialversicherungsnummern und Führerscheine. In 209.000 Fällen enthielten die Dokumente auch Informationen zu den Bankkarten der Opfer. Dieses Leck war auf die Ausnutzung einer kritischen Sicherheitsanfälligkeit in Apache Struts 2 (CVE-2017-5638) zurückzuführen, während das Update bereits im März 2017 veröffentlicht wurde. Das Unternehmen hatte zwei Monate Zeit, um das Update zu installieren, aber niemand kümmerte sich darum.



In diesem Artikel wird das Problem der Auswahl eines Tools zur Durchführung von SCA im Hinblick auf die Qualität der Analyseergebnisse erörtert. Es wird auch einen Funktionsvergleich der Werkzeuge geben. Der Einbettungsprozess in CI / CD und die Integrationsmöglichkeiten bleiben künftigen Veröffentlichungen überlassen. Eine breite Liste von Tools wurde von OWASP auf seiner Website vorgestellt . Im Rahmen der aktuellen Überprüfung werden wir jedoch nur auf das beliebteste Open-Source-Tool Dependency Check, den etwas weniger bekannten Open-Source-Plattform Dependency Track und die Sonatype Nexus IQ Enterprise-Lösung eingehen. Wir werden auch herausfinden, wie diese Lösungen funktionieren, und die Ergebnisse vergleichen, die für falsch positive Ergebnisse erhalten wurden.

Arbeitsprinzip

Dependency Check ist ein Dienstprogramm (CLI, Maven, Jenkins-Modul, Ant), das Projektdateien analysiert, Informationen zu Abhängigkeiten (Paketname, Gruppen-ID, Spezifikationstitel, Version ...) sammelt und eine CPE-Zeile (Common Platform Enumeration), Package erstellt URL (PURL) und erkennt Schwachstellen für CPE / PURL aus Datenbanken (NVD, Sonatype OSS Index, NPM Audit API ...) und erstellt dann einen einmaligen Bericht im HTML-, JSON-, XML-Format ...



Sehen wir uns an, wie das CPE aussieht:

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

• Teil: Ein Hinweis darauf, dass die Komponente zur Anwendung (a), zum Betriebssystem (o), zur Hardware (h) gehört (Pflichtelement)
• Anbieter: Name des Herstellers des Produkts (Erforderlich)
• Produkt: Produktname (Erforderlicher Artikel)
• Version: Komponentenversion (Veralteter Artikel)
• Update: Aktualisieren Sie das Paket
• Ausgabe: Legacy-Version (veraltet)
• Sprache: Die in RFC-5646 definierte Sprache
• SW Edition: Softwareversion
• Ziel-SW: Die Softwareumgebung, in der das Produkt ausgeführt wird
• Ziel-HW: Die Hardwareumgebung, in der das Produkt ausgeführt wird
• Sonstiges: Lieferanten- oder Produktinformationen

Ein Beispiel für CPE sieht folgendermaßen aus:

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

Die Zeile bedeutet, dass CPE Version 2.3 eine Komponente der Anwendung des Herstellers pivotal_software mit dem Namen spring_frameworkVersion 3.0.0 beschreibt. Wenn wir die Sicherheitsanfälligkeit CVE-2014-0225 in NVD öffnen , wird diese CPE erwähnt. Das erste Problem, das sofort bemerkt werden sollte, ist, dass das CVE in NVD laut CPE meldet, dass es ein Problem im Framework und nicht in einer bestimmten Komponente gibt. Das heißt, wenn die Entwickler eng mit dem Framework verbunden sind und die identifizierte Sicherheitsanfälligkeit nicht für die von den Entwicklern verwendeten Module gilt, muss der Sicherheitsspezialist dieses CVE irgendwie zerlegen und über eine Aktualisierung nachdenken.



Die URL wird auch von SCA-Tools verwendet. Das Paket-URL-Format lautet wie folgt:

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

• Sheme: Es wird immer 'pkg' angezeigt , das angibt, dass dies die URL des Pakets ist (Erforderlich).
• Typ: Der "Typ" des Pakets oder das "Protokoll" des Pakets, z. B. Maven, Npm, Nuget, Gem, Pypi usw. (Obligatorische Klausel)
• Namespace: Einige Namenspräfixe, z. B. Maven-Gruppen-ID, Docker-Image-Eigentümer, GitHub-Benutzer oder Organisation. Optional und abhängig vom Typ.
• Name: Paketname (Erforderlich)
• Version: Paketversion
• Qualifizierer: Zusätzliche Qualifizierungen für das Paket, z. B. Betriebssystem, Architektur, Verteilung usw. Optionales und typspezifisches Element.
• Unterpfad: Zusätzlicher Pfad im Paket relativ zum Paketstamm

Zum Beispiel:

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 ist eine lokale Webplattform, die vorgefertigte Stücklisten akzeptiert, die von CycloneDX und SPDX erstellt wurden, dh vorgefertigte Spezifikationen zu vorhandenen Abhängigkeiten. Dies ist eine XML-Datei, die Abhängigkeiten beschreibt - Name, Hashes, Paket-URL, Herausgeber, Lizenz. Als Nächstes analysiert Dependency Track die Stückliste, untersucht die CVEs, die für die identifizierten Abhängigkeiten aus der Schwachstellendatenbank (NVD, Sonatype OSS Index ...) verfügbar sind, erstellt dann Diagramme, berechnet Metriken und aktualisiert regelmäßig die Schwachstellenstatusdaten der Komponenten.



Ein Beispiel dafür, wie eine Stückliste im XML-Format aussehen könnte:

<?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>

Die Stückliste kann nicht nur als Eingabeparameter für die Abhängigkeitsverfolgung verwendet werden, sondern auch zur Bestandsaufnahme von Softwarekomponenten in der Lieferkette, beispielsweise zur Bereitstellung von Software für den Kunden. Im Jahr 2014 wurde sogar das Cyber ​​Supply Chain Management- und Transparenzgesetz von 2014 zur Prüfung in den USA vorgeschlagen , in dem festgelegt wurde, dass beim Kauf von Software jeder Staat. Die Einrichtung muss eine Stückliste anfordern, um die Ausbeutung anfälliger Komponenten zu verhindern. Das Gesetz ist jedoch nie in Kraft getreten.



Zurück zu SCA: Dependency Track ist sofort in Notification Platforms wie Slack und Schwachstellenmanagementsysteme wie Kenna Security integriert. Es sollte auch gesagt werden, dass Dependency Track unter anderem veraltete Versionen von Paketen erkennt und Informationen zu Lizenzen bereitstellt (aufgrund der Unterstützung von SPDX).



Wenn wir speziell über die Qualität von SCA sprechen, gibt es einen grundlegenden Unterschied.



Der Abhängigkeitstrack akzeptiert nicht das Projekt als Eingabe, sondern die Stückliste. Das heißt, wenn wir das Projekt überprüfen wollen, müssen wir zuerst bom.xml generieren, zum Beispiel mit CycloneDX. Somit ist Dependency Track direkt von CycloneDX abhängig. Gleichzeitig können Anpassungen vorgenommen werden. Daher hat das OZON-Team das CycloneDX-Modul geschrieben , um Stücklistendateien für Golang-Projekte zum weiteren Scannen über den Abhängigkeits-Track zu erstellen.



Nexus IQIst eine kommerzielle SCA-Lösung von Sonatype, die Teil des Sonatype-Ökosystems ist und auch den Nexus Repository Manager enthält. Nexus IQ kann sowohl Kriegsarchive (für Java-Projekte) über die Weboberfläche oder API als auch Stücklisten als Eingabedaten akzeptieren, wenn es Ihrer Organisation nicht gelungen ist, von CycloneDX auf eine neue Lösung umzustellen. Im Gegensatz zu Open Source-Lösungen bezieht sich IQ nicht nur auf die CPE / PURL für die identifizierte Komponente und die entsprechende Sicherheitsanfälligkeit in der Datenbank, sondern berücksichtigt auch die eigene Forschung, beispielsweise den Namen der anfälligen Funktion oder Klasse. IQ-Mechanismen werden später in der Analyse der Ergebnisse diskutiert.



Lassen Sie uns einige der Funktionsmerkmale zusammenfassen und auch die unterstützten Sprachen für die Analyse berücksichtigen:





Funktionalität





Integrationsmöglichkeiten

Abhängigkeitsprüfung

Erster Start

Lassen Sie uns die Abhängigkeitsprüfung für eine absichtlich anfällige DVJA- Anwendung ausführen .



Dazu verwenden wir das Dependency Check Maven Plugin :

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

Infolgedessen wird dependency-check-report.html im Zielverzeichnis angezeigt.







Öffnen wir die Datei. Nach den zusammenfassenden Informationen zur Gesamtzahl der Schwachstellen werden Informationen zu Schwachstellen mit einem hohen Schweregrad und Vertrauen angezeigt, die das Paket, die CPE und die CVE-Nummer angeben.



Darauf folgen detailliertere Informationen, insbesondere, worauf die Beweise beruhten, dh auf einer bestimmten Stückliste.







Als nächstes folgt die Beschreibung von CPE, PURL und CVE. Empfehlungen zur Korrektur sind übrigens nicht beigefügt, da sie nicht in der NVD-Datenbank enthalten sind.







Um die Scanergebnisse systematisch anzuzeigen, können Sie Nginx mit minimalen Einstellungen konfigurieren oder die resultierenden Fehler an das Fehlermanagementsystem senden, das die Abhängigkeitsprüfungsverbinder unterstützt. Zum Beispiel Defect Dojo.

Abhängigkeitsspur

Installation

Dependency Track ist wiederum eine Webplattform mit der Anzeige von Diagrammen, sodass es kein akutes Problem gibt, Fehler in einer Drittanbieterlösung zu speichern.

Es gibt die folgenden unterstützten Skripts für die Installation: Docker, WAR, Executable WAR.

Erster Start

Gehen Sie zur URL des laufenden Dienstes. Wir geben über admin / admin ein, ändern den Benutzernamen und das Passwort und gelangen dann zum Dashboard. Als Nächstes erstellen wir ein Projekt für die Java-Testanwendung unter Startseite / Projekte → Projekt erstellen . Nehmen wir als Beispiel DVJA.







Da die Abhängigkeitsspur nur eine Stückliste als Eingabe akzeptieren kann, muss diese Stückliste abgerufen werden. Verwenden wir das CycloneDX Maven Plugin :

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

Holen Sie sich bom.xml und laden Sie die Datei in das erstellte DVJA- Projekt hoch → Abhängigkeiten → Stückliste hochladen .



Gehen wir zu Administration → Analysatoren. Wir verstehen, dass nur der interne Analysator aktiviert ist, einschließlich NVD. Wir werden auch Sonatype OSS Index verbinden.







Daher erhalten wir das folgende Bild für unser Projekt:







In der Liste finden Sie auch eine Sicherheitsanfälligkeit für Sonatype OSS:







Die größte Enttäuschung war, dass Dependency Track XML-Berichte zur Abhängigkeitsprüfung nicht mehr akzeptiert. Die letzten unterstützten Versionen der Dependency Check-Integration waren 1.0.0 - 4.0.2, während ich 5.3.2 getestet habe.



Hier ist ein Video (und jetzt ), als es noch möglich war.

Nexus IQ

Erster Start

Das Nexus IQ wird aus den Dokumentationsarchiven installiert , aber wir haben zu diesem Zweck ein Docker-Image kompiliert.



Nach dem Anmelden an der Konsole müssen Sie eine Organisation und eine Anwendung erstellen.















Wie Sie sehen können, ist die Einrichtung im Fall von IQ etwas komplizierter, da wir auch Richtlinien erstellen müssen, die für verschiedene „Phasen“ (dev, build, stage, release) gelten. Dies ist erforderlich, um anfällige Komponenten zu blockieren, wenn sie sich entlang der Pipeline näher an das Produkt heranbewegen, oder um sie zu blockieren, sobald sie beim Herunterladen durch die Entwickler in das Nexus Repo gelangen.



Um den Unterschied zwischen Open Source und Enterprise zu spüren, führen wir denselben Scan über den Nexus IQ auf dieselbe Weise über das Maven-Plugin durch , nachdem zuvor eine Testanwendung in der NexusIQ-Oberfläche erstellt wurde 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>

Folgen Sie der URL zum generierten Bericht in der IQ-Weboberfläche:







Hier sehen Sie alle Richtlinienverstöße mit unterschiedlichen Signifikanzstufen (von Info bis Sicherheitskritisch). Der Buchstabe D neben der Komponente bedeutet, dass die Komponente eine direkte Abhängigkeit ist, und der Buchstabe T neben der Komponente bedeutet, dass die Komponente eine transitive Abhängigkeit ist, dh, sie ist transitiv.



Übrigens berichtet der Open Source-Sicherheitsbericht 2020 von Snyk, dass über 70% der in Node.js, Java und Ruby gefundenen Open Source-Schwachstellen in transitiven Abhängigkeiten sind.



Wenn wir einen Verstoß gegen die Nexus IQ-Richtlinie öffnen, sehen wir die Beschreibung der Komponente sowie das Versionsdiagramm, in dem der Speicherort der aktuellen Version auf der Zeitachse sowie der Zeitpunkt angegeben ist, an dem die Sicherheitsanfälligkeit nicht mehr anfällig ist. Die Höhe der Kerzenhalter in der Grafik zeigt die Beliebtheit dieser Komponente.







Wenn Sie zum Abschnitt "Sicherheitsanfälligkeiten" gehen und das CVE offenlegen, können Sie die Beschreibung dieser Sicherheitsanfälligkeit, Empfehlungen zur Beseitigung sowie den Grund für die Verletzung dieser Komponente, dh das Vorhandensein einer Klasse, lesen DiskFileitem.class.











Lassen Sie uns nur die Java-Komponenten von Drittanbietern zusammenfassen und die js-Komponenten entfernen. In Klammern geben wir die Anzahl der Schwachstellen an, die außerhalb des NVD gefunden wurden.



Gesamt-Nexus-IQ:

• Gescannte Abhängigkeiten: 62
• Gefährdete Abhängigkeiten: 16
• Gefundene Sicherheitslücken: 42 (8 Sonatyp db)

Total Dependency Check:

• Gescannte Abhängigkeiten: 47
• Gefährdete Abhängigkeiten: 13
• Gefundene Sicherheitslücken: 91 (14 Sonatyp Oss)

Total Dependency Track:

• Gescannte Abhängigkeiten: 59
• Gefährdete Abhängigkeiten: 10
• Gefundene Sicherheitslücken: 51 (1 Sonatyp oss)

Die nächsten Schritte bestehen darin, die erzielten Ergebnisse zu analysieren und herauszufinden, welche dieser Schwachstellen ein echter Defekt und welche falsch positiv ist.

Haftungsausschluss

Diese Bewertung ist keine unbestreitbare Wahrheit. Der Autor hatte nicht das Ziel, ein separates Instrument von anderen abzuheben. Ziel der Überprüfung war es zu zeigen, wie die SCA-Tools funktionieren und wie ihre Ergebnisse überprüft werden.

Vergleich der Ergebnisse

Bedingungen: Ein



falsches Positiv für Schwachstellen in Komponenten von Drittanbietern ist:

• CVE-Nichtübereinstimmung für die identifizierte Komponente
• , 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.
• Beispielsweise wurde CVE in einer Spring-Web-Komponente gefunden, wonach SCA in anderen Komponenten des Spring Framework auf dasselbe CVE verweist, während CVE nichts mit anderen Komponenten zu tun hat. In diesem Fall ist es falsch positiv.

Forschungsgegenstand ist das Open Source Projekt DVJA. Die Forschung umfasste nur Java-Komponenten (keine js).

Zusammenfassende Ergebnisse

Gehen wir direkt zum Ergebnis einer manuellen Überprüfung der identifizierten Schwachstellen. Den vollständigen Bericht zu jedem CVE finden Sie im Anhang.



Zusammenfassende Ergebnisse für alle Schwachstellen:



Zusammenfassende Ergebnisse nach Komponenten:



Lassen Sie uns visuelle Diagramme erstellen, um das Verhältnis von falsch positiv und falsch negativ zur Gesamtzahl der Schwachstellen zu bewerten. Komponenten werden horizontal markiert, und darin identifizierte Schwachstellen werden vertikal markiert.















Im Vergleich dazu wurde vom Sonatype-Team eine ähnliche Studie durchgeführt, um ein 1.531-Komponenten-Projekt mithilfe des OWASP-Abhängigkeitschecks zu testen. Wie wir sehen können, ist das Verhältnis von Rauschen zu korrekten Triggern mit unseren Ergebnissen vergleichbar.





Quelle: www.sonatype.com/why-precision-matters-ebook Schauen



wir uns einige CVEs aus unseren Scan-Ergebnissen an, um den Grund für diese Ergebnisse zu verstehen.

Mehr Details

# 1

Schauen wir uns zunächst einige interessante Punkte des Sonatype Nexus IQ an.



Nexus IQ weist auf ein Deserialisierungsproblem mit der Möglichkeit hin, RCE in Spring Framework mehrmals auszuführen. CVE-2016-1000027 im Spring-Web: 3.0.5 zum ersten Mal und CVE-2011-2894 im Spring-Kontext: 3.0.5 und Spring-Core: 3.0.5. Auf den ersten Blick scheint es eine doppelte Sicherheitslücke in mehreren CVEs zu geben. Wenn Sie sich CVE-2016-1000027 und CVE-2011-2894 in der NVD-Datenbank ansehen, scheint alles offensichtlich zu sein





Beschreibung von CVE-2011-2894 von NVD :





Beschreibung von CVE-2016-1000027 von NVD :





CVE-2011-2894 selbst ist ziemlich berühmt. Im White Source- Bericht 2011 wurde dieser CVE als einer der häufigsten eingestuft. Beschreibungen für CVE-2016-100027 sind im Prinzip ein wenig in NVD enthalten und scheinen nur für Spring Framework 4.1.4 anwendbar zu sein. Schauen Sie sich die Referenz an und hier wird es mehr oder weniger klar. Aus dem Artikel von Tenable geht hervor, dass zusätzlich zu der Sicherheitsanfälligkeit RemoteInvocationSerializingExporterin CVE-2011-2894 die Sicherheitsanfälligkeit in beobachtet wird HttpInvokerServiceExporter. Dies sagt uns Nexus IQ:







Trotzdem gibt es in NVD nichts Vergleichbares, weshalb Dependency Check und Dependency Track falsch negativ sind.



Aus der Beschreibung von CVE-2011-2894 können Sie auch ersehen, dass die Sicherheitsanfälligkeit tatsächlich sowohl im Spring-Kontext: 3.0.5 als auch im Spring-Core: 3.0.5 vorhanden ist. Eine Bestätigung hierzu finden Sie im Artikel der Person, die diese Sicherheitsanfälligkeit gefunden hat.

# 2

Wenn wir die Sicherheitsanfälligkeit CVE-2016-4003 untersuchen, werden wir verstehen, dass sie in Version 2.3.28 behoben wurde. Nexus IQ informiert uns jedoch darüber. Die Beschreibung der Sicherheitsanfälligkeit enthält einen Hinweis:







Das heißt, die Sicherheitsanfälligkeit besteht nur in Verbindung mit einer veralteten Version der JRE, vor der sie uns warnen wollten. Trotzdem halten wir dies für falsch positiv, wenn auch nicht für das schlechteste.

Nummer 3

Wenn wir uns die Beschreibungen für CVE-2017-9804 und CVE-2017-7672 ansehen, werden wir verstehen, dass das Problem darin besteht URLValidator class, und CVE-2017-9804 folgt aus CVE-2017-7672. Das Vorhandensein der zweiten Sicherheitsanfälligkeit trägt keine Nutzlast, außer dass der Schweregrad auf Hoch angestiegen ist, sodass dies als unnötiges Rauschen angesehen werden kann.



Insgesamt wurden für den Nexus IQ keine weiteren falsch positiven Ergebnisse gefunden.

# 4

Es gibt mehrere Dinge, die den IQ von anderen Entscheidungen unterscheiden.





Das CVE in NVD besagt, dass es nur für die Versionen 5.2.x bis 5.2.3, 5.1.x bis 5.1.13 und die Versionen 5.0.x bis 5.0.16 gilt, wenn wir uns die CVE-Beschreibung im Nexus IQ ansehen.

In diesem Fall wird Folgendes angezeigt : Hinweis zur abweichenden Empfehlung: Das Sonatype-Sicherheitsforschungsteam hat festgestellt, dass diese Sicherheitsanfälligkeit in Version 3.0.2.RELEASE und nicht in 5.0.x eingeführt wurde, wie in der Empfehlung angegeben.



Darauf folgt ein PoC für diese Sicherheitsanfälligkeit, der meldet, dass er in Version 3.0.5 vorhanden ist.



False Negative wird an Dependency Check und Dependency Track gesendet.

# 5

Schauen wir uns False Positive für Dependency Check und Dependency Track an.



Die Abhängigkeitsprüfung zeichnet sich dadurch aus, dass sie die CVEs widerspiegelt, die für das gesamte Framework in NVD gelten, sowie die Komponenten, für die diese CVEs nicht gelten. Dies gilt für CVE-2012-0394, CVE-2013-2115, CVE-2014-0114, CVE-2015-0899, CVE-2015-2992, CVE-2016-1181, CVE-2016-1182, deren Abhängigkeitsprüfung "vermasselt" wurde. zu struts-taglib: 1.3.8 und struts-tiles-1.3.8. Diese Komponenten haben nichts mit dem zu tun, was in CVE beschrieben wird - Anforderungsverarbeitung, Seitenvalidierung usw. Dies liegt an der Tatsache, dass diese CVEs und die Komponenten nur das Framework gemeinsam haben, weshalb Dependency Check dies als Sicherheitslücke ansah.



Die gleiche Situation mit spring-tx: 3.0.5 und eine ähnliche Situation mit Federbeinkern: 1.3.8. Für Struts-Core haben Dependency Check und Dependency Track viele Schwachstellen gefunden, die tatsächlich für Struts2-Core gelten, bei dem es sich im Wesentlichen um ein separates Framework handelt. In diesem Fall verstand Nexus IQ das Bild richtig und zeigte in den von ihm herausgegebenen CVEs an, dass der Struts-Core das Ende seiner Lebensdauer erreicht hatte und es notwendig war, zu Struts2-Core zu wechseln.

# 6

In einigen Situationen ist es unfair, einen expliziten Fehler bei der Abhängigkeitsprüfung und der Abhängigkeitsverfolgung zu interpretieren. Insbesondere CVE-2013-4152, CVE-2013-6429, CVE-2013-6430, CVE-2013-7315, CVE-2014-0054, CVE-2014-0225, CVE-2014-0225, die Abhängigkeitsprüfung und Abhängigkeitsverfolgung sind bezogen auf Federkern: 3.0.5 beziehen sich tatsächlich auf Federbahn: 3.0.5. Gleichzeitig wurden einige dieser CVEs gefunden und der Nexus IQ identifizierte sie dennoch korrekt für eine andere Komponente. Da diese Schwachstellen im Spring-Core nicht gefunden wurden, kann nicht argumentiert werden, dass sie im Prinzip nicht im Framework enthalten sind, und Open Source-Tools haben zu Recht auf diese Schwachstellen hingewiesen (sie haben nur ein wenig versäumt).

Schlussfolgerungen

Wie wir sehen können, führt die Bestimmung der Zuverlässigkeit der identifizierten Schwachstellen durch manuelle Überprüfung nicht zu eindeutigen Ergebnissen, was zu kontroversen Fragen führt. Die Ergebnisse sind so, dass die Nexus IQ-Lösung die niedrigste Falsch-Positiv-Rate und die höchste Genauigkeit aufweist.



Dies ist vor allem darauf zurückzuführen, dass das Sonatype-Team die Beschreibung für jede CVE-Sicherheitsanfälligkeit von NVD in seinen Datenbanken erweitert hat und mit Genauigkeit für die Klasse oder Funktion der Sicherheitsanfälligkeit für eine bestimmte Version der Komponente zusätzliche Untersuchungen durchgeführt hat (z. B. Überprüfung von Sicherheitslücken bei älteren Versionen) Softwareversionen).



Einen wichtigen Einfluss auf die Ergebnisse haben die Sicherheitslücken, die nicht in NVD enthalten waren, aber dennoch in der Sonatype-Datenbank mit der Marke SONATYPE vorhanden sind. Laut dem Stand der Open Source-Sicherheitslücken 202045% der entdeckten Open Source-Schwachstellen werden nicht an NVD gemeldet. Laut der WhiteSource-Datenbank werden nur 29% aller außerhalb von NVD gemeldeten Open Source-Schwachstellen dort veröffentlicht. Deshalb ist es wichtig, auch anderswo nach Schwachstellen zu suchen.



Infolgedessen erzeugt die Abhängigkeitsprüfung viel Rauschen, da einige anfällige Komponenten fehlen. Dependency Track erzeugt weniger Rauschen und zeigt eine große Anzahl von Komponenten, die die Augen in der Weboberfläche optisch nicht verletzen.



Die Praxis zeigt jedoch, dass Open Source der erste Schritt auf dem Weg zur Reifung von DevSecOps sein sollte. Das erste, woran man denken muss, um SCA in die Entwicklung einzubetten, sind Prozesse, nämlich gemeinsam mit dem Management und verwandten Abteilungen darüber nachzudenken, wie die idealen Prozesse in ihrer Organisation aussehen sollten. Es kann sich herausstellen, dass Dependency Check oder Dependency Track für Ihr Unternehmen zunächst alle Geschäftsanforderungen abdeckt und Enterprise-Lösungen aufgrund der zunehmenden Komplexität der entwickelten Anwendungen eine logische Fortsetzung darstellen.