DevSecOps: principi di funzionamento e confronto SCA. Parte prima

L'importanza dell'analisi dei componenti software di terze parti (inglese: Software Composition Analysis - SCA) nel processo di sviluppo cresce man mano che vengono pubblicati annualmente rapporti sulle vulnerabilità delle librerie open source dalle aziende Synopsys, Sonatype, Snyk, White Source. Secondo il rapporto La situazione delle vulnerabilità di sicurezza nel software open source 2020 il numero di vulnerabilità scoperte nel software open source nel 2019 è aumentato di quasi 1,5 volte rispetto all'anno precedente, mentre i componenti open source sono utilizzati nel 60% - 80% dei progetti. Secondo un parere indipendente, i processi SCA rappresentano una pratica separata all'interno degli standard OWASP SAMM e BSIMM come indicatore di maturità, e nella prima metà del 2020, OWASP ha pubblicato un nuovo standard, l'OWASP Software Component Verification Standard (SCVS), che fornisce le migliori pratiche per la verifica dei componenti di terze parti nella catena di approvvigionamento software.

Uno dei casi più emblematici è avvenuto con l'azienda Equifax nel maggio 2017. Sconosciuti hacker hanno ottenuto informazioni su 143 milioni di americani, incluse le loro nomi completi, indirizzi, numeri di previdenza sociale e patenti di guida. In 209.000 casi, nei documenti era anche presente l'informazione sulle carte di credito delle vittime. Questa violazione è avvenuta a seguito dello sfruttamento di una vulnerabilità critica in Apache Struts 2 (CVE-2017-5638), mentre la patch era stata rilasciata già a marzo 2017. L'azienda aveva due mesi per installare l'aggiornamento, ma nessuno si è preoccupato di farlo.

In questo articolo si discuterà della scelta dello strumento per condurre la SCA dal punto di vista della qualità dei risultati dell'analisi. Sarà anche fornito un confronto funzionale degli strumenti. Il processo di integrazione in CI/CD e le possibilità di integrazione saranno trattati in pubblicazioni successive. Una vasta lista di strumenti è stata presentata da OWASP sul proprio sito, ma nel presente studio ci concentreremo solo sullo strumento open source più popolare, Dependency Check, sulla piattaforma open source meno conosciuta Dependency Track e sulla soluzione enterprise Sonatype Nexus IQ. Analizzeremo anche come funzionano queste soluzioni e confronteremo i risultati ottenuti riguardo ai falsi positivi.

Il principio di funzionamento

Dependency Check è uno strumento (CLI, maven, modulo jenkins, ant) che analizza i file del progetto, raccoglie frammenti di informazioni sulle dipendenze (nome pacchetto, groupid, titolo specifica, versione…), costruisce una stringa CPE — (Common Platform Enumeration), Package URL (PURL) e identifica per CPE/PURL vulnerabilità da database (NVD, Sonatype OSS Index, NPM Audit API…), dopodiché genera un rapporto una tantum in formato HTML, JSON, XML…

Vediamo come appare un CPE:

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

• Part: Indicazione che il componente riguarda un'applicazione (a), un sistema operativo (o), hardware (h) (Punto obbligatorio)
• Vendor: Nome del produttore del prodotto (Punto obbligatorio)
• Product: Nome del prodotto (Punto obbligatorio)
• Versione: Versione del componente (Punto obsoleto)
• Aggiornamento: Aggiornamento del pacchetto
• Edition: Versione ereditata (Punto obsoleto)
• Language: Lingua definita in RFC-5646
• SW Edition: Versione del software
• Target SW: Ambiente software in cui opera il prodotto
• Target HW: Ambiente hardware in cui opera il prodotto
• Other: Informazioni sul fornitore o sul prodotto

Un esempio di CPE appare nel seguente modo:

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

La stringa indica che il CPE versione 2.3 descrive un componente di applicazione del produttore pivotal_software con il nome spring_framework versione 3.0.0. Se apriamo la vulnerabilità CVE-2014-0225 in NVD, possiamo vedere un riferimento a questo CPE. Il primo problema su cui vale la pena prestare attenzione è che il CVE in NVD, secondo il CPE, segnala la presenza di un problema nel framework, e non in un componente specifico. Cioè, se gli sviluppatori sono fortemente legati al framework e la vulnerabilità identificata non riguarda i moduli usati dagli sviluppatori, il professionista della sicurezza dovrà comunque analizzare questo CVE e considerare un aggiornamento.

L'URL è inoltre utilizzato dagli strumenti SCA. Il formato dell'URL del pacchetto è il seguente:

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

• Scheme: Sarà sempre 'pkg', indicando che è un URL del pacchetto (Punto obbligatorio)
• Type: «Tipo» del pacchetto o «protocollo» del pacchetto, ad esempio maven, npm, nuget, gem, pypi ecc. (Punto obbligatorio)
• Namespace: Un prefisso del nome, come l'identificatore del gruppo Maven, il proprietario dell'immagine Docker, l'utente o l'organizzazione GitHub. Facoltativo e dipende dal tipo.
• Nome: Nome del pacchetto (Punto obbligatorio)
• Versione: Versione del pacchetto
• Qualifiers: Dati di qualificazione aggiuntivi per il pacchetto, come SO, architettura, distribuzione, ecc. Non obbligatori e dipendenti dal tipo di voce.
• Sotto percorso: Percorso aggiuntivo nel pacchetto relativo alla radice del pacchetto

Ad esempio:

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 — piattaforma web on-premise che accetta Bill of Materials (BOM) già formati CycloneDX e SPDX, ovvero specifiche pronte delle dipendenze esistenti. Questo è un file XML con descrizione delle dipendenze — nome, hash, url del pacchetto, editore, licenza. Successivamente, Dependency Track analizza il BOM, verifica le dipendenze identificate contro le vulnerabilità CVE nel database delle vulnerabilità (NVD, Sonatype OSS Index …), quindi costruisce grafici e calcola metriche, aggiornando regolarmente i dati sullo stato delle vulnerabilità dei componenti.

Esempio di come potrebbe apparire un BOM in formato 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
    
      

Il BOM può essere utilizzato non solo come parametri di ingresso per Dependency Track, ma anche per l'inventario dei componenti software nella catena di fornitura, ad esempio, per fornire al cliente software. Nel 2014, negli Stati Uniti è stata persino proposta una legge «Cyber Supply Chain Management and Transparency Act of 2014», che stabiliva che, all'acquisto di software, qualsiasi ente pubblico dovesse richiedere un BOM per prevenire l'uso di componenti vulnerabili; tuttavia, la legge non è mai entrata in vigore.

Tornando a SCA, Dependency Track ha integrazioni pronte con le piattaforme di notifica come Slack e con sistemi di gestione delle vulnerabilità come Kenna Security. Va anche detto che Dependency Track identifica versioni obsolete dei pacchetti e fornisce informazioni sulle licenze (grazie al supporto di SPDX).

Se si parla specificamente della qualità SCA, qui c'è una differenza fondamentale.

Dependency Track non accetta il progetto come input, ma accetta precisamente il BOM. Questo significa che se vogliamo verificare il progetto, prima dobbiamo generare bom.xml, ad esempio, utilizzando CycloneDX. In questo modo, Dependency Track dipende direttamente da CycloneDX. Allo stesso tempo, ciò consente la personalizzazione. Così, il team di OZON ha scritto il modulo CycloneDX per la creazione di file BOM per progetti in Golang al fine di effettuare una successiva scansione tramite Dependency Track.

Nexus IQ è una soluzione SCA commerciale offerta da Sonatype, che fa parte dell'ecosistema Sonatype, al quale appartiene anche Nexus Repository Manager. Nexus IQ può accettare come input sia archivi war (per i progetti java) tramite l'interfaccia web o API, sia BOM, se la vostra organizzazione non è riuscita a passare da CycloneDX a una nuova soluzione. A differenza delle soluzioni open source, IQ non si basa solo su CP/PURL della componente identificata e sulla relativa vulnerabilità nel database, ma considera anche le proprie ricerche, ad esempio, il nome della funzione o della classe vulnerabile. I meccanismi di IQ saranno esaminati più avanti nell'analisi dei risultati.

Riassumiamo alcune conclusioni sulle caratteristiche funzionali e vediamo anche i linguaggi supportati per l'analisi:

Lingua
Nexus IQ
Dependency Check
Dependency Track

Java
+
+
+

C/C++
+
+
—

C#
+
+
—

.Net
+
+
+

Erlang
—
—
+

JavaScript (NodeJS)
+
+
+

PHP
+
+
+

Python
+
+
+

Ruby
+
+
+

Perl
—
—
—

Scala
+
+
+

Objective C
+
+
—

Swift
+
+
—

R
+
—
—

Go
+
+
+

Funzionalità

Funzionalità
Nexus IQ
Dependency Check
Dependency Track

Possibilità di verificare la conformità licenziale dei componenti utilizzati nel codice sorgente
+
—
+

Possibilità di scansione e analisi alla ricerca di vulnerabilità e conformità licenziale per le immagini Docker
+ Integrazione con Clair
—
—

Possibilità di impostare politiche di sicurezza per l'uso di biblioteche open source
+
—
—

Possibilità di eseguire scansioni di repository open source alla ricerca di componenti vulnerabili
+ RubyGems, Maven, NPM, Nuget, Pypi, Conan, Bower, Conda, Go, p2, R, Yum, Helm, Docker, CocoaPods, Git LFS
—
+ Hex, RubyGems, Maven, NPM, Nuget, Pypi

Presenza di un gruppo di ricerca specializzato
+
—
—

Operare in un contesto chiuso
+
+
+

Utilizzo di database esterni
+ Database chiuso Sonatype
+ Sonatype OSS, NPM Public Advisors
+ Sonatype OSS, NPM Public Advisors, RetireJS, VulnDB, supporto per un proprio database di vulnerabilità

Possibilità di filtrare i componenti open source al momento del caricamento nel contesto di sviluppo secondo le politiche configurate
+
—
—

Raccomandazioni per la correzione delle vulnerabilità, inclusi collegamenti ai rimedi
+
+- (dipende dalla descrizione nelle basi di dati pubbliche)
+- (dipende dalla descrizione nelle basi di dati pubbliche)

Classificazione delle vulnerabilità identificate in base al grado di criticità
+
+
+

Modello di accesso per ruoli
+
—
+

Supporto per interfaccia a riga di comando CLI
+
+
+- (solo per CycloneDX)

Campionamento / ordinamento delle vulnerabilità in base a criteri definiti
+
—
+

Dashboard sullo stato delle applicazioni
+
—
+

Generazione di report in formato PDF
+
—
—

Generazione di report in formato JSONCSV
+
+
—

Supporto per la lingua russa
—
—
—

Capacità di integrazione

Integrazione
Nexus IQ
Dependency Check
Dependency Track

Integrazione con LDAP/Active Directory
+
—
+

Integrazione con sistema di integrazione continua (continuous integration) Bamboo
+
—
—

Integrazione con sistema di integrazione continua (continuous integration) TeamCity
+
—
—

Integrazione con sistema di integrazione continua (continuous integration) GitLab
+
+- (in forma di plugin per GitLab)
+

Integrazione con sistema di integrazione continua (continuous integration) Jenkins
+
+
+

Disponibilità di plugin per IDE
+ IntelliJ, Eclipse, Visual Studio
—
—

Supporto per integrazioni personalizzate tramite web-services (API) dello strumento
+
—
+

Dependency Check

Primo avvio

Avviamo Dependency Check su un'applicazione vulnerabile intenzionalmente DVJA.

Per fare questo utilizzeremo Dependency Check Maven Plugin:

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

Di conseguenza, nella directory target apparirà dependency-check-report.html.

Apriamo il file. Dopo le informazioni generali sul numero totale di vulnerabilità possiamo vedere le informazioni sulle vulnerabilità ad alto livello di severità e confidenza con riferimento al pacchetto, CPE, numero CVE.

Segue una informazione più dettagliata, in particolare ciò su cui si basa la decisione (evidence), cioè un certo BOM.

Successivamente troviamo CPE, PURL e descrizione CVE. Le raccomandazioni per le correzioni non sono incluse in quanto non presenti nel database NVD.

Per una visione sistematica dei risultati della scansione, è possibile configurare Nginx con impostazioni minime, oppure inviare i difetti ottenuti a un sistema di gestione dei difetti che supporta connettori per Dependency Check. Ad esempio, Defect Dojo.

Dependency Track

Installazione

Dependency Track, a sua volta, è una piattaforma web con grafici visivi, quindi il problema di archiviare i difetti in una soluzione di terzi non si pone qui.
Per l'installazione sono disponibili i seguenti scenari supportati: Docker, WAR, Executable WAR.

Primo avvio

Accediamo all'URL del servizio avviato. Accediamo tramite admin/admin, cambiamo il nome utente e la password, dopo di che arriviamo alla Dashboard. La prossima cosa che faremo è creare un progetto per un'applicazione di prova su Java in Home/Projects → Crea Progetto . Come esempio, prendiamo DVJA.

Poiché Dependency Track può accettare solo BOM come input, è necessario ottenere questo BOM. Utilizziamo CycloneDX Maven Plugin:

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

Ottenendo bom.xml e caricando il file nel progetto creato DVJA → Dipendenze → Carica BOM.

Andiamo in Amministrazione → Analizzatori. Comprendiamo che abbiamo abilitato solo l'Analizzatore Interno, che include il NVD. Colleghiamo anche Sonatype OSS Index.

Così facendo, otteniamo la seguente situazione per il nostro progetto:

È possibile trovare un'altra vulnerabilità applicabile a Sonatype OSS:

La principale delusione è stata che Dependency Track non accetta più i rapporti XML di Dependency Check. Le ultime versioni supportate per l'integrazione con Dependency Check erano 1.0.0 — 4.0.2, mentre testavo la versione 5.3.2.

Ecco video (e ecco), quando ciò era ancora possibile.

Nexus IQ

Primo avvio

L'installazione di Nexus IQ avviene da archivi tramite documentazione, ma per questi scopi abbiamo assemblato un'immagine Docker.

Dopo aver effettuato l'accesso alla console, è necessario creare un'Organizzazione e un'Applicazione.

Come si può vedere, la configurazione per IQ è un po' più complessa, poiché è necessario anche creare politiche applicabili ai diversi “stadi” (dev, build, stage, release). Questo è necessario per bloccare i componenti vulnerabili man mano che avanzano nel pipeline verso la produzione, o bloccarli non appena entrano nel Nexus Repo durante il download da parte degli sviluppatori.

Per percepire la differenza tra open source e enterprise, eseguiremo una scansione simile tramite Nexus IQ analogamente a Maven plugin, creando in precedenza un'applicazione di test nell'interfaccia di 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=

Accediamo all'URL del rapporto generato nell'interfaccia web di IQ:

Qui è possibile vedere tutte le violazioni della politica con indicazione di diversi livelli di gravità (da Info a Security Critical). La lettera D accanto a un componente significa che il componente è una Dipendenza Diretta, mentre la lettera T accanto a un componente significa che il componente è una Dipendenza Transitiva.

A proposito, il rapporto State of Open Source Security Report 2020 di Snyk riporta che oltre il 70% delle vulnerabilità open source scoperte in Node.js, Java e Ruby si trovano nelle dipendenze transitive.

Se apriamo una delle violazioni della politica Nexus IQ, possiamo vedere la descrizione del componente, così come il Version Graph, che mostra la posizione dell'attuale versione sulla linea temporale, oltre a quando la vulnerabilità smette di essere tale. L'altezza delle barre sul grafico indica la popolarità d'uso di questo componente.

Se andiamo alla sezione delle vulnerabilità e espandiamo il CVE, possiamo leggere la descrizione di questa vulnerabilità, le raccomandazioni per la risoluzione e il motivo per cui questo componente è stato segnalato come una violazione, cioè la presenza della classe DiskFileitem.class.

Riassumiamo solo le questioni relative ai componenti Java di terze parti, escludendo i componenti js. Tra parentesi indichiamo il numero di vulnerabilità trovate al di fuori della NVD.

Totale Nexus IQ:

• Dipendenze scansionate: 62
• Dipendenze vulnerabili: 16
• Vulnerabilità trovate: 42 (8 sonatype db)

Totale Dependency Check:

• Dipendenze scansionate: 47
• Dipendenze vulnerabili: 13
• Vulnerabilità trovate: 91 (14 sonatype oss)

Totale Dependency Track:

• Dipendenze scansionate: 59
• Dipendenze vulnerabili: 10
• Vulnerabilità trovate: 51 (1 sonatype oss)

Nel passo successivo analizzeremo i risultati ottenuti e capiremo quali di queste vulnerabilità rappresentino un difetto reale e quali siano falsi positivi.

Disclaimer

Questa revisione non è un'affermazione incontestabile. L'autore non aveva il compito di isolare uno specifico strumento rispetto ad altri. Lo scopo della revisione era dimostrare i meccanismi operativi degli strumenti SCA e i metodi per verificare i loro risultati.

Confronto dei risultati

Condizioni:

Un falso positivo rispetto alle vulnerabilità dei componenti di terze parti è:

• Discrepanza tra il CVE e il componente rilevato
• Ad esempio, se una vulnerabilità è stata identificata nel framework struts2, e lo strumento indica un componente del framework struts-tiles, al quale questa vulnerabilità non si applica, questo è un falso positivo.
• Discrepanza tra il CVE e la versione del componente rilevata
• Ad esempio, se la vulnerabilità è legata alla versione python > 3.5 e lo strumento segnala come vulnerabile la versione 2.7, questo è un falso positivo, in quanto in realtà la vulnerabilità si riferisce solo alla branch di prodotto 3.x.
• Duplicazione del CVE
• Ad esempio, se lo SCA ha segnalato un CVE che consente di realizzare RCE, e successivamente lo SCA indica per lo stesso componente un CVE applicabile a prodotti Cisco soggetti a tale RCE. In tal caso, si tratterà di un falso positivo.
• Ad esempio, la CVE è stata trovata nel componente spring-web, dopo di che l'SCA indica la stessa CVE in altri componenti del framework Spring Framework, mentre la CVE non ha nulla a che fare con altri componenti. In tal caso si tratta di un falso positivo.

Il soggetto di studio scelto è il progetto Open Source DVJA. Nello studio sono stati coinvolti solo componenti Java (senza JS).

Risultati riassuntivi

Passiamo subito ai risultati della revisione manuale delle vulnerabilità identificate. Il rapporto completo per ogni CVE è disponibile nell'Appendice.

Risultati riassuntivi su tutte le vulnerabilità:

Parametro
Nexus IQ
Dependency Check
Dependency Track

Totale vulnerabilità identificate
42
91
51

Vulnerabilità rilevate erroneamente (falso positivo)
2(4.76%)
62(68,13%)
29(56.86%)

Nessuna vulnerabilità rilevante trovata (falso negativo)
10
20
27

Risultati riassuntivi per componenti:

Parametro
Nexus IQ
Dependency Check
Dependency Track

Totale componenti identificati
62
47
59

Totale componenti vulnerabili
16
13
10

Componenti vulnerabili identificati erroneamente (falso positivo)
1
5
0

Componenti vulnerabili identificati erroneamente (falso positivo)
0
6
6

Costruiamo grafici visivi per valutare il rapporto tra falsi positivi e falsi negativi rispetto al numero totale di vulnerabilità. Sull'asse orizzontale sono segnati i componenti, mentre sull'asse verticale le vulnerabilità rilevate in essi.

Per confronto, uno studio analogo è stato condotto dal team di Sonatype testando un progetto di 1531 componenti utilizzando OWASP Dependency Check. Come possiamo vedere, il rapporto tra rumore e corretti esiti è paragonabile ai nostri risultati.

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

Consideriamo alcune CVE dai risultati della nostra scansione per comprendere il motivo di tali risultati.

Ulteriori informazioni

№1

Iniziamo ad analizzare alcuni punti interessanti di Sonatype Nexus IQ.

Nexus IQ indica un problema di deserializzazione con la possibilità di eseguire un RCE nel Spring Framework diverse volte. CVE-2016-1000027 in spring-web:3.0.5 per la prima volta, e CVE-2011-2894 in spring-context:3.0.5 e spring-core:3.0.5. A prima vista sembra che ci sia una duplicazione della vulnerabilità attraverso più CVE. Infatti, se guardiamo la CVE-2016-1000027 e la CVE-2011-2894 nel database NVD, sembra tutto chiaro.

Componente
Vulnerabilità

spring-web:3.0.5
CVE-2016-1000027

spring-context:3.0.5
CVE-2011-2894

spring-core:3.0.5
CVE-2011-2894

Descrizione CVE-2011-2894 da NVD:


Descrizione CVE-2016-1000027 da NVD:


La CVE-2011-2894 è di per sé piuttosto nota. Nel rapporto White Source del 2011 questa CVE è stata riconosciuta come una delle più comuni. Le descrizioni della CVE-2016-100027 sono piuttosto scarse in NVD, e sembra applicabile solo per Spring Framework 4.1.4. Diamo un'occhiata a reference e qui diventa tutto più chiaro. Dall' articolo di Tenable comprendiamo che oltre alla vulnerabilità in RemoteInvocationSerializingExporter nella CVE-2011-2894, la vulnerabilità è osservata in HttpInvokerServiceExporter. Questo è ciò che ci dice Nexus IQ:

Tuttavia, nulla di simile è presente in NVD, il che provoca false negative per Dependency Check e Dependency Track.

Dalla descrizione di CVE-2011-2894 si può comprendere che la vulnerabilità è effettivamente presente sia in spring-context:3.0.5 che in spring-core:3.0.5. Una conferma di questo si può trovare in un articolo di chi ha scoperto questa vulnerabilità.

№2

Componente
Vulnerabilità
Risultato

struts2-core:2.3.30
CVE-2016-4003
FALSE

Se analizziamo la vulnerabilità CVE-2016-4003, possiamo capire che è stata risolta già nella versione 2.3.28, tuttavia Nexus IQ ci informa ancora a riguardo. Nella descrizione della vulnerabilità c'è una nota:

Cioè, la vulnerabilità esiste solo in combinazione con una versione obsoleta di JRE, di cui ci preavvisano. Tuttavia, consideriamo questo un False Positive, anche se non è tra i più gravi.

№ 3

Componente
Vulnerabilità
Risultato

xwork-core:2.3.30
CVE-2017-9804
TRUE

xwork-core:2.3.30
CVE-2017-7672
FALSE

Se guardiamo la descrizione di CVE-2017-9804 e CVE-2017-7672, possiamo capire che il problema riguarda la classe URLValidator, e CVE-2017-9804 deriva da CVE-2017-7672. La presenza della seconda vulnerabilità non porta alcun valore aggiunto se non l’aumento della sua severità a High, quindi si può considerare un rumore superfluo.

In generale, non sono stati riscontrati altri false positive per Nexus IQ.

№4

Ci sono diversi aspetti che distinguono IQ rispetto ad altre soluzioni.

Componente
Vulnerabilità
Risultato

spring-web:3.0.5
CVE-2020-5398
TRUE

NVD riporta che questo CVE è applicabile solo alle versioni 5.2.x fino a 5.2.3, 5.1.x fino a 5.1.13 e alle versioni 5.0.x fino a 5.0.16, tuttavia, se esaminiamo la descrizione del CVE in Nexus IQ, vediamo quanto segue:
Avviso di Deviamento: Il team di ricerca sulla sicurezza di Sonatype ha scoperto che questa vulnerabilità è stata introdotta nella versione 3.0.2.RELEASE e non 5.0.x come indicato nell'avviso.

Dopo segue un PoC per questa vulnerabilità, che informa che è presente nella versione 3.0.5.

Il false negative viene inviato a Dependency Check e Dependency Track.

№5

Esaminiamo i false positive per Dependency Check e Dependency Track.

Dependency Check si distingue per il fatto che riflette i CVE che riguardano l'intero framework in NVD, in componenti a cui questi CVE non si applicano. Questo riguarda CVE-2012-0394, CVE-2013-2115, CVE-2014-0114, CVE-2015-0899, CVE-2015-2992, CVE-2016-1181, CVE-2016-1182, che Dependency Check ha “agganciato” a struts-taglib:1.3.8 e struts-tiles-1.3.8. Questi componenti non hanno nulla a che fare con ciò che è descritto nel CVE — elaborazione delle richieste, validazione delle pagine e così via. Questo è dovuto al fatto che l'unico elemento in comune tra questi CVE e i componenti è solo il framework, il che ha portato Dependency Check a considerarlo una vulnerabilità.

La stessa situazione si verifica con spring-tx:3.0.5, e una situazione simile con struts-core:1.3.8. Per struts-core, Dependency Check e Dependency Track hanno trovato molte vulnerabilità che in realtà si riferiscono a struts2-core, che è sostanzialmente un framework separato. In questo caso, Nexus IQ ha interpretato correttamente la situazione e nei CVE che ha fornito ha indicato che struts-core è giunto a fine vita e che è necessario passare a struts2-core.

№6

In alcune situazioni, è iniquo interpretare in modo esplicito gli errori di Dependency Check e Dependency Track. In particolare, CVE-2013-4152, CVE-2013-6429, CVE-2013-6430, CVE-2013-7315, CVE-2014-0054, CVE-2014-0225, CVE-2014-0225, che Dependency Check e Dependency Track hanno attribuito a spring-core:3.0.5, si riferiscono in realtà a spring-web:3.0.5. Tuttavia, alcune di queste CVE sono state trovate anche da Nexus IQ; tuttavia, IQ le ha correttamente identificate come relative a un'altra componente. Non si può affermare che poiché queste vulnerabilità non sono state trovate in spring-core, non esistano nel framework in generale e gli strumenti open source hanno giustamente segnalato queste vulnerabilità (hanno semplicemente mancato il bersaglio).

Conclusioni

Come possiamo vedere, la determinazione dell'affidabilità delle vulnerabilità identificate tramite revisione manuale non produce risultati chiari, il che porta a questioni controverse. I risultati indicano che la soluzione di Nexus IQ ha il tasso più basso di falsi positivi e la massima precisione.

In primo luogo, ciò è dovuto al fatto che il team di Sonatype ha ampliato la descrizione di ciascuna vulnerabilità CVE proveniente da NVD nelle proprie banche dati, specificando con precisione fino alla classe o alla funzione della vulnerabilità per ciascuna versione della componente, conducendo ulteriori ricerche (ad esempio, verificando le vulnerabilità su versioni più vecchie del software).

Un'importante influenza sui risultati proviene anche da quelle vulnerabilità che non sono entrate in NVD, ma che sono comunque presenti nel database di Sonatype con la nota SONATYPE. Secondo il rapporto La situazione delle vulnerabilità di sicurezza nel software open source 2020 il 45% delle vulnerabilità scoperte con codice sorgente aperto non è segnalato in NVD. Secondo il database di WhiteSource, solo il 29% di tutte le vulnerabilità con codice sorgente aperto, registrate al di fuori di NVD, vengono infine pubblicate lì, quindi è fondamentale cercare vulnerabilità anche in altre fonti.

Di conseguenza, Dependency Check genera un alto numero di falsi positivi, trascurando alcune componenti vulnerabili. Dependency Track produce meno rumore e identifica un numero maggiore di componenti, il che non risulta visivamente fastidioso nell'interfaccia web.

Tuttavia, la pratica dimostra che l'open source dovrebbe essere il primo passo verso un DevSecOps maturo. La prima cosa su cui riflettere per integrare l'SCA nello sviluppo è rappresentata dai processi, in particolare le riflessioni con la direzione e i dipartimenti affini su come dovrebbero apparire i processi ideali nella propria organizzazione. Potrebbe infatti rivelarsi che, inizialmente, per la vostra organizzazione, Dependency Check o Dependency Track soddisfano tutte le esigenze aziendali, mentre le soluzioni Enterprise rappresenteranno una continuazione logica a causa della crescente complessità delle applicazioni sviluppate.

Appendice A. Risultati relativi ai componenti
Abbreviazioni:

• Alto — vulnerabilità di alto e critico livello nel componente
• Medio — vulnerabilità di livello critico medio nel componente
• VERO — Vulnerabilità identificata correttamente (True positive issue)
• FALSO — Falso allerta (False positive issue)

Componente
Nexus IQ
Dependency Check
Dependency Track
Risultato

dom4j: 1.6.1
High
High
High
TRUE

log4j-core: 2.3
High
High
High
TRUE

log4j: 1.2.14
High
High
—
TRUE

commons-collections:3.1
High
High
High
TRUE

commons-fileupload:1.3.2
High
High
High
TRUE

commons-beanutils:1.7.0
High
High
High
TRUE

commons-codec:1:10
Medium
—
—
TRUE

mysql-connector-java:5.1.42
High
High
High
TRUE

spring-expression:3.0.5
High
componente non trovato

TRUE

spring-web:3.0.5
High
componente non trovato
High
TRUE

spring-context:3.0.5
Medium
componente non trovato
—
TRUE

spring-core:3.0.5
Medium
High
High
TRUE

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

spring-tx:3.0.5
—
High
—
FALSE

struts-core:1.3.8
High
High
High
TRUE

xwork-core: 2.3.30
High
—
—
TRUE

struts2-core: 2.3.30
High
High
High
TRUE

struts-taglib:1.3.8
—
High
—
FALSE

struts-tiles-1.3.8
—
High
—
FALSE

Appendice B. Risultati relativi alle vulnerabilità
Abbreviazioni:

• Alto — vulnerabilità di alto e critico livello nel componente
• Medio — vulnerabilità di livello critico medio nel componente
• VERO — Vulnerabilità identificata correttamente (True positive issue)
• FALSO — Falso allerta (False positive issue)

Componente
Nexus IQ
Dependency Check
Dependency Track
Severità
Risultato
Commento

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

CVE-2020-10683
CVE-2020-10683
CVE-2020-10683
High
TRUE

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

CVE-2020-9488
CVE-2020-9488
CVE-2020-9488
Basso
TRUE

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

—
CVE-2020-9488
—
Basso
TRUE

SONATYPE-2010-0053
—
—
High
TRUE

commons-collections:3.1
—
CVE-2015-6420
CVE-2015-6420
High
FALSE
Duplica RCE(OSSINDEX)

—
CVE-2017-15708
CVE-2017-15708
High
FALSE
Duplica RCE(OSSINDEX)

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

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

SONATYPE-2014-0173
—
—
Medium
TRUE

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

—
CVE-2019-10086
CVE-2019-10086
High
FALSE
La vulnerabilità è applicabile solo per le versioni 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
High
TRUE

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

—
CVE-2020-2875
—
Medium
FALSE
È la stessa vulnerabilità di CVE-2019-2692, ma con la nota “gli attacchi possono influenzare significativamente prodotti aggiuntivi”

—
CVE-2017-15945
—
High
FALSE
Non applicabile a mysql-connector-java

—
CVE-2020-2933
—
Basso
FALSE
Duplicato di CVE-2020-2934

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

spring-expression:3.0.5
CVE-2018-1270
componente non trovato
—
High
TRUE

CVE-2018-1257
—
—
Medium
TRUE

spring-web:3.0.5
CVE-2016-1000027
componente non trovato
—
High
TRUE

CVE-2014-0225
—
CVE-2014-0225
High
TRUE

CVE-2011-2730
—
—
High
TRUE

—
—
CVE-2013-4152
Medium
TRUE

CVE-2018-1272
—
—
High
TRUE

CVE-2020-5398
—
—
High
TRUE
Un esempio significativo per IQ: "Il team di ricerca sulla sicurezza di Sonatype ha scoperto che questa vulnerabilità è stata introdotta nella versione 3.0.2.RELEASE e non nella 5.0.x come affermato nell'avviso."

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
componente non trovato
—
Medium
TRUE

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

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

—
—
CVE-2013-4152
Medium
FALSE
Duplicato della stessa vulnerabilità in spring-web

—
CVE-2013-4152
—
Medium
FALSE
La vulnerabilità si applica al componente spring-web

—
CVE-2013-6429
CVE-2013-6429
Medium
FALSE
La vulnerabilità si applica al componente spring-web

—
CVE-2013-6430
—
Medium
FALSE
La vulnerabilità si applica al componente spring-web

—
CVE-2013-7315
CVE-2013-7315
Medium
FALSE
SPLIT da CVE-2013-4152. + La vulnerabilità si applica al componente spring-web

—
CVE-2014-0054
CVE-2014-0054
Medium
FALSE
La vulnerabilità si applica al componente spring-web

—
CVE-2014-0225
—
High
FALSE
La vulnerabilità si applica al componente spring-web

—
—
CVE-2014-0225
High
FALSE
Duplicato della stessa vulnerabilità in spring-web

—
CVE-2014-1904
CVE-2014-1904
Medium
FALSE
La vulnerabilità si applica al componente spring-web-mvc

—
CVE-2014-3625
CVE-2014-3625
Medium
FALSE
La vulnerabilità si applica al componente spring-web-mvc

—
CVE-2016-9878
CVE-2016-9878
High
FALSE
La vulnerabilità si applica al componente spring-web-mvc

—
CVE-2018-1270
CVE-2018-1270
High
FALSE
Per spring-expression / spring-messages

—
CVE-2018-1271
CVE-2018-1271
Medium
FALSE
La vulnerabilità si applica al componente spring-web-mvc

—
CVE-2018-1272
CVE-2018-1272
High
TRUE

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

SONATYPE-2015-0327
—
—
Basso
TRUE

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

spring-tx:3.0.5
—
CVE-2011-2730
—
High
FALSE
La vulnerabilità non si applica a spring-tx

—
CVE-2011-2894
—
High
FALSE
La vulnerabilità non si applica a spring-tx

—
CVE-2013-4152
—
Medium
FALSE
La vulnerabilità non si applica a spring-tx

—
CVE-2013-6429
—
Medium
FALSE
La vulnerabilità non si applica a spring-tx

—
CVE-2013-6430
—
Medium
FALSE
La vulnerabilità non si applica a spring-tx

—
CVE-2013-7315
—
Medium
FALSE
La vulnerabilità non si applica a spring-tx

—
CVE-2014-0054
—
Medium
FALSE
La vulnerabilità non si applica a spring-tx

—
CVE-2014-0225
—
High
FALSE
La vulnerabilità non si applica a spring-tx

—
CVE-2014-1904
—
Medium
FALSE
La vulnerabilità non si applica a spring-tx

—
CVE-2014-3625
—
Medium
FALSE
La vulnerabilità non si applica a spring-tx

—
CVE-2016-9878
—
High
FALSE
La vulnerabilità non si applica a spring-tx

—
CVE-2018-1270
—
High
FALSE
La vulnerabilità non si applica a spring-tx

—
CVE-2018-1271
—
Medium
FALSE
La vulnerabilità non si applica a spring-tx

—
CVE-2018-1272
—
Medium
FALSE
La vulnerabilità non si applica a spring-tx

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

Medium
FALSO
Vulnerabilità a Struts 2

—
CVE-2012-0391 (OSSINDEX)
CVE-2012-0391
High
FALSE
Vulnerabilità a Struts 2

—
CVE-2014-0094 (OSSINDEX)
CVE-2014-0094
Medium
FALSE
Vulnerabilità a Struts 2

—
CVE-2014-0113 (OSSINDEX)
CVE-2014-0113
High
FALSE
Vulnerabilità a Struts 2

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

—
—
CVE-2011-5057
Medium
FALSE
Vulnerabilità a Struts 2

—
CVE-2012-0392 (OSSINDEX)
CVE-2012-0392
High
FALSE
Vulnerabilità a Struts 2

—
CVE-2012-0393 (OSSINDEX)
CVE-2012-0393
Medium
FALSE
Vulnerabilità a Struts 2

CVE-2015-0899
CVE-2015-0899
—
High
TRUE

—
CVE-2012-0394
CVE-2012-0394
Medium
FALSE
Vulnerabilità a Struts 2

—
CVE-2012-0838 (OSSINDEX)
CVE-2012-0838
High
FALSE
Vulnerabilità a Struts 2

—
CVE-2013-1965 (OSSINDEX)
CVE-2013-1965
High
FALSE
Vulnerabilità a Struts 2

—
CVE-2013-1966 (OSSINDEX)
CVE-2013-1966
High
FALSO
Vulnerabilità a Struts 2

—
CVE-2013-2115
CVE-2013-2115
High
FALSO
Vulnerabilità a Struts 2

—
CVE-2013-2134 (OSSINDEX)
CVE-2013-2134
High
FALSO
Vulnerabilità a Struts 2

—
CVE-2013-2135 (OSSINDEX)
CVE-2013-2135
High
FALSO
Vulnerabilità a Struts 2

CVE-2014-0114
CVE-2014-0114
—
High
TRUE

—
CVE-2015-2992
CVE-2015-2992
Medium
FALSE
Vulnerabilità a Struts 2

—
CVE-2016-0785 (OSSINDEX)
CVE-2016-0785
High
FALSE
Vulnerabilità a Struts 2

CVE-2016-1181
CVE-2016-1181
—
High
TRUE

—
CVE-2016-4003 (OSSINDEX)
CVE-2016-4003
High
FALSE
Vulnerabilità a Struts 2

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

SONATYPE-2017-0173
—
—
High
TRUE

CVE-2017-7672
—
—
High
FALSE
Duplicato di CVE-2017-9804

SONATYPE-2016-0127
—
—
High
TRUE

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

—
CVE-2017-9787
CVE-2017-9787
High
TRUE

—
CVE-2017-9791
CVE-2017-9791
High
TRUE

—
CVE-2017-9793
—
High
FALSE
Duplicato di CVE-2018-1327

—
CVE-2017-9804
—
High
TRUE

—
CVE-2017-9805
CVE-2017-9805
High
TRUE

CVE-2016-4003
—
—
Medium
FALSE
Applicabile ad Apache Struts 2.x fino alla versione 2.3.28, mentre attualmente è disponibile la versione 2.3.30. Tuttavia, a giudicare dalla descrizione, il CVE si applica a tutte le versioni di Struts 2, se si utilizza JRE 1.7 o inferiore. Sembra che qui stiamo cercando di fare il doppio controllo, ma somiglia molto a un FALSE

—
CVE-2018-1327
CVE-2018-1327
High
TRUE

CVE-2017-5638
CVE-2017-5638
CVE-2017-5638
High
TRUE
Quella vulnerabilità che è stata sfruttata dagli hacker in Equifax nel 2017

CVE-2017-12611
CVE-2017-12611
—
High
TRUE

CVE-2018-11776
CVE-2018-11776
CVE-2018-11776
High
TRUE

struts-taglib:1.3.8
—
CVE-2012-0394
—
Medium
FALSE
Per struts2-core

—
CVE-2013-2115
—
High
FALSE
Per struts2-core

—
CVE-2014-0114
—
High
FALSE
Per commons-beanutils

—
CVE-2015-0899
—
High
FALSE
Non pertinente a taglib

—
CVE-2015-2992
—
Medium
FALSE
Pertinente a struts2-core

—
CVE-2016-1181
—
High
FALSE
Non pertinente a taglib

—
CVE-2016-1182
—
High
FALSE
Non pertinente a taglib

struts-tiles-1.3.8
—
CVE-2012-0394
—
Medium
FALSE
Per struts2-core

—
CVE-2013-2115
—
High
FALSE
Per struts2-core

—
CVE-2014-0114
—
High
FALSE
Sotto commons-beanutils

—
CVE-2015-0899
—
High
FALSE
Non pertinente a tiles

—
CVE-2015-2992
—
Medium
FALSE
Per struts2-core

—
CVE-2016-1181
—
High
FALSE
Non pertinente a taglib

—
CVE-2016-1182
—
High
FALSE
Non pertinente a taglib

Fonte: habr.com