ProHoster > Blog > Administration > DevSecOps: Arbeitsprinzipien und Vergleich von SCA. Teil eins

DevSecOps: Arbeitsprinzipien und Vergleich von SCA. Teil eins

Die Bedeutung der Analyse von Drittanbieterkomponenten (engl. Software Composition Analysis – SCA) im Entwicklungsprozess steigt mit der Veröffentlichung der jĂ€hrlichen Berichte ĂŒber SicherheitsanfĂ€lligkeiten von Open Source-Bibliotheken, die von Unternehmen wie Synopsys, Sonatype, Snyk und White Source veröffentlicht werden. Laut dem Bericht The State of Open Source Security Vulnerabilities 2020 hat die Anzahl der identifizierten SicherheitsanfĂ€lligkeiten in Open Source im Jahr 2019 fast um das 1,5-Fache im Vergleich zum Vorjahr zugenommen, wĂ€hrend Open-Source-Komponenten in 60 % bis 80 % der Projekte verwendet werden. Wenn wir auf unabhĂ€ngige Meinungen zurĂŒckgreifen, sind die SCA-Prozesse eine separate Praxis des OWASP SAMM und BSIMM als Reifeindikator, und in der ersten HĂ€lfte des Jahres 2020 hat OWASP den neuen Standard OWASP Software Component Verification Standard (SCVS) veröffentlicht, der Best Practices zur ÜberprĂŒfung von Drittanbieterkomponenten in der Software-Lieferkette bereitstellt.

DevSecOps: Arbeitsprinzipien und Vergleich von SCA. Teil eins

Einer der aufschlussreichsten FĂ€lle ereignete sich mit der Firma Equifax im Mai 2017. Unbekannte Angreifer erlangten Informationen ĂŒber 143 Millionen Amerikaner, einschließlich vollstĂ€ndiger Namen, Adressen, Sozialversicherungsnummern und FĂŒhrerscheindaten. In 209.000 FĂ€llen war auch Informationen ĂŒber die Bankkarten der Betroffenen in den Unterlagen enthalten. Diese Datenpanne trat aufgrund der Ausnutzung einer kritischen SicherheitsanfĂ€lligkeit in Apache Struts 2 (CVE-2017-5638) auf, wĂ€hrend der Patch bereits im MĂ€rz 2017 veröffentlicht worden war. Das Unternehmen hatte zwei Monate Zeit, um das Update zu installieren, aber niemand kĂŒmmerte sich darum.

In diesem Artikel wird die Frage der Auswahl eines Tools zur DurchfĂŒhrung von SCA aus der Perspektive der QualitĂ€t der Analyseergebnisse diskutiert. Außerdem wird ein funktionaler Vergleich der Tools vorgestellt. Den Integrationsprozess in CI/CD und die Integrationsmöglichkeiten lassen wir fĂŒr zukĂŒnftige Veröffentlichungen. Eine umfassende Liste von Tools wurde von OWASP auf seiner Website, aber im Rahmen des aktuellen Reviews werden wir nur das beliebteste Open-Source-Tool Dependency Check, die etwas weniger bekannte Open-Source-Plattform Dependency Track und die Enterprise-Lösung Sonatype Nexus IQ behandeln. Zudem werden wir untersuchen, wie diese Lösungen funktionieren und die erhaltenen Ergebnisse auf Falschmeldungen vergleichen.

DevSecOps: Arbeitsprinzipien und Vergleich von SCA. Teil eins

Funktionsweise

Dependency Check — ist ein Werkzeug (CLI, Maven, Jenkins-Modul, Ant), das Projektdateien analysiert, Informationsfragmente ĂŒ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 
) ermittelt, anschließend wird ein einmaliger Bericht im Format HTML, JSON, XML 
 erstellt.

Schauen wir uns an, wie CPE aussieht:

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

  • Part: Angabe, dass die Komponente zu einer Anwendung (a), einem Betriebssystem (o) oder Hardware (h) gehört (Pflichtfeld)
  • Vendor: Name des Produktanbieters (Pflichtfeld)
  • Product: Name des Produkts (Pflichtfeld)
  • Version: Version der Komponente (veraltetes Feld)
  • Update: Paketaktualisierung
  • Edition: Herkunftsversion (veraltetes Feld)
  • Language: Sprache, definiert in RFC-5646
  • SW Edition: Softwareversion
  • Target SW: Software-Umgebung, in der das Produkt lĂ€uft
  • Target HW: Hardware-Umgebung, in der das Produkt lĂ€uft
  • Other: Informationen ĂŒber den Anbieter oder das Produkt

Ein Beispiel fĂŒr CPE sieht folgendermaßen aus:

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

Die Zeichenfolge bedeutet, dass CPE Version 2.3 eine Anwendungs-Komponente des Anbieters beschreibt pivotal_software mit dem Namen spring_framework in der Version 3.0.0. Wenn wir die Schwachstelle CVE-2014-0225 im NVD ansehen, können wir die ErwĂ€hnung dieses CPE sehen. Das erste Problem, das sofort beachtet werden sollte — die CVE im NVD gibt laut CPE an, dass ein Problem im Framework besteht und nicht bei einer speziellen Komponente. Das heißt, wenn die Entwickler stark auf das Framework setzen und die gefundene Schwachstelle nicht die Module betrifft, die von den Entwicklern genutzt werden, wird der Sicherheitsspezialist sich mit dieser CVE auseinandersetzen und ĂŒber Updates nachdenken mĂŒssen.

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

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

  • Scheme: Wird immer 'pkg' sein, was darauf hinweist, dass es sich um eine Paket-URL handelt (Pflichtfeld)
  • Type: 'Typ' des Pakets oder 'Protokoll' des Pakets, z. B. Maven, NPM, NuGet, Gem, PyPI usw. (Pflichtfeld)
  • Namespace: Ein gewisser NamensprĂ€fix, wie zum Beispiel die Maven-Gruppen-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: Version des Pakets
  • Qualifiers: ZusĂ€tzliche Qualifikationsdaten fĂŒr das Paket, wie OS, Architektur, Distribution usw. Optional und abhĂ€ngig vom Typ des Punktes.
  • Subpfad: 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 On-Premise-Webplattform, die fertige Bill of Materials (BOM) akzeptiert, die erstellt wurden CycloneDX und SPDX, also fertige Spezifikationen zu bestehenden AbhĂ€ngigkeiten. Dies ist eine XML-Datei mit einer Beschreibung der AbhĂ€ngigkeiten — Name, Hashes, Paket-URL, Herausgeber, Lizenz. Anschließend analysiert Dependency Track die BOM, ĂŒberprĂŒft die bestehenden CVEs zu den identifizierten AbhĂ€ngigkeiten aus der Datenbank fĂŒr SicherheitsanfĂ€lligkeiten (NVD, Sonatype OSS Index 
) und erstellt daraufhin Grafiken, berechnet Metriken und aktualisiert regelmĂ€ĂŸig die Daten ĂŒber den Status von SicherheitsanfĂ€lligkeiten der Komponenten.

Ein Beispiel, wie eine BOM im XML-Format aussehen könnte:

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

BOM kann nicht nur als Eingabeparameter fĂŒr Dependency Track verwendet werden, sondern auch zur Inventarisierung von Softwarekomponenten in der Lieferkette, beispielsweise zur Bereitstellung an den Softwarekunden. Im Jahr 2014 wurde in den USA sogar ein Gesetz vorgeschlagen, „Cyber Supply Chain Management and Transparency Act of 2014“, das besagte, dass bei der Beschaffung von Software jede Behörde BOM anfordern sollte, um die Verwendung anfĂ€lliger Komponenten zu verhindern, jedoch trat der Akt aufgrund dessen nicht in Kraft.

ZurĂŒck zu SCA: Dependency Track hat bereits fertige Integrationen mit Benachrichtigungsplattformen wie Slack und Schwachstellenmanagement-Systemen wie Kenna Security. Zudem ist zu sagen, dass Dependency Track auch veraltete Versionen von Paketen erkennt und Informationen ĂŒber Lizenzen bereitstellt (unterstĂŒtzt durch SPDX).

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

Dependency Track akzeptiert das Projekt nicht als Eingabewert, sondern akzeptiert genau genommen BOM. Das bedeutet, dass wir, wenn wir das Projekt ĂŒberprĂŒfen möchten, zuerst bom.xml generieren mĂŒssen, zum Beispiel mit Hilfe von CycloneDX. Somit hĂ€ngt Dependency Track direkt von CycloneDX ab. Gleichzeitig bietet es die Möglichkeit zur Anpassung. So hat das Team von OZON das CycloneDX-Modul zum Erstellen von BOM-Dateien fĂŒr Projekte in Golang mit dem Ziel, diese spĂ€ter ĂŒber Dependency Track zu scannen, entwickelt.

Nexus IQ ist eine kommerzielle SCA-Lösung von Sonatype, die 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 das Web-Interface oder die API als auch BOM akzeptieren, falls Ihre Organisation nicht rechtzeitig von CycloneDX zu einer neuen Lösung umgestiegen ist. Im Gegensatz zu Open-Source-Lösungen greift IQ nicht nur auf CP/PURL zur identifizierten Komponente und der entsprechenden Schwachstelle in der Datenbank zu, sondern berĂŒcksichtigt auch eigene Recherchen, zum Beispiel den Namen der verwundbaren Funktion oder Klasse. Die Mechanismen von IQ werden spĂ€ter bei der Analyse der Ergebnisse nĂ€her betrachtet.

Lassen Sie uns einige Ergebnisse zu den funktionalen Merkmalen zusammenfassen und die unterstĂŒtzten Programmiersprachen 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

Die Möglichkeit, die in den Quellcode verwendeten Komponenten auf Lizenzreinheit zu ĂŒberprĂŒfen.
+
—
+

Die Möglichkeit, auf Schwachstellen und Lizenzreinheit fĂŒr Docker-Images zu scannen und zu analysieren.
+ Integration mit Clair
—
—

Die Möglichkeit, Sicherheitsrichtlinien fĂŒr die Verwendung von Open-Source-Bibliotheken festzulegen.
+
—
—

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

Das Vorhandensein einer spezialisierten Forschungsgruppe.
+
—
—

Arbeiten im geschlossenen Umfeld.
+
+
+

Verwendung externen 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 beim Hochladen in die Entwicklungsumgebung gemĂ€ĂŸ den konfigurierten Richtlinien zu filtern.
+
—
—

Empfehlungen zur Behebung von Schwachstellen, Vorhandensein von Links zur Behebung
+
+- (abhÀngig von der Beschreibung in öffentlichen Datenbanken)
+- (abhÀngig von der Beschreibung in öffentlichen Datenbanken)

Einstufung der entdeckten Schwachstellen nach KritikalitÀt
+
+
+

Rollenbasiertes Zugriffsmodell
+
—
+

UnterstĂŒtzung der CLI-BenutzeroberflĂ€che
+
+
+- (nur fĂŒr CycloneDX)

Filterung / Sortierung von Schwachstellen nach definierten Kriterien
+
—
+

Dashboard zum Anwendungsstatus
+
—
+

Generierung von Berichten im PDF-Format
+
—
—

Generierung 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 Bamboo
+
—
—

Integration mit dem Continuous Integration-System TeamCity
+
—
—

Integration mit dem Continuous Integration-System GitLab
+
+- (in Form eines Plugins fĂŒr GitLab)
+

Integration mit dem Continuous Integration-System Jenkins
+
+
+

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

UnterstĂŒtzung der benutzerdefinierten Integration ĂŒber web-services (API) des Tools
+
—
+

Dependency Check

Erster Start

Wir werden Dependency Check auf einer absichtlich anfĂ€lligen Anwendung ausfĂŒhren DVJA.

Dazu nutzen wir Dependency Check Maven Plugin:

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

Infolgedessen wird die Datei dependency-check-report.html im Zielverzeichnis erstellt.

DevSecOps: Arbeitsprinzipien und Vergleich von SCA. Teil eins

Wir öffnen die Datei. Nach der Zusammenfassung der Gesamtanzahl an Schwachstellen können wir Informationen ĂŒber Schwachstellen mit hohem Schweregrad und Vertrauen sehen, einschließlich Paket, CPE und Anzahl der CVE.

Darauf folgt eine detailliertere Information, insbesondere die Grundlage der Entscheidung (Evidenz), also eine Art BOM.

DevSecOps: Arbeitsprinzipien und Vergleich von SCA. Teil eins

Darauf folgen CPE, PURL und die Beschreibung der CVE. Empfehlungen zur Behebung liegen ĂŒbrigens nicht vor, da sie in der NVD-Datenbank nicht verfĂŒgbar sind.

DevSecOps: Arbeitsprinzipien und Vergleich von SCA. Teil eins

FĂŒr eine systematische Betrachtung der Scanergebnisse kann Nginx mit minimalen Einstellungen konfiguriert oder die erhaltenen Defekte in ein Defektmanagementsystem gesendet werden, das Connectoren zu Dependency Check unterstĂŒtzt, wie z.B. Defect Dojo.

Dependency Track

Installation

Dependency Track hingegen ist eine Webplattform mit Diagrammansichten, weshalb das dringende Thema der Speicherung von Defekten in einer externen Lösung hier nicht relevant ist.
FĂŒr die Installation gibt es folgende unterstĂŒtzte Szenarien: Docker, WAR, Executable WAR.

Erster Start

Wir gehen zur URL des gestarteten Dienstes. Wir melden uns mit admin/admin an, Ă€ndern den Benutzernamen und das Passwort, wonach wir auf das Dashboard gelangen. Das nĂ€chste, was wir tun werden, ist ein Projekt fĂŒr eine Testanwendung in Java zu erstellen in Home/Projekte → Projekt erstellen . Als Beispiel nehmen wir DVJA.

DevSecOps: Arbeitsprinzipien und Vergleich von SCA. Teil eins

Da Dependency Track nur BOM als Eingabedaten akzeptieren kann, muss dieses BOM erstellt werden. Wir nutzen CycloneDX Maven Plugin:

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

Wir erhalten bom.xml und laden die Datei im erstellten Projekt hoch. DVJA → AbhĂ€ngigkeiten → BOM hochladen.

Gehen wir zu Verwaltung → Analyzer. Wir sehen, dass nur der interne Analyzer aktiviert ist, der NVD umfasst. Lassen Sie uns auch den Sonatype OSS Index verbinden.

DevSecOps: Arbeitsprinzipien und Vergleich von SCA. Teil eins

So erhalten wir die folgende Übersicht fĂŒr unser Projekt:

DevSecOps: Arbeitsprinzipien und Vergleich von SCA. Teil eins

In der Liste finden wir auch eine Schwachstelle, die auf Sonatype OSS zutrifft:

DevSecOps: Arbeitsprinzipien und Vergleich von SCA. Teil eins

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 das Video (und hier), 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 diesen Zweck ein Docker-Image zusammengestellt.

Nach dem Einloggen in die Konsole mĂŒssen wir eine Organisation und eine Anwendung erstellen.

DevSecOps: Arbeitsprinzipien und Vergleich von SCA. Teil eins

DevSecOps: Arbeitsprinzipien und Vergleich von SCA. Teil eins

DevSecOps: Arbeitsprinzipien und Vergleich von SCA. Teil eins

Wie man sieht, erfolgt die Konfiguration im Fall von IQ etwas komplizierter, da wir auch Richtlinien erstellen mĂŒssen, die fĂŒr verschiedene "Stufen" (dev, build, stage, release) gelten. Dies ist notwendig, um verwundbare Komponenten wĂ€hrend des Fortschreitens durch die Pipeline nĂ€her zur Produktion zu blockieren oder sie zu blockieren, sobald sie beim Download durch Entwickler in das Nexus Repo gelangen.

Um den Unterschied zwischen Open Source und Enterprise zu spĂŒren, fĂŒhren wir einen Ă€hnlichen Scan durch Nexus IQ durch, Ă€hnlich wie durch 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=

Wir gehen zur URL des generierten Berichts in der Web-OberflÀche IQ:

DevSecOps: Arbeitsprinzipien und Vergleich von SCA. Teil eins

Hier kann man alle VerstĂ¶ĂŸe gegen die Richtlinien sehen, die mit unterschiedlichen Schweregraden (von Info bis Sicherheitskritisch) gekennzeichnet sind. Der Buchstabe D neben der Komponente bedeutet, dass die Komponente eine Direkte AbhĂ€ngigkeit ist, wĂ€hrend der Buchstabe T neben der Komponente bedeutet, dass die Komponente eine Transitive AbhĂ€ngigkeit ist, also transitive.

Übrigens berichtet der Bericht State of Open Source Security Report 2020 von Snyk, dass mehr als 70 % der in Node.js, Java und Ruby gefundenen Schwachstellen in transitive AbhĂ€ngigkeiten fallen.

Wenn Sie einen der VerstĂ¶ĂŸe gegen die Nexus IQ-Richtlinien öffnen, können wir eine Beschreibung der Komponente sowie ein Version Graph sehen, der den Standort der aktuellen Version auf der zeitlichen Grafik zeigt und auch, zu welchem Zeitpunkt die Verwundbarkeit nicht mehr besteht. Die Höhe der Kerzen auf der Grafik zeigt die PopularitĂ€t der Nutzung dieser Komponente an.

DevSecOps: Arbeitsprinzipien und Vergleich von SCA. Teil eins

Wenn Sie zum Bereich der Verwundbarkeiten wechseln und die CVE aufklappen, können Sie die Beschreibung dieser Verwundbarkeit, Empfehlungen zur Behebung sowie den Grund lesen, warum diese Komponente gegen die Richtlinien verstĂ¶ĂŸt, nĂ€mlich das Vorhandensein der Klasse DiskFileitem.class.

DevSecOps: Arbeitsprinzipien und Vergleich von SCA. Teil eins

DevSecOps: Arbeitsprinzipien und Vergleich von SCA. Teil eins

Lassen Sie uns die Ergebnisse zusammenfassen, die nur die Drittanbieter-Java-Komponenten betreffen, und die JS-Komponenten entfernen. In Klammern geben wir die Anzahl der Verwundbarkeiten an, die außerhalb der NVD gefunden wurden.

Insgesamt Nexus IQ:

  • Scannte AbhĂ€ngigkeiten: 62
  • Verwundbare AbhĂ€ngigkeiten: 16
  • Gefundene Verwundbarkeiten: 42 (8 sonatype db)

Insgesamt Dependency Check:

  • Scannte AbhĂ€ngigkeiten: 47
  • Verwundbare AbhĂ€ngigkeiten: 13
  • Gefundene Verwundbarkeiten: 91 (14 sonatype oss)

Insgesamt Dependency Track:

  • Scannte AbhĂ€ngigkeiten: 59
  • Verwundbare AbhĂ€ngigkeiten: 10
  • Gefundene Verwundbarkeiten: 51 (1 sonatype oss)

Im nÀchsten Schritt werden wir die erhaltenen Ergebnisse analysieren und herausfinden, welche dieser Verwundbarkeiten ein tatsÀchlicher Defekt ist und welche ein Fehlalarm.

Haftungsausschluss

Dieses Review ist keine unbestreitbare Wahrheit. Es war nicht das Ziel des Autors, ein bestimmtes Tool hervorzuheben. Der Sinn des Reviews war es, die Arbeitsmechanismen von SCA-Tools und die Methoden zur ÜberprĂŒfung ihrer Ergebnisse zu zeigen.

Vergleich der Ergebnisse

Bedingungen:

Ein Fehlalarm in Bezug auf die Verwundbarkeiten von Drittanbieterkomponenten liegt vor bei:

  • NichtĂŒbereinstimmung der CVE mit der identifizierten Komponente
  • Wenn zum Beispiel eine Verwundbarkeit im Struts2-Framework festgestellt wird und das Tool auf die Komponente des Struts-Tiles-Frameworks hinweist, die nicht von dieser Verwundbarkeit betroffen ist, dann ist das ein Fehlalarm.
  • NichtĂŒbereinstimmung der CVE mit der identifizierten Version der Komponente
  • Wenn zum Beispiel die Verwundbarkeit an die Version python > 3.5 gebunden ist und das Tool die Version 2.7 als verwundbar markiert, dann ist das ein Fehlalarm, da die Verwundbarkeit tatsĂ€chlich nur fĂŒr die Produktlinie 3.x gilt.
  • Duplizierung der CVE
  • Wenn das SCA zum Beispiel auf eine CVE hinweist, die die DurchfĂŒhrung von RCE ermöglicht, und dann das SCA fĂŒr dieselbe Komponente eine CVE anfĂŒhrt, die fĂŒr Produkte von Cisco gilt, die dieser RCE ausgesetzt sind. In diesem Fall ließe sich von einem Fehlalarm sprechen.
  • Zum Beispiel wurde eine CVE im spring-web-Komponenten gefunden, woraufhin die SCA auf dieselbe CVE in anderen Komponenten des Spring Framework hinweist, wĂ€hrend die CVE fĂŒr andere Komponenten irrelevant ist. In diesem Fall liegt ein False Positive vor.

Das Forschungsobjekt ist das Open-Source-Projekt DVJA. In der Untersuchung waren nur Java-Komponenten (ohne JS) beteiligt.

Zusammenfassende Ergebnisse

Kommen wir direkt zu den Ergebnissen der manuellen ÜberprĂŒfung der identifizierten Schwachstellen. Der vollstĂ€ndige Bericht zu jeder CVE ist im Anhang zu finden.

Zusammenfassende Ergebnisse zu allen Schwachstellen:

Parameter
Nexus IQ
Dependency Check
Dependency Track

Insgesamt identifizierte Schwachstellen
42
91
51

FĂ€lschlicherweise identifizierte Schwachstellen (False Positive)
2(4.76%)
62(68,13%)
29(56.86%)

Nicht relevante Schwachstellen festgestellt (False Negative)
10
20
27

Zusammenfassende Ergebnisse nach Komponenten:

Parameter
Nexus IQ
Dependency Check
Dependency Track

Insgesamt identifizierte Komponenten
62
47
59

Insgesamt anfÀllige Komponenten
16
13
10

FÀlschlicherweise identifizierte anfÀllige Komponenten (False Positive)
1
5
0

FÀlschlicherweise identifizierte anfÀllige Komponenten (False Positive)
0
6
6

Lassen Sie uns visuelle Grafiken erstellen, um das VerhÀltnis von False Positives und False Negatives zur Gesamtzahl der Schwachstellen zu bewerten. Die horizontalen Achsen zeigen die Komponenten an, die vertikalen Achsen die darin identifizierten Schwachstellen.

DevSecOps: Arbeitsprinzipien und Vergleich von SCA. Teil eins

DevSecOps: Arbeitsprinzipien und Vergleich von SCA. Teil eins

DevSecOps: Arbeitsprinzipien und Vergleich von SCA. Teil eins

Zum Vergleich wurde eine Ă€hnliche Untersuchung von Sonatype zur Analyse eines Projekts mit 1531 Komponenten mithilfe des OWASP Dependency Checks durchgefĂŒhrt. Wie wir sehen können, ist das VerhĂ€ltnis von Rauschen zu korrekten Auslösungen mit unseren Ergebnissen vergleichbar.

DevSecOps: Arbeitsprinzipien und Vergleich von SCA. Teil eins
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 solche Ergebnisse zu verstehen.

Weitere Informationen

Nr. 1

ZunÀchst betrachten wir einige interessante Punkte von Sonatype Nexus IQ.

Nexus IQ weist auf ein Problem mit der Deserialisierung hin, das die Möglichkeit zur DurchfĂŒhrung von RCE im Spring Framework mehrmals zulĂ€sst. CVE-2016-1000027 in spring-web:3.0.5 zum ersten Mal und CVE-2011-2894 in spring-context:3.0.5 und spring-core:3.0.5. ZunĂ€chst scheint es, als ob die Schwachstelle in mehreren CVEs dupliziert wird. Wenn man die CVE-2016-1000027 und die CVE-2011-2894 in der NVD-Datenbank betrachtet, wirkt alles offensichtlich.

Komponente
Schwachstelle

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 NVD:
DevSecOps: Arbeitsprinzipien und Vergleich von SCA. Teil eins

Beschreibung CVE-2016-1000027 aus NVD:
DevSecOps: Arbeitsprinzipien und Vergleich von SCA. Teil eins

CVE-2011-2894 ist an sich recht bekannt. Im Bericht von White Source aus dem Jahr 2011 wurde diese CVE als eine der hĂ€ufigsten anerkannt. Die Beschreibungen fĂŒr CVE-2016-100027 sind im Grunde genommen selten in der NVD, und sie scheint nur fĂŒr Spring Framework 4.1.4 anwendbar zu sein. Schauen wir uns an Referenz und es wird immer klarer. Aus dem Artikel von Tenable verstehen wir, dass neben der Schwachstelle in RemoteInvocationSerializingExporter eine Schwachstelle auch in CVE-2011-2894 beobachtet wird. HttpInvokerServiceExporter. Darauf weist uns Nexus IQ hin:

DevSecOps: Arbeitsprinzipien und Vergleich von SCA. Teil eins

Dennoch gibt es nichts Derartiges in NVD, weshalb Dependency Check und Dependency Track falsche negative Ergebnisse liefern.

Aus der Beschreibung von CVE-2011-2894 kann man ebenfalls verstehen, 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 man in dem Artikel von dem, der diese Schwachstelle gefunden hat.

Nr. 2

Komponente
Schwachstelle
Ergebnis

struts2-core:2.3.30
CVE-2016-4003
FALSCH

Wenn wir die Schwachstelle CVE-2016-4003 betrachten, wird deutlich, dass sie bereits in Version 2.3.28 behoben wurde, dennoch weist uns Nexus IQ darauf hin. In der Beschreibung der Schwachstelle gibt es einen Hinweis:

DevSecOps: Arbeitsprinzipien und Vergleich von SCA. Teil eins

Das heißt, die Schwachstelle existiert nur in Verbindung mit einer veralteten JRE-Version, worĂŒber wir informiert werden. Dennoch halten wir dies fĂŒr ein False Positive, auch wenn es nicht die schlimmste ist.

Nr. 3

Komponente
Schwachstelle
Ergebnis

xwork-core:2.3.30
CVE-2017-9804
WAHR

xwork-core:2.3.30
CVE-2017-7672
FALSCH

Wenn wir die Beschreibung von CVE-2017-9804 und CVE-2017-7672 betrachten, wird klar, dass das Problem in der URLValidator-Klasse, wobei CVE-2017-9804 aus CVE-2017-7672 hervorgeht. Das Vorhandensein der zweiten Schwachstelle bringt keine nĂŒtzlichen Informationen mit sich, außer dass ihre Schwere auf Hoch gestiegen ist, weshalb man dies als unnötigen LĂ€rm betrachten kann.

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

Nr. 4

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

Komponente
Schwachstelle
Ergebnis

spring-web:3.0.5
CVE-2020-5398
WAHR

CVE in NVD besagt, dass sie nur fĂŒr Versionen 5.2.x bis 5.2.3, 5.1.x bis 5.1.13 und Versionen 5.0.x bis 5.0.16 gilt, dennoch, wenn wir die Beschreibung von CVE in Nexus IQ betrachten, sehen wir Folgendes:
Advisory Deviation Notice: Das Sicherheitsteam von Sonatype hat entdeckt, dass diese Schwachstelle in Version 3.0.2.RELEASE und nicht in 5.0.x, wie im Advisory angegeben, eingefĂŒhrt wurde.

Darauf folgt ein PoC zu dieser Schwachstelle, der besagt, dass sie in Version 3.0.5 vorhanden ist.

False Negative wird an Dependency Check und Dependency Track gesendet.

Nr. 5

Betrachten wir die False Positives fĂŒr Dependency Check und Dependency Track.

Dependency Check unterscheidet sich dadurch, dass es die CVEs, die dem gesamten Framework im NVD zugeordnet sind, in jene Komponenten schreibt, auf die diese CVEs nicht anwendbar sind. Dies betrifft CVE-2012-0394, CVE-2013-2115, CVE-2014-0114, CVE-2015-0899, CVE-2015-2992, CVE-2016-1181, CVE-2016-1182, die Dependency Check "angehĂ€ngt" hat an struts-taglib:1.3.8 und struts-tiles-1.3.8. Diese Komponenten haben nichts mit dem zu tun, was in den CVEs beschrieben wird — das Bearbeiten von Anfragen, die Validierung von Seiten usw. Dies liegt daran, dass das Einzige, was diese CVEs und Komponenten verbindet, das Framework ist, weshalb Dependency Check dies als Schwachstelle betrachtet hat.

Die Situation bei spring-tx:3.0.5 ist Ă€hnlich, und es gibt eine vergleichbare Situation mit struts-core:1.3.8. FĂŒr struts-core fanden Dependency Check und Dependency Track viele Schwachstellen, die tatsĂ€chlich auf struts2-core zutreffen, das im Grunde genommen ein separates Framework ist. In diesem Fall hat Nexus IQ das Bild korrekt verstanden und in den ausgegebenen CVEs angegeben, dass struts-core das End of Life erreicht hat und ein Wechsel zu struts2-core notwendig ist.

Nr. 6

In einigen Situationen ist es ungerecht, einen offensichtlichen Fehler von Dependency Check und Dependency Track zu interpretieren. Insbesondere CVE-2013-4152, CVE-2013-6429, CVE-2013-6430, CVE-2013-7315, CVE-2014-0054, CVE-2014-0225, die Dependency Check und Dependency Track struts-core:3.0.5 zuordnen, sind tatsĂ€chlich fĂŒr spring-web:3.0.5 relevant. Gleichzeitig wurden einige dieser CVEs auch von Nexus IQ gefunden, dennoch hat IQ sie korrekt einem anderen Bestandteil zugeordnet. Nur weil diese Schwachstellen nicht in spring-core gefunden wurden, kann man nicht behaupten, dass sie im Framework grundsĂ€tzlich nicht existieren; die Open-Source-Tools haben zu Recht auf diese Schwachstellen hingewiesen (sie haben nur ein wenig danebengegriffen).

Das DBMS Tarantool ist ein attraktives, zukunftstrÀchtiges Produkt zur Erstellung von hochbelasteten Anwendungen.

Wie wir sehen können, liefert die manuelle ÜberprĂŒfung keine eindeutigen Ergebnisse zur Validierung der gefundenen Schwachstellen, weshalb strittige Punkte entstehen. Die Ergebnisse sind so, dass die Lösung von Nexus IQ die geringste Rate an Fehlalarmen und die höchste Genauigkeit aufweist.

PrimĂ€r liegt das daran, dass das Team von Sonatype die Beschreibung fĂŒr jede Schwachstelle CVE aus der NVD in seinen Datenbanken erweitert hat, indem es die Schwachstellen bis hin zur Klasse oder Funktion fĂŒr die jeweilige Version des Bauteils genau angegeben hat und zusĂ€tzliche Forschungen durchgefĂŒhrt hat (zum Beispiel durch die ÜberprĂŒfung von Schwachstellen in Ă€lteren Softwareversionen).

Einen nicht unerheblichen Einfluss auf die Ergebnisse haben auch die Schwachstellen, die nicht in die NVD aufgenommen wurden, aber dennoch 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 in Open Source nicht in der NVD veröffentlicht. Laut der Datenbank von WhiteSource werden nur 29 % aller Schwachstellen in Open Source, die außerhalb der NVD registriert sind, letztendlich dort veröffentlicht. Daher ist es so wichtig, auch nach Schwachstellen in anderen Quellen zu suchen.

Als Ergebnis gibt Dependency Check eine große Menge an Rauschen aus und lĂ€sst einige verwundbare Komponenten aus. Dependency Track erzeugt weniger Rauschen und identifiziert viele Komponenten, was visuell in der WeboberflĂ€che nicht ins Auge springt.

Dennoch zeigt die Praxis, dass Open Source der erste Schritt auf dem Weg zu einem reifen DevSecOps sein sollte. ZunĂ€chst sollten Sie darĂŒber nachdenken, wie SCA in den Entwicklungsprozess integriert werden kann, und zwar durch GesprĂ€che mit dem Management und den benachbarten Abteilungen darĂŒber, wie die idealen Prozesse in Ihrer Organisation aussehen sollten. Möglicherweise stellt sich heraus, dass insbesondere fĂŒr Ihre Organisation zu Beginn Dependency Check oder Dependency Track alle geschĂ€ftlichen Anforderungen abdecken, wĂ€hrend Unternehmenslösungen aufgrund der zunehmenden KomplexitĂ€t der entwickelten Anwendungen eine logische Fortsetzung darstellen.

Anlage A. Ergebnisse bezĂŒglich der Komponenten
Legende:

  • Hoch — Hoch- und kritische Verwundbarkeiten in der Komponente
  • Mittel — Verwundbarkeiten mittlerer KritikalitĂ€t in der Komponente
  • WAHR — Korrekt identifizierte Verwundbarkeit (True positive issue)
  • FALSCH — Fehlalarm (False positive issue)

Komponente
Nexus IQ
Dependency Check
Dependency Track
Ergebnis

dom4j: 1.6.1
Hoch
Hoch
Hoch
WAHR

log4j-core: 2.3
Hoch
Hoch
Hoch
WAHR

log4j: 1.2.14
Hoch
Hoch
—
WAHR

commons-collections:3.1
Hoch
Hoch
Hoch
WAHR

commons-fileupload:1.3.2
Hoch
Hoch
Hoch
WAHR

commons-beanutils:1.7.0
Hoch
Hoch
Hoch
WAHR

commons-codec:1:10
Mittel
—
—
WAHR

mysql-connector-java:5.1.42
Hoch
Hoch
Hoch
WAHR

spring-expression:3.0.5
Hoch
Komponente nicht gefunden

WAHR

spring-web:3.0.5
Hoch
Komponente nicht gefunden
Hoch
WAHR

spring-context:3.0.5
Mittel
Komponente nicht gefunden
—
WAHR

spring-core:3.0.5
Mittel
Hoch
Hoch
WAHR

struts2-config-browser-plugin:2.3.30
Mittel
—
—
WAHR

spring-tx:3.0.5
—
Hoch
—
FALSCH

struts-core:1.3.8
Hoch
Hoch
Hoch
WAHR

xwork-core: 2.3.30
Hoch
—
—
WAHR

struts2-core: 2.3.30
Hoch
Hoch
Hoch
WAHR

struts-taglib:1.3.8
—
Hoch
—
FALSCH

struts-tiles-1.3.8
—
Hoch
—
FALSCH

Anlage B. Ergebnisse bezĂŒglich der Verwundbarkeiten
Legende:

  • Hoch — Hoch- und kritische Verwundbarkeiten in der Komponente
  • Mittel — Verwundbarkeiten mittlerer KritikalitĂ€t in der Komponente
  • WAHR — Korrekt identifizierte Verwundbarkeit (True positive issue)
  • FALSCH — Fehlalarm (False positive issue)

Komponente
Nexus IQ
Dependency Check
Dependency Track
Schweregrad
Ergebnis
Kommentar

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

CVE-2020-10683
CVE-2020-10683
CVE-2020-10683
Hoch
WAHR

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

CVE-2020-9488
CVE-2020-9488
CVE-2020-9488
Niedrig
WAHR

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

—
CVE-2020-9488
—
Niedrig
WAHR

SONATYPE-2010-0053
—
—
Hoch
WAHR

commons-collections:3.1
—
CVE-2015-6420
CVE-2015-6420
Hoch
FALSCH
Dupliziert RCE(OSSINDEX)

—
CVE-2017-15708
CVE-2017-15708
Hoch
FALSCH
Dupliziert RCE(OSSINDEX)

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

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

SONATYPE-2014-0173
—
—
Mittel
WAHR

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

—
CVE-2019-10086
CVE-2019-10086
Hoch
FALSCH
Die Verwundbarkeit gilt nur fĂŒr Versionen 1.9.2+

commons-codec:1:10
SONATYPE-2012-0050
—
—
Mittel
WAHR

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

CVE-2019-2692
CVE-2019-2692
—
Mittel
WAHR

—
CVE-2020-2875
—
Mittel
FALSCH
Die gleiche Verwundbarkeit wie CVE-2019-2692, aber mit dem Hinweis "Angriffe können erhebliche Auswirkungen auf zusÀtzliche Produkte haben"

—
CVE-2017-15945
—
Hoch
FALSCH
Gilt nicht fĂŒr mysql-connector-java

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

CVE-2020-2934
CVE-2020-2934
—
Mittel
WAHR

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

CVE-2018-1257
—
—
Mittel
WAHR

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

CVE-2014-0225
—
CVE-2014-0225
Hoch
WAHR

CVE-2011-2730
—
—
Hoch
WAHR

—
—
CVE-2013-4152
Mittel
WAHR

CVE-2018-1272
—
—
Hoch
WAHR

CVE-2020-5398
—
—
Hoch
WAHR
Ein bemerkenswertes Beispiel fĂŒr IQ: "Das Sicherheitsteam von Sonatype stellte fest, dass diese Verwundbarkeit in Version 3.0.2.RELEASE und nicht in 5.0.x wie im Hinweis angegeben eingefĂŒhrt wurde."

CVE-2013-6429
—
—
Mittel
WAHR

CVE-2014-0054
—
CVE-2014-0054
Mittel
WAHR

CVE-2013-6430
—
—
Mittel
WAHR

spring-context:3.0.5
CVE-2011-2894
Komponente nicht gefunden
—
Mittel
WAHR

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

CVE-2011-2894
CVE-2011-2894
CVE-2011-2894
Mittel
WAHR

—
—
CVE-2013-4152
Mittel
FALSCH
Duplikat dieser Verwundbarkeit in spring-web

—
CVE-2013-4152
—
Mittel
FALSCH
Die Verwundbarkeit bezieht sich auf die Komponente spring-web

—
CVE-2013-6429
CVE-2013-6429
Mittel
FALSCH
Die Verwundbarkeit bezieht sich auf die Komponente spring-web

—
CVE-2013-6430
—
Mittel
FALSCH
Die Verwundbarkeit bezieht sich auf die Komponente spring-web

—
CVE-2013-7315
CVE-2013-7315
Mittel
FALSCH
SPLIT aus CVE-2013-4152. + Die Verwundbarkeit bezieht sich auf die Komponente spring-web

—
CVE-2014-0054
CVE-2014-0054
Mittel
FALSCH
Die Verwundbarkeit bezieht sich auf die Komponente spring-web

—
CVE-2014-0225
—
Hoch
FALSCH
Die Verwundbarkeit bezieht sich auf die Komponente spring-web

—
—
CVE-2014-0225
Hoch
FALSCH
Duplikat dieser Verwundbarkeit in spring-web

—
CVE-2014-1904
CVE-2014-1904
Mittel
FALSCH
Die Verwundbarkeit bezieht sich auf die Komponente spring-web-mvc

—
CVE-2014-3625
CVE-2014-3625
Mittel
FALSCH
Die Verwundbarkeit bezieht sich auf die Komponente spring-web-mvc

—
CVE-2016-9878
CVE-2016-9878
Hoch
FALSCH
Die Verwundbarkeit bezieht sich auf die Komponente spring-web-mvc

—
CVE-2018-1270
CVE-2018-1270
Hoch
FALSCH
FĂŒr spring-expression / spring-messages

—
CVE-2018-1271
CVE-2018-1271
Mittel
FALSCH
Die Verwundbarkeit bezieht sich auf die Komponente spring-web-mvc

—
CVE-2018-1272
CVE-2018-1272
Hoch
WAHR

CVE-2014-3578
CVE-2014-3578 (OSSINDEX)
CVE-2014-3578
Mittel
WAHR

SONATYPE-2015-0327
—
—
Niedrig
WAHR

struts2-config-browser-plugin:2.3.30
SONATYPE-2016-0104
—
—
Mittel
WAHR

spring-tx:3.0.5
—
CVE-2011-2730
—
Hoch
FALSCH
Die Verwundbarkeit betrifft nicht spring-tx

—
CVE-2011-2894
—
Hoch
FALSCH
Die Verwundbarkeit betrifft nicht spring-tx

—
CVE-2013-4152
—
Mittel
FALSCH
Die Verwundbarkeit betrifft nicht spring-tx

—
CVE-2013-6429
—
Mittel
FALSCH
Die Verwundbarkeit betrifft nicht spring-tx

—
CVE-2013-6430
—
Mittel
FALSCH
Die Verwundbarkeit betrifft nicht spring-tx

—
CVE-2013-7315
—
Mittel
FALSCH
Die Verwundbarkeit betrifft nicht spring-tx

—
CVE-2014-0054
—
Mittel
FALSCH
Die Verwundbarkeit betrifft nicht spring-tx

—
CVE-2014-0225
—
Hoch
FALSCH
Die Verwundbarkeit betrifft nicht spring-tx

—
CVE-2014-1904
—
Mittel
FALSCH
Die Verwundbarkeit betrifft nicht spring-tx

—
CVE-2014-3625
—
Mittel
FALSCH
Die Verwundbarkeit betrifft nicht spring-tx

—
CVE-2016-9878
—
Hoch
FALSCH
Die Verwundbarkeit betrifft nicht spring-tx

—
CVE-2018-1270
—
Hoch
FALSCH
Die Verwundbarkeit betrifft nicht spring-tx

—
CVE-2018-1271
—
Mittel
FALSCH
Die Verwundbarkeit betrifft nicht spring-tx

—
CVE-2018-1272
—
Mittel
FALSCH
Die Verwundbarkeit betrifft nicht spring-tx

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

Mittel
FALSCH
Verwundbarkeit fĂŒr Struts 2

—
CVE-2012-0391 (OSSINDEX)
CVE-2012-0391
Hoch
FALSCH
Verwundbarkeit fĂŒr Struts 2

—
CVE-2014-0094 (OSSINDEX)
CVE-2014-0094
Mittel
FALSCH
Verwundbarkeit fĂŒr Struts 2

—
CVE-2014-0113 (OSSINDEX)
CVE-2014-0113
Hoch
FALSCH
Verwundbarkeit fĂŒr Struts 2

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

—
—
CVE-2011-5057
Mittel
FALSCH
Verwundbarkeit fĂŒr Struts 2

—
CVE-2012-0392 (OSSINDEX)
CVE-2012-0392
Hoch
FALSCH
Verwundbarkeit fĂŒr Struts 2

—
CVE-2012-0393 (OSSINDEX)
CVE-2012-0393
Mittel
FALSCH
Verwundbarkeit fĂŒr Struts 2

CVE-2015-0899
CVE-2015-0899
—
Hoch
WAHR

—
CVE-2012-0394
CVE-2012-0394
Mittel
FALSCH
Verwundbarkeit fĂŒr Struts 2

—
CVE-2012-0838 (OSSINDEX)
CVE-2012-0838
Hoch
FALSCH
Verwundbarkeit fĂŒr Struts 2

—
CVE-2013-1965 (OSSINDEX)
CVE-2013-1965
Hoch
FALSCH
Verwundbarkeit fĂŒr Struts 2

—
CVE-2013-1966 (OSSINDEX)
CVE-2013-1966
Hoch
FALSCH
Verwundbarkeit fĂŒr Struts 2

—
CVE-2013-2115
CVE-2013-2115
Hoch
FALSCH
Verwundbarkeit fĂŒr Struts 2

—
CVE-2013-2134 (OSSINDEX)
CVE-2013-2134
Hoch
FALSCH
Verwundbarkeit fĂŒr Struts 2

—
CVE-2013-2135 (OSSINDEX)
CVE-2013-2135
Hoch
FALSCH
Verwundbarkeit fĂŒr Struts 2

CVE-2014-0114
CVE-2014-0114
—
Hoch
WAHR

—
CVE-2015-2992
CVE-2015-2992
Mittel
FALSCH
Verwundbarkeit fĂŒr Struts 2

—
CVE-2016-0785 (OSSINDEX)
CVE-2016-0785
Hoch
FALSCH
Verwundbarkeit fĂŒr Struts 2

CVE-2016-1181
CVE-2016-1181
—
Hoch
WAHR

—
CVE-2016-4003 (OSSINDEX)
CVE-2016-4003
Hoch
FALSCH
Verwundbarkeit fĂŒr Struts 2

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

SONATYPE-2017-0173
—
—
Hoch
WAHR

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

SONATYPE-2016-0127
—
—
Hoch
WAHR

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

—
CVE-2017-9787
CVE-2017-9787
Hoch
WAHR

—
CVE-2017-9791
CVE-2017-9791
Hoch
WAHR

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

—
CVE-2017-9804
—
Hoch
WAHR

—
CVE-2017-9805
CVE-2017-9805
Hoch
WAHR

CVE-2016-4003
—
—
Mittel
FALSCH
Anwendbar auf Apache Struts 2.x bis 2.3.28, dies ist Version 2.3.30. Dennoch gilt laut Beschreibung CVE fĂŒr alle Struts 2-Versionen, wenn JRE 1.7 und frĂŒher verwendet wird. Anscheinend wollte man auf Nummer sicher gehen, aber es sieht eher nach einem FALSE aus.

—
CVE-2018-1327
CVE-2018-1327
Hoch
WAHR

CVE-2017-5638
CVE-2017-5638
CVE-2017-5638
Hoch
WAHR
Dies ist die SicherheitslĂŒcke, die 2017 von Angreifern bei Equifax ausgenutzt wurde.

CVE-2017-12611
CVE-2017-12611
—
Hoch
WAHR

CVE-2018-11776
CVE-2018-11776
CVE-2018-11776
Hoch
WAHR

struts-taglib:1.3.8
—
CVE-2012-0394
—
Mittel
FALSCH
FĂŒr struts2-core

—
CVE-2013-2115
—
Hoch
FALSCH
FĂŒr struts2-core

—
CVE-2014-0114
—
Hoch
FALSCH
FĂŒr commons-beanutils

—
CVE-2015-0899
—
Hoch
FALSCH
Nicht relevant fĂŒr taglib

—
CVE-2015-2992
—
Mittel
FALSCH
Relevant fĂŒr struts2-core

—
CVE-2016-1181
—
Hoch
FALSCH
Nicht relevant fĂŒr taglib

—
CVE-2016-1182
—
Hoch
FALSCH
Nicht relevant fĂŒr taglib

struts-tiles-1.3.8
—
CVE-2012-0394
—
Mittel
FALSCH
FĂŒr struts2-core

—
CVE-2013-2115
—
Hoch
FALSCH
FĂŒr struts2-core

—
CVE-2014-0114
—
Hoch
FALSCH
Unter commons-beanutils

—
CVE-2015-0899
—
Hoch
FALSCH
Nicht relevant fĂŒr tiles

—
CVE-2015-2992
—
Mittel
FALSCH
FĂŒr struts2-core

—
CVE-2016-1181
—
Hoch
FALSCH
Nicht relevant fĂŒr taglib

—
CVE-2016-1182
—
Hoch
FALSCH
Nicht relevant fĂŒr taglib

Quelle: habr.com

60GB SSD 8Gb DDR4