Importanța analizei componentelor software de terță parte (eng. Software Composition Analysis — SCA) în procesul de dezvoltare crește odată cu publicarea anuală a rapoartelor privind vulnerabilitățile bibliotecilor open source, publicate de companiile Synopsys, Sonatype, Snyk, White Source. Potrivit raportului numărul de vulnerabilități detectate în open source în 2019 a crescut cu aproape 1.5 ori comparativ cu anul precedent, în timp ce componentele cu cod deschis sunt utilizate în 60% până la 80% din proiecte. Dacă ne raportăm la opiniile independente, procesele SCA sunt o practică distinctă în OWASP SAMM și BSIMM ca indicator de maturitate, iar în prima jumătate a anului 2020, OWASP a lansat un nou standard OWASP Software Component Verification Standard (SCVS), care oferă bune practici pentru verificarea componentelor de terță parte în lanțul de furnizare a software-ului.

Unul dintre cele mai ilustrative cazuri cu compania Equifax în mai 2017. Hackerii necunoscuți au obținut informații despre 143 de milioane de americani, inclusiv nume complete, adrese, numere de asigurare socială și permise de conducere. În 209.000 de cazuri, documentele conțineau de asemenea informații despre cardurile bancare ale victimelor. Această scurgere de date a avut loc în urma exploatării unei vulnerabilități critice în Apache Struts 2 (CVE-2017-5638), deși un patch fusese lansat în martie 2017. Compania a avut două luni pentru a implementa actualizarea, dar nimeni nu s-a ocupat de aceasta.
În acest articol se va discuta alegerea instrumentului pentru realizarea SCA din perspectiva calității rezultatelor analizei. De asemenea, va fi prezentat un comparativ funcțional al instrumentelor. Procesul de integrare în CI/CD și posibilitățile de integrare vor fi lăsate pentru publicații viitoare. O listă extinsă de instrumente a fost prezentată de OWASP , dar în cadrul acestui rezumat ne vom referi doar la cel mai popular instrument open source Dependency Check, la platforma open source ceva mai puțin cunoscută Dependency Track și la soluția Enterprise Sonatype Nexus IQ. De asemenea, vom analiza modul în care funcționează aceste soluții și vom compara rezultatele obținute în ceea ce privește alertele false.

Principiul de funcționare
— este un utilitar (CLI, maven, modul jenkins, ant) care analizează fișierele proiectului, colectează fragmente de informații despre dependențe (numele pachetului, groupid, titlul specificației, versiune…), construiește un șir CPE — (Common Platform Enumeration), Package URL (PURL) și identifică pentru CPE/PURL vulnerabilități din baze de date (NVD, Sonatype OSS Index, NPM Audit API…), după care generează un raport temporar în format HTML, JSON, XML…
Să examinăm cum arată CPE:
cpe:2.3:part:vendor:product:version:update:edition:language:sw_edition:target_sw:target_hw:other- Part: Indicație privind faptul că componenta aparține aplicației (a), sistemului de operare (o), hardware-ului (h) (punct obligatoriu)
- Vendor: Numele producătorului produsului (punct obligatoriu)
- Product: Numele produsului (punct obligatoriu)
- Version: Versiunea componentei (punct învechit)
- Actualizare: Actualizarea pachetului
- Edition: Versiunea moștenită (punct învechit)
- Language: Limbă, definită în RFC-5646
- SW Edition: Versiunea software-ului
- Target SW: Mediul software în care funcționează produsul
- Target HW: Mediul hardware în care funcționează produsul
- Other: Informații despre furnizor sau produs
Un exemplu de CPE arată astfel:
cpe:2.3:a:pivotal_software:spring_framework:3.0.0:*:*:*:*:*:*:* Șirul indică faptul că CPE versiunea 2.3 descrie componenta aplicației de la producătorul pivotal_software cu numele spring_framework versiunea 3.0.0. Dacă deschidem vulnerabilitatea în NVD, putem observa menționarea acestei CPE. Prima problemă la care ar trebui să ne concentrăm este că CVE în NVD, conform CPE, raportează o problemă în framework, nu în o anumită componentă. Asta înseamnă că, dacă dezvoltatorii sunt puternic legați de framework, iar vulnerabilitatea identificată nu se referă la modulele pe care le folosesc, specialistului în securitate îi va fi necesar să analizeze această CVE și să se gândească la actualizare.
Adresa URL este, de asemenea, utilizată de instrumentele SCA. Formatul adresei URL a pachetului este următorul:
scheme:type/namespace/name@version?qualifiers#subpath- Scheme: Va fi întotdeauna ‘pkg’, indicând că aceasta este adresa URL a pachetului (punct obligatoriu)
- Type: «Tip» de pachet sau «protocol» de pachet, de exemplu maven, npm, nuget, gem, pypi etc. (punct obligatoriu)
- Namespace: Un anumit prefix al numelui, cum ar fi identificatorul grupului Maven, proprietarul imaginii Docker, utilizator sau organizație GitHub. Opțional și depinde de tip.
- Name: Numele pachetului (punct obligatoriu)
- Version: Versiunea pachetului
- Qualifiers: Date suplimentare de calificare pentru pachet, precum OS, arhitectură, distribuție etc. Opțional și dependent de tip.
- Subpath: Cale suplimentară în pachet în raport cu rădăcina pachetului
De exemplu:
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— platformă web on-premise care acceptă Bill of Materials (BOM) pregătite și , adică specificații pregătite despre dependențele existente. Acesta este un fișier XML care descrie dependențele — nume, hashes, URL pachet, editor, licență. Apoi, Dependency Track analizează BOM-ul, compară dependențele identificate cu CVE-uri din baza de date a vulnerabilităților (NVD, Sonatype OSS Index ...), după care construiește grafice, calculează metrici, actualizând regulat informațiile despre statutul vulnerabilităților componentelor.
Exemplu de cum poate arăta un BOM în format XML:
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-ul poate fi folosit nu doar ca parametru de intrare pentru Dependency Track, ci și pentru inventarierea componentelor software în lanțul de aprovizionare, de exemplu, pentru a oferi clientului software. În 2014, a fost propus în SUA chiar și un proiect de lege , care stipula că la achiziția de software, orice instituție guvernamentală trebuie să solicite BOM pentru a preveni utilizarea componentelor vulnerabile, însă actul nu a fost aplicat niciodată.
Revenind la SCA, Dependency Track are integrații gata făcute cu platforme de notificare precum Slack, sisteme de management al vulnerabilităților precum Kenna Security. De asemenea, merită menționat că Dependency Track identifică versiunile învechite ale pachetelor și oferă informații despre licențe (prin suportul pentru SPDX).
Dacă vorbim despre calitatea SCA, atunci aici există o diferență fundamentală.
Dependency Track nu primește proiectul ca date de intrare, ci acceptă BOM. Asta înseamnă că, dacă vrem să verificăm proiectul, mai întâi trebuie să generăm bom.xml, de exemplu, cu ajutorul CycloneDX. Astfel, Dependency Track depinde direct de CycloneDX. În același timp, aceasta oferă posibilitatea de personalizare. Așa a scris echipa OZON pentru generarea fișierelor BOM pentru proiectele în Golang, cu scopul de a fi scanate ulterior prin Dependency Track.
este o soluție comercială SCA de la Sonatype, care face parte din ecosistemul Sonatype, care include, de asemenea, Nexus Repository Manager. Nexus IQ poate accepta ca date de intrare atât arhive war (pentru proiectele Java) prin interfața web sau API, cât și BOM, dacă organizația dumneavoastră nu a reușit să tranziția de la CycloneDX la noua soluție. Spre deosebire de soluțiile open source, IQ nu se limitează doar la CP/PURL pentru componenta identificată și vulnerabilitatea corespunzătoare din baza de date, ci ia în considerare și cercetările proprii, de exemplu, numele funcției sau clasei vulnerabile. Mecanismele IQ vor fi discutate mai târziu în analiza rezultatelor.
Să tragem câteva concluzii despre caracteristicile funcționale, precum și să examinăm limbajele acceptate pentru analiză:
Language
Nexus IQ
Dependency Check
Dependency Track
Java
+
+
+
C/C++
+
+
—
C#
+
+
—
.Net
+
+
+
Erlang
—
—
+
JavaScript (NodeJS)
+
+
+
PHP
+
+
+
Python
+
+
+
Ruby
+
+
+
Perl
—
—
—
Scala
+
+
+
Objective C
+
+
—
Swift
+
+
—
R
+
—
—
Go
+
+
+
Funcționalitățile
Funcționalitățile
Nexus IQ
Dependency Check
Dependency Track
Posibilitatea de a asigura verificarea componentelor utilizate în codul sursă pentru conformitatea licenței
+
—
+
Posibilitatea de a scana și analiza imaginile Docker pentru vulnerabilități și conformitatea licenței
+ Integrare cu Clair
—
—
Posibilitatea de a configura politica de securitate pentru utilizarea bibliotecilor open source
+
—
—
Posibilitatea de a scana repositoare open source pentru a identifica componente vulnerabile
+ RubyGems, Maven, NPM, Nuget, Pypi, Conan, Bower, Conda, Go, p2, R, Yum, Helm, Docker, CocoaPods, Git LFS
—
+ Hex, RubyGems, Maven, NPM, Nuget, Pypi
Existenta unei echipe de cercetare specializată
+
—
—
Funcționare într-un contur închis
+
+
+
Utilizarea bazelor de date externe
+ Baza de date închisă Sonatype
+ Sonatype OSS, NPM Public Advisors
+ Sonatype OSS, NPM Public Advisors, RetireJS, VulnDB, suport pentru propria bază de date de vulnerabilități
Posibilitatea de a filtra componentele open source în timpul încercării de a le încărca în conturul de dezvoltare conform politicilor configurate
+
—
—
Recomandări pentru remedierea vulnerabilităților, cu linkuri către soluții
+
+- (depinde de descrierea din bazele publice)
+- (depinde de descrierea din bazele publice)
Clasificarea vulnerabilităților găsite în funcție de gravitate
+
+
+
Modelul de acces pe roluri
+
—
+
Suport pentru interfața de linie de comandă CLI
+
+
+- (doar pentru CycloneDX)
Filtrarea / sortarea vulnerabilităților în funcție de criteriile definite
+
—
+
Dashboard pentru starea aplicațiilor
+
—
+
Generarea raportelor în format PDF
+
—
—
Generarea raportelor în format JSONCSV
+
+
—
Suport pentru limba rusă
—
—
—
Capabilități de integrare
Integrare
Nexus IQ
Dependency Check
Dependency Track
Integrare cu LDAP/Active Directory
+
—
+
Integrare cu sistemul de integrare continuă (continous integration) Bamboo
+
—
—
Integrare cu sistemul de integrare continuă (continous integration) TeamCity
+
—
—
Integrare cu sistemul de integrare continuă (continous integration) GitLab
+
+- (sub formă de plugin pentru GitLab)
+
Integrare cu sistemul de integrare continuă (continous integration) Jenkins
+
+
+
Disponibilitatea plugin-urilor pentru IDE
+ IntelliJ, Eclipse, Visual Studio
—
—
Suport pentru integrarea personalizată prin web-services (API) ale instrumentului
+
—
+
Dependency Check
Prima lansare
Vom rula Dependency Check pe o aplicație vulnerabilă intenționat .
Pentru aceasta, vom folosi :
mvn org.owasp:dependency-check-maven:checkCa rezultat, în directorul target va apărea dependency-check-report.html.

Vom deschide fișierul. După informațiile sumare despre numărul total de vulnerabilități, putem vedea informații despre vulnerabilitățile cu nivel mare de gravitate și încredere, indicând pachetul, CPE, numărul CVE.
Urmează informații mai detaliate, în special despre baza deciziei (evidence), adică un fel de BOM.

Apoi apare CPE, PURL și descrierea CVE. Recomandările pentru remedieri nu sunt incluse din cauza absenței lor în baza NVD.

Pentru a vizualiza sistematic rezultatele scanării, se poate configura Nginx cu setări minime sau trimite defectele obținute în sistemul de gestionare a defectelor care suportă conectorii pentru Dependency Check. De exemplu, Defect Dojo.
Dependency Track
Instalare
Dependency Track, la rândul său, este o platformă web cu grafice vizibile, așa că problematica stocării defectelor în soluții externe nu se pune aici.
Pentru instalare, există următoarele scenarii acceptate: Docker, WAR, Executable WAR.
Prima lansare
Accesăm URL-ul serviciului lansat. Ne logăm cu admin/admin, schimbăm numele de utilizator și parola, după care ajungem la Dashboard. Următorul lucru pe care îl vom face este să creăm un proiect pentru aplicația de testare în Java în Home/Projects → Create Project . Ca exemplu, vom lua DVJA.

Deoarece Dependency Track poate accepta doar BOM ca date de intrare, este necesar să obținem acest BOM. Să folosim :
mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBomVom obține bom.xml și vom încărca fișierul în proiectul creat DVJA → Dependeencies → Upload BOM.
Accesăm Administration → Analyzers. Observăm că avem activat doar Internal Analyzer, care include NVD. Vom conecta și Sonatype OSS Index.

Astfel, vom obține următoarea imagine pentru proiectul nostru:

De asemenea, în listă putem găsi o vulnerabilitate aplicabilă la Sonatype OSS:

Principalul dezamăgire a fost că Dependency Track nu mai acceptă rapoarte XML de la Dependency Check. Ultimele versiuni acceptate de integrare cu Dependency Check erau 1.0.0 — 4.0.2, în timp ce eu testam versiunea 5.3.2.
Iată Volume Provisioning ), când acest lucru era încă posibil.
Nexus IQ
Prima lansare
Instalarea Nexus IQ se face din arhive de , dar pentru aceste scopuri am creat o imagine Docker.
După ce ne conectăm la consolă, este necesar să creăm o Organizație și o Aplicație.



Așa cum se poate observa, configurarea în cazul IQ este ceva mai complexă, deoarece trebuie să creăm și politici aplicabile pentru diferite „etape” (dev, build, stage, release). Acest lucru este necesar pentru a bloca componentele vulnerabile pe măsură ce avansăm în pipeline spre producție, sau pentru a le bloca de îndată ce ajung în Nexus Repo la descărcarea de către dezvoltatori.
Pentru a simți diferența dintre open source și enterprise, vom efectua aceeași scanare prin Nexus IQ similar cu , după ce am creat anterior o aplicație de test în interfața NexusIQ dvja-test-and-compare:
mvn com.sonatype.clm:clm-maven-plugin:evaluate -Dclm.applicationId=dvja-test-and-compare -Dclm.serverUrl= -Dclm.username= -Dclm.password=
Accesăm URL-ul raportului generat în interfața web IQ:

Aici putem vedea toate încălcările politicii, indicând diferite niveluri de severitate (de la Info la Security Critical). Litera D lângă componentă înseamnă că aceasta este o Direct Dependency, iar litera T lângă componentă înseamnă că aceasta este o Transitive Dependency, adică este tranzitivă.
Apropo, raportul de la Snyk indică faptul că peste 70% din vulnerabilitățile open source descoperite în Node.js, Java și Ruby se află în dependențe tranzitive.
Dacă deschidem una dintre încălcările politicii Nexus IQ, putem vedea descrierea componentei, precum și Graph-ul Versiunii, care arată locația versiunii curente pe graficul temporal, precum și momentul în care vulnerabilitatea încetează să mai fie vulnerabilă. Înălțimea lumânărilor de pe grafic indică popularitatea utilizării acestei componente.

Dacă mergem la secțiunea vulnerabilităților și desfășurăm CVE, putem citi descrierea acestei vulnerabilități, recomandările de remediere, precum și motivul pentru care această componentă a fost inclusă sub încălcare, adică existența clasei DiskFileitem.class.


Să tragem concluzii doar cu privire la componentele externe Java, eliminând componentele js. În paranteză vom indica numărul de vulnerabilități care au fost găsite în afara NVD.
Total Nexus IQ:
- Dependențe Scannate: 62
- Dependențe Vulnerabile: 16
- Vulnerabilități Găsite: 42 (8 baza de date sonatype)
Total Dependency Check:
- Dependențe Scannate: 47
- Dependențe Vulnerabile: 13
- Vulnerabilități Găsite: 91 (14 sonatype oss)
Total Dependency Track:
- Dependențe Scannate: 59
- Dependențe Vulnerabile: 10
- Vulnerabilități Găsite: 51 (1 sonatype oss)
Următorul pas este să analizăm rezultatele obținute și să ne dăm seama ce dintre aceste vulnerabilități reprezintă un defect real și ce este o alarmă falsă.
Declinarea responsabilității
Această revizuire nu este o adevăr incontestabil. Autorul nu a avut ca obiectiv să evidențieze un anumit instrument în comparație cu altele. Scopul revizuirii a fost să arate mecanismele de funcționare ale instrumentelor SCA și modalitățile de verificare a rezultatelor lor.
Compararea rezultatelor
Condiții:
O alarmă falsă în ceea ce privește vulnerabilitățile componentelor externe este:
- Neconcordanța CVE cu componenta identificată
- De exemplu, dacă vulnerabilitatea este identificată în cadrul struts2 și instrumentul indică o componentă din cadrul struts-tiles, la care această vulnerabilitate nu se aplică, atunci aceasta este o alarmă falsă.
- Neconcordanța CVE cu versiunea identificată a componentei
- De exemplu, vulnerabilitatea este legată de versiunea python > 3.5 și instrumentul marchează versiunea 2.7 ca vulnerabilă - aceasta este o alarmă falsă, deoarece, de fapt, vulnerabilitatea se aplică doar ramurii de produs 3.x.
- Dubla CVE
- De exemplu, dacă SCA a indicat o CVE care permite realizarea RCE, după care SCA indică pentru aceeași componentă o CVE aplicabilă produselor Cisco, expuse acestui RCE. În acest caz, va fi o alarmă falsă.
- De exemplu, CVE a fost găsită în componenta spring-web, iar ulterior SCA indică aceeași CVE în alte componente ale framework-ului Spring Framework, în timp ce CVE nu are legătură cu alte componente. În acest caz va fi un false positive.
Obiectul cercetării a fost proiectul Open Source DVJA. În cercetare au fost incluse doar componente java (fără js).
Rezultate sintetice
Să trecem direct la rezultatul revizuirii manuale a vulnerabilităților identificate. Cu raportul complet pentru fiecare CVE poate fi consultat în Anexă.
Rezultate sintetice pentru toate vulnerabilitățile:
Parametru
Nexus IQ
Dependency Check
Dependency Track
Număr total de vulnerabilități identificate
42
91
51
Număr greșit de vulnerabilități identificate (false positive)
2(4.76%)
62(68,13%)
29(56.86%)
Nu au fost identificate vulnerabilități relevante (false negative)
10
20
27
Rezultate sintetice pe componente:
Parametru
Nexus IQ
Dependency Check
Dependency Track
Număr total de componente identificate
62
47
59
Număr total de componente vulnerabile
16
13
10
Număr greșit de componente vulnerabile identificate (false positive)
1
5
0
Număr greșit de componente vulnerabile identificate (false positive)
0
6
6
Vom construi grafice vizuale pentru a evalua raportul între false positive și false negative față de numărul total de vulnerabilități. Pe orizontală sunt indicate componentele, iar pe verticală vulnerabilitățile identificate în acestea.



Pentru comparație, o cercetare similară a fost realizată de echipa Sonatype pe un proiect format din 1531 de componente folosind OWASP Dependency Check. Așa cum putem observa, raportul între zgomot și alarme corecte este comparabil cu rezultatele noastre.

Sursa:
Să examinăm câteva CVE din rezultatele scanării noastre pentru a înțelege cauza acestor rezultate.
Află mai multe
Nr. 1
Să discutăm mai întâi despre câteva puncte interesante din Sonatype Nexus IQ.
Nexus IQ semnalează o problemă de deserializare cu posibilitate de a executa RCE în Spring Framework de mai multe ori. CVE-2016-1000027 în spring-web:3.0.5 prima dată, și CVE-2011-2894 în spring-context:3.0.5 și spring-core:3.0.5. La prima vedere, pare că există o duplicare a vulnerabilității pe mai multe CVE. Deoarece, dacă ne uităm la CVE-2016-1000027 și CVE-2011-2894 în baza de date NVD, totul pare clar.
Componentă
Vulnerabilitatea
spring-web:3.0.5
CVE-2016-1000027
spring-context:3.0.5
CVE-2011-2894
spring-core:3.0.5
CVE-2011-2894
Descriere din NVD:

Descriere din NVD:

CVE-2011-2894 este destul de bine cunoscută. În raportul această CVE a fost recunoscută ca fiind una dintre cele mai frecvente. Descrierile pentru CVE-2016-100027 sunt în general puține în NVD, iar aplicabilitatea acesteia pare a fi doar pentru Spring Framework 4.1.4. Să ne uităm la și aici devine mai mult sau mai puțin clar. Din înțelegem că pe lângă vulnerabilitatea din RemoteInvocationSerializingExporter în CVE-2011-2894, vulnerabilitatea se observă în HttpInvokerServiceExporter. Despre asta ne informează Nexus IQ:

Cu toate acestea, nu există nimic similar în NVD, motiv pentru care Dependency Check și Dependency Track obțin false negative.
De asemenea, din descrierea CVE-2011-2894 putem înțelege că vulnerabilitatea este cu adevărat prezentă atât în spring-context:3.0.5, cât și în spring-core:3.0.5. O confirmare a acestui lucru poate fi găsită în articolul celui care a descoperit această vulnerabilitate.
Nr. 2
Componentă
Vulnerabilitatea
Rezultatul
struts2-core:2.3.30
CVE-2016-4003
FALSE
Dacă analizăm vulnerabilitatea CVE-2016-4003, vom înțelege că a fost corectată încă din versiunea 2.3.28, totuși Nexus IQ ne informează despre aceasta. În descrierea vulnerabilității există o notă:

Asta înseamnă că vulnerabilitatea există doar în asociere cu o versiune învechită de JRE, despre care am fost avertizați. Totuși, considerăm aceasta un False Positive, deși nu este cel mai grav.
Nr. 3
Componentă
Vulnerabilitatea
Rezultatul
xwork-core:2.3.30
CVE-2017-9804
TRUE
xwork-core:2.3.30
CVE-2017-7672
FALSE
Dacă ne uităm la descrierea CVE-2017-9804 și CVE-2017-7672, vom înțelege că problema este în clasa URLValidator, iar CVE-2017-9804 derivă din CVE-2017-7672. Prezența celei de-a doua vulnerabilități nu aduce niciun beneficiu util, în afară de faptul că severitatea ei a crescut la High, motiv pentru care putem considera aceasta un zgomot inutil.
În general, nu au fost găsite alte false positive pentru Nexus IQ.
Nr. 4
Există câteva aspecte care scot în evidență IQ în comparație cu alte soluții.
Componentă
Vulnerabilitatea
Rezultatul
spring-web:3.0.5
CVE-2020-5398
TRUE
CVE în NVD indică faptul că este aplicabil doar versiunilor 5.2.x până la 5.2.3, 5.1.x până la 5.1.13 și versiunilor 5.0.x până la 5.0.16, totuși, dacă ne uităm la descrierea CVE în Nexus IQ, vom vedea următoarele:
Advisory Deviation Notice: Echipa de cercetare în securitate Sonatype a descoperit că această vulnerabilitate a fost introdusă în versiunea 3.0.2.RELEASE și nu în 5.0.x, așa cum este menționat în notificare.
După aceasta urmează PoC pentru această vulnerabilitate, care indică că ea este prezentă în versiunea 3.0.5.
False negative este trimis către Dependency Check și Dependency Track.
Nr. 5
Să ne uităm la false positive pentru Dependency Check și Dependency Track.
Dependency Check se evidențiază prin faptul că reflectă CVE-urile care se aplică întregii framework din NVD, în acele componente la care aceste CVE nu se aplică. Acest lucru se referă la CVE-2012-0394, CVE-2013-2115, CVE-2014-0114, CVE-2015-0899, CVE-2015-2992, CVE-2016-1181, CVE-2016-1182, care au fost 'atașate' la struts-taglib:1.3.8 și struts-tiles-1.3.8. Aceste componente nu au nicio legătură cu ceea ce este descris în CVE — procesarea cererilor, validarea paginilor etc. Aceasta se datorează faptului că singurul lucru comun între aceste CVE și componente este framework-ul, motiv pentru care Dependency Check a considerat aceasta o vulnerabilitate.
Situația este similară cu spring-tx:3.0.5 și există situații asemănătoare cu struts-core:1.3.8. Pentru struts-core, Dependency Check și Dependency Track au găsit foarte multe vulnerabilități care de fapt se aplică lui struts2-core, care este în esență un cadru separat. În acest caz, Nexus IQ a înțeles corect situația și în CVE-urile pe care le-a emis, a menționat că struts-core a ajuns la sfârșitul vieții și trebuie să se treacă la struts2-core.
№6
În unele situații, a interpreta o eroare evidentă a Dependency Check și Dependency Track este injust. În special CVE-2013-4152, CVE-2013-6429, CVE-2013-6430, CVE-2013-7315, CVE-2014-0054, CVE-2014-0225, care au fost atribuite de Dependency Check și Dependency Track lui spring-core:3.0.5, se referă de fapt la spring-web:3.0.5. De asemenea, o parte dintre aceste CVE au fost găsite și de Nexus IQ, cu toate acestea IQ le-a identificat corect la un alt component. Faptul că aceste vulnerabilități nu au fost găsite în spring-core nu înseamnă că nu există în cadru în general, iar instrumentele open source au indicat corect aceste vulnerabilități (doar că au avut o ușoară necorelare).
Conclusions
Așa cum putem vedea, determinarea validității vulnerabilităților identificate prin revizuirea manuală nu oferă rezultate clare, ceea ce duce la momente disputate. Rezultatele arată că soluția Nexus IQ are cea mai mică rată de fals pozitive și cea mai mare precizie.
În primul rând, acest lucru se datorează faptului că echipa Sonatype a extins descrierea fiecărei vulnerabilități CVE din NVD în bazele lor, specificând cu precizie până la clasă sau funcție vulnerabilitatea pentru fiecare versiune a componentelor, realizând cercetări suplimentare (de exemplu, verificând vulnerabilitățile pe versiuni mai vechi de software).
Un impact semnificativ asupra rezultatelor îl au și acele vulnerabilități care nu au fost incluse în NVD, dar care sunt totuși prezente în baza Sonatype cu marcajul SONATYPE. Conform raportului aproape 45% din vulnerabilitățile descoperite cu sursă deschisă nu sunt raportate în NVD. Conform bazei de date WhiteSource, doar 29% din toate vulnerabilitățile cu sursă deschisă înregistrate în afara NVD sunt în cele din urmă publicate în aceasta, de aceea este atât de important să căutăm vulnerabilități și în alte surse.
Ca rezultat, Dependency Check produce o cantitate mare de zgomot, omorând o parte din componente vulnerabile. Dependency Track produce mai puțin zgomot și identifică un număr mare de componente, ceea ce nu deranjează vizual în interfața web.
Cu toate acestea, practica arată că open source ar trebui să fie prima etapă pe calea către un DevSecOps matur. Primul lucru la care trebuie să vă gândiți pentru a integra SCA în dezvoltare este procesele, adică reflecțiile alături de conducere și departamentele aferente cu privire la cum ar trebui să arate procesele ideale în organizația dumneavoastră. Poate că pentru organizația dumneavoastră, la început, Dependency Check sau Dependency Track vor acoperi toate nevoile de afaceri, în timp ce soluțiile Enterprise vor fi o continuare logică datorită creșterii complexității aplicațiilor dezvoltate.
Anexa A. Rezultate pentru componente
Semne convenționale:
- High — vulnerabilități de nivel înalt și critic în componentă
- Medium — vulnerabilități de nivel mediu de criticitate în componentă
- TRUE — vulnerabilitate identificată corect (True positive issue)
- FALSE — fals pozitiv (False positive issue)
Componentă
Nexus IQ
Dependency Check
Dependency Track
Rezultatul
dom4j: 1.6.1
Ridicat
Ridicat
Ridicat
TRUE
log4j-core: 2.3
Ridicat
Ridicat
Ridicat
TRUE
log4j: 1.2.14
Ridicat
Ridicat
—
TRUE
commons-collections:3.1
Ridicat
Ridicat
Ridicat
TRUE
commons-fileupload:1.3.2
Ridicat
Ridicat
Ridicat
TRUE
commons-beanutils:1.7.0
Ridicat
Ridicat
Ridicat
TRUE
commons-codec:1:10
Medium
—
—
TRUE
mysql-connector-java:5.1.42
Ridicat
Ridicat
Ridicat
TRUE
spring-expression:3.0.5
Ridicat
componenta nu a fost găsită
TRUE
spring-web:3.0.5
Ridicat
componenta nu a fost găsită
Ridicat
TRUE
spring-context:3.0.5
Medium
componenta nu a fost găsită
—
TRUE
spring-core:3.0.5
Medium
Ridicat
Ridicat
TRUE
struts2-config-browser-plugin:2.3.30
Medium
—
—
TRUE
spring-tx:3.0.5
—
Ridicat
—
FALSE
struts-core:1.3.8
Ridicat
Ridicat
Ridicat
TRUE
xwork-core: 2.3.30
Ridicat
—
—
TRUE
struts2-core: 2.3.30
Ridicat
Ridicat
Ridicat
TRUE
struts-taglib:1.3.8
—
Ridicat
—
FALSE
struts-tiles-1.3.8
—
Ridicat
—
FALSE
Anexa B. Rezultate pentru vulnerabilități
Semne convenționale:
- High — vulnerabilități de nivel înalt și critic în componentă
- Medium — vulnerabilități de nivel mediu de criticitate în componentă
- TRUE — vulnerabilitate identificată corect (True positive issue)
- FALSE — fals pozitiv (False positive issue)
Componentă
Nexus IQ
Dependency Check
Dependency Track
Severitate
Rezultatul
Comentariu
dom4j: 1.6.1
CVE-2018-1000632
CVE-2018-1000632
CVE-2018-1000632
Ridicat
TRUE
CVE-2020-10683
CVE-2020-10683
CVE-2020-10683
Ridicat
TRUE
log4j-core: 2.3
CVE-2017-5645
CVE-2017-5645
CVE-2017-5645
Ridicat
TRUE
CVE-2020-9488
CVE-2020-9488
CVE-2020-9488
Low
TRUE
log4j: 1.2.14
CVE-2019-17571
CVE-2019-17571
—
Ridicat
TRUE
—
CVE-2020-9488
—
Low
TRUE
SONATYPE-2010-0053
—
—
Ridicat
TRUE
commons-collections:3.1
—
CVE-2015-6420
CVE-2015-6420
Ridicat
FALSE
Se duplică RCE(OSSINDEX)
—
CVE-2017-15708
CVE-2017-15708
Ridicat
FALSE
Se duplică RCE(OSSINDEX)
SONATYPE-2015-0002
RCE (OSSINDEX)
RCE(OSSINDEX)
Ridicat
TRUE
commons-fileupload:1.3.2
CVE-2016-1000031
CVE-2016-1000031
CVE-2016-1000031
Ridicat
TRUE
SONATYPE-2014-0173
—
—
Medium
TRUE
commons-beanutils:1.7.0
CVE-2014-0114
CVE-2014-0114
CVE-2014-0114
Ridicat
TRUE
—
CVE-2019-10086
CVE-2019-10086
Ridicat
FALSE
Vulnerabilitatea se aplică doar versiunilor 1.9.2+
commons-codec:1:10
SONATYPE-2012-0050
—
—
Medium
TRUE
mysql-connector-java:5.1.42
CVE-2018-3258
CVE-2018-3258
CVE-2018-3258
Ridicat
TRUE
CVE-2019-2692
CVE-2019-2692
—
Medium
TRUE
—
CVE-2020-2875
—
Medium
FALSE
Aceeași vulnerabilitate ca și CVE-2019-2692, dar cu adăugarea „atacurile pot afecta semnificativ produse suplimentare”
—
CVE-2017-15945
—
Ridicat
FALSE
Nu se aplică mysql-connector-java
—
CVE-2020-2933
—
Low
FALSE
Duplicat al CVE-2020-2934
CVE-2020-2934
CVE-2020-2934
—
Medium
TRUE
spring-expression:3.0.5
CVE-2018-1270
componenta nu a fost găsită
—
Ridicat
TRUE
CVE-2018-1257
—
—
Medium
TRUE
spring-web:3.0.5
CVE-2016-1000027
componenta nu a fost găsită
—
Ridicat
TRUE
CVE-2014-0225
—
CVE-2014-0225
Ridicat
TRUE
CVE-2011-2730
—
—
Ridicat
TRUE
—
—
CVE-2013-4152
Medium
TRUE
CVE-2018-1272
—
—
Ridicat
TRUE
CVE-2020-5398
—
—
Ridicat
TRUE
Un exemplu semnificativ în favoarea IQ: „Echipa de cercetare în securitate Sonatype a descoperit că această vulnerabilitate a fost introdusă în versiunea 3.0.2.RELEASE și nu 5.0.x așa cum se afirmă în aviz.”
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
componenta nu a fost găsită
—
Medium
TRUE
spring-core:3.0.5
—
CVE-2011-2730
CVE-2011-2730
Ridicat
TRUE
CVE-2011-2894
CVE-2011-2894
CVE-2011-2894
Medium
TRUE
—
—
CVE-2013-4152
Medium
FALSE
Duplicat al aceleași vulnerabilități în spring-web
—
CVE-2013-4152
—
Medium
FALSE
Vulnerabilitatea se aplică componentului spring-web
—
CVE-2013-6429
CVE-2013-6429
Medium
FALSE
Vulnerabilitatea se aplică componentului spring-web
—
CVE-2013-6430
—
Medium
FALSE
Vulnerabilitatea se aplică componentului spring-web
—
CVE-2013-7315
CVE-2013-7315
Medium
FALSE
SPLIT din CVE-2013-4152. + Vulnerabilitatea se aplică componentului spring-web
—
CVE-2014-0054
CVE-2014-0054
Medium
FALSE
Vulnerabilitatea se aplică componentului spring-web
—
CVE-2014-0225
—
Ridicat
FALSE
Vulnerabilitatea se aplică componentului spring-web
—
—
CVE-2014-0225
Ridicat
FALSE
Duplicat al aceleași vulnerabilități în spring-web
—
CVE-2014-1904
CVE-2014-1904
Medium
FALSE
Vulnerabilitatea se aplică componentului spring-web-mvc
—
CVE-2014-3625
CVE-2014-3625
Medium
FALSE
Vulnerabilitatea se aplică componentului spring-web-mvc
—
CVE-2016-9878
CVE-2016-9878
Ridicat
FALSE
Vulnerabilitatea se aplică componentului spring-web-mvc
—
CVE-2018-1270
CVE-2018-1270
Ridicat
FALSE
Pentru spring-expression / spring-messages
—
CVE-2018-1271
CVE-2018-1271
Medium
FALSE
Vulnerabilitatea se aplică componentului spring-web-mvc
—
CVE-2018-1272
CVE-2018-1272
Ridicat
TRUE
CVE-2014-3578
CVE-2014-3578 (OSSINDEX)
CVE-2014-3578
Medium
TRUE
SONATYPE-2015-0327
—
—
Low
TRUE
struts2-config-browser-plugin:2.3.30
SONATYPE-2016-0104
—
—
Medium
TRUE
spring-tx:3.0.5
—
CVE-2011-2730
—
Ridicat
FALSE
Vulnerabilitatea nu se aplică spring-tx
—
CVE-2011-2894
—
Ridicat
FALSE
Vulnerabilitatea nu se aplică spring-tx
—
CVE-2013-4152
—
Medium
FALSE
Vulnerabilitatea nu se aplică spring-tx
—
CVE-2013-6429
—
Medium
FALSE
Vulnerabilitatea nu se aplică spring-tx
—
CVE-2013-6430
—
Medium
FALSE
Vulnerabilitatea nu se aplică spring-tx
—
CVE-2013-7315
—
Medium
FALSE
Vulnerabilitatea nu se aplică spring-tx
—
CVE-2014-0054
—
Medium
FALSE
Vulnerabilitatea nu se aplică spring-tx
—
CVE-2014-0225
—
Ridicat
FALSE
Vulnerabilitatea nu se aplică spring-tx
—
CVE-2014-1904
—
Medium
FALSE
Vulnerabilitatea nu se aplică spring-tx
—
CVE-2014-3625
—
Medium
FALSE
Vulnerabilitatea nu se aplică spring-tx
—
CVE-2016-9878
—
Ridicat
FALSE
Vulnerabilitatea nu se aplică spring-tx
—
CVE-2018-1270
—
Ridicat
FALSE
Vulnerabilitatea nu se aplică spring-tx
—
CVE-2018-1271
—
Medium
FALSE
Vulnerabilitatea nu se aplică spring-tx
—
CVE-2018-1272
—
Medium
FALSE
Vulnerabilitatea nu se aplică spring-tx
struts-core:1.3.8
—
CVE-2011-5057 (OSSINDEX)
Medium
FASLE
Vulnerabilitate la Struts 2
—
CVE-2012-0391 (OSSINDEX)
CVE-2012-0391
Ridicat
FALSE
Vulnerabilitate la Struts 2
—
CVE-2014-0094 (OSSINDEX)
CVE-2014-0094
Medium
FALSE
Vulnerabilitate la Struts 2
—
CVE-2014-0113 (OSSINDEX)
CVE-2014-0113
Ridicat
FALSE
Vulnerabilitate la Struts 2
CVE-2016-1182
3VE-2016-1182
—
Ridicat
TRUE
—
—
CVE-2011-5057
Medium
FALSE
Vulnerabilitate la Struts 2
—
CVE-2012-0392 (OSSINDEX)
CVE-2012-0392
Ridicat
FALSE
Vulnerabilitate la Struts 2
—
CVE-2012-0393 (OSSINDEX)
CVE-2012-0393
Medium
FALSE
Vulnerabilitate la Struts 2
CVE-2015-0899
CVE-2015-0899
—
Ridicat
TRUE
—
CVE-2012-0394
CVE-2012-0394
Medium
FALSE
Vulnerabilitate la Struts 2
—
CVE-2012-0838 (OSSINDEX)
CVE-2012-0838
Ridicat
FALSE
Vulnerabilitate la Struts 2
—
CVE-2013-1965 (OSSINDEX)
CVE-2013-1965
Ridicat
FALSE
Vulnerabilitate la Struts 2
—
CVE-2013-1966 (OSSINDEX)
CVE-2013-1966
Ridicat
FASLE
Vulnerabilitate la Struts 2
—
CVE-2013-2115
CVE-2013-2115
Ridicat
FASLE
Vulnerabilitate la Struts 2
—
CVE-2013-2134 (OSSINDEX)
CVE-2013-2134
Ridicat
FASLE
Vulnerabilitate la Struts 2
—
CVE-2013-2135 (OSSINDEX)
CVE-2013-2135
Ridicat
FASLE
Vulnerabilitate la Struts 2
CVE-2014-0114
CVE-2014-0114
—
Ridicat
TRUE
—
CVE-2015-2992
CVE-2015-2992
Medium
FALSE
Vulnerabilitate la Struts 2
—
CVE-2016-0785 (OSSINDEX)
CVE-2016-0785
Ridicat
FALSE
Vulnerabilitate la Struts 2
CVE-2016-1181
CVE-2016-1181
—
Ridicat
TRUE
—
CVE-2016-4003 (OSSINDEX)
CVE-2016-4003
Ridicat
FALSE
Vulnerabilitate la Struts 2
xwork-core:2.3.30
CVE-2017-9804
—
—
Ridicat
TRUE
SONATYPE-2017-0173
—
—
Ridicat
TRUE
CVE-2017-7672
—
—
Ridicat
FALSE
Duplicat la CVE-2017-9804
SONATYPE-2016-0127
—
—
Ridicat
TRUE
struts2-core:2.3.30
—
CVE-2016-6795
CVE-2016-6795
Ridicat
TRUE
—
CVE-2017-9787
CVE-2017-9787
Ridicat
TRUE
—
CVE-2017-9791
CVE-2017-9791
Ridicat
TRUE
—
CVE-2017-9793
—
Ridicat
FALSE
Duplicat la CVE-2018-1327
—
CVE-2017-9804
—
Ridicat
TRUE
—
CVE-2017-9805
CVE-2017-9805
Ridicat
TRUE
CVE-2016-4003
—
—
Medium
FALSE
Se aplică la Apache Struts 2.x până la 2.3.28, iar aceasta este versiunea 2.3.30. Cu toate acestea, conform descrierii, CVE este valabil pentru toate versiunile Struts 2, dacă se folosește JRE 1.7 sau mai puțin. Se pare că au vrut să fie siguri, dar mai degrabă pare un FALSE.
—
CVE-2018-1327
CVE-2018-1327
Ridicat
TRUE
CVE-2017-5638
CVE-2017-5638
CVE-2017-5638
Ridicat
TRUE
Aceasta este vulnerabilitatea de care au profitat atacatorii la Equifax în 2017.
CVE-2017-12611
CVE-2017-12611
—
Ridicat
TRUE
CVE-2018-11776
CVE-2018-11776
CVE-2018-11776
Ridicat
TRUE
struts-taglib:1.3.8
—
CVE-2012-0394
—
Medium
FALSE
Pentru struts2-core
—
CVE-2013-2115
—
Ridicat
FALSE
Pentru struts2-core
—
CVE-2014-0114
—
Ridicat
FALSE
Pentru commons-beanutils
—
CVE-2015-0899
—
Ridicat
FALSE
Nu se aplică la taglib
—
CVE-2015-2992
—
Medium
FALSE
Se aplică la struts2-core
—
CVE-2016-1181
—
Ridicat
FALSE
Nu se aplică la taglib
—
CVE-2016-1182
—
Ridicat
FALSE
Nu se aplică la taglib
struts-tiles-1.3.8
—
CVE-2012-0394
—
Medium
FALSE
Pentru struts2-core
—
CVE-2013-2115
—
Ridicat
FALSE
Pentru struts2-core
—
CVE-2014-0114
—
Ridicat
FALSE
Sub commons-beanutils
—
CVE-2015-0899
—
Ridicat
FALSE
Nu se aplică la tiles
—
CVE-2015-2992
—
Medium
FALSE
Pentru struts2-core
—
CVE-2016-1181
—
Ridicat
FALSE
Nu se aplică la taglib
—
CVE-2016-1182
—
Ridicat
FALSE
Nu se aplică la taglib
Sursa: habr.com
