🥇DevSecOps: Funktionsprinzipien und Vergleich von SCA. Teil eins

Die Bedeutung der Analyse von Drittanbieter-Softwarekomponenten (engl. Software Composition Analysis — SCA) im Entwicklungsprozess wächst. Dies zeigt sich in den jährlichen Berichten über Schwachstellen in Open-Source-Bibliotheken, die von Firmen wie Synopsys, Sonatype, Snyk und White Source veröffentlicht werden. Laut dem Bericht The State of Open Source Security Vulnerabilities 2020 hat die Zahl der entdeckten Schwachstellen in Open Source im Jahr 2019 fast um das 1,5-Fache im Vergleich zum Vorjahr zugenommen, während Komponenten mit offenem Code in 60 % bis 80 % der Projekte verwendet werden. Laut unabhängiger Meinung sind SCA-Prozesse eine eigenständige Praxis in OWASP SAMM und BSIMM als Indikator für die Reife. In der ersten Hälfte des Jahres 2020 veröffentlichte OWASP den neuen Standard OWASP Software Component Verification Standard (SCVS), der Best Practices zur Überprüfung von Drittanbieterkomponenten in der Software-Lieferkette bereitstellt.

Einer der beeindruckendsten Fälle geschah Im Mai 2017 kam es zu einem Vorfall mit der Firma Equifax. Unbekannte Angreifer erlangten Zugriff auf die Daten von 143 Millionen Amerikanern, einschließlich vollständiger Namen, Adressen, Sozialversicherungsnummern und Führerscheindaten. In 209.000 Fällen waren auch Informationen zu den Bankkarten der Betroffenen betroffen. Diese Datenpanne resultierte aus der Ausnutzung einer kritischen Schwachstelle in Apache Struts 2 (CVE-2017-5638), während das Patch bereits im März 2017 veröffentlicht wurde. Das Unternehmen hatte zwei Monate Zeit, um das Update zu implementieren, doch diese Frist wurde nicht eingehalten.

In diesem Artikel wird die Auswahl eines Tools für die Durchführung von SCA aus der Perspektive der Analysequalität diskutiert. Außerdem wird ein funktionaler Vergleich der Tools vorgestellt. Den Prozess der Integration in CI/CD und die Integrationsmöglichkeiten lassen wir für zukünftige Veröffentlichungen offen. Eine umfangreiche Liste von Tools wurde von OWASP veröffentlicht. auf ihrer Website, aber in diesem Überblick konzentrieren wir uns nur auf das am weitesten verbreitete Open-Source-Tool Dependency Check, die etwas weniger bekannte Open-Source-Plattform Dependency Track und die Enterprise-Lösung Sonatype Nexus IQ. Wir werden auch untersuchen, wie diese Lösungen funktionieren und die Ergebnisse hinsichtlich falsch-positiver Meldungen vergleichen.

Funktionsweise

Dependency Check ist ein Tool (CLI, Maven, Jenkins-Modul, Ant), das die Projektdateien analysiert, Informationen über Abhängigkeiten (Paketname, GroupID, Spezifikationstitel, Version…) sammelt, eine CPE-Zeichenfolge (Common Platform Enumeration), Package URL (PURL) erstellt und für CPE/PURL Schwachstellen aus Datenbanken (NVD, Sonatype OSS Index, NPM Audit API…) identifiziert, wonach ein einmaliger Bericht im Format HTML, JSON, XML… erstellt wird.

Schauen wir uns an, wie eine CPE aussieht:

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

Teil: Die Angabe, dass die Komponente zu einer Anwendung (a), einem Betriebssystem (o) oder Hardware (h) gehört (Pflichtfeld)
Hersteller: Der Name des Herstellers des Produkts (Pflichtfeld)
Produkt: Der Name des Produkts (Pflichtfeld)
Version: Die Version der Komponente (veraltetes Feld)
Update: Paketaktualisierung
Ausgabe: Die vererbte Version (veraltetes Feld)
Sprache: Die Sprache, definiert in RFC-5646
SW-Version: Die Softwareversion
Ziel-SW: Programmierumgebung, in der das Produkt läuft
Ziel-HW: Hardwareumgebung, in der das Produkt läuft
Andere: Informationen über den Anbieter oder das Produkt

Ein Beispiel für CPE sieht wie folgt aus:

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

Die Zeile bedeutet, dass CPE Version 2.3 ein Anwendungsmodul des Herstellers beschreibt pivotal_software mit dem Namen spring_framework in der Version 3.0.0. Wenn wir die Schwachstelle CVE-2014-0225 in NVD öffnen, können wir einen Verweis auf dieses CPE sehen. Das erste Problem, auf das man sofort achten sollte — CVE in NVD berichtet gemäß CPE über ein Problem im Framework und nicht in einem spezifischen Modul. Das heißt, wenn die Entwickler stark vom Framework abhängen und die entdeckte Schwachstelle nicht die Module betrifft, die die Entwickler verwenden, muss der Sicherheitsspezialist sich mit dieser CVE auseinandersetzen und über ein Update nachdenken.

Die URL wird auch von SCA-Tools verwendet. Das Format der Paket-URL sieht folgendermaßen aus:

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

Sсheme: Wird immer 'pkg' sein, was darauf hinweist, dass es sich um eine Paket-URL handelt (Pflichtfeld)
Type: Der 'Typ' des Pakets oder das 'Protokoll' des Pakets, z. B. maven, npm, nuget, gem, pypi usw. (Pflichtfeld)
Namespace: Ein gewisser Namenspräfix, wie die Maven-Gruppe-ID, der Besitzer des Docker-Images, ein Benutzer oder eine Organisation auf GitHub. Optional und abhängig vom Typ.
Name: Name des Pakets (Pflichtfeld)
Version: Versionsnummer des Pakets
Qualifiers: Zusätzliche Qualifikatoren für das Paket, wie Betriebssystem, Architektur, Distribution usw. Optional und typabhängig.
Subpath: 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 — eine lokale Webplattform, die fertiggestellte Stücklisten (Bill of Materials, BOM) verarbeitet, die erstellt wurden CycloneDX und SPDX, also fertiggestellte Spezifikationen über vorhandene Abhängigkeiten. Dies ist eine XML-Datei mit einer Beschreibung der Abhängigkeiten — Name, Hashes, Paket-URL, Publisher, Lizenz. Anschließend analysiert Dependency Track die BOM, überprüft die ermittelten Abhängigkeiten auf CVEs aus der Datenbank für Schwachstellen (NVD, Sonatype OSS Index …), erstellt Diagramme, berechnet Metriken und aktualisiert regelmäßig die Informationen zum Status der Schwachstellen von Komponenten.

Beispiel, wie eine BOM im XML-Format aussehen kann:

Apache
      org.apache.tomcat
      tomcat-catalina
      9.0.14
      
        3942447fac867ae5cdb3229b658f4d48
        e6b1000b94e835ffd37f4c6dcbdad43f4b48a02a
        f498a8ff2dd007e29c2074f5e4b01a9a01775c3ff3aeaf6906ea503bc5791b7b
        e8f33e424f3f4ed6db76a482fde1a5298970e442c531729119e37991884bdffab4f9426b7ee11fccd074eeda0634d71697d6f88a460dce0ac8d627a29f7d1282
      
      
        
          Apache-2.0
        
      
      pkg:maven/org.apache.tomcat/tomcat-catalina@9.0.14

Die BOM kann nicht nur als Eingabeparameter für Dependency Track verwendet werden, sondern auch zur Inventarisierung von Softwarekomponenten in der Lieferkette, beispielsweise zur Bereitstellung für den Softwarekunden. Im Jahr 2014 wurde in den USA sogar ein Gesetz zur Diskussion gestellt, „Cyber Supply Chain Management and Transparency Act von 2014“, der besagte, dass beim Erwerb von Software jede staatliche Einrichtung eine BOM anfordern muss, um die Verwendung verwundbarer Komponenten zu verhindern. Allerdings ist dieser Akt nie in Kraft getreten.

Zurück zu SCA: Dependency Track bietet bereits Integrationen mit Benachrichtigungsplattformen wie Slack sowie mit Schwachstellenmanagementsystemen wie Kenna Security. Es ist auch erwähnenswert, dass Dependency Track zusätzlich veraltete Versionen von Paketen identifiziert und Lizenzinformationen bereitstellt (dank der Unterstützung von SPDX).

Wenn es um die Qualität von SCA geht, gibt es hier einen grundlegenden Unterschied.

Dependency Track akzeptiert nicht das Projekt als Eingabedaten, sondern nimmt tatsächlich die BOM entgegen. Das bedeutet, dass wir, wenn wir ein Projekt überprüfen wollen, zuerst eine bom.xml erstellen müssen, beispielsweise mit CycloneDX. Somit ist Dependency Track direkt von CycloneDX abhängig. Gleichzeitig bietet dies Möglichkeiten zur Anpassung. So hat das OZON-Team ein CycloneDX-Modul zur Erstellung von BOM-Dateien für Projekte in Golang entwickelt, um sie anschließend über Dependency Track zu scannen.

Nexus IQ — kommerzieles SCA-Angebot von Sonatype, das Teil des Sonatype-Ökosystems ist, zu dem auch der Nexus Repository Manager gehört. Nexus IQ kann sowohl WAR-Archive (für Java-Projekte) über die Web-Oberfläche oder API als auch BOM-Daten akzeptieren, falls Ihre Organisation nicht rechtzeitig von CycloneDX auf die neue Lösung umgestiegen ist. Im Gegensatz zu Open-Source-Lösungen berücksichtigt IQ nicht nur CP/PURL für die identifizierte Komponente und die entsprechenden Schwachstellen in der Datenbank, sondern auch eigene Untersuchungen, wie den Namen der verwundbaren Funktion oder Klasse. Die Mechanismen von IQ werden später bei der Analyse der Ergebnisse behandelt.

Lassen Sie uns einige Schlussfolgerungen zu den funktionalen Merkmalen ziehen und die unterstützten Sprachen für die Analyse betrachten:

Sprache
Nexus IQ
Dependency Check
Dependency Track

Java
+
+
+

C/C++
+
+
—

C#
+
+
—

.Net
+
+
+

Erlang
—
—
+

JavaScript (NodeJS)
+
+
+

PHP
+
+
+

Python
+
+
+

Ruby
+
+
+

Perl
—
—
—

Scala
+
+
+

Objective C
+
+
—

Swift
+
+
—

R
+
—
—

Go
+
+
+

Funktionale Möglichkeiten

Funktionale Möglichkeiten
Nexus IQ
Dependency Check
Dependency Track

Möglichkeit zur Überprüfung der Lizenztreue von Komponenten, die im Quellcode verwendet werden
+
—
+

Möglichkeit zur Scannung und Analyse von Docker-Images auf Schwachstellen und Lizenztreue
+ Integration mit Clair
—
—

Möglichkeit zur Anpassung von Sicherheitsrichtlinien für die Verwendung von Open-Source-Bibliotheken
+
—
—

Die Möglichkeit zur Analyse von Open-Source-Repositories auf verwundbare Komponenten
+ RubyGems, Maven, NPM, Nuget, Pypi, Conan, Bower, Conda, Go, p2, R, Yum, Helm, Docker, CocoaPods, Git LFS
—
+ Hex, RubyGems, Maven, NPM, Nuget, Pypi

Vorhandensein einer spezialisierten Forschungsgruppe
+
—
—

Arbeiten in einem geschützten Umfeld
+
+
+

Verwendung von Drittanbieter-Datenbanken
+ Geschlossene Datenbank von Sonatype
+ Sonatype OSS, NPM Public Advisors
+ Sonatype OSS, NPM Public Advisors, RetireJS, VulnDB, Unterstützung einer eigenen Schwachstellendatenbank

Die Möglichkeit, Open-Source-Komponenten bei dem Versuch, in die Entwicklungsumgebung hochzuladen, gemäß den konfigurierten Richtlinien zu filtern
+
—
—

Empfehlungen zur Behebung von Schwachstellen, einschließlich Links zu Patches
+
+- (abhängig von der Beschreibung in öffentlichen Datenbanken)
+- (abhängig von der Beschreibung in öffentlichen Datenbanken)

Bewertung der entdeckten Schwachstellen nach Kritikalität
+
+
+

Rollenbasismodell für den Zugriff
+
—
+

Unterstützung einer Kommandozeilen-Schnittstelle (CLI)
+
+
+- (nur für CycloneDX)

Filtern / Sortieren von Schwachstellen nach definierten Kriterien
+
—
+

Dashboard zum Status der Anwendungen
+
—
+

Erstellung von Berichten im PDF-Format
+
—
—

Erstellung von Berichten im JSONCSV-Format
+
+
—

Unterstützung der russischen Sprache
—
—
—

Integrationsmöglichkeiten

Integration
Nexus IQ
Dependency Check
Dependency Track

Integration mit LDAP / Active Directory
+
—
+

Integration mit dem Continuous Integration System (Continous Integration) Bamboo
+
—
—

Integration mit dem Continuous Integration System (Continous Integration) TeamCity
+
—
—

Integration mit dem Continuous Integration System (Continous Integration) GitLab
+
+- (als Plugin für GitLab)
+

Integration mit dem Continuous Integration System (Continous Integration) Jenkins
+
+
+

Verfügbarkeit von Plugins für IDEs
+ IntelliJ, Eclipse, Visual Studio
—
—

Unterstützung für benutzerdefinierte Integrationen über Web-Services (API) des Tools
+
—
+

Dependency Check

Erster Start

Wir starten das Dependency Check für eine absichtlich verwundbare Anwendung DVJA.

Dazu verwenden wir Dependency Check Maven Plugin:

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

Das Ergebnis wird die Datei dependency-check-report.html im Verzeichnis target erscheinen.

Öffnen Sie die Datei. Nach der Zusammenfassung über die Gesamtzahl der Schwachstellen sehen wir Informationen über Schwachstellen mit hohem Schweregrad und Vertrauen, einschließlich Paket, CPE und der Anzahl der CVE.

Anschließend folgen detailliertere Informationen, insbesondere die Gründe für die Entscheidungen (Evidenz), also gewissermaßen ein BOM.

Darüber hinaus gibt es CPE, PURL und die Beschreibung der CVE. Empfehlungen zur Behebung sind übrigens nicht enthalten, da diese in der NVD-Datenbank fehlen.

Um eine systematische Überprüfung der Scan-Ergebnisse zu ermöglichen, kann Nginx mit minimalen Einstellungen konfiguriert werden, oder die gefundenen Defekte können in ein Defektmanagementsystem gesendet werden, das Connectoren zu Dependency Check unterstützt. Zum Beispiel Defect Dojo.

Dependency Track

Installation von

Dependency Track hingegen ist eine Webplattform mit grafischen Darstellungen, sodass die Frage des Speicherns von Defekten in einer externen Lösung hier nicht relevant ist.
Für die Installation sind die folgenden unterstützten Szenarien verfügbar: Docker, WAR, ausführbare WAR.

Erster Start

Gehen Sie zur URL des gestarteten Dienstes. Melden Sie sich mit admin/admin an, ändern Sie den Benutzername und das Passwort, und gelangen Sie dann zum Dashboard. Als nächstes erstellen wir ein Projekt für eine Testanwendung in Java in Home/Projects → Projekt erstellen . Als Beispiel verwenden wir DVJA.

Da Dependency Track nur BOM-Daten als Eingabe akzeptieren kann, muss dieses BOM beschafft werden. Lassen Sie uns CycloneDX Maven Plugin:

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

Das bom.xml wird erstellt und die Datei in dem erstellten Projekt hochgeladen. DVJA → Abhängigkeiten → BOM hochladen.

Gehen Sie zu Verwaltung → Analysatoren. Wir stellen fest, dass nur der interne Analysator aktiviert ist, der NVD umfasst. Lassen Sie uns auch den Sonatype OSS Index aktivieren.

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

Auch in der Liste findet sich eine Schwachstelle, die für Sonatype OSS anwendbar ist:

Die größte Enttäuschung war, dass Dependency Track keine XML-Berichte von Dependency Check mehr akzeptiert. Die letzten unterstützten Integrationsversionen mit Dependency Check waren 1.0.0 – 4.0.2, während ich 5.3.2 getestet habe.

Hier Video (und hier ist), als dies noch möglich war.

Nexus IQ

Erster Start

Die Installation von Nexus IQ erfolgt aus Archiven über Dokumentation., aber wir haben uns für diese Zwecke ein Docker-Image erstellt.

Nach dem Einloggen in die Konsole müssen Sie eine Organisation und eine Anwendung erstellen.

Wie zu sehen ist, gestaltet sich die Konfiguration im Fall von IQ etwas komplizierter, da wir auch Richtlinien erstellen müssen, die für verschiedene „Stufen“ (dev, build, stage, release) anwendbar sind. Dies ist notwendig, um anfällige Komponenten während des Fortschritts im Pipeline näher zur Produktion zu blockieren oder sofort 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 einen ähnlichen Scan über Nexus IQ durch, der dem entspricht Maven-Plugin, nachdem wir zuvor eine Testanwendung im NexusIQ-Interface erstellt haben dvja-test-and-compare:

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

Gehen Sie über die URL zum generierten Bericht im IQ-Webinterface:

Hier können Sie alle Verstöße gegen die Richtlinien sehen, die nach verschiedenen Schweregraden (von Info bis Security Critical) gekennzeichnet sind. Der Buchstabe D neben einer Komponente bedeutet, dass es sich um eine direkte Abhängigkeit handelt, und der Buchstabe T neben einer Komponente zeigt an, dass es sich um eine transitive Abhängigkeit handelt.

Übrigens, der Bericht State of Open Source Security Report 2020 von Snyk berichtet, dass über 70 % der in Node.js, Java und Ruby entdeckten Open-Source-Sicherheitsanfälligkeiten in transitiven Abhängigkeiten liegen.

Wenn wir eine der Richtlinienverletzungen in Nexus IQ öffnen, können wir die Beschreibung der Komponente sowie das Versionsdiagramm sehen, das den aktuellen Stand der Version im zeitlichen Verlauf darstellt und zeigt, wann die Sicherheitsanfälligkeit nicht mehr besteht. Die Höhe der Kerzen im Diagramm zeigt die Beliebtheit der Nutzung dieser Komponente an.

Wenn Sie zum Abschnitt der Schwachstellen wechseln und die CVE aufklappen, können Sie die Beschreibung dieser Schwachstelle, Empfehlungen zur Behebung sowie den Grund lesen, warum diese Komponente unter einen Verstoß fällt, das heißt, das Vorhandensein einer Klasse. DiskFileitem.class.

Fassen wir nur die externen Java-Komponenten zusammen, indem wir die js-Komponenten entfernen. In Klammern geben wir die Anzahl der Schwachstellen an, die außerhalb der NVD gefunden wurden.

Insgesamt Nexus IQ:

Durchsuchte Abhängigkeiten: 62
Verletzbare Abhängigkeiten: 16
Gefundene Schwachstellen: 42 (8 sonatype db)

Insgesamt Dependency Check:

Durchsuchte Abhängigkeiten: 47
Verletzbare Abhängigkeiten: 13
Gefundene Schwachstellen: 91 (14 sonatype oss)

Insgesamt Dependency Track:

Durchsuchte Abhängigkeiten: 59
Verletzbare Abhängigkeiten: 10
Gefundene Schwachstellen: 51 (1 sonatype oss)

Im nächsten Schritt analysieren wir die Ergebnisse und untersuchen, welche dieser Schwachstellen ein tatsächlicher Defekt ist und welche ein Fehlalarm.

Haftungsausschluss

Diese Überprüfung ist keine unumstößliche Wahrheit. Der Autor hatte nicht das Ziel, ein bestimmtes Werkzeug herauszuheben. Sinn der Überprüfung war es, die Funktionsweisen von SCA-Tools und die Methoden zur Überprüfung ihrer Ergebnisse aufzuzeigen.

Vergleich der Ergebnisse

Bedingungen:

Ein Fehlalarm in Bezug auf Schwachstellen von Drittanbieter-Komponenten ist:

CVE-Unstimmigkeit mit dem identifizierten Bauteil
Wenn zum Beispiel eine Schwachstelle im Framework struts2 entdeckt wird und das Tool auf das Bauteil struts-tiles hinweist, zu dem diese Schwachstelle nicht gehört, ist das ein False Positive.
CVE-Unstimmigkeit mit der identifizierten Version des Bauteils
Wenn eine Schwachstelle an die Version python > 3.5 gebunden ist und das Tool die verwundbare Version 2.7 anzeigt, ist das ein False Positive, da die Schwachstelle tatsächlich nur die Produktreihe 3.x betrifft.
CVE-Duplizierung
Wenn beispielsweise das SCA auf eine CVE hinweist, die RCE ermöglicht, und danach dasselbe SCA für dieses Bauteil eine CVE angibt, die für Cisco-Produkte gilt, die dieser RCE ausgesetzt sind, wäre das ein False Positive.
Wenn beispielsweise eine CVE im Bauteil spring-web gefunden wurde, und das SCA dann auf dieselbe CVE in anderen Bauteilen des Spring Framework hinweist, während diese CVE nichts mit anderen Bauteilen zu tun hat, wäre das ein False Positive.

Gegenstand der Untersuchung ist das Open Source-Projekt DVJA. An der Untersuchung nahmen nur Java-Komponenten (ohne JS) teil.

Zusammenfassende Ergebnisse

Lassen Sie uns direkt zu den Ergebnissen der manuellen Überprüfung der identifizierten Schwachstellen übergehen. Den vollständigen Bericht zu jeder CVE finden Sie im Anhang.

Zusammenfassende Ergebnisse zu allen Schwachstellen:

Parameter
Nexus IQ
Dependency Check
Dependency Track

Insgesamt identifizierte Schwachstellen
42
91
51

Falsch identifizierte Schwachstellen (false positive)
2(4.76%)
62(68,13%)
29(56.86%)

Keine relevanten Schwachstellen gefunden (false negative)
10
20
27

Zusammenfassende Ergebnisse nach Komponenten:

Parameter
Nexus IQ
Dependency Check
Dependency Track

Insgesamt identifizierte Komponenten
62
47
59

Insgesamt verwundbare Komponenten
16
13
10

Falsch identifizierte verwundbare Komponenten (false positive)
1
5
0

Falsch identifizierte verwundbare Komponenten (false positive)
0
6
6

Wir werden visuelle Diagramme erstellen, um das Verhältnis von false positives und false negatives zur Gesamtzahl der Schwachstellen zu bewerten. Auf der horizontalen Achse sind die Komponenten und auf der vertikalen Achse die darin identifizierten Schwachstellen dargestellt.

Zum Vergleich wurde eine ähnliche Studie vom Sonatype-Team durchgeführt, die ein Projekt mit 1531 Komponenten mithilfe des OWASP Dependency Checks getestet hat. Wie wir sehen können, steht das Verhältnis von Störgeräuschen zu korrekten Auslösungen im Einklang mit unseren Ergebnissen.

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

Lassen Sie uns einige CVEs aus den Ergebnissen unseres Scans betrachten, um die Gründe für diese Ergebnisse zu verstehen.

Mehr erfahren

Nr. 1

Zuerst betrachten wir einige interessante Aspekte von Sonatype Nexus IQ.

Nexus IQ weist auf ein Deserialisierungsproblem hin, das in der Spring Framework mehrfach RCE ermöglichen kann. CVE-2016-1000027 in spring-web:3.0.5 erstmals und CVE-2011-2894 in spring-context:3.0.5 sowie spring-core:3.0.5. Zunächst scheint es, dass eine Schwachstelle in mehreren CVEs dupliziert wird. Denn wenn wir CVE-2016-1000027 und CVE-2011-2894 in der NVD-Datenbank betrachten, scheint alles offensichtlich.

Komponente
Sicherheitsanfälligkeit

spring-web:3.0.5
CVE-2016-1000027

spring-context:3.0.5
CVE-2011-2894

spring-core:3.0.5
CVE-2011-2894

Beschreibung CVE-2011-2894 aus der NVD:

Beschreibung CVE-2016-1000027 aus der NVD:

CVE-2011-2894 selbst ist ziemlich bekannt. Im Bericht von White Source aus dem Jahr 2011 wurde diese CVE als eine der am häufigsten vorkommenden angesehen. Beschreibung für CVE-2016-100027 gibt es in NVD nur wenige, und sie scheint nur für die Spring Framework 4.1.4 anwendbar zu sein. Lassen Sie uns Referenz betrachten, und dann wird alles mehr oder weniger klar. Aus der Tenable-Artikels verstehen wir, dass neben der Schwachstelle in der RemoteInvocationSerializingExporter in CVE-2011-2894 eine Schwachstelle auch in der HttpInvokerServiceExporter. Darüber informiert uns Nexus IQ:

Dennoch ist nichts Derartiges in der NVD vorhanden, was dazu führt, dass Dependency Check und Dependency Track falsche Negative erhalten.

Außerdem kann aus der Beschreibung von CVE-2011-2894 entnommen werden, dass die Schwachstelle tatsächlich sowohl in spring-context:3.0.5 als auch in spring-core:3.0.5 vorhanden ist. Eine Bestätigung hierfür findet sich in einem Artikel des Entdeckers dieser Schwachstelle.

Nr.2

Komponente
Sicherheitsanfälligkeit
Ergebnis

struts2-core:2.3.30
CVE-2016-4003
FALSE

Wenn wir die Schwachstelle CVE-2016-4003 betrachten, stellen wir fest, dass sie bereits in Version 2.3.28 behoben wurde. Dennoch informiert uns Nexus IQ darüber. Im Beschreibungstext zur Schwachstelle gibt es einen Hinweis:

Das bedeutet, dass die Schwachstelle nur in Verbindung mit einer veralteten Version der JRE besteht, und darauf wollten wir hingewiesen werden. Wir betrachten dies trotzdem als False Positive, auch wenn es nicht die schlimmste ist.

Nr. 3

Komponente
Sicherheitsanfälligkeit
Ergebnis

xwork-core:2.3.30
CVE-2017-9804
TRUE

xwork-core:2.3.30
CVE-2017-7672
FALSE

Wenn wir die Beschreibung von CVE-2017-9804 und CVE-2017-7672 betrachten, verstehen wir, dass das Problem in der URLValidator-Klasseliegt, wobei CVE-2017-9804 aus CVE-2017-7672 resultiert. Das Vorhandensein der zweiten Schwachstelle hat keinen praktischen Nutzen, außer dass ihre Schwere auf Hoch gestiegen ist, weshalb wir dies als überflüssigen Lärm betrachten können.

Insgesamt wurden keine weiteren False Positives für Nexus IQ gefunden.

Nr. 4

Es gibt mehrere Punkte, die IQ von anderen Lösungen abheben.

Komponente
Sicherheitsanfälligkeit
Ergebnis

spring-web:3.0.5
CVE-2020-5398
TRUE

Das CVE im NVD berichtet, 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 zutrifft. Wenn wir jedoch die Beschreibung des CVE in Nexus IQ betrachten, sehen wir Folgendes:
Advisory Deviation Notice: Das Sicherheitsteam von Sonatype hat festgestellt, dass diese Schwachstelle in Version 3.0.2.RELEASE und nicht in 5.0.x, wie im Advisory angegeben, eingeführt wurde.

Danach folgt ein PoC zu dieser Schwachstelle, das meldet, dass sie in Version 3.0.5 vorhanden ist.

Ein False Negative wird an den Dependency Check und Dependency Track gesendet.

Nr. 5

Betrachten wir das False Positive für Dependency Check und Dependency Track.

Der Dependency Check hebt hervor, dass die CVEs, die in der NVD zum gesamten Framework gehören, auf die Komponenten angewendet werden, auf die diese CVEs nicht zutreffen. Dies betrifft CVE-2012-0394, CVE-2013-2115, CVE-2014-0114, CVE-2015-0899, CVE-2015-2992, CVE-2016-1181, CVE-2016-1182, die der Dependency Check mit struts-taglib:1.3.8 und struts-tiles-1.3.8 verknüpft hat. Diese Komponenten haben nichts mit dem in den CVEs beschriebenen zu tun — Anfragebearbeitung, Seitenvalidierung und so weiter. Das Einzige, was diese CVEs und Komponenten gemeinsam haben, ist das Framework, weshalb der Dependency Check dies als Schwachstelle gewertet hat.

Die gleiche Situation gilt für spring-tx:3.0.5, und eine ähnliche Situation gibt es mit struts-core:1.3.8. Für struts-core hat der Dependency Check und Dependency Track viele Schwachstellen gefunden, die tatsächlich auf struts2-core zutreffen, das im Grunde ein eigenständiges Framework ist. In diesem Fall hat Nexus IQ das Bild richtig verstanden und in den CVEs, die es ausgegeben hat, angegeben, dass struts-core das Ende seiner Lebensdauer erreicht hat und auf struts2-core umgestiegen werden muss.

Nr. 6

In einigen Fällen ist es ungerecht, die offensichtlichen Fehler von Dependency Check und Dependency Track zu interpretieren. Insbesondere die CVEs CVE-2013-4152, CVE-2013-6429, CVE-2013-6430, CVE-2013-7315, CVE-2014-0054, CVE-2014-0225, die von Dependency Check und Dependency Track als zu spring-core:3.0.5 gehörend eingestuft wurden, gehören tatsächlich zu spring-web:3.0.5. Einige dieser CVEs wurden auch in Nexus IQ gefunden, dort jedoch korrekt einer anderen Komponente zugeordnet. Nur weil diese Sicherheitsanfälligkeiten nicht in spring-core gefunden wurden, kann nicht behauptet werden, dass sie im Framework grundsätzlich nicht existieren; die Open-Source-Tools haben diese Schwachstellen schlichtweg etwas daneben eingeordnet.

Fazit

Wie wir sehen können, führt die manuelle Überprüfung zur Bestimmung der Verlässlichkeit der entdeckten Schwachstellen nicht zu eindeutigen Ergebnissen, wodurch umstrittene Punkte entstehen. Die Resultate zeigen, dass die Lösung von Nexus IQ die geringste Rate an Fehlalarmen und die höchste Genauigkeit aufweist.

Zunächst einmal liegt es daran, dass das Team von Sonatype die Beschreibung für jede CVE-Schwachstelle aus dem NVD in seinen Datenbanken erweitert hat, indem es präzise nach Klassifizierung oder Funktion der Schwachstelle für die jeweilige Version des Komponenten recherchiert hat, einschließlich zusätzlicher Untersuchungen (zum Beispiel durch Überprüfung von Schwachstellen in älteren Softwareversionen).

Ein ebenfalls bedeutender Einfluss auf die Ergebnisse sind die Schwachstellen, die nicht in den NVD aufgenommen wurden, jedoch in der Sonatype-Datenbank mit dem Vermerk SONATYPE vorhanden sind. Laut dem Bericht The State of Open Source Security Vulnerabilities 2020 werden 45 % der entdeckten Schwachstellen mit offenem Quellcode nicht im NVD gemeldet. Laut der WhiteSource-Datenbank werden nur 29 % aller Schwachstellen mit offenem Quellcode, die außerhalb des NVD registriert sind, letztendlich in diesem veröffentlicht, weshalb es wichtig ist, auch in anderen Quellen nach Schwachstellen zu suchen.

Zusammenfassend erzeugt Dependency Check eine große Menge an Rauschen und übersieht dabei einige verwundbare Komponenten. Dependency Track erzeugt weniger Rauschen und identifiziert eine größere Anzahl von Komponenten, was visuell angenehmer im Web-Interface ist.

Dennoch zeigt die Praxis, dass Open Source der erste Schritt auf dem Weg zu einem reifen DevSecOps sein sollte. Der erste Aspekt, über den man nachdenken sollte, um SCA in die Entwicklung zu integrieren, sind die Prozesse. Dabei sollte man gemeinsam mit der Führungsebene und den angrenzenden Abteilungen überlegen, wie die idealen Prozesse in Ihrer Organisation aussehen sollten. Möglicherweise stellt sich heraus, dass für Ihre Organisation zu Beginn Dependency Check oder Dependency Track alle geschäftlichen Anforderungen erfüllen, während Enterprise-Lösungen eine logische Fortsetzung aufgrund der zunehmenden Komplexität der entwickelten Anwendungen darstellen.

Anhang A. Ergebnisse zu den Komponenten
Bezeichner:

Hoch — Schwachstellen hoher und kritischer Stufen in der Komponente
Mittel — Schwachstellen mittlerer Kritikalität in der Komponente
WAHR — Eindeutig identifizierte Schwachstelle (Wahrer Positivfall)
FALSCH — Fehlalarm (Falscher Positivfall)

Komponente
Nexus IQ
Dependency Check
Dependency Track
Ergebnis

dom4j: 1.6.1
Hoch
Hoch
Hoch
TRUE

log4j-core: 2.3
Hoch
Hoch
Hoch
TRUE

log4j: 1.2.14
Hoch
Hoch
—
TRUE

commons-collections: 3.1
Hoch
Hoch
Hoch
TRUE

commons-fileupload: 1.3.2
Hoch
Hoch
Hoch
TRUE

commons-beanutils: 1.7.0
Hoch
Hoch
Hoch
TRUE

commons-codec: 1:10
Medium
—
—
TRUE

mysql-connector-java: 5.1.42
Hoch
Hoch
Hoch
TRUE

spring-expression: 3.0.5
Hoch
Komponente nicht gefunden

TRUE

spring-web:3.0.5
Hoch
Komponente nicht gefunden
Hoch
TRUE

spring-context:3.0.5
Medium
Komponente nicht gefunden
—
TRUE

spring-core:3.0.5
Medium
Hoch
Hoch
TRUE

struts2-config-browser-plugin: 2.3.30
Medium
—
—
TRUE

spring-tx: 3.0.5
—
Hoch
—
FALSE

struts-core: 1.3.8
Hoch
Hoch
Hoch
TRUE

xwork-core: 2.3.30
Hoch
—
—
TRUE

struts2-core: 2.3.30
Hoch
Hoch
Hoch
TRUE

struts-taglib: 1.3.8
—
Hoch
—
FALSE

struts-tiles-1.3.8
—
Hoch
—
FALSE

Anhang B. Ergebnisse zu den Schwachstellen
Bezeichner:

Hoch — Schwachstellen hoher und kritischer Stufen in der Komponente
Mittel — Schwachstellen mittlerer Kritikalität in der Komponente
WAHR — Eindeutig identifizierte Schwachstelle (Wahrer Positivfall)
FALSCH — Fehlalarm (Falscher Positivfall)

Komponente
Nexus IQ
Dependency Check
Dependency Track
Schweregrad
Ergebnis
Kommentar

dom4j: 1.6.1
CVE-2018-1000632
CVE-2018-1000632
CVE-2018-1000632
Hoch
TRUE

CVE-2020-10683
CVE-2020-10683
CVE-2020-10683
Hoch
TRUE

log4j-core: 2.3
CVE-2017-5645
CVE-2017-5645
CVE-2017-5645
Hoch
TRUE

CVE-2020-9488
CVE-2020-9488
CVE-2020-9488
Niedrig
TRUE

log4j: 1.2.14
CVE-2019-17571
CVE-2019-17571
—
Hoch
TRUE

—
CVE-2020-9488
—
Niedrig
TRUE

SONATYPE-2010-0053
—
—
Hoch
TRUE

commons-collections: 3.1
—
CVE-2015-6420
CVE-2015-6420
Hoch
FALSE
Doppelt zu RCE(OSSINDEX)

—
CVE-2017-15708
CVE-2017-15708
Hoch
FALSE
Doppelt zu RCE(OSSINDEX)

SONATYPE-2015-0002
RCE (OSSINDEX)
RCE(OSSINDEX)
Hoch
TRUE

commons-fileupload: 1.3.2
CVE-2016-1000031
CVE-2016-1000031
CVE-2016-1000031
Hoch
TRUE

SONATYPE-2014-0173
—
—
Medium
TRUE

commons-beanutils: 1.7.0
CVE-2014-0114
CVE-2014-0114
CVE-2014-0114
Hoch
TRUE

—
CVE-2019-10086
CVE-2019-10086
Hoch
FALSE
Die Schwachstelle ist nur für Versionen 1.9.2+ relevant

commons-codec: 1:10
SONATYPE-2012-0050
—
—
Medium
TRUE

mysql-connector-java: 5.1.42
CVE-2018-3258
CVE-2018-3258
CVE-2018-3258
Hoch
TRUE

CVE-2019-2692
CVE-2019-2692
—
Medium
TRUE

—
CVE-2020-2875
—
Medium
FALSE
Die gleiche Schwachstelle wie CVE-2019-2692, jedoch mit dem Hinweis „Angriffe können zusätzlich andere Produkte erheblich beeinflussen“

—
CVE-2017-15945
—
Hoch
FALSE
Gilt nicht für mysql-connector-java

—
CVE-2020-2933
—
Niedrig
FALSE
Duplikat zu CVE-2020-2934

CVE-2020-2934
CVE-2020-2934
—
Medium
TRUE

spring-expression: 3.0.5
CVE-2018-1270
Komponente nicht gefunden
—
Hoch
TRUE

CVE-2018-1257
—
—
Medium
TRUE

spring-web:3.0.5
CVE-2016-1000027
Komponente nicht gefunden
—
Hoch
TRUE

CVE-2014-0225
—
CVE-2014-0225
Hoch
TRUE

CVE-2011-2730
—
—
Hoch
TRUE

—
—
CVE-2013-4152
Medium
TRUE

CVE-2018-1272
—
—
Hoch
TRUE

CVE-2020-5398
—
—
Hoch
TRUE
Ein anschauliches Beispiel für IQ: „Das Sicherheitsteam von Sonatype hat erkannt, dass diese Schwachstelle in Version 3.0.2.RELEASE und nicht in 5.0.x, wie im Berater angegeben, eingeführt wurde.“

CVE-2013-6429
—
—
Medium
TRUE

CVE-2014-0054
—
CVE-2014-0054
Medium
TRUE

CVE-2013-6430
—
—
Medium
TRUE

spring-context:3.0.5
CVE-2011-2894
Komponente nicht gefunden
—
Medium
TRUE

spring-core:3.0.5
—
CVE-2011-2730
CVE-2011-2730
Hoch
TRUE

CVE-2011-2894
CVE-2011-2894
CVE-2011-2894
Medium
TRUE

—
—
CVE-2013-4152
Medium
FALSE
Duplikat dieser Schwachstelle in spring-web

—
CVE-2013-4152
—
Medium
FALSE
Die Schwachstelle betrifft die Komponente spring-web

—
CVE-2013-6429
CVE-2013-6429
Medium
FALSE
Die Schwachstelle betrifft die Komponente spring-web

—
CVE-2013-6430
—
Medium
FALSE
Die Schwachstelle betrifft die Komponente spring-web

—
CVE-2013-7315
CVE-2013-7315
Medium
FALSE
SPALTE aus CVE-2013-4152. + Die Schwachstelle betrifft die Komponente spring-web

—
CVE-2014-0054
CVE-2014-0054
Medium
FALSE
Die Schwachstelle betrifft die Komponente spring-web

—
CVE-2014-0225
—
Hoch
FALSE
Die Schwachstelle betrifft die Komponente spring-web

—
—
CVE-2014-0225
Hoch
FALSE
Duplikat dieser Schwachstelle in spring-web

—
CVE-2014-1904
CVE-2014-1904
Medium
FALSE
Die Schwachstelle betrifft die Komponente spring-web-mvc

—
CVE-2014-3625
CVE-2014-3625
Medium
FALSE
Die Schwachstelle betrifft die Komponente spring-web-mvc

—
CVE-2016-9878
CVE-2016-9878
Hoch
FALSE
Die Schwachstelle betrifft die Komponente spring-web-mvc

—
CVE-2018-1270
CVE-2018-1270
Hoch
FALSE
Für spring-expression / spring-messages

—
CVE-2018-1271
CVE-2018-1271
Medium
FALSE
Die Schwachstelle betrifft die Komponente spring-web-mvc

—
CVE-2018-1272
CVE-2018-1272
Hoch
TRUE

CVE-2014-3578
CVE-2014-3578 (OSSINDEX)
CVE-2014-3578
Medium
TRUE

SONATYPE-2015-0327
—
—
Niedrig
TRUE

struts2-config-browser-plugin: 2.3.30
SONATYPE-2016-0104
—
—
Medium
TRUE

spring-tx: 3.0.5
—
CVE-2011-2730
—
Hoch
FALSE
Die Schwachstelle betrifft nicht spring-tx

—
CVE-2011-2894
—
Hoch
FALSE
Die Schwachstelle betrifft nicht spring-tx

—
CVE-2013-4152
—
Medium
FALSE
Die Schwachstelle betrifft nicht spring-tx

—
CVE-2013-6429
—
Medium
FALSE
Die Schwachstelle betrifft nicht spring-tx

—
CVE-2013-6430
—
Medium
FALSE
Die Schwachstelle betrifft nicht spring-tx

—
CVE-2013-7315
—
Medium
FALSE
Die Schwachstelle betrifft nicht spring-tx

—
CVE-2014-0054
—
Medium
FALSE
Die Schwachstelle betrifft nicht spring-tx

—
CVE-2014-0225
—
Hoch
FALSE
Die Schwachstelle betrifft nicht spring-tx

—
CVE-2014-1904
—
Medium
FALSE
Die Schwachstelle betrifft nicht spring-tx

—
CVE-2014-3625
—
Medium
FALSE
Die Schwachstelle betrifft nicht spring-tx

—
CVE-2016-9878
—
Hoch
FALSE
Die Schwachstelle betrifft nicht spring-tx

—
CVE-2018-1270
—
Hoch
FALSE
Die Schwachstelle betrifft nicht spring-tx

—
CVE-2018-1271
—
Medium
FALSE
Die Schwachstelle betrifft nicht spring-tx

—
CVE-2018-1272
—
Medium
FALSE
Die Schwachstelle betrifft nicht spring-tx

struts-core: 1.3.8
—
CVE-2011-5057 (OSSINDEX)

Medium
FALSCH
Schwachstelle in Struts 2

—
CVE-2012-0391 (OSSINDEX)
CVE-2012-0391
Hoch
FALSE
Schwachstelle in Struts 2

—
CVE-2014-0094 (OSSINDEX)
CVE-2014-0094
Medium
FALSE
Schwachstelle in Struts 2

—
CVE-2014-0113 (OSSINDEX)
CVE-2014-0113
Hoch
FALSE
Schwachstelle in Struts 2

CVE-2016-1182
3VE-2016-1182
—
Hoch
TRUE

—
—
CVE-2011-5057
Medium
FALSE
Schwachstelle in Struts 2

—
CVE-2012-0392 (OSSINDEX)
CVE-2012-0392
Hoch
FALSE
Schwachstelle in Struts 2

—
CVE-2012-0393 (OSSINDEX)
CVE-2012-0393
Medium
FALSE
Schwachstelle in Struts 2

CVE-2015-0899
CVE-2015-0899
—
Hoch
TRUE

—
CVE-2012-0394
CVE-2012-0394
Medium
FALSE
Schwachstelle in Struts 2

—
CVE-2012-0838 (OSSINDEX)
CVE-2012-0838
Hoch
FALSE
Schwachstelle in Struts 2

—
CVE-2013-1965 (OSSINDEX)
CVE-2013-1965
Hoch
FALSE
Schwachstelle in Struts 2

—
CVE-2013-1966 (OSSINDEX)
CVE-2013-1966
Hoch
FALSCH
Schwachstelle in Struts 2

—
CVE-2013-2115
CVE-2013-2115
Hoch
FALSCH
Schwachstelle in Struts 2

—
CVE-2013-2134 (OSSINDEX)
CVE-2013-2134
Hoch
FALSCH
Schwachstelle in Struts 2

—
CVE-2013-2135 (OSSINDEX)
CVE-2013-2135
Hoch
FALSCH
Schwachstelle in Struts 2

CVE-2014-0114
CVE-2014-0114
—
Hoch
TRUE

—
CVE-2015-2992
CVE-2015-2992
Medium
FALSE
Schwachstelle in Struts 2

—
CVE-2016-0785 (OSSINDEX)
CVE-2016-0785
Hoch
FALSE
Schwachstelle in Struts 2

CVE-2016-1181
CVE-2016-1181
—
Hoch
TRUE

—
CVE-2016-4003 (OSSINDEX)
CVE-2016-4003
Hoch
FALSE
Schwachstelle in Struts 2

xwork-core:2.3.30
CVE-2017-9804
—
—
Hoch
TRUE

SONATYPE-2017-0173
—
—
Hoch
TRUE

CVE-2017-7672
—
—
Hoch
FALSE
Duplikat zu CVE-2017-9804

SONATYPE-2016-0127
—
—
Hoch
TRUE

struts2-core:2.3.30
—
CVE-2016-6795
CVE-2016-6795
Hoch
TRUE

—
CVE-2017-9787
CVE-2017-9787
Hoch
TRUE

—
CVE-2017-9791
CVE-2017-9791
Hoch
TRUE

—
CVE-2017-9793
—
Hoch
FALSE
Duplikat zu CVE-2018-1327

—
CVE-2017-9804
—
Hoch
TRUE

—
CVE-2017-9805
CVE-2017-9805
Hoch
TRUE

CVE-2016-4003
—
—
Medium
FALSE
Anwendbar auf Apache Struts 2.x bis 2.3.28; dies ist Version 2.3.30. Basierend auf der Beschreibung scheint CVE jedoch auf alle Struts 2-Versionen anzuwenden zu sein, wenn JRE 1.7 oder niedriger verwendet wird. Wir wollten uns hier eher absichern, aber es wirkt mehr wie ein FALSE.

—
CVE-2018-1327
CVE-2018-1327
Hoch
TRUE

CVE-2017-5638
CVE-2017-5638
CVE-2017-5638
Hoch
TRUE
Die Schwachstelle, die von den Angreifern bei Equifax 2017 ausgenutzt wurde.

CVE-2017-12611
CVE-2017-12611
—
Hoch
TRUE

CVE-2018-11776
CVE-2018-11776
CVE-2018-11776
Hoch
TRUE

struts-taglib: 1.3.8
—
CVE-2012-0394
—
Medium
FALSE
Für struts2-core

—
CVE-2013-2115
—
Hoch
FALSE
Für struts2-core

—
CVE-2014-0114
—
Hoch
FALSE
Für commons-beanutils

—
CVE-2015-0899
—
Hoch
FALSE
Nicht zutreffend auf taglib

—
CVE-2015-2992
—
Medium
FALSE
Zutreffend für struts2-core

—
CVE-2016-1181
—
Hoch
FALSE
Nicht zutreffend auf taglib

—
CVE-2016-1182
—
Hoch
FALSE
Nicht zutreffend auf taglib

struts-tiles-1.3.8
—
CVE-2012-0394
—
Medium
FALSE
Für struts2-core