🥇DevSecOps: principi di funzionamento e confronto SCA. Parte prima

L'importanza dell'analisi dei componenti software di terze parti (Software Composition Analysis — SCA) aumenta durante il processo di sviluppo, mano a mano che vengono pubblicati report annuali sulle vulnerabilità delle librerie open source dalle aziende Synopsys, Sonatype, Snyk e White Source. Secondo il rapporto Lo stato delle vulnerabilità nella sicurezza open source 2020 il numero di vulnerabilità identificate nell'open source è aumentato quasi di 1.5 volte nel 2019 rispetto all'anno precedente, mentre i componenti open source sono utilizzati in dal 60% all'80% dei progetti. Se consideriamo l'opinione di esperti, i processi SCA sono una pratica distinta secondo OWASP SAMM e BSIMM come indicatore di maturità. Nella prima metà del 2020, OWASP ha rilasciato un nuovo standard, l'OWASP Software Component Verification Standard (SCVS), che offre le migliori pratiche per la verifica dei componenti di terze parti nella catena di fornitura del software.

Uno dei casi più significativi è avvenuto con la compagnia Equifax a maggio 2017. Sconosciuti hacker hanno ottenuto informazioni su 143 milioni di americani, comprese le loro nomi completi, indirizzi, numeri di previdenza sociale e patenti di guida. In 209.000 casi, erano presenti anche informazioni sulle carte di credito delle vittime. Questa violazione è avvenuta a causa di un'importante vulnerabilità in Apache Struts 2 (CVE-2017-5638), mentre una patch era già stata rilasciata a marzo 2017. L'azienda ha avuto due mesi per installare l'aggiornamento, ma nessuno se ne è occupato.

In questo articolo si discuterà la scelta dello strumento per effettuare SCA dal punto di vista della qualità dei risultati dell'analisi. Verrà inoltre 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 gamma di strumenti è stata presentata da OWASP sul suo sito web, ma in questo articolo ci concentreremo solo sugli strumenti open source più popolari: Dependency Check, la piattaforma open source meno conosciuta Dependency Track e la soluzione Enterprise Sonatype Nexus IQ. Inoltre, analizzeremo come funzionano queste soluzioni e confronteremo i risultati ottenuti in termini di falsi positivi.

Principio di funzionamento

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

Vediamo come appare una CPE:

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

Part: Indicazione che il componente appartiene a un'applicazione (a), sistema operativo (o), hardware (h) (Obbligatorio)
Vendor: Nome del produttore del prodotto (Obbligatorio)
Product: Nome del prodotto (Obbligatorio)
Versione: Versione del componente (Voce obsoleta)
Aggiornamento: Aggiornamento del pacchetto
Edition: Versione ereditata (Voce obsoleta)
Language: Lingua definita in RFC-5646
SW Edition: Versione del software
Target SW: Ambiente software in cui opera il prodotto
HW target: Ambiente hardware in cui opera il prodotto
Altro: Informazioni sul fornitore o sul prodotto

Un esempio di CPE è il seguente:

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

Questa stringa indica che la CPE versione 2.3 descrive un componente di applicazione dal produttore pivotal_software con il nome spring_framework versione 3.0.0. Se apriamo la vulnerabilità CVE-2014-0225 in NVD, possiamo vedere il riferimento a questa CPE. Il primo problema da notare è che il CVE in NVD, secondo la CPE, segnala la presenza di una vulnerabilità nel framework, non in un componente specifico. Ciò significa che se gli sviluppatori sono fortemente legati al framework e la vulnerabilità identificata non riguarda i moduli utilizzati dagli sviluppatori, il professionista della sicurezza dovrà comunque esaminare questo CVE e considerare un aggiornamento.

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

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

Schema: Sarà sempre ‘pkg’, che indica che si tratta di un URL di pacchetto (Obbligatorio)
Tipo: Il ‘tipo’ del pacchetto o ‘protocollo’ del pacchetto, ad esempio maven, npm, nuget, gem, pypi, ecc. (Obbligatorio)
Namespace: Un certo prefisso del nome, come l'identificatore del gruppo Maven, il proprietario dell'immagine Docker, l'utente o l'organizzazione GitHub. Facoltativo e dipendente dal tipo.
Nome: Nome del pacchetto (campo obbligatorio)
Versione: Versione del pacchetto
Qualificatori: Dati qualificativi aggiuntivi per il pacchetto, come SO, architettura, distribuzione, ecc. Facoltativo e dipendente dal tipo.
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à pronti generati CycloneDX e SPDX, ovvero specifiche pronte riguardo le dipendenze esistenti. Questo è un file XML con descrizione delle dipendenze: nome, hash, url del pacchetto, pubblicatore, licenza. Successivamente, Dependency Track analizza il BOM, esamina le vulnerabilità CVE associate nelle dipendenze dalla base di dati delle vulnerabilità (NVD, Sonatype OSS Index …), quindi costruisce grafici, calcola metriche e aggiorna regolarmente i dati sullo stato delle vulnerabilità delle componenti.

Ecco un 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 input per Dependency Track, ma anche per l'inventario dei componenti software nella catena di fornitura, ad esempio, per fornire ai clienti software. Nel 2014, negli Stati Uniti, è stata persino proposta una legge «Cyber Supply Chain Management and Transparency Act of 2014», che affermava che al momento dell'acquisto di software qualsiasi ente pubblico dovrebbe richiedere un BOM per prevenire l'uso di componenti vulnerabili, tuttavia, a causa di ciò, la legge non è mai entrata in vigore.

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

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

Dependency Track non accetta un progetto come input, ma accetta un BOM. Ciò significa che se vogliamo controllare un progetto, dobbiamo prima generare bom.xml, ad esempio, utilizzando CycloneDX. In questo modo, Dependency Track dipende direttamente da CycloneDX. Allo stesso tempo, questo offre la possibilità di personalizzazione. Così, il team di OZON ha scritto un modulo CycloneDX per la creazione di file BOM per progetti in Golang con l'obiettivo di una successiva scansione tramite Dependency Track.

Nexus IQ — soluzione commerciale SCA di Sonatype che fa parte dell'ecosistema Sonatype, che include anche Nexus Repository Manager. Nexus IQ può accettare in input sia archivi war (per progetti Java) tramite interfaccia web o API, sia BOM, se la vostra organizzazione non ha ancora effettuato il passaggio da CycloneDX alla nuova soluzione. A differenza delle soluzioni open source, IQ si riferisce non solo a CP/PURL per il componente identificato e alla relativa vulnerabilità nel database, ma considera anche ricerche interne, come il nome della funzione o della classe vulnerabile. I meccanismi di IQ saranno esaminati più avanti nella valutazione dei risultati.

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

Linguaggio
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

Capacità di verificare la conformità delle licenze per i componenti utilizzati nel codice sorgente
+
—
+

Possibilità di scansione e analisi per vulnerabilità e conformità delle licenze per le immagini Docker
+ Integrazione con Clair
—
—

Possibilità di impostare politiche di sicurezza per l'utilizzo di librerie open source
+
—
—

Possibilità di eseguire la scansione di repository open source per 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
+
—
—

Operatività in un ambiente chiuso
+
+
+

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

Possibilità di filtrare componenti open source durante il tentativo di caricamento nell'ambiente di sviluppo secondo le politiche configurate
+
—
—

Raccomandazioni per la correzione delle vulnerabilità, presenza di link per la correzione
+
+- (dipende dalla descrizione nei database pubblici)
+- (dipende dalla descrizione nei database pubblici)

Classificazione delle vulnerabilità scoperte in base alla gravità
+
+
+

Modello di accesso basato sui ruoli
+
—
+

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

Estrazione / 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 il sistema di integrazione continua (continuous integration) Bamboo
+
—
—

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

Integrazione con il sistema di integrazione continua (continuous integration) GitLab
+
+- (come plug-in per GitLab)
+

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

Disponibilità di plug-in per IDE
+ IntelliJ, Eclipse, Visual Studio
—
—

Supporto per integrazione personalizzata tramite web-services (API) dello strumento
+
—
+

Dependency Check

Primo avvio

Eseguiamo il Dependency Check su un'applicazione volutamente vulnerabile DVJA.

Per 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 una panoramica sulle vulnerabilità totali, possiamo vedere informazioni sulle vulnerabilità con un alto livello di gravità e fiducia, con riferimento al pacchetto, CPE, numero CVE.

Successivamente, seguirà informazioni più dettagliate, in particolare su quale sia stata la motivazione (evidence), ovvero un certo BOM.

Dopo, ci saranno CPE, PURL e descrizione CVE. Le raccomandazioni per la correzione, tra l'altro, non vengono fornite a causa della loro assenza nel database NVD.

Per un'analisi sistematica dei risultati della scansione, è possibile configurare Nginx con impostazioni minime o inviare i difetti rilevati a un sistema di gestione dei difetti che supporta connettori per il Dependency Check. Ad esempio, Defect Dojo.

Dependency Track

Installazione

Dependency Track, d'altra parte, è una piattaforma web con rappresentazioni grafiche, quindi la questione del salvataggio dei difetti in una soluzione esterna non si pone.
I seguenti scenari sono supportati per l'installazione: Docker, WAR, Executable WAR.

Primo avvio

Accedi all'URL del servizio avviato. Entra con admin/admin, cambia login e password, dopo di che accederai al Dashboard. La prossima cosa che faremo sarà creare un progetto per l'applicazione di test in Java in Home/Projects → Create Project . Prenderemo come esempio 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

Otteniamo bom.xml e carichiamo il file nel progetto creato DVJA → Dependencies → Upload BOM.

Andiamo su Administration → Analyzers. Siamo consapevoli che è attivato solo l'Internal Analyzer, incluso NVD. Colleghiamo anche Sonatype OSS Index.

Così, otteniamo il seguente scenario per il nostro progetto:

Nell'elenco è presente anche una vulnerabilità applicabile a Sonatype OSS:

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

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

Nexus IQ

Primo avvio

L'installazione di Nexus IQ avviene dai pacchetti scaricati da documentazione, ma per questo scopo abbiamo creato un'immagine Docker.

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

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

Per percepire la differenza tra open source ed enterprise, eseguiremo una scansione analoga tramite Nexus IQ plugin Maven, creando preventivamente 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=

Andiamo all'URL per il rapporto generato nell'interfaccia web di IQ:

Qui puoi vedere tutte le violazioni della politica con indicazioni di vari livelli di gravità (da Info a Security Critical). La lettera D accanto a un componente indica che è una Direct Dependency, mentre la lettera T accanto a un componente indica che è una Transitive Dependency, ovvero è transitiva.

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

Se apriamo una delle violazioni della politica di Nexus IQ, possiamo vedere una descrizione del componente, così come il Version Graph, che mostra la posizione della versione attuale sulla linea temporale, e in quale momento la vulnerabilità smette di essere tale. L'altezza delle candele sul grafico indica la popolarità di utilizzo di questo componente.

Se si accede alla sezione delle vulnerabilità e si espande il CVE, è possibile leggere la descrizione di questa vulnerabilità, le raccomandazioni per la risoluzione e il motivo per cui questo componente è stato considerato in violazione, cioè la presenza della classe. DiskFileitem.class.

Riassumiamo solo le vulnerabilità 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 analizzate: 62
Dipendenze vulnerabili: 16
Vulnerabilità trovate: 42 (8 db sonatype)

Totale Dependency Check:

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

Totale Dependency Track:

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

Il passo successivo sarà analizzare i risultati ottenuti e capire quali di queste vulnerabilità rappresentano un reale difetto e quali sono falsi positivi.

Disclaimer

Questa revisione non è una verità indiscutibile. L'autore non aveva l'obiettivo di mettere in evidenza uno strumento rispetto agli altri. Il senso della revisione era dimostrare i meccanismi di funzionamento degli strumenti SCA e i modi di verificare i loro risultati.

Confronto dei risultati

Condizioni:

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

Incongruenza CVE con il componente identificato
Ad esempio, se la vulnerabilità è stata trovata nel framework struts2 e lo strumento indica il componente del framework struts-tiles, al quale questa vulnerabilità non si aplica, si tratta di un falso positivo
Incongruenza CVE con la versione identificata del componente
Ad esempio, se la vulnerabilità è legata alla versione di python > 3.5 e lo strumento segnala come vulnerabile la versione 2.7 — si tratta di un falso positivo, poiché in realtà la vulnerabilità si applica solo alla serie di prodotti 3.x
Duplicazione di CVE
Ad esempio, se SCA ha indicato un CVE che consente di implementare RCE, dopo di che SCA indica per lo stesso componente un CVE applicabile ai prodotti Cisco, soggetti a questa RCE. In tal caso si tratta di un falso positivo.
Ad esempio, se una CVE è stata trovata nel componente spring-web, dopo di che SCA fa riferimento a questa stessa CVE in altri componenti del framework Spring, mentre la CVE non si applica ad altri componenti. In tal caso si tratta di un falso positivo.

L'oggetto della ricerca è il progetto Open Source DVJA. Nello studio sono stati inclusi solo componenti java (senza js).

Risultati complessivi

Passiamo subito ai risultati della revisione manuale delle vulnerabilità identificate. È possibile consultare il rapporto completo per ogni CVE nell'Allegato.

Risultati complessivi su tutte le vulnerabilità:

Caratteristica
Nexus IQ
Dependency Check
Dependency Track

Vulnerabilità totali identificate
42
91
51

Falsi positivi (vulnerabilità identificate erroneamente)
2(4.76%)
62(68,13%)
29(56.86%)

Nessuna vulnerabilità pertinente identificata (falsi negativi)
10
20
27

Risultati complessivi per componenti:

Caratteristica
Nexus IQ
Dependency Check
Dependency Track

Totale componenti identificati
62
47
59

Totale componenti vulnerabili
16
13
10

Falsi positivi identificati per componenti vulnerabili
1
5
0

Falsi positivi identificati per componenti vulnerabili
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 indicati i componenti, e su quello verticale le vulnerabilità identificate al loro interno.

A titolo di confronto, uno studio analogo è stato condotto dal team di Sonatype testando un progetto composto da 1531 componenti utilizzando OWASP Dependency Check. Come possiamo vedere, il rapporto tra rumore e allarmi corretti è simile ai nostri risultati.

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

Esaminiamo alcune CVE dai risultati della nostra scansione per capire le ragioni di tali risultati.

Scopri di più

№1

Iniziamo a esplorare alcuni aspetti interessanti di Sonatype Nexus IQ.

Nexus IQ indica un problema di deserializzazione con la possibilità di eseguire RCE nel Spring Framework più 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. Inizialmente sembra che ci sia una duplicazione della vulnerabilità in più CVE. Infatti, se guardiamo CVE-2016-1000027 e CVE-2011-2894 nel database NVD, tutto appare 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:

CVE-2011-2894 è abbastanza nota di per sé. Nella relazione White Source del 2011 questo CVE è stato riconosciuto come uno dei più frequenti. Le descrizioni per 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ù o meno chiaro. Da un articolo di Tenable comprendiamo che, oltre alla vulnerabilità in RemoteInvocationSerializingExporter in CVE-2011-2894, la vulnerabilità è presente anche in HttpInvokerServiceExporter. Questo è ciò che ci dice Nexus IQ:

Tuttavia, niente di simile si trova in NVD, per cui Dependency Check e Dependency Track ricevono falsi negativi.

Inoltre, dalla descrizione di CVE-2011-2894 si può capire che la vulnerabilità è effettivamente presente sia in spring-context:3.0.5 che in spring-core:3.0.5. Questa conferma può essere trovata nell'articolo di colui che ha scoperto questa vulnerabilità.

№2

Componente
Vulnerabilità
Risultato

struts2-core:2.3.30
CVE-2016-4003
FALSE

Se approfondiamo la vulnerabilità CVE-2016-4003, capiremo che è stata corretta già nella versione 2.3.28; tuttavia, Nexus IQ ci avvisa di essa. Nella descrizione della vulnerabilità c'è una nota:

In altre parole, la vulnerabilità esiste solo in combinazione con una versione obsoleta di JRE, di cui siamo stati avvisati. Riteniamo comunque che si tratti di 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 analizziamo la descrizione di CVE-2017-9804 e CVE-2017-7672, comprendiamo che il problema riguarda la classe URLValidator, e CVE-2017-9804 deriva da CVE-2017-7672. La presenza della seconda vulnerabilità non apporta alcun valore utile se non quello che la sua severità è aumentata a High, quindi possiamo considerarla un rumore superfluo.

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

№4

Ci sono diversi aspetti che fanno risaltare IQ rispetto ad altre soluzioni.

Componente
Vulnerabilità
Risultato

spring-web:3.0.5
CVE-2020-5398
TRUE

Il CVE in NVD segnala che è applicabile solo per le versioni 5.2.x fino a 5.2.3, 5.1.x fino a 5.1.13, e versioni 5.0.x fino a 5.0.16; tuttavia, se guardiamo la descrizione del CVE in Nexus IQ, vediamo quanto segue:
Avviso di Deviazione del Consiglio: 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 indicato nell'avviso.

Dopo questo, segue un PoC per questa vulnerabilità, che segnala la sua presenza nella versione 3.0.5.

Un falso negativo viene inviato a Dependency Check e Dependency Track.

№5

Esaminiamo il falso positivo per Dependency Check e Dependency Track.

Dependency Check si distingue per il fatto di riflettere quelle CVE che si riferiscono all'intero framework in NVD, per i componenti a cui queste CVE non sono applicabili. Questo riguarda le 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 "assieme" a struts-taglib:1.3.8 e struts-tiles-1.3.8. Questi componenti non hanno nulla a che fare con ciò che è descritto nelle CVE — gestione delle richieste, validazione delle pagine e così via. Ciò è dovuto al fatto che ciò che è comune tra queste 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 applicano a struts2-core, che è sostanzialmente un framework separato. In questo caso, Nexus IQ ha compreso correttamente la situazione e nelle CVE che ha fornito ha indicato che struts-core era a fine vita e che era necessario passare a struts2-core.

№6

In alcune situazioni, è ingiusto interpretare gli errori evidenti di Dependency Check e Dependency Track. In particolare, le vulnerabilità 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, in realtà appartengono a spring-web:3.0.5. Inoltre, alcune di queste vulnerabilità sono state trovate anche in Nexus IQ; tuttavia, IQ le ha correttamente identificate come appartenenti a un'altra componente. Dal fatto che queste vulnerabilità non siano state trovate in spring-core, non si può affermare che non esistano nel framework in generale, e gli strumenti open source hanno giustamente indicato queste vulnerabilità (solo che hanno fatto un piccolo errore di attribuzione).

Conclusioni

Come possiamo vedere, la valutazione della validità delle vulnerabilità identificate tramite revisione manuale non fornisce risultati chiari, causando momenti controversi. I risultati mostrano che la soluzione 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 per ciascuna vulnerabilità CVE del NVD nelle proprie banche dati, specificando con precisione la classe o la funzione di vulnerabilità per ciascuna versione del componente, avendo condotto ulteriori ricerche (ad esempio, verificando le vulnerabilità su versioni precedenti del software).

Un fattore non trascurabile nei risultati è rappresentato anche da quelle vulnerabilità che non sono state incluse nel NVD, ma che sono comunque presenti nel database di Sonatype contrassegnate come SONATYPE. Secondo il rapporto Lo stato delle vulnerabilità nella sicurezza open source 2020 il 45% delle vulnerabilità scoperte nel software open source non viene riportato nel NVD. Secondo il database di WhiteSource, solo il 29% di tutte le vulnerabilità open source registrate al di fuori del NVD viene infine pubblicato lì, rendendo così fondamentale cercare vulnerabilità anche in altre fonti.

Come risultato, Dependency Check genera un elevato numero di falsi positivi, tralasciando alcune componenti vulnerabili. Dependency Track genera meno falsi positivi e identifica un numero maggiore di componenti, risultando visivamente più chiaro nell'interfaccia web.

Tuttavia, la pratica dimostra che il software open source deve diventare il primo passo verso una solida implementazione del DevSecOps. Il primo aspetto da considerare per integrare l'SCA nello sviluppo è rappresentato dai processi, in particolare riflettendo insieme alla direzione e ai reparti correlati su come dovrebbero apparire i processi ideali all'interno della propria organizzazione. Potrebbe rivelarsi che per la tua organizzazione, inizialmente, Dependency Check o Dependency Track coprano tutte le esigenze aziendali, mentre le soluzioni enterprise rappresentino un naturale proseguimento per via dell'aumento della complessità delle applicazioni in fase di sviluppo.

Appendice A. Risultati relativi ai componenti
Legende:

High — vulnerabilità di alto e critico livello nel componente
Medium — vulnerabilità di livello medio di criticità nel componente
TRUE — Vulnerabilità correttamente identificata (True positive issue)
FALSE — Falso positivo (False positive issue)

Componente
Nexus IQ
Dependency Check
Dependency Track
Risultato

dom4j: 1.6.1
Alto
Alto
Alto
TRUE

log4j-core: 2.3
Alto
Alto
Alto
TRUE

log4j: 1.2.14
Alto
Alto
—
TRUE

commons-collections:3.1
Alto
Alto
Alto
TRUE

commons-fileupload:1.3.2
Alto
Alto
Alto
TRUE

commons-beanutils:1.7.0
Alto
Alto
Alto
TRUE

commons-codec:1:10
Medium
—
—
TRUE

mysql-connector-java:5.1.42
Alto
Alto
Alto
TRUE

spring-expression:3.0.5
Alto
componente non trovato

TRUE

spring-web:3.0.5
Alto
componente non trovato
Alto
TRUE

spring-context:3.0.5
Medium
componente non trovato
—
TRUE

spring-core:3.0.5
Medium
Alto
Alto
TRUE

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

spring-tx:3.0.5
—
Alto
—
FALSE

struts-core:1.3.8
Alto
Alto
Alto
TRUE

xwork-core: 2.3.30
Alto
—
—
TRUE

struts2-core: 2.3.30
Alto
Alto
Alto
TRUE

struts-taglib:1.3.8
—
Alto
—
FALSE

struts-tiles-1.3.8
—
Alto
—
FALSE

Appendice B. Risultati relativi alle vulnerabilità
Legende:

High — vulnerabilità di alto e critico livello nel componente
Medium — vulnerabilità di livello medio di criticità nel componente
TRUE — Vulnerabilità correttamente identificata (True positive issue)
FALSE — Falso positivo (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
Alto
TRUE

CVE-2020-10683
CVE-2020-10683
CVE-2020-10683
Alto
TRUE

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

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

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

—
CVE-2020-9488
—
Basso
TRUE

SONATYPE-2010-0053
—
—
Alto
TRUE

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

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

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

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

SONATYPE-2014-0173
—
—
Medium
TRUE

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

—
CVE-2019-10086
CVE-2019-10086
Alto
FALSE
La vulnerabilità si applica solo alle 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
Alto
TRUE

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

—
CVE-2020-2875
—
Medium
FALSE
La stessa vulnerabilità di CVE-2019-2692, con l'aggiunta «gli attacchi possono avere un impatto significativo su ulteriori prodotti»

—
CVE-2017-15945
—
Alto
FALSE
Non relativo 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
—
Alto
TRUE

CVE-2018-1257
—
—
Medium
TRUE

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

CVE-2014-0225
—
CVE-2014-0225
Alto
TRUE

CVE-2011-2730
—
—
Alto
TRUE

—
—
CVE-2013-4152
Medium
TRUE

CVE-2018-1272
—
—
Alto
TRUE

CVE-2020-5398
—
—
Alto
TRUE
Esempio esemplare a favore di 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 indicato 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
Alto
TRUE

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

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

—
CVE-2013-4152
—
Medium
FALSE
La vulnerabilità riguarda il componente spring-web

—
CVE-2013-6429
CVE-2013-6429
Medium
FALSE
La vulnerabilità riguarda il componente spring-web

—
CVE-2013-6430
—
Medium
FALSE
La vulnerabilità riguarda il componente spring-web

—
CVE-2013-7315
CVE-2013-7315
Medium
FALSE
SPLIT di CVE-2013-4152. + La vulnerabilità riguarda il componente spring-web

—
CVE-2014-0054
CVE-2014-0054
Medium
FALSE
La vulnerabilità riguarda il componente spring-web

—
CVE-2014-0225
—
Alto
FALSE
La vulnerabilità riguarda il componente spring-web

—
—
CVE-2014-0225
Alto
FALSE
Duplicato di questa stessa vulnerabilità in spring-web

—
CVE-2014-1904
CVE-2014-1904
Medium
FALSE
La vulnerabilità riguarda il componente spring-web-mvc

—
CVE-2014-3625
CVE-2014-3625
Medium
FALSE
La vulnerabilità riguarda il componente spring-web-mvc

—
CVE-2016-9878
CVE-2016-9878
Alto
FALSE
La vulnerabilità riguarda il componente spring-web-mvc

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

—
CVE-2018-1271
CVE-2018-1271
Medium
FALSE
La vulnerabilità riguarda il componente spring-web-mvc

—
CVE-2018-1272
CVE-2018-1272
Alto
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
—
Alto
FALSE
La vulnerabilità non è relativa a spring-tx

—
CVE-2011-2894
—
Alto
FALSE
La vulnerabilità non è relativa a spring-tx

—
CVE-2013-4152
—
Medium
FALSE
La vulnerabilità non è relativa a spring-tx

—
CVE-2013-6429
—
Medium
FALSE
La vulnerabilità non è relativa a spring-tx

—
CVE-2013-6430
—
Medium
FALSE
La vulnerabilità non è relativa a spring-tx

—
CVE-2013-7315
—
Medium
FALSE
La vulnerabilità non è relativa a spring-tx

—
CVE-2014-0054
—
Medium
FALSE
La vulnerabilità non è relativa a spring-tx

—
CVE-2014-0225
—
Alto
FALSE
La vulnerabilità non è relativa a spring-tx

—
CVE-2014-1904
—
Medium
FALSE
La vulnerabilità non è relativa a spring-tx

—
CVE-2014-3625
—
Medium
FALSE
La vulnerabilità non è relativa a spring-tx

—
CVE-2016-9878
—
Alto
FALSE
La vulnerabilità non è relativa a spring-tx

—
CVE-2018-1270
—
Alto
FALSE
La vulnerabilità non è relativa a spring-tx

—
CVE-2018-1271
—
Medium
FALSE
La vulnerabilità non è relativa a spring-tx

—
CVE-2018-1272
—
Medium
FALSE
La vulnerabilità non è relativa a spring-tx

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

Medium
FASLE
Vulnerabilità relativa a Struts 2

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

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

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

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

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

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

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

CVE-2015-0899
CVE-2015-0899
—
Alto
TRUE

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

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

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

—
CVE-2013-1966 (OSSINDEX)
CVE-2013-1966
Alto
FASLE
Vulnerabilità relativa a Struts 2

—
CVE-2013-2115
CVE-2013-2115
Alto
FASLE
Vulnerabilità relativa a Struts 2

—
CVE-2013-2134 (OSSINDEX)
CVE-2013-2134
Alto
FASLE
Vulnerabilità relativa a Struts 2

—
CVE-2013-2135 (OSSINDEX)
CVE-2013-2135
Alto
FASLE
Vulnerabilità relativa a Struts 2

CVE-2014-0114
CVE-2014-0114
—
Alto
TRUE

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

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

CVE-2016-1181
CVE-2016-1181
—
Alto
TRUE

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

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

SONATYPE-2017-0173
—
—
Alto
TRUE

CVE-2017-7672
—
—
Alto
FALSE
Duplice di CVE-2017-9804

SONATYPE-2016-0127
—
—
Alto
TRUE

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

—
CVE-2017-9787
CVE-2017-9787
Alto
TRUE

—
CVE-2017-9791
CVE-2017-9791
Alto
TRUE

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

—
CVE-2017-9804
—
Alto
TRUE

—
CVE-2017-9805
CVE-2017-9805
Alto
TRUE

CVE-2016-4003
—
—
Medium
FALSE
Applicabile ad Apache Struts 2.x fino alla versione 2.3.28, mentre attualmente è in uso la versione 2.3.30. Tuttavia, in base alla descrizione, il CVE è valido per tutte le versioni di Struts 2, se si utilizza JRE 1.7 o inferiore. Sembra che qui ci abbiano voluto tutelare, ma più che altro assomiglia a un FALSE

—
CVE-2018-1327
CVE-2018-1327
Alto
TRUE

CVE-2017-5638
CVE-2017-5638
CVE-2017-5638
Alto
TRUE
Questa è la vulnerabilità sfruttata dagli attaccanti in Equifax nel 2017

CVE-2017-12611
CVE-2017-12611
—
Alto
TRUE

CVE-2018-11776
CVE-2018-11776
CVE-2018-11776
Alto
TRUE

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

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

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

—
CVE-2015-0899
—
Alto
FALSE
Non si applica a taglib

—
CVE-2015-2992
—
Medium
FALSE
Si applica a struts2-core

—
CVE-2016-1181
—
Alto
FALSE
Non si applica a taglib

—
CVE-2016-1182
—
Alto
FALSE
Non si applica a taglib

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