DevSecOps: működési elvek és SCA összehasonlítás. Első rész

A szoftverösszetevő-elemzés (SCA) jelentősége a fejlesztési folyamatban nő, ahogy évente megjelennek a nyílt forráskódú könyvtárak sebezhetőségeiről szóló jelentések, amelyeket a Synopsys, Sonatype, Snyk és White Source közzétesznek. A jelentés szerint A nyílt forráskódú biztonsági sebezhetőségek állapota 2020 a 2019-ben felfedezett nyílt forráskódú sebezhetőségek száma majdnem másfélszeresére nőtt az előző évhez képest, ennek ellenére a nyílt forráskódú komponenseket a projektek 60%-80%-ában használják. Ha független véleményre hivatkozunk, akkor a SCA folyamatokat az OWASP SAMM és a BSIMM külön gyakorlataiként említik a érettségi mutatóként, és 2020 első felében az OWASP új szabványt adott ki, az OWASP Szoftverkomponens-ellenőrzési Szabványt (SCVS), amely a nyílt forráskódú komponensek ellenőrzésére vonatkozó legjobb gyakorlatokat nyújt a szoftverellátási láncban.

Az egyik legszembetűnőbb eset történt az Equifax céggel, 2017 májusában történt. Ismeretlen elkövetők 143 millió amerikai adataihoz jutottak, beleértve a teljes neveket, címeket, társadalombiztosítási számokat és jogosítványokat. 209 000 esetben a dokumentumokban az áldozatok bankkártya-információi is szerepeltek. Ez az adatlopás a kritikus sebezhetőség kiaknázása miatt következett be az Apache Struts 2 (CVE-2017-5638) rendszerben, miközben a javítás már 2017 márciusában megjelent. A cégnek két hónapja volt a frissítés telepítésére, de ezzel senki sem foglalkozott.

Ez a cikk a SCA végrehajtásához szükséges eszköz kiválasztásának kérdését tárgyalja, az elemzés eredményének minősége szempontjából. Funkcionális összehasonlítást is bemutatunk. A CI/CD integrációs folyamatait és lehetőségeit a következő publikációkra hagyjuk. Az OWASP egy széles eszközlistát terjesztett elő a weboldalán, de a jelenlegi áttekintés keretében csak a legnépszerűbb nyílt forráskódú eszközt, a Dependency Check-et, a kevésbé ismert nyílt forráskódú platformot, a Dependency Track-et és a Sonatype Nexus IQ vállalati megoldást érintjük. Megvizsgáljuk, hogyan működnek ezek a megoldások, és összehasonlítjuk az eredményeket a hamis riasztások tekintetében.

A működés elve

Dependency Check — ez egy CLI eszköz (maven, jenkins modul, ant), amely elemezi a projekt fájljait, összegyűjti a függőségekkel kapcsolatos információkat (csomagnév, groupid, specifikációs cím, verzió…), felépíti a CPE (Common Platform Enumeration), Package URL (PURL) karakterláncot, és az NVD, Sonatype OSS Index, NPM Audit API… adatbázisokból sebezhetőségeket azonosít a CPE/PURL számára, majd egyszeri jelentést készít HTML, JSON, XML formátumban…

Nézzük meg, hogyan néz ki a CPE:

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

• Part: A jelzés arra, hogy a komponens alkalmazáshoz (a), operációs rendszerhez (o), vagy hardverhez (h) tartozik (Kötelező elem)
• Vendor: A termék gyártójának neve (Kötelező elem)
• Product: A termék neve (Kötelező elem)
• Verzió: A komponens verziója (Elavult elem)
• Frissítés: A csomag frissítése
• Edition: A címzett verzió (Elavult elem)
• Language: A RFC-5646-ban meghatározott nyelv
• SW Edition: A szoftver verziója
• Target SW: A programkörnyezet, amelyben a termék működik
• Target HW: A hardverkörnyezet, amelyben a termék működik
• Other: Információ a beszállítóról vagy a termékről

Egy példa a CPE-re a következőképpen néz ki:

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

A karakterlánc azt jelenti, hogy a CPE 2.3 verziója egy alkalmazáskomponenst ír le a gyártótól pivotal_software a névvel spring_framework 3.0.0 verzióval. Ha megnézzük a sebezhetőséget CVE-2014-0225 az NVD-ben, akkor láthatjuk ezt a CPE-t. Az első probléma, amire azonnal érdemes figyelni — a CVE az NVD-ben azt jelzi, hogy a probléma a keretrendszerben van, nem konkrétan egy komponensben. Tehát ha a fejlesztők szorosan kapcsolódnak a keretrendszerhez, és az észlelt sebezhetőség nem érinti azokat a modulokat, amelyeket a fejlesztők használnak, a biztonsági szakembernek úgyis foglalkoznia kell a CVE-vel és gondolkodnia az aktualizáláson.

Az URL-címet szintén használják az SCA eszközök. A csomag URL-cím formátuma a következő:

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

• Scheme: Mindig ‘pkg’ lesz, ami azt jelzi, hogy ez egy csomag URL-cím (Kötelező elem)
• Type: A csomag ‘típus’ vagy ‘protokoll’, például maven, npm, nuget, gem, pypi stb. (Kötelező elem)
• Namespace: Valamilyen név előtag, mint például a Maven csoportazonosító, Docker kép tulajdonosa, GitHub felhasználó vagy szervezet. Opcionális és a típustól függ.
• Név: Csomag neve (Kötelező elem)
• Verzió: Csomag verziója
• Qualifiers: További képesítési adatok a csomagról, mint például az operációs rendszer, architektúra, disztribúció stb. Opcionális és típustól függő elem.
• Alútvonal: További útvonal a csomagban a csomag gyökere szerint

Például:

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 — helyben hosztolható webplatform, amely elkészült Anyagjegyzékeket (BOM) fogad el, amelyek létrejöttek CycloneDX és SPDX, tehát a meglévő függőségek specifikációi. Ez egy XML-fájl a függőségekről — név, hashek, csomag url, kiadó, licenc. A Dependency Track ezután feldolgozza a BOM-ot, megvizsgálja a meglévő függőségeket, és CVE-t keres az időszakos biztonsági adatbázisokban (NVD, Sonatype OSS Index ...), majd diagramokat épít, metrikákat számít, és rendszeresen frissíti az összetevők sebezhetőségi státuszáról szóló adatokat.

Példa arra, hogyan nézhet ki a BOM XML-formátumban:

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
    
      

A BOM nemcsak bemeneti paramétereként használható a Dependency Track számára, hanem a szoftverkomponensek leltárának készítésére is a beszállítói láncban, például a szoftver ügyfélnak való átadása céljából. 2014-ben az Egyesült Államokban még egy törvényjavaslatot is benyújtottak, „Cyber Supply Chain Management and Transparency Act of 2014”, amely kimondta, hogy szoftver vásárlásakor minden kormányzati szervnek kérnie kell a BOM-ot, hogy megakadályozza a sebezhető komponensek használatát, de a törvény végül soha nem lépett hatályba.

Visszatérve az SCA-ra, a Dependency Track-nak kész integrációi vannak olyan értesítési platformokkal, mint a Slack, és sebezhetőségkezelő rendszerekkel, mint a Kenna Security. Érdemes megemlíteni, hogy a Dependency Track képes az elavult csomagverziók azonosítására és információkat szolgáltat a licencekről (SPDX támogatás révén).

Ha a SCA minőségéről van szó, akkor itt alapvető különbség van.

A Dependency Track nem projektet fogad el bemenetként, hanem konkrétan a BOM-ot. Ez azt jelenti, hogy ha ellenőrizni szeretnénk egy projektet, akkor először generálnunk kell egy bom.xml-t, például a CycloneDX segítségével. Így a Dependency Track közvetlenül függ a CycloneDX-től. Ugyanakkor ez lehetőséget ad a testreszabásra. Így az OZON csapata írta a CycloneDX modult BOM-fájlok készítéséhez Golang projektek számára a Dependency Track-en keresztüli további ellenőrzés céljából.

Nexus IQ — a Sonatype cég kereskedelmi SCA megoldása, amely a Sonatype ökoszisztémájának része, amelybe a Nexus Repository Manager is tartozik. A Nexus IQ bemeneti adatokként fogadhat el .war archívumokat (java projektekhez) a webes felületen vagy API-n keresztül, valamint BOM-ot, ha a szervezet nem volt képes átállni a CycloneDX-ra az új megoldásra. A nyílt forráskódú megoldásokkal ellentétben az IQ nemcsak a CP/PURL által azonosított komponenshez és a kapcsolódó sebezhetőségekhez nyúl, hanem figyelembe veszi a saját kutatásait is, például a sebezhető függvény vagy osztály nevét. Az IQ mechanizmusait később, az eredmények elemzésekor fogjuk megvitatni.

Összegyűjtjük néhány következtetést a funkciók jellemzőiről, és megvizsgáljuk az elemzéshez támogatott nyelveket:

Nyelv
Nexus IQ
Dependency Check
Dependency Track

Java
+
+
+

C/C++
+
+
—

C#
+
+
—

.Net
+
+
+

Erlang
—
—
+

JavaScript (NodeJS)
+
+
+

PHP
+
+
+

Python
+
+
+

Ruby
+
+
+

Perl
—
—
—

Scala
+
+
+

Objective C
+
+
—

Swift
+
+
—

R
+
—
—

Go
+
+
+

Functional Capabilities

Functional Capabilities
Nexus IQ
Dependency Check
Dependency Track

Lehetőség a forráskódban használt komponensek licenc tisztaságának ellenőrzésére
+
—
+

Lehetőség a Docker képek sebezhetőségi és licenc tisztasági vizsgálatára és elemzésére
+ Integráció a Clair-rel
—
—

Lehetőség a nyílt forráskódú könyvtárak használati biztonsági politikájának beállítására
+
—
—

Lehetőség nyílt forráskódú tárolók sebezhető komponenseinek ellenőrzésére
+ RubyGems, Maven, NPM, Nuget, Pypi, Conan, Bower, Conda, Go, p2, R, Yum, Helm, Docker, CocoaPods, Git LFS
—
+ Hex, RubyGems, Maven, NPM, Nuget, Pypi

Specializált kutatócsapat megléte
+
—
—

Zárt környezetben való működés
+
+
+

Harmadik fél adatbázisainak használata
+ Zárt Sonatype adatbázis
+ Sonatype OSS, NPM Publish Advisors
+ Sonatype OSS, NPM Public Advisors, RetireJS, VulnDB, saját sebezhetőségi adatbázis támogatása

Lehetőség a nyílt forráskódú komponensek szűrésére a fejlesztési környezetbe való betöltéskor a konfigurált politikák szerint
+
—
—

Ajánlások a sebezhetőségek javításához, javítási hivatkozások megléte
+
+- (a nyilvános adatbázisok leírásától függően)
+- (a nyilvános adatbázisok leírásától függően)

Az észlelt sebezhetőségek rangsorolása kritikus mérték szerint
+
+
+

Hozzáférési szerepmintázat
+
—
+

CLI (parancssori felület) támogatás
+
+
+- (csak CycloneDX esetében)

Sebezhetőségek mintavételezése / rendezése meghatározott kritériumok szerint
+
—
+

Az alkalmazások állapotának irányítópultja
+
—
+

Jelentések generálása PDF formátumban
+
—
—

Jelentések generálása JSONCSV formátumban
+
+
—

Orosz nyelv támogatása
—
—
—

Integrációs lehetőségek

Integráció
Nexus IQ
Dependency Check
Dependency Track

Integráció LDAP/Active Directory rendszerrel
+
—
+

Integráció a Bamboo folyamatos integrációs rendszerével
+
—
—

Integráció a TeamCity folyamatos integrációs rendszerével
+
—
—

Integráció a GitLab folyamatos integrációs rendszerével
+
+- (GitLab plugin formájában)
+

Integráció a Jenkins folyamatos integrációs rendszerével
+
+
+

IDE-khez készült pluginok elérhetősége
+ IntelliJ, Eclipse, Visual Studio
—
—

Testreszabott integráció támogatása webszolgáltatásokon (API) keresztül
+
—
+

Dependency Check

Első indítás

Futtassuk a Dependency Check-et egy szándékosan sebezhető alkalmazáson DVJA.

Ehhez használjuk Dependency Check Maven Plugin:

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

Ennek eredményeként a target könyvtárban megjelenik a dependency-check-report.html.

Nyissuk meg a fájlt. A sebezhetőségek összesített számáról szóló információ után láthatjuk a magas szintű vészhelyzet és bizalom sebezhetőségeit, ezeknek a csomag, CPE, CVE számát is tartalmazzák.

Ezt követi a részletesebb információ, különösen arról, hogy miből származik a döntés (evidence), azaz egy BOM.

Ezután a CPE, PURL és a CVE leírása következik. A javítási ajánlások nem állnak rendelkezésre, mivel a NVD adatbázisból hiányoznak.

A vizsgálati eredmények rendszerezetlen megtekintéséhez konfigurálhat egy egyszerű Nginx beállítást, vagy küldheti a kapott hibákat a hibakezelő rendszerbe, amely támogatja a Dependency Check csatlakozóit. Például a Defect Dojo.

Dependency Track

Telepítés

A Dependency Track egy webes platform, amely grafikus megjelenítést biztosít, így itt nem merül fel az éles kérdés a hibák külső megoldásban történő tárolásáról.
A telepítéshez az alábbi támogatott forgatókönyvek állnak rendelkezésre: Docker, WAR, Futtatható WAR.

Első indítás

Lépjen be az elindított szolgáltatás URL-jére. Belépés admin/admin-nal, jelszó megváltoztatása után beléphet az Irányítópultra. A következő lépés, hogy projektet hozzunk létre egy tesztalkalmazás számára Java-ban a Home/Projects → Projekt létrehozása . Példának vegyük a DVJA-t.

Mivel a Dependency Track csak BOM-okat tud fogadni bemenetként, ezért ezt a BOM-ot meg kell szereznünk. Használjuk CycloneDX Maven Plugin:

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

Megkapjuk a bom.xml-t, és feltöltjük a fájlt a létrehozott projektbe DVJA → Függőségek → BOM feltöltése.

Lépjünk be az Adminisztráció → Elemzők menübe. Megértjük, hogy csak a Belső Elemző van engedélyezve, amely tartalmazza az NVD-t. Csatlakoztassuk a Sonatype OSS Indexet is.

Így a következő képet kapjuk a projektünkhöz:

A listában egy olyan sebezhetőség is található, ami a Sonatype OSS-re alkalmazható:

A legnagyobb csalódás az volt, hogy a Dependency Track már nem fogadja el a Dependency Check xml-jelentéseit. Az utolsó támogatott verziók a Dependency Check-kel való integrációban 1.0.0 – 4.0.2 voltak, miközben én a 5.3.2-t teszteltem.

Íme videón (és itt van), amikor ez még lehetséges volt.

Nexus IQ

Első indítás

A Nexus IQ telepítése archívumokból történik dokumentáció, de mi ezekhez a célokhoz saját Docker képet készítettünk.

A konzolba lépés után létre kell hozni egy Szervezetet és Alkalmazást.

Ahogyan látható, az IQ beállítása egy kicsit bonyolultabb, mivel politikákat is kell létrehoznunk, amelyek alkalmazhatóak a különböző “stádiumokban” (fejlesztés, létrehozás, előkészítés, kiadás). Erre van szükség, hogy blokkoljuk a sebezhető komponenseket, ahogy közelebb jutunk a termeléshez, vagy hogy blokkoljuk, amint a fejlesztők letöltik őket a Nexus Repo-ba.

A különbség érzékeléséhez nyílt forrású és vállalati megoldások között végezzünk el egy ugyanilyen vizsgálatot a Nexus IQ-n keresztül, hasonlóan Maven plugin, előzetesen létrehozva egy tesztalkalmazást a NexusIQ felületén dvja-teszt-és-összehasonlít:

mvn com.sonatype.clm:clm-maven-plugin:evaluate -Dclm.applicationId=dvja-teszt-és-összehasonlít -Dclm.serverUrl= -Dclm.username= -Dclm.password=

Lépjünk a generált jelentés URL-jére az IQ webes felületén:

Itt látható az összes politikai megsértés, különböző jelentőségi szintek megadásával (Info-tól a Biztonsági Kritikusig). A komponens melletti D betű azt jelenti, hogy a komponens Közvetlen Függőség, míg a T betű a komponens mellett azt jelenti, hogy a komponens Átmeneti Függőség.

Egyébként a jelentés State of Open Source Security Report 2020 a Snyk-tól arról számol be, hogy a nyílt forrású szoftverekben felfedezett sebezhetőségek több mint 70%-a, amelyeket Node.js, Java és Ruby esetében találtak, átmeneti függőségekben található.

Ha megnyitunk egy Nexus IQ politikai megsértést, láthatjuk az összetevő leírását, valamint a Version Graph-ot, amely megmutatja, hogy a jelenlegi verzió hol helyezkedik el az időbeli grafikonon, és mikor válik az adott sebezhetőség már nem sebezhetővé. A grafikonon lévő gyertyák magassága azt jelzi, hogy mennyire népszerűen használják ezt az összetevőt.

Ha a sebezhetőségek szakaszába lépünk és kinyitjuk a CVE-t, elolvashatjuk a sebezhetőség leírását, a javasolt megoldásokat, valamint az okot, amiért az adott összetevő megsértette a politikát, azaz a klassz feltüntetését. DiskFileitem.class.

Vegyük számításba kizárólag a harmadik féltől származó Java összetevőket, eltávolítva a js összetevőket. Zárójelben feltüntetjük, hogy hány sebezhetőséget találtunk az NVD-n kívül.

Összesen Nexus IQ:

• Az ellenőrzött függőségek száma: 62
• Sebezhető függőségek száma: 16
• Talált sebezhetőségek: 42 (8 sonatype db)

Összesen Dependency Check:

• Az ellenőrzött függőségek száma: 47
• Sebezhető függőségek száma: 13
• Talált sebezhetőségek: 91 (14 sonatype oss)

Összesen Dependency Track:

• Az ellenőrzött függőségek száma: 59
• Sebezhető függőségek száma: 10
• Talált sebezhetőségek: 51 (1 sonatype oss)

A következő lépés az eredmények elemzése, és annak megértése, hogy az ezekből a sebezhetőségekből melyik valódi hiba és melyik téves riasztás.

Megjegyzés

Ez a felülvizsgálat nem kétségbe vonhatatlan igazság. Az író célja nem volt kiemelni egy adott eszközt a többiek közül. A felülvizsgálat lényege az SCA eszközök működési mechanizmusának bemutatása és a eredmények ellenőrzésének módjai voltak.

Az eredmények összehasonlítása

Feltételek:

A harmadik féltől származó összetevők sebezhetőségeivel kapcsolatos téves riasztás az alábbi:

• A CVE nem felel meg a megállapított összetevőnek
• Például, ha egy sebezhetőséget a struts2 keretrendszerben észleltek, de az eszköz a struts-tiles keretrendszerre mutat, amelyre ez a sebezhetőség nem vonatkozik, akkor ez téves riasztás.
• A CVE nem felel meg a megállapított összetevő verziójának
• Például, ha a sebezhetőség a python > 3.5 verzióhoz van kötve, és az eszköz a 2.7 verziót jelöli sebezhetőnek — ez téves riasztás, mivel a sebezhetőség valójában csak a 3.x termékágra vonatkozik.
• CVE duplikálás
• Például, ha az SCA egy olyan CVE-t jelölt, amely RCE-t tesz lehetővé, majd az SCA ugyanehhez az összetevőhöz egy olyan CVE-t jelöl, amely a Cisco termékekre vonatkozik, melyek sebezhetőek ezen RCE-vel szemben. Ilyen esetben téves riasztás lesz.
• Például a CVE-t a spring-web komponensben találták, majd az SCA ugyanarra a CVE-re hivatkozik a Spring Framework más komponenseinél, miközben a CVE-nek nincs kapcsolata más komponensekkel. Ilyen esetben hamis pozitív jelzésről van szó.

A kutatás tárgya az Open Source DVJA projekt lett. A tanulmányban kizárólag Java komponensek vettek részt (JS nélkül).

Összegző eredmények

Azonnal áttérünk a manuális felülvizsgálat során feltárt sebezhetőségek eredményeire. A részletes jelentést minden CVE-ről az Mellékletben találhatják.

Összegző eredmények minden sebezhetőségről:

A parameter
Nexus IQ
Dependency Check
Dependency Track

Összesen feltárt sebezhetőségek
42
91
51

Hibásan azonosított sebezhetőségek (hamis pozitív)
2(4.76%)
62(68,13%)
29(56.86%)

Nem találtunk releváns sebezhetőségeket (hamis negatív)
10
20
27

Összegző eredmények a komponensek szerint:

A parameter
Nexus IQ
Dependency Check
Dependency Track

Összesen feltárt komponensek
62
47
59

Összesen sebezhető komponensek
16
13
10

Hibásan azonosított sebezhető komponensek (hamis pozitív)
1
5
0

Hibásan azonosított sebezhető komponensek (hamis pozitív)
0
6
6

Grafikus ábrákat készítünk, hogy felmérjük a hamis pozitív és hamis negatív jelzések arányát a teljes sebezhetőségi számhoz viszonyítva. A vízszintes tengelyen a komponensek, a függőleges tengelyen pedig az azokban feltárt sebezhetőségek találhatók.

Összehasonlításként, hasonló kutatást végzett a Sonatype csapata egy 1531 komponenst tartalmazó projekt tesztelésével az OWASP Dependency Check segítségével. Ahogy láthatjuk, a zaj és a helyes pálcák aránya hasonló a mi eredményeinkhez.

Forrás: www.sonatype.com/why-precision-matters-ebook

Nézzük meg néhány CVE-t a szkennelési eredményeinkből, hogy megértsük ezeknek az eredményeknek az okát.

További információ

1. számú

Kevesebb érdekes pontot elemzünk a Sonatype Nexus IQ-ból.

A Nexus IQ a deszerializációval kapcsolatos problémára hívja fel a figyelmet, amely lehetővé teszi a RCE-t a Spring Frameworkben többször is. A CVE-2016-1000027 a spring-web:3.0.5-ben először, és a CVE-2011-2894 a spring-context:3.0.5 és spring-core:3.0.5-ön. Eleinte úgy tűnik, hogy a sebezhetőségek többszöri CVE alapján történő duplikálása történik. Ugyanis, ha megvizsgáljuk a CVE-2016-1000027-t és a CVE-2011-2894-et az NVD adatbázisában, úgy tűnik, hogy minden világos.

Összetevő
Sérülékenység

spring-web:3.0.5
CVE-2016-1000027

spring-context:3.0.5
CVE-2011-2894

spring-core:3.0.5
CVE-2011-2894

Leírás CVE-2011-2894 az NVD-ből:


Leírás CVE-2016-1000027 az NVD-ből:


A CVE-2011-2894 önállóan eléggé ismert. A jelentésben a White Source 2011-es évjárata ezt a CVE-t az egyik leggyakrabban előfordulóként ismerték el. A CVE-2016-100027-re vonatkozóan az NVD-ben viszonylag kevés leírás található, és úgy tűnik, hogy kizárólag a Spring Framework 4.1.4-re alkalmazható. Nézzük meg a reference és itt minden egyre világosabbá válik. A Tenable cikkéből azt értjük, hogy a RemoteInvocationSerializingExporter sebezhetősége mellett a CVE-2011-2894-ben a sebezhetőség megfigyelhető a HttpInvokerServiceExporter-ben. Erről beszél nekünk a Nexus IQ:.

Mindazonáltal az NVD-ben nincs hasonló, ami miatt a Dependency Check és a Dependency Track hamis negatív adatokat kap.

A CVE-2011-2894 leírásából az is kiderül, hogy a sebezhetőség valóban jelen van a spring-context:3.0.5 és a spring-core:3.0.5 verziókban. Ezt megerősíti annak a cikknek a feljegyzése, aki felfedezte ezt a sebezhetőséget.

№2

Összetevő
Sérülékenység
Eredmény

struts2-core:2.3.30
CVE-2016-4003
HAMIS

Ha megvizsgáljuk a CVE-2016-4003 sebezhetőséget, akkor azt tapasztaljuk, hogy már a 2.3.28 verzióban javították, ennek ellenére a Nexus IQ mégis értesít róla. A sebezhetőség leírásában van egy megjegyzés:

Ez azt jelenti, hogy a sebezhetőség csak egy elavult JRE verzióval együtt létezik, amiről figyelmeztetnek minket. Ennek ellenére ezt hamis pozitívnak tekintjük, bár nem a legrosszabb.

№ 3

Összetevő
Sérülékenység
Eredmény

xwork-core:2.3.30
CVE-2017-9804
IGAZ

xwork-core:2.3.30
CVE-2017-7672
HAMIS

Ha megnézzük a CVE-2017-9804 és a CVE-2017-7672 leírását, akkor megfogalmazódik, hogy a probléma a URLValidator osztályban, és a CVE-2017-9804 a CVE-2017-7672-ből ered. A második sebezhetőség megléte semmilyen hasznos információt nem hordoz, azon kívül, hogy a súlyossága magasra nőtt, ezért ezt felesleges zajnak lehet tekinteni.

Összességében más hamis pozitívokat nem találtunk a Nexus IQ-nál.

№4

Több szempont is kiemeli az IQ-t más megoldások közül.

Összetevő
Sérülékenység
Eredmény

spring-web:3.0.5
CVE-2020-5398
IGAZ

A NVD szerint a CVE csak az 5.2.x 5.2.3 előtti verzióira, az 5.1.x 5.1.13 előtti verzióira és az 5.0.x 5.0.16 előtti verzióira vonatkozik, ugyanakkor ha megnézzük a CVE leírását a Nexus IQ-ban, a következőket láthatjuk:
Tanácsadói eltérés értesítés: A Sonatype biztonsági kutatócsapata felfedezte, hogy ezt a sebezhetőséget a 3.0.2.RELEASE verzióban vezették be, és nem az 5.0.x-ben, ahogyan a tanácsadóban szerepel.

Ezt egy PoC követi e sebezhetőséghez, amely jelzi, hogy ez a 3.0.5 verzióban is jelen van.

Hamis negatívok kerülnek a Dependency Check és a Dependency Track küldésre.

№5

Nézzük meg a hamis pozitívokat a Dependency Check és a Dependency Track esetében.

A Dependency Check kiemelkedik abban, hogy azokat a CVE-ket tükrözi, amelyek az NVD-ben az egész keretrendszerre vonatkoznak, azokban a komponensekben, amelyekhez ezek a CVE-k nem alkalmazhatóak. Ez vonatkozik a CVE-2012-0394, CVE-2013-2115, CVE-2014-0114, CVE-2015-0899, CVE-2015-2992, CVE-2016-1181, CVE-2016-1182 CVE-kre, amelyeket a Dependency Check

Hasonló helyzet áll fenn a spring-tx:3.0.5 esetében, és hasonló a helyzet a struts-core:1.3.8-nál. A struts-core esetében a Dependency Check és a Dependency Track rengeteg sebezhetőséget talált, amelyek valójában a struts2-core-ra vonatkoznak, amely lényegében egy különálló keretrendszer. Esetünkben a Nexus IQ helyesen értelmezte a helyzetet, és az általa kiadott CVE-k között jelezte, hogy a struts-core elérte a lejárati dátumot, és át kell térni a struts2-core-ra.

6. szám

Egyes helyzetekben nem igazságos az egyértelmű hibát a Dependency Check és a Dependency Track által értelmezni. A CVE-2013-4152, CVE-2013-6429, CVE-2013-6430, CVE-2013-7315, CVE-2014-0054, CVE-2014-0225, CVE-2014-0225 például, amelyeket a Dependency Check és a Dependency Track a spring-core:3.0.5-höz sorolt, valójában a spring-web:3.0.5-höz tartoznak. Közben ezek közül néhány CVE-t a Nexus IQ is megtalált, azonban az IQ helyesen a másik komponenshez rendelte őket. Az, hogy ezek a sebezhetőségek nem voltak felfedezve a spring-core-ban, nem jelenti azt, hogy ne lennének a keretrendszerben alapvetően, és az open source eszközök jogosan jelezték ezeket a sebezhetőségeket (csak egy kicsit tévedtek).

Következtetések

Ahogy láthatjuk, a felfedezett sebezhetőségek hitelességének meghatározása kézi ellenőrzés esetén nem ad egyértelmű eredményeket, ami vitás helyzeteket teremt. Az eredmények azt mutatják, hogy a Nexus IQ megoldása a legkevesebb hamis pozitív eredménnyel és a legnagyobb pontossággal bír.

Először is, ez azzal kapcsolatos, hogy a Sonatype csapata kibővítette a NVD-ből származó CVE sebezhetőségek leírását saját adatbázisaikban, pontosan megjelölve a sebezhetőség osztályát vagy funkcióját az adott komponens verziójára nézve, további kutatásokat végezve (például az öregebb szoftververziók sebezhetőségeit is ellenőrizve).

A NVD-be nem bekerült sebezhetőségek, de a Sonatype adatbázisában SONATYPE jelöléssel szereplő sebezhetőségek is jelentős hatással vannak az eredményekre. A jelentés szerint A nyílt forráskódú biztonsági sebezhetőségek állapota 2020 a felfedezett nyílt forráskódú sebezhetőségek 45%-áról nem számolnak be az NVD-ben. A WhiteSource adatbázisa szerint a nyílt forráskódú sebezhetőségek csupán 29%-a, amelyet az NVD-n kívül regisztráltak, végül publikálják az NVD-ben, ezért oly fontos, hogy más forrásokban is keresni a sebezhetőségeket.

Összességében a Dependency Check rengeteg zajt generál, miközben egyes sebezhető komponensek kimaradnak. A Dependency Track kevesebb zajt generál és nagyobb számú komponenst fedez fel, ami esztétikailag is kellemesebb a webes felületen.

Mindazonáltal a gyakorlat azt mutatja, hogy az open source-nak kellene az első lépésnek lennie a fejlődő DevSecOps irányába. Az első dolog, amin érdemes elgondolkodni a SCA fejlesztésbe való beágyazásához, a folyamatok, nevezetesen a vezetőséggel és a kapcsolódó részlegekkel való közös gondolkodás arról, hogyan is nézzenek ki az ideális folyamatok a saját szervezetükben. Lehet, hogy kiderül, hogy a Dependency Check vagy a Dependency Track az Önök számára kezdetben minden üzleti igényt kielégít, míg a vállalati megoldások logikus folytatását jelentik az egyre bonyolultabb alkalmazások fejlesztésének.

A. Melléklet. Eredmények az összetevők kapcsán
Jelölések:

• Magas — magas és kritikus szintű sebezhetőségek az összetevőben
• Közepes — közepes szintű sebezhetőségek az összetevőben
• IGAZ — helyesen azonosított sebezhetőség (True positive issue)
• HAMIS — téves riasztás (False positive issue)

Összetevő
Nexus IQ
Dependency Check
Dependency Track
Eredmény

dom4j: 1.6.1
Magas
Magas
Magas
IGAZ

log4j-core: 2.3
Magas
Magas
Magas
IGAZ

log4j: 1.2.14
Magas
Magas
—
IGAZ

commons-collections: 3.1
Magas
Magas
Magas
IGAZ

commons-fileupload: 1.3.2
Magas
Magas
Magas
IGAZ

commons-beanutils: 1.7.0
Magas
Magas
Magas
IGAZ

commons-codec: 1:10
Közepes
—
—
IGAZ

mysql-connector-java: 5.1.42
Magas
Magas
Magas
IGAZ

spring-expression: 3.0.5
Magas
komponens nem található

IGAZ

spring-web:3.0.5
Magas
komponens nem található
Magas
IGAZ

spring-context:3.0.5
Közepes
komponens nem található
—
IGAZ

spring-core:3.0.5
Közepes
Magas
Magas
IGAZ

struts2-config-browser-plugin: 2.3.30
Közepes
—
—
IGAZ

spring-tx: 3.0.5
—
Magas
—
HAMIS

struts-core: 1.3.8
Magas
Magas
Magas
IGAZ

xwork-core: 2.3.30
Magas
—
—
IGAZ

struts2-core: 2.3.30
Magas
Magas
Magas
IGAZ

struts-taglib: 1.3.8
—
Magas
—
HAMIS

struts-tiles-1.3.8
—
Magas
—
HAMIS

B. Melléklet. Eredmények a sebezhetőségek kapcsán
Jelölések:

• Magas — magas és kritikus szintű sebezhetőségek az összetevőben
• Közepes — közepes szintű sebezhetőségek az összetevőben
• IGAZ — helyesen azonosított sebezhetőség (True positive issue)
• HAMIS — téves riasztás (False positive issue)

Összetevő
Nexus IQ
Dependency Check
Dependency Track
Súlyosság
Eredmény
Megjegyzés

dom4j: 1.6.1
CVE-2018-1000632
CVE-2018-1000632
CVE-2018-1000632
Magas
IGAZ

CVE-2020-10683
CVE-2020-10683
CVE-2020-10683
Magas
IGAZ

log4j-core: 2.3
CVE-2017-5645
CVE-2017-5645
CVE-2017-5645
Magas
IGAZ

CVE-2020-9488
CVE-2020-9488
CVE-2020-9488
Alacsony
IGAZ

log4j: 1.2.14
CVE-2019-17571
CVE-2019-17571
—
Magas
IGAZ

—
CVE-2020-9488
—
Alacsony
IGAZ

SONATYPE-2010-0053
—
—
Magas
IGAZ

commons-collections: 3.1
—
CVE-2015-6420
CVE-2015-6420
Magas
HAMIS
Ismétli RCE(OSSINDEX)

—
CVE-2017-15708
CVE-2017-15708
Magas
HAMIS
Ismétli RCE(OSSINDEX)

SONATYPE-2015-0002
RCE (OSSINDEX)
RCE(OSSINDEX)
Magas
IGAZ

commons-fileupload: 1.3.2
CVE-2016-1000031
CVE-2016-1000031
CVE-2016-1000031
Magas
IGAZ

SONATYPE-2014-0173
—
—
Közepes
IGAZ

commons-beanutils: 1.7.0
CVE-2014-0114
CVE-2014-0114
CVE-2014-0114
Magas
IGAZ

—
CVE-2019-10086
CVE-2019-10086
Magas
HAMIS
A sebezhetőség csak a 1.9.2+ verziókra vonatkozik

commons-codec: 1:10
SONATYPE-2012-0050
—
—
Közepes
IGAZ

mysql-connector-java: 5.1.42
CVE-2018-3258
CVE-2018-3258
CVE-2018-3258
Magas
IGAZ

CVE-2019-2692
CVE-2019-2692
—
Közepes
IGAZ

—
CVE-2020-2875
—
Közepes
HAMIS
Ugyanaz a sebezhetőség, mint a CVE-2019-2692, de a hivatkozással, hogy "a támadások jelentősen befolyásolhatják a további termékeket"

—
CVE-2017-15945
—
Magas
HAMIS
Nem vonatkozik a mysql-connector-java-ra

—
CVE-2020-2933
—
Alacsony
HAMIS
Duplikált a CVE-2020-2934-hez

CVE-2020-2934
CVE-2020-2934
—
Közepes
IGAZ

spring-expression: 3.0.5
CVE-2018-1270
komponens nem található
—
Magas
IGAZ

CVE-2018-1257
—
—
Közepes
IGAZ

spring-web:3.0.5
CVE-2016-1000027
komponens nem található
—
Magas
IGAZ

CVE-2014-0225
—
CVE-2014-0225
Magas
IGAZ

CVE-2011-2730
—
—
Magas
IGAZ

—
—
CVE-2013-4152
Közepes
IGAZ

CVE-2018-1272
—
—
Magas
IGAZ

CVE-2020-5398
—
—
Magas
IGAZ
Példás eset az IQ mellett: „A Sonatype biztonsági kutatócsapata felfedezte, hogy ezt a sebezhetőséget a 3.0.2.RELEASE verzióban vezették be, és nem az 5.0.x verzióban, ahogy a közleményben állt.”

CVE-2013-6429
—
—
Közepes
IGAZ

CVE-2014-0054
—
CVE-2014-0054
Közepes
IGAZ

CVE-2013-6430
—
—
Közepes
IGAZ

spring-context:3.0.5
CVE-2011-2894
komponens nem található
—
Közepes
IGAZ

spring-core:3.0.5
—
CVE-2011-2730
CVE-2011-2730
Magas
IGAZ

CVE-2011-2894
CVE-2011-2894
CVE-2011-2894
Közepes
IGAZ

—
—
CVE-2013-4152
Közepes
HAMIS
Ez a sebezhetőség ugyanennek a sebezhetőségnek az másolata a spring-web számára

—
CVE-2013-4152
—
Közepes
HAMIS
A sebezhetőség a spring-web komponenshez tartozik

—
CVE-2013-6429
CVE-2013-6429
Közepes
HAMIS
A sebezhetőség a spring-web komponenshez tartozik

—
CVE-2013-6430
—
Közepes
HAMIS
A sebezhetőség a spring-web komponenshez tartozik

—
CVE-2013-7315
CVE-2013-7315
Közepes
HAMIS
SPLIT a CVE-2013-4152-ből. + A sebezhetőség a spring-web komponenshez tartozik

—
CVE-2014-0054
CVE-2014-0054
Közepes
HAMIS
A sebezhetőség a spring-web komponenshez tartozik

—
CVE-2014-0225
—
Magas
HAMIS
A sebezhetőség a spring-web komponenshez tartozik

—
—
CVE-2014-0225
Magas
HAMIS
Ez a sebezhetőség ugyanennek a sebezhetőségnek az másolata a spring-web számára

—
CVE-2014-1904
CVE-2014-1904
Közepes
HAMIS
A sebezhetőség a spring-web-mvc komponenshez tartozik

—
CVE-2014-3625
CVE-2014-3625
Közepes
HAMIS
A sebezhetőség a spring-web-mvc komponenshez tartozik

—
CVE-2016-9878
CVE-2016-9878
Magas
HAMIS
A sebezhetőség a spring-web-mvc komponenshez tartozik

—
CVE-2018-1270
CVE-2018-1270
Magas
HAMIS
A spring-expression / spring-messages számára

—
CVE-2018-1271
CVE-2018-1271
Közepes
HAMIS
A sebezhetőség a spring-web-mvc komponenshez tartozik

—
CVE-2018-1272
CVE-2018-1272
Magas
IGAZ

CVE-2014-3578
CVE-2014-3578 (OSSINDEX)
CVE-2014-3578
Közepes
IGAZ

SONATYPE-2015-0327
—
—
Alacsony
IGAZ

struts2-config-browser-plugin: 2.3.30
SONATYPE-2016-0104
—
—
Közepes
IGAZ

spring-tx: 3.0.5
—
CVE-2011-2730
—
Magas
HAMIS
A sebezhetőség nem vonatkozik a spring-tx-re

—
CVE-2011-2894
—
Magas
HAMIS
A sebezhetőség nem vonatkozik a spring-tx-re

—
CVE-2013-4152
—
Közepes
HAMIS
A sebezhetőség nem vonatkozik a spring-tx-re

—
CVE-2013-6429
—
Közepes
HAMIS
A sebezhetőség nem vonatkozik a spring-tx-re

—
CVE-2013-6430
—
Közepes
HAMIS
A sebezhetőség nem vonatkozik a spring-tx-re

—
CVE-2013-7315
—
Közepes
HAMIS
A sebezhetőség nem vonatkozik a spring-tx-re

—
CVE-2014-0054
—
Közepes
HAMIS
A sebezhetőség nem vonatkozik a spring-tx-re

—
CVE-2014-0225
—
Magas
HAMIS
A sebezhetőség nem vonatkozik a spring-tx-re

—
CVE-2014-1904
—
Közepes
HAMIS
A sebezhetőség nem vonatkozik a spring-tx-re

—
CVE-2014-3625
—
Közepes
HAMIS
A sebezhetőség nem vonatkozik a spring-tx-re

—
CVE-2016-9878
—
Magas
HAMIS
A sebezhetőség nem vonatkozik a spring-tx-re

—
CVE-2018-1270
—
Magas
HAMIS
A sebezhetőség nem vonatkozik a spring-tx-re

—
CVE-2018-1271
—
Közepes
HAMIS
A sebezhetőség nem vonatkozik a spring-tx-re

—
CVE-2018-1272
—
Közepes
HAMIS
A sebezhetőség nem vonatkozik a spring-tx-re

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

Közepes
HAMIS
Sebezhetőség a Struts 2-höz

—
CVE-2012-0391 (OSSINDEX)
CVE-2012-0391
Magas
HAMIS
Sebezhetőség a Struts 2-höz

—
CVE-2014-0094 (OSSINDEX)
CVE-2014-0094
Közepes
HAMIS
Sebezhetőség a Struts 2-höz

—
CVE-2014-0113 (OSSINDEX)
CVE-2014-0113
Magas
HAMIS
Sebezhetőség a Struts 2-höz

CVE-2016-1182
3VE-2016-1182
—
Magas
IGAZ

—
—
CVE-2011-5057
Közepes
HAMIS
Sebezhetőség a Struts 2-höz

—
CVE-2012-0392 (OSSINDEX)
CVE-2012-0392
Magas
HAMIS
Sebezhetőség a Struts 2-höz

—
CVE-2012-0393 (OSSINDEX)
CVE-2012-0393
Közepes
HAMIS
Sebezhetőség a Struts 2-höz

CVE-2015-0899
CVE-2015-0899
—
Magas
IGAZ

—
CVE-2012-0394
CVE-2012-0394
Közepes
HAMIS
Sebezhetőség a Struts 2-höz

—
CVE-2012-0838 (OSSINDEX)
CVE-2012-0838
Magas
HAMIS
Sebezhetőség a Struts 2-höz

—
CVE-2013-1965 (OSSINDEX)
CVE-2013-1965
Magas
HAMIS
Sebezhetőség a Struts 2-höz

—
CVE-2013-1966 (OSSINDEX)
CVE-2013-1966
Magas
HAMIS
Sebezhetőség a Struts 2-höz

—
CVE-2013-2115
CVE-2013-2115
Magas
HAMIS
Sebezhetőség a Struts 2-höz

—
CVE-2013-2134 (OSSINDEX)
CVE-2013-2134
Magas
HAMIS
Sebezhetőség a Struts 2-höz

—
CVE-2013-2135 (OSSINDEX)
CVE-2013-2135
Magas
HAMIS
Sebezhetőség a Struts 2-höz

CVE-2014-0114
CVE-2014-0114
—
Magas
IGAZ

—
CVE-2015-2992
CVE-2015-2992
Közepes
HAMIS
Sebezhetőség a Struts 2-höz

—
CVE-2016-0785 (OSSINDEX)
CVE-2016-0785
Magas
HAMIS
Sebezhetőség a Struts 2-höz

CVE-2016-1181
CVE-2016-1181
—
Magas
IGAZ

—
CVE-2016-4003 (OSSINDEX)
CVE-2016-4003
Magas
HAMIS
Sebezhetőség a Struts 2-höz

xwork-core:2.3.30
CVE-2017-9804
—
—
Magas
IGAZ

SONATYPE-2017-0173
—
—
Magas
IGAZ

CVE-2017-7672
—
—
Magas
HAMIS
Dupla k CVE-2017-9804

SONATYPE-2016-0127
—
—
Magas
IGAZ

struts2-core:2.3.30
—
CVE-2016-6795
CVE-2016-6795
Magas
IGAZ

—
CVE-2017-9787
CVE-2017-9787
Magas
IGAZ

—
CVE-2017-9791
CVE-2017-9791
Magas
IGAZ

—
CVE-2017-9793
—
Magas
HAMIS
Duplikát k CVE-2018-1327

—
CVE-2017-9804
—
Magas
IGAZ

—
CVE-2017-9805
CVE-2017-9805
Magas
IGAZ

CVE-2016-4003
—
—
Közepes
HAMIS
Alkalmazható az Apache Struts 2.x 2.3.28-ig, míg a verzió 2.3.30. Mindazonáltal, a leírás alapján a CVE bármely Struts 2 verzióra érvényes, ha JRE 1.7 vagy annál régebbit használnak. Úgy tűnik, hogy itt próbálták biztosítani magukat, de inkább úgy tűnik, hogy FALSE.

—
CVE-2018-1327
CVE-2018-1327
Magas
IGAZ

CVE-2017-5638
CVE-2017-5638
CVE-2017-5638
Magas
IGAZ
Ez a sebezhetőség, amelyet a hackerek kihasználtak az Equifaxnál 2017-ben.

CVE-2017-12611
CVE-2017-12611
—
Magas
IGAZ

CVE-2018-11776
CVE-2018-11776
CVE-2018-11776
Magas
IGAZ

struts-taglib: 1.3.8
—
CVE-2012-0394
—
Közepes
HAMIS
A struts2-core-hoz.

—
CVE-2013-2115
—
Magas
HAMIS
A struts2-core-hoz.

—
CVE-2014-0114
—
Magas
HAMIS
A commons-beanutils-hoz.

—
CVE-2015-0899
—
Magas
HAMIS
Nem vonatkozik a taglib-re.

—
CVE-2015-2992
—
Közepes
HAMIS
A struts2-core-hoz tartozik.

—
CVE-2016-1181
—
Magas
HAMIS
Nem vonatkozik a taglib-re.

—
CVE-2016-1182
—
Magas
HAMIS
Nem vonatkozik a taglib-re.

struts-tiles-1.3.8
—
CVE-2012-0394
—
Közepes
HAMIS
A struts2-core-hoz.

—
CVE-2013-2115
—
Magas
HAMIS
A struts2-core-hoz.

—
CVE-2014-0114
—
Magas
HAMIS
A commons-beanutils alatt.

—
CVE-2015-0899
—
Magas
HAMIS
Nem vonatkozik a tiles-ra.

—
CVE-2015-2992
—
Közepes
HAMIS
A struts2-core-hoz.

—
CVE-2016-1181
—
Magas
HAMIS
Nem vonatkozik a taglib-re.

—
CVE-2016-1182
—
Magas
HAMIS
Nem vonatkozik a taglib-re.

Forrás: habr.com