L'importanza dell'analisi dei componenti software di terze parti (Software Composition Analysis - SCA) nel processo di sviluppo sta crescendo con il rilascio di rapporti annuali sulle vulnerabilità delle librerie open source, pubblicati da Synopsys, Sonatype, Snyk e White Source . Secondo il rapporto il numero di vulnerabilità open source identificate nel 2019 è aumentato di quasi 1.5 volte rispetto all’anno precedente, mentre i componenti open source sono utilizzati dal 60% all’80% dei progetti. Su base indipendente, i processi SCA sono una pratica separata di OWASP SAMM e BSIMM come indicatore di maturità e, nella prima metà del 2020, OWASP ha rilasciato il nuovo OWASP Software Component Verification Standard (SCVS), fornendo le migliori pratiche per la verifica di terze parti. componenti delle parti nella catena di fornitura BY.
Uno dei casi più illustrativi con Equifax nel maggio 2017. Aggressori sconosciuti hanno ottenuto informazioni su 143 milioni di americani, inclusi nomi completi, indirizzi, numeri di previdenza sociale e patenti di guida. In 209 casi i documenti contenevano anche informazioni sulle carte bancarie delle vittime. Questa fuga di notizie si è verificata a seguito dello sfruttamento di una vulnerabilità critica in Apache Struts 000 (CVE-2-2017), mentre la correzione è stata rilasciata nel marzo 5638. L'azienda aveva due mesi per installare l'aggiornamento, ma nessuno se ne è preoccupato.
Questo articolo discuterà la questione della scelta di uno strumento per condurre 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 funzionalità di integrazione saranno lasciati per pubblicazioni successive. OWASP ha presentato un'ampia gamma di strumenti , ma nella presente recensione toccheremo solo lo strumento open source più popolare Dependency Check, la piattaforma open source leggermente meno conosciuta Dependency Track e la soluzione Enterprise Sonatype Nexus IQ. Capiremo anche come funzionano queste soluzioni e confronteremo i risultati ottenuti per i falsi positivi.
Come funziona
è un'utilità (CLI, maven, modulo jenkins, formica) che analizza i file di progetto, raccoglie informazioni sulle dipendenze (nome del pacchetto, ID gruppo, titolo della specifica, versione...), crea una riga CPE (Common Platform Enumeration) , URL del pacchetto (PURL) e identifica le vulnerabilità per CPE/PURL dai database (NVD, Sonatype OSS Index, NPM Audit API...), dopo di che crea un report una tantum in formato HTML, JSON, XML...
Diamo un'occhiata a come appare il CPE:
cpe:2.3:part:vendor:product:version:update:edition:language:sw_edition:target_sw:target_hw:other- Parte: Indicazione che il componente è relativo all'applicazione (a), al sistema operativo (o), all'hardware (h) (Obbligatorio)
- Venditore: Nome del produttore del prodotto (richiesto)
- Prodotti: Nome prodotto (richiesto)
- Versione: Versione componente (Articolo obsoleto)
- Aggiornare: Aggiornamento del pacchetto
- Edizione: Versione legacy (articolo obsoleto)
- Lingua: Lingua definita in RFC-5646
- Edizione SW: Versione software
- SW di destinazione: Ambiente software in cui opera il prodotto
- Hardware di destinazione: L'ambiente hardware in cui opera il prodotto
- Altro: Informazioni sul fornitore o sul prodotto
Un esempio di CPE è simile al seguente:
cpe:2.3:a:pivotal_software:spring_framework:3.0.0:*:*:*:*:*:*:*
La riga significa che la versione CPE 2.3 descrive il componente applicativo del produttore pivotal_software con il nome spring_framework versione 3.0.0. Se apriamo una vulnerabilità in NVD possiamo vedere una menzione di questo CPE. Il primo problema a cui prestare subito attenzione è che CVE in NVD, secondo CPE, segnala un problema nel framework e non in un componente specifico. Cioè, se gli sviluppatori sono strettamente legati al framework e la vulnerabilità identificata non influisce sui moduli utilizzati dagli sviluppatori, uno specialista della sicurezza dovrà in un modo o nell'altro smontare questo CVE e pensare all'aggiornamento.
L'URL viene utilizzato anche dagli strumenti SCA. Il formato dell'URL del pacchetto è il seguente:
scheme:type/namespace/name@version?qualifiers#subpath- Schema: Ci sarà sempre "pkg" a indicare che si tratta dell'URL di un pacchetto (obbligatorio)
- Tipo: Il "tipo" del pacchetto o il "protocollo" del pacchetto, come maven, npm, nuget, gem, pypi, ecc. (Articolo richiesto)
- Spazio dei nomi: Alcuni prefissi del nome, ad esempio un ID gruppo Maven, il proprietario dell'immagine Docker, un utente GitHub o un'organizzazione. Facoltativo e dipende dal tipo.
- Nome e Cognome: Nome del pacchetto (obbligatorio)
- Versione: Versione del pacchetto
- Qualificazioni: Dati di qualificazione aggiuntivi per il pacchetto, come sistema operativo, architettura, distribuzione, ecc. Facoltativi e specifici del tipo.
- Sottopercorso: Percorso aggiuntivo nel pacchetto relativo alla radice del pacchetto
Per esempio:
pkg:golang/google.golang.org/genproto#googleapis/api/annotations
pkg:maven/org.apache.commons/[email protected]
pkg:pypi/[email protected]— una piattaforma web on-premise che accetta la generazione di distinte materiali (BOM) già pronte и , ovvero specifiche già pronte sulle dipendenze esistenti. Questo è un file XML che descrive le dipendenze: nome, hash, URL del pacchetto, editore, licenza. Successivamente, Dependency Track analizza la BOM, esamina i CVE disponibili per le dipendenze identificate dal database delle vulnerabilità (NVD, Sonatype OSS Index...), dopo di che costruisce grafici, calcola metriche, aggiorna regolarmente i dati sullo stato di vulnerabilità dei componenti .
Un esempio di come potrebbe apparire una distinta base in formato XML:
<?xml version="1.0" encoding="UTF-8"?>
<bom xmlns="http://cyclonedx.org/schema/bom/1.2" serialNumber="urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79" version="1">
<components>
<component type="library">
<publisher>Apache</publisher>
<group>org.apache.tomcat</group>
<name>tomcat-catalina</name>
<version>9.0.14</version>
<hashes>
<hash alg="MD5">3942447fac867ae5cdb3229b658f4d48</hash>
<hash alg="SHA-1">e6b1000b94e835ffd37f4c6dcbdad43f4b48a02a</hash>
<hash alg="SHA-256">f498a8ff2dd007e29c2074f5e4b01a9a01775c3ff3aeaf6906ea503bc5791b7b</hash>
<hash alg="SHA-512">e8f33e424f3f4ed6db76a482fde1a5298970e442c531729119e37991884bdffab4f9426b7ee11fccd074eeda0634d71697d6f88a460dce0ac8d627a29f7d1282</hash>
</hashes>
<licenses>
<license>
<id>Apache-2.0</id>
</license>
</licenses>
<purl>pkg:maven/org.apache.tomcat/[email protected]</purl>
</component>
<!-- More components here -->
</components>
</bom>La distinta base può essere utilizzata non solo come parametri di input per il Dependency Track, ma anche per l'inventario dei componenti software nella catena di fornitura, ad esempio per fornire software a un cliente. Nel 2014 è stata proposta una legge anche negli Stati Uniti , in cui si affermava che al momento dell'acquisto di software, qualsiasi stato. L'istituzione deve richiedere una distinta base per impedire l'uso di componenti vulnerabili, ma la legge non è ancora entrata in vigore.
Tornando a SCA, Dependency Track dispone di integrazioni già pronte con piattaforme di notifica come Slack e sistemi di gestione delle vulnerabilità come Kenna Security. Vale anche la pena dire che Dependency Track, tra le altre cose, identifica le versioni obsolete dei pacchetti e fornisce informazioni sulle licenze (grazie al supporto SPDX).
Se parliamo specificamente della qualità della SCA, allora c'è una differenza fondamentale.
La traccia delle dipendenze non accetta il progetto come input, ma piuttosto la distinta base. Ciò significa che se vogliamo testare il progetto, dobbiamo prima generare bom.xml, ad esempio utilizzando CycloneDX. Pertanto, Dependency Track dipende direttamente da CycloneDX. Allo stesso tempo, consente la personalizzazione. Questo è ciò che ha scritto il team OZON per assemblare file BOM per progetti Golang per ulteriori scansioni tramite Dependency Track.
è una soluzione SCA commerciale di Sonatype, che fa parte dell'ecosistema Sonatype, che include anche Nexus Repository Manager. Nexus IQ può accettare come input sia archivi di guerra (per progetti Java) tramite l'interfaccia web o API, sia BOM, se la tua organizzazione non è ancora passata da CycloneDX a una nuova soluzione. A differenza delle soluzioni open source, IQ non si riferisce solo al componente identificato e alla corrispondente vulnerabilità nel database con CP/PURL, ma tiene conto anche della propria ricerca, ad esempio il nome della funzione o della classe vulnerabile. I meccanismi del QI verranno discussi più avanti nell'analisi dei risultati.
Riassumiamo alcune delle caratteristiche funzionali e consideriamo anche le lingue supportate per l'analisi:
lingua
QI del Nexus
Controllo delle dipendenze
Traccia delle dipendenze
Java
+
+
+
C / C ++
+
+
-
C#
+
+
-
. Net
+
+
+
Erlang
-
-
+
JavaScript (NodoJS)
+
+
+
PHP
+
+
+
Python
+
+
+
Ruby
+
+
+
Perl
-
-
-
Scala
+
+
+
Obiettivo C
+
+
-
Swift
+
+
-
R
+
-
-
Go
+
+
+
funzionalità
funzionalità
QI del Nexus
Controllo delle dipendenze
Traccia delle dipendenze
La capacità di garantire che i componenti utilizzati nel codice sorgente siano controllati per verificarne la purezza concessa in licenza
+
-
+
Capacità di scansionare e analizzare le vulnerabilità e la pulizia della licenza per le immagini Docker
+ Integrazione con Clair
-
-
Possibilità di configurare politiche di sicurezza per utilizzare librerie open source
+
-
-
Possibilità di scansionare 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
Disponibilità di un gruppo di ricerca specializzato
+
-
-
Funzionamento a circuito chiuso
+
+
+
Utilizzo di database di terze parti
+ Database Sonatype chiuso
+ Sonatype OSS, consulenti pubblici NPM
+ Sonatype OSS, NPM Public Advisors, RetireJS, VulnDB, supporto per il proprio database delle vulnerabilità
Possibilità di filtrare i componenti open source durante il tentativo di caricamento nel ciclo di sviluppo in base alle policy configurate
+
-
-
Raccomandazioni per correggere le vulnerabilità, disponibilità di collegamenti alle correzioni
+
+- (dipende dalla descrizione nei database pubblici)
+- (dipende dalla descrizione nei database pubblici)
Classifica delle vulnerabilità rilevate per gravità
+
+
+
Modello di accesso basato sui ruoli
+
-
+
Supporto CLI
+
+
+- (solo per CycloneDX)
Campionamento/ordinamento delle vulnerabilità secondo criteri definiti
+
-
+
Dashboard per stato della domanda
+
-
+
Generazione di report in formato PDF
+
-
-
Generazione di report in formato JSONCSV
+
+
-
Supporto per la lingua russa
-
-
-
Capacità di integrazione
integrazione
QI del Nexus
Controllo delle dipendenze
Traccia delle dipendenze
Integrazione LDAP/Active Directory
+
-
+
Integrazione con il sistema di integrazione continua Bamboo
+
-
-
Integrazione con il sistema di integrazione continua TeamCity
+
-
-
Integrazione con il sistema di integrazione continua GitLab
+
+- (come plugin per GitLab)
+
Integrazione con il sistema di integrazione continua Jenkins
+
+
+
Disponibilità di plugin per IDE
+ IntelliJ, Eclipse, Visual Studio
-
-
Supporto per l'integrazione personalizzata tramite servizi web (API) dello strumento
+
-
+
Controllo delle dipendenze
Первый запуск
Eseguiamo il controllo delle dipendenze su un'applicazione deliberatamente vulnerabile .
Per questo useremo :
mvn org.owasp:dependency-check-maven:checkDi conseguenza, nella directory di destinazione verrà visualizzato dependency-check-report.html.
Apriamo il file. Dopo le informazioni di riepilogo sul numero totale di vulnerabilità, possiamo visualizzare informazioni sulle vulnerabilità con un livello elevato di gravità e confidenza, indicando il pacchetto, il CPE e il numero di CVE.
Seguono informazioni più dettagliate, in particolare la base su cui è stata presa la decisione (prove), ovvero una determinata distinta base.
Poi arriva la descrizione CPE, PURL e CVE. A proposito, le raccomandazioni per la correzione non sono incluse a causa della loro assenza nel database NVD.
Per visualizzare sistematicamente i risultati della scansione, è possibile configurare Nginx con impostazioni minime o inviare i difetti risultanti a un sistema di gestione dei difetti che supporti i connettori per il controllo delle dipendenze. Ad esempio, Difetto Dojo.
Traccia delle dipendenze
Installazione
Dependency Track, a sua volta, è una piattaforma basata sul web con grafici di visualizzazione, quindi qui non si pone il problema urgente della memorizzazione dei difetti in una soluzione di terze parti.
Gli script supportati per l'installazione sono: Docker, WAR, Executable WAR.
Первый запуск
Andiamo all'URL del servizio in esecuzione. Effettuiamo l'accesso tramite admin/admin, modifichiamo login e password e poi arriviamo alla Dashboard. La prossima cosa che faremo è creare un progetto per un'applicazione di test in Java in Home/Progetti → Crea progetto . Prendiamo come esempio il DVJA.
Poiché la traccia delle dipendenze può accettare solo la distinta base come input, questa distinta base deve essere recuperata. Approfittiamo :
mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBomOtteniamo bom.xml e carichiamo il file nel progetto creato DVJA → Dipendenze → Carica distinta base.
Andiamo su Amministrazione → Analizzatori. Comprendiamo che abbiamo abilitato solo l'analizzatore interno, che include NVD. Colleghiamo anche Sonatype OSS Index.
Pertanto, otteniamo la seguente immagine per il nostro progetto:
Inoltre nell'elenco puoi trovare una vulnerabilità applicabile a Sonatype OSS:
La principale delusione è stata il fatto che Dependency Track non accetta più report xml di Dependency Check. Le ultime versioni supportate dell'integrazione del controllo delle dipendenze erano 1.0.0 - 4.0.2, mentre ho testato la 5.3.2.
Qui (e ) quando era ancora possibile.
QI del Nexus
Первый запуск
L'installazione di Nexus IQ proviene dagli archivi di , ma abbiamo creato un'immagine Docker per questi scopi.
Dopo aver effettuato l'accesso alla console, è necessario creare un'organizzazione e un'applicazione.
Come puoi vedere, la configurazione nel caso di IQ è un po' più complicata, perché dobbiamo anche creare policy applicabili a diverse "fasi" (sviluppo, build, stage, rilascio). Ciò è necessario per bloccare i componenti vulnerabili mentre si spostano attraverso la pipeline più vicina alla produzione o per bloccarli non appena entrano nel Nexus Repo quando vengono scaricati dagli sviluppatori.
Per sentire la differenza tra open source ed enterprise, eseguiamo la stessa scansione tramite Nexus IQ nello stesso modo attraverso , avendo precedentemente creato un'applicazione di prova nell'interfaccia NexusIQ dvja-test-and-compare:
mvn com.sonatype.clm:clm-maven-plugin:evaluate -Dclm.applicationId=dvja-test-and-compare -Dclm.serverUrl=<NEXUSIQIP> -Dclm.username=<USERNAME> -Dclm.password=<PASSWORD>
Segui l'URL del report generato nell'interfaccia web IQ:
Qui puoi vedere tutte le violazioni delle policy che indicano diversi livelli di significatività (da Info a Security Critical). La lettera D accanto al componente significa che il componente è Dipendenza Diretta e la lettera T accanto al componente significa che il componente è Dipendenza Transitiva, ovvero è transitivo.
A proposito, il rapporto di Snyk riporta che oltre il 70% delle vulnerabilità open source scoperte in Node.js, Java e Ruby si trovano in dipendenze transitive.
Se apriamo una delle violazioni della policy Nexus IQ, possiamo vedere una descrizione del componente, nonché un grafico della versione, che mostra la posizione della versione corrente nel grafico temporale, nonché il punto in cui la vulnerabilità cessa di esistere. essere vulnerabile. L'altezza delle candele sul grafico mostra la popolarità dell'utilizzo di questo componente.
Se vai nella sezione vulnerabilità ed espandi il CVE, puoi leggere una descrizione di questa vulnerabilità, i consigli per l'eliminazione, nonché il motivo per cui questo componente è stato violato, ovvero la presenza della classe DiskFileitem.class.
Riassumiamo solo quelli relativi ai componenti Java di terze parti, eliminando i componenti js. Tra parentesi indichiamo il numero di vulnerabilità riscontrate al di fuori di NVD.
QI totale del Nexus:
- Dipendenze scansionate: 62
- Dipendenze vulnerabili: 16
- Vulnerabilità trovate: 42 (8 sonatipo db)
Controllo della dipendenza totale:
- Dipendenze scansionate: 47
- Dipendenze vulnerabili: 13
- Vulnerabilità trovate: 91 (14 sonatipo oss)
Traccia della dipendenza totale:
- Dipendenze scansionate: 59
- Dipendenze vulnerabili: 10
- Vulnerabilità trovate: 51 (1 sonatipo oss)
Nei prossimi passi analizzeremo i risultati ottenuti e capiremo quale di queste vulnerabilità è un vero difetto e quale è un falso positivo.
Disclaimer
Questa recensione non è una verità indiscutibile. L'autore non aveva l'obiettivo di evidenziare uno strumento separato rispetto agli altri. Lo scopo della revisione era quello di mostrare i meccanismi di funzionamento degli strumenti SCA e le modalità per verificarne i risultati.
Confronto dei risultati
Termini e condizioni:
Un falso positivo per le vulnerabilità dei componenti di terze parti è:
- Mancata corrispondenza CVE con il componente identificato
- Ad esempio, se viene identificata una vulnerabilità nel framework struts2 e lo strumento punta a un componente del framework struts-tiles a cui questa vulnerabilità non si applica, allora si tratta di un falso positivo
- Mancata corrispondenza CVE con la versione identificata del componente
- Ad esempio, la vulnerabilità è legata alla versione Python > 3.5 e lo strumento contrassegna la versione 2.7 come vulnerabile: questo è un falso positivo, poiché in realtà la vulnerabilità si applica solo al ramo del prodotto 3.x
- CVE duplicato
- Ad esempio, se la SCA specifica un CVE che abilita un RCE, allora la SCA specifica un CVE per lo stesso componente che si applica ai prodotti Cisco interessati da tale RCE. In questo caso sarà un falso positivo.
- Ad esempio, è stato trovato un CVE in un componente spring-web, dopodiché SCA punta allo stesso CVE in altri componenti di Spring Framework, mentre il CVE non ha nulla a che fare con altri componenti. In questo caso sarà un falso positivo.
Oggetto dello studio era il progetto Open Source DVJA. Lo studio ha coinvolto solo componenti Java (senza js).
Risultati riassuntivi
Andiamo direttamente ai risultati di una revisione manuale delle vulnerabilità identificate. Il rapporto completo per ciascun CVE è disponibile in Appendice.
Risultati di riepilogo per tutte le vulnerabilità:
Parametro
QI del Nexus
Controllo delle dipendenze
Traccia delle dipendenze
Vulnerabilità totali identificate
42
91
51
Vulnerabilità identificate erroneamente (falso positivo)
2 (4.76%)
62 (68,13%)
29 (56.86%)
Nessuna vulnerabilità rilevante trovata (falso negativo)
10
20
27
Risultati riassuntivi per componente:
Parametro
QI del Nexus
Controllo delle dipendenze
Traccia delle dipendenze
Componenti totali identificati
62
47
59
Componenti vulnerabili totali
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à. I componenti sono contrassegnati orizzontalmente e le vulnerabilità identificate in essi sono contrassegnate verticalmente.
Per fare un confronto, uno studio simile è stato condotto dal team Sonatype testando un progetto di 1531 componenti utilizzando OWASP Dependency Check. Come possiamo vedere, il rapporto tra rumore e risposte corrette è paragonabile ai nostri risultati.
Fonte:
Diamo un'occhiata ad alcuni CVE dai risultati della nostra scansione per comprendere il motivo di questi risultati.
Più
№ 1
Diamo prima un'occhiata ad alcuni punti interessanti sul Sonatype Nexus IQ.
Nexus IQ segnala un problema con la deserializzazione con la possibilità di eseguire più volte RCE nello Spring Framework. 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 vi sia una duplicazione della vulnerabilità su più CVE. Perché, se guardi CVE-2016-1000027 e CVE-2011-2894 nel database NVD, sembra che tutto sia ovvio
componente
vulnerabilità
primavera-web:3.0.5
CVE-2016-1000027
contesto primaverile:3.0.5
CVE-2011-2894
nucleo a molla: 3.0.5
CVE-2011-2894
descrizione da NVD:
descrizione da NVD:
Lo stesso CVE-2011-2894 è piuttosto famoso. Nel rapporto questo CVE è stato riconosciuto come uno dei più comuni. Le descrizioni per CVE-2016-100027, in linea di principio, sono poche in NVD e sembra essere applicabile solo per Spring Framework 4.1.4. Diamo un'occhiata a e qui tutto diventa più o meno chiaro. Da Comprendiamo che oltre alla vulnerabilità in RemoteInvocationSerializingExporter in CVE-2011-2894, la vulnerabilità è osservata in HttpInvokerServiceExporter. Questo è ciò che ci dice Nexus IQ:
Tuttavia, non c'è nulla di simile in NVD, motivo per cui il controllo delle dipendenze e il tracciamento delle dipendenze ricevono ciascuno un falso negativo.
Anche 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. La conferma di ciò può essere trovata in un articolo della persona che ha riscontrato questa vulnerabilità.
№ 2
componente
vulnerabilità
risultato
puntoni2-core:2.3.30
CVE-2016-4003
FALSO
Se studiamo la vulnerabilità CVE-2016-4003, capiremo che è stata risolta nella versione 2.3.28, tuttavia Nexus IQ ce lo segnala. C'è una nota nella descrizione della vulnerabilità:
Cioè, la vulnerabilità esiste solo in combinazione con una versione obsoleta di JRE, di cui hanno deciso di avvisarci. Tuttavia consideriamo questo Falso Positivo, anche se non il peggiore.
№ 3
componente
vulnerabilità
risultato
xwork-core:2.3.30
CVE-2017-9804
TRUE
xwork-core:2.3.30
CVE-2017-7672
FALSO
Se guardiamo le descrizioni di CVE-2017-9804 e CVE-2017-7672, capiremo che il problema è URLValidator class, con CVE-2017-9804 derivante da CVE-2017-7672. La presenza della seconda vulnerabilità non comporta alcun carico utile se non il fatto che la sua gravità è aumentata a Alta, quindi possiamo considerarla rumore non necessario.
Nel complesso, non sono stati trovati altri falsi positivi per Nexus IQ.
№ 4
Ci sono molte cose che distinguono IQ dalle altre soluzioni.
componente
vulnerabilità
risultato
primavera-web:3.0.5
CVE-2020-5398
TRUE
Il CVE nell'NVD afferma che si applica solo alle versioni 5.2.x prima della 5.2.3, 5.1.x prima della 5.1.13 e alle versioni 5.0.x prima della 5.0.16, tuttavia, se guardiamo la descrizione CVE in Nexus IQ , allora vedremo quanto segue:
Avviso di deviazione dall'avviso: 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.
Questo è seguito da un PoC per questa vulnerabilità, in cui si afferma che è presente nella versione 3.0.5.
Il falso negativo viene inviato al controllo delle dipendenze e al tracciamento delle dipendenze.
№ 5
Diamo un'occhiata ai falsi positivi per il controllo delle dipendenze e il tracciamento delle dipendenze.
Il controllo delle dipendenze si distingue in quanto riflette quei CVE che si applicano all'intero framework in NVD a quei componenti a cui questi CVE non si applicano. Si tratta di CVE-2012-0394, CVE-2013-2115, CVE-2014-0114, CVE-2015-0899, CVE-2015-2992, CVE-2016-1181, CVE-2016-1182, il quale Controllo Dipendenze “ha incasinato ” a struts-taglib:1.3.8 e struts-tiles-1.3.8. Questi componenti non hanno nulla a che fare con quanto descritto nel CVE: elaborazione della richiesta, convalida della pagina e così via. Ciò è dovuto al fatto che ciò che hanno in comune questi CVE e componenti è solo il framework, motivo per cui Dependency Check lo considera una vulnerabilità.
La stessa situazione è 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 rilevato molte vulnerabilità che sono effettivamente applicabili a struts2-core, che è essenzialmente un framework separato. In questo caso, Nexus IQ ha compreso correttamente il quadro e nei CVE emessi indicava che struts-core aveva raggiunto la fine della vita utile ed era necessario passare a struts2-core.
№ 6
In alcune situazioni, non è giusto interpretare un evidente errore di controllo delle dipendenze e di tracciamento delle dipendenze. In particolare CVE-2013-4152, CVE-2013-6429, CVE-2013-6430, CVE-2013-7315, CVE-2014-0054, CVE-2014-0225, CVE-2014-0225, che controlla le dipendenze e tiene traccia delle dipendenze attribuito a spring-core:3.0.5 in realtà appartiene a spring-web:3.0.5. Allo stesso tempo, alcuni di questi CVE sono stati trovati anche da Nexus IQ, tuttavia, IQ li ha identificati correttamente in un altro componente. Poiché queste vulnerabilità non sono state trovate nello spring-core, non si può sostenere che non siano presenti nel framework in linea di principio e gli strumenti open source hanno giustamente sottolineato queste vulnerabilità (ne hanno solo perse un po').
risultati
Come possiamo vedere, determinare l'affidabilità delle vulnerabilità identificate mediante revisione manuale non fornisce risultati inequivocabili, motivo per cui sorgono questioni controverse. I risultati sono che la soluzione Nexus IQ ha il tasso di falsi positivi più basso e la massima precisione.
Ciò è dovuto innanzitutto al fatto che il team Sonatype ha ampliato la descrizione di ciascuna vulnerabilità CVE di NVD nei propri database, indicando le vulnerabilità per una particolare versione dei componenti fino alla classe o alla funzione, conducendo ulteriori ricerche (ad esempio , verificando le vulnerabilità sulle versioni software precedenti).
Un'importante influenza sui risultati hanno anche quelle vulnerabilità che non sono state incluse in NVD, ma sono comunque presenti nel database Sonatype con il marchio SONATYPE. Secondo il rapporto Il 45% delle vulnerabilità open source scoperte non vengono segnalate a NVD. Secondo il database WhiteSource, solo il 29% di tutte le vulnerabilità open source segnalate al di fuori di NVD finiscono lì, motivo per cui è importante cercare le vulnerabilità anche in altre fonti.
Di conseguenza, il controllo delle dipendenze produce molto rumore, mancando alcuni componenti vulnerabili. Dependency Track produce meno rumore e rileva un gran numero di componenti, il che non danneggia visivamente gli occhi nell'interfaccia web.
Tuttavia, la pratica dimostra che l’open source dovrebbe diventare il primo passo verso un DevSecOps maturo. La prima cosa a cui dovresti pensare quando integri la SCA nello sviluppo sono i processi, vale a dire pensare insieme al management e ai dipartimenti correlati su come dovrebbero essere i processi ideali nella tua organizzazione. Potrebbe accadere che per la tua organizzazione, in un primo momento, Dependency Check o Dependency Track copriranno tutte le esigenze aziendali e le soluzioni Enterprise saranno una continuazione logica a causa della crescente complessità delle applicazioni in fase di sviluppo.
Appendice A: Risultati dei componenti
Legenda:
- Alto: vulnerabilità di livello alto e critico nel componente
- Medio: vulnerabilità di livello di criticità medio nel componente
- VERO: vero problema positivo
- FALSO: problema falso positivo
componente
QI del Nexus
Controllo delle dipendenze
Traccia delle dipendenze
risultato
dom4j: 1.6.1
Alta
Alta
Alta
TRUE
log4j-core: 2.3
Alta
Alta
Alta
TRUE
log4j: 1.2.14
Alta
Alta
-
TRUE
collezioni-comuni:3.1
Alta
Alta
Alta
TRUE
commons-fileupload:1.3.2
Alta
Alta
Alta
TRUE
commons-beanutils:1.7.0
Alta
Alta
Alta
TRUE
codec-common:1:10
Medio
-
-
TRUE
mysql-connettore-java:5.1.42
Alta
Alta
Alta
TRUE
espressione primaverile:3.0.5
Alta
componente non trovato
TRUE
primavera-web:3.0.5
Alta
componente non trovato
Alta
TRUE
contesto primaverile:3.0.5
Medio
componente non trovato
-
TRUE
nucleo a molla: 3.0.5
Medio
Alta
Alta
TRUE
struts2-config-browser-plugin:2.3.30
Medio
-
-
TRUE
primavera-tx:3.0.5
-
Alta
-
FALSO
nucleo dei montanti:1.3.8
Alta
Alta
Alta
TRUE
xwork-core: 2.3.30
Alta
-
-
TRUE
montanti2-core: 2.3.30
Alta
Alta
Alta
TRUE
struts-taglib:1.3.8
-
Alta
-
FALSO
struts-tiles-1.3.8
-
Alta
-
FALSO
Appendice B: Risultati sulla vulnerabilità
Legenda:
- Alto: vulnerabilità di livello alto e critico nel componente
- Medio: vulnerabilità di livello di criticità medio nel componente
- VERO: vero problema positivo
- FALSO: problema falso positivo
componente
QI del Nexus
Controllo delle dipendenze
Traccia delle dipendenze
Gravità
risultato
commento
dom4j: 1.6.1
CVE-2018-1000632
CVE-2018-1000632
CVE-2018-1000632
Alta
TRUE
CVE-2020-10683
CVE-2020-10683
CVE-2020-10683
Alta
TRUE
log4j-core: 2.3
CVE-2017-5645
CVE-2017-5645
CVE-2017-5645
Alta
TRUE
CVE-2020-9488
CVE-2020-9488
CVE-2020-9488
Basso
TRUE
log4j: 1.2.14
CVE-2019-17571
CVE-2019-17571
-
Alta
TRUE
-
CVE-2020-9488
-
Basso
TRUE
SONATIPO-2010-0053
-
-
Alta
TRUE
collezioni-comuni:3.1
-
CVE-2015-6420
CVE-2015-6420
Alta
FALSO
Duplica RCE(OSSINDEX)
-
CVE-2017-15708
CVE-2017-15708
Alta
FALSO
Duplica RCE(OSSINDEX)
SONATIPO-2015-0002
RCE (OSSINDICE)
RCE(OSSINDICE)
Alta
TRUE
commons-fileupload:1.3.2
CVE-2016-1000031
CVE-2016-1000031
CVE-2016-1000031
Alta
TRUE
SONATIPO-2014-0173
-
-
Medio
TRUE
commons-beanutils:1.7.0
CVE-2014-0114
CVE-2014-0114
CVE-2014-0114
Alta
TRUE
-
CVE-2019-10086
CVE-2019-10086
Alta
FALSO
La vulnerabilità si applica solo alle versioni 1.9.2+
codec-common:1:10
SONATIPO-2012-0050
-
-
Medio
TRUE
mysql-connettore-java:5.1.42
CVE-2018-3258
CVE-2018-3258
CVE-2018-3258
Alta
TRUE
CVE-2019-2692
CVE-2019-2692
-
Medio
TRUE
-
CVE-2020-2875
-
Medio
FALSO
La stessa vulnerabilità di CVE-2019-2692, ma con la nota "gli attacchi potrebbero avere un impatto significativo su altri prodotti"
-
CVE-2017-15945
-
Alta
FALSO
Non rilevante per mysql-connector-java
-
CVE-2020-2933
-
Basso
FALSO
Duplicato di CVE-2020-2934
CVE-2020-2934
CVE-2020-2934
-
Medio
TRUE
espressione primaverile:3.0.5
CVE-2018-1270
componente non trovato
-
Alta
TRUE
CVE-2018-1257
-
-
Medio
TRUE
primavera-web:3.0.5
CVE-2016-1000027
componente non trovato
-
Alta
TRUE
CVE-2014-0225
-
CVE-2014-0225
Alta
TRUE
CVE-2011-2730
-
-
Alta
TRUE
-
-
CVE-2013-4152
Medio
TRUE
CVE-2018-1272
-
-
Alta
TRUE
CVE-2020-5398
-
-
Alta
TRUE
Un esempio illustrativo 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 5.0.x come affermato nell'avviso."
CVE-2013-6429
-
-
Medio
TRUE
CVE-2014-0054
-
CVE-2014-0054
Medio
TRUE
CVE-2013-6430
-
-
Medio
TRUE
contesto primaverile:3.0.5
CVE-2011-2894
componente non trovato
-
Medio
TRUE
nucleo a molla: 3.0.5
-
CVE-2011-2730
CVE-2011-2730
Alta
TRUE
CVE-2011-2894
CVE-2011-2894
CVE-2011-2894
Medio
TRUE
-
-
CVE-2013-4152
Medio
FALSO
Duplicato della stessa vulnerabilità in spring-web
-
CVE-2013-4152
-
Medio
FALSO
La vulnerabilità riguarda il componente spring-web
-
CVE-2013-6429
CVE-2013-6429
Medio
FALSO
La vulnerabilità riguarda il componente spring-web
-
CVE-2013-6430
-
Medio
FALSO
La vulnerabilità riguarda il componente spring-web
-
CVE-2013-7315
CVE-2013-7315
Medio
FALSO
SPLIT da CVE-2013-4152. + La vulnerabilità riguarda il componente spring-web
-
CVE-2014-0054
CVE-2014-0054
Medio
FALSO
La vulnerabilità riguarda il componente spring-web
-
CVE-2014-0225
-
Alta
FALSO
La vulnerabilità riguarda il componente spring-web
-
-
CVE-2014-0225
Alta
FALSO
Duplicato della stessa vulnerabilità in spring-web
-
CVE-2014-1904
CVE-2014-1904
Medio
FALSO
La vulnerabilità riguarda il componente spring-web-mvc
-
CVE-2014-3625
CVE-2014-3625
Medio
FALSO
La vulnerabilità riguarda il componente spring-web-mvc
-
CVE-2016-9878
CVE-2016-9878
Alta
FALSO
La vulnerabilità riguarda il componente spring-web-mvc
-
CVE-2018-1270
CVE-2018-1270
Alta
FALSO
Per espressioni primaverili/messaggi primaverili
-
CVE-2018-1271
CVE-2018-1271
Medio
FALSO
La vulnerabilità riguarda il componente spring-web-mvc
-
CVE-2018-1272
CVE-2018-1272
Alta
TRUE
CVE-2014-3578
CVE-2014-3578 (OSSINDEX)
CVE-2014-3578
Medio
TRUE
SONATIPO-2015-0327
-
-
Basso
TRUE
struts2-config-browser-plugin:2.3.30
SONATIPO-2016-0104
-
-
Medio
TRUE
primavera-tx:3.0.5
-
CVE-2011-2730
-
Alta
FALSO
La vulnerabilità non è specifica di spring-tx
-
CVE-2011-2894
-
Alta
FALSO
La vulnerabilità non è specifica di spring-tx
-
CVE-2013-4152
-
Medio
FALSO
La vulnerabilità non è specifica di spring-tx
-
CVE-2013-6429
-
Medio
FALSO
La vulnerabilità non è specifica di spring-tx
-
CVE-2013-6430
-
Medio
FALSO
La vulnerabilità non è specifica di spring-tx
-
CVE-2013-7315
-
Medio
FALSO
La vulnerabilità non è specifica di spring-tx
-
CVE-2014-0054
-
Medio
FALSO
La vulnerabilità non è specifica di spring-tx
-
CVE-2014-0225
-
Alta
FALSO
La vulnerabilità non è specifica di spring-tx
-
CVE-2014-1904
-
Medio
FALSO
La vulnerabilità non è specifica di spring-tx
-
CVE-2014-3625
-
Medio
FALSO
La vulnerabilità non è specifica di spring-tx
-
CVE-2016-9878
-
Alta
FALSO
La vulnerabilità non è specifica di spring-tx
-
CVE-2018-1270
-
Alta
FALSO
La vulnerabilità non è specifica di spring-tx
-
CVE-2018-1271
-
Medio
FALSO
La vulnerabilità non è specifica di spring-tx
-
CVE-2018-1272
-
Medio
FALSO
La vulnerabilità non è specifica di spring-tx
nucleo dei montanti:1.3.8
-
CVE-2011-5057 (OSSINDEX)
Medio
FASILE
Vulnerabilità agli Struts 2
-
CVE-2012-0391 (OSSINDEX)
CVE-2012-0391
Alta
FALSO
Vulnerabilità agli Struts 2
-
CVE-2014-0094 (OSSINDEX)
CVE-2014-0094
Medio
FALSO
Vulnerabilità agli Struts 2
-
CVE-2014-0113 (OSSINDEX)
CVE-2014-0113
Alta
FALSO
Vulnerabilità agli Struts 2
CVE-2016-1182
3VE-2016-1182
-
Alta
TRUE
-
-
CVE-2011-5057
Medio
FALSO
Vulnerabilità agli Struts 2
-
CVE-2012-0392 (OSSINDEX)
CVE-2012-0392
Alta
FALSO
Vulnerabilità agli Struts 2
-
CVE-2012-0393 (OSSINDEX)
CVE-2012-0393
Medio
FALSO
Vulnerabilità agli Struts 2
CVE-2015-0899
CVE-2015-0899
-
Alta
TRUE
-
CVE-2012-0394
CVE-2012-0394
Medio
FALSO
Vulnerabilità agli Struts 2
-
CVE-2012-0838 (OSSINDEX)
CVE-2012-0838
Alta
FALSO
Vulnerabilità agli Struts 2
-
CVE-2013-1965 (OSSINDEX)
CVE-2013-1965
Alta
FALSO
Vulnerabilità agli Struts 2
-
CVE-2013-1966 (OSSINDEX)
CVE-2013-1966
Alta
FASILE
Vulnerabilità agli Struts 2
-
CVE-2013-2115
CVE-2013-2115
Alta
FASILE
Vulnerabilità agli Struts 2
-
CVE-2013-2134 (OSSINDEX)
CVE-2013-2134
Alta
FASILE
Vulnerabilità agli Struts 2
-
CVE-2013-2135 (OSSINDEX)
CVE-2013-2135
Alta
FASILE
Vulnerabilità agli Struts 2
CVE-2014-0114
CVE-2014-0114
-
Alta
TRUE
-
CVE-2015-2992
CVE-2015-2992
Medio
FALSO
Vulnerabilità agli Struts 2
-
CVE-2016-0785 (OSSINDEX)
CVE-2016-0785
Alta
FALSO
Vulnerabilità agli Struts 2
CVE-2016-1181
CVE-2016-1181
-
Alta
TRUE
-
CVE-2016-4003 (OSSINDEX)
CVE-2016-4003
Alta
FALSO
Vulnerabilità agli Struts 2
xwork-core:2.3.30
CVE-2017-9804
-
-
Alta
TRUE
SONATIPO-2017-0173
-
-
Alta
TRUE
CVE-2017-7672
-
-
Alta
FALSO
Duplicato di CVE-2017-9804
SONATIPO-2016-0127
-
-
Alta
TRUE
puntoni2-core:2.3.30
-
CVE-2016-6795
CVE-2016-6795
Alta
TRUE
-
CVE-2017-9787
CVE-2017-9787
Alta
TRUE
-
CVE-2017-9791
CVE-2017-9791
Alta
TRUE
-
CVE-2017-9793
-
Alta
FALSO
Duplicato di CVE-2018-1327
-
CVE-2017-9804
-
Alta
TRUE
-
CVE-2017-9805
CVE-2017-9805
Alta
TRUE
CVE-2016-4003
-
-
Medio
FALSO
Applicabile ad Apache Struts 2.x fino a 2.3.28, ovvero la versione 2.3.30. Tuttavia, in base alla descrizione, il CVE è valido per qualsiasi versione di Struts 2 se viene utilizzato JRE 1.7 o inferiore. Apparentemente hanno deciso di riassicurarci qui, ma sembra più FALSO
-
CVE-2018-1327
CVE-2018-1327
Alta
TRUE
CVE-2017-5638
CVE-2017-5638
CVE-2017-5638
Alta
TRUE
La stessa vulnerabilità sfruttata dagli hacker di Equifax nel 2017
CVE-2017-12611
CVE-2017-12611
-
Alta
TRUE
CVE-2018-11776
CVE-2018-11776
CVE-2018-11776
Alta
TRUE
struts-taglib:1.3.8
-
CVE-2012-0394
-
Medio
FALSO
Per puntoni2-core
-
CVE-2013-2115
-
Alta
FALSO
Per puntoni2-core
-
CVE-2014-0114
-
Alta
FALSO
Per commons-beanutils
-
CVE-2015-0899
-
Alta
FALSO
Non si applica a taglib
-
CVE-2015-2992
-
Medio
FALSO
Si riferisce a struts2-core
-
CVE-2016-1181
-
Alta
FALSO
Non si applica a taglib
-
CVE-2016-1182
-
Alta
FALSO
Non si applica a taglib
struts-tiles-1.3.8
-
CVE-2012-0394
-
Medio
FALSO
Per puntoni2-core
-
CVE-2013-2115
-
Alta
FALSO
Per puntoni2-core
-
CVE-2014-0114
-
Alta
FALSO
Sotto commons-beanutils
-
CVE-2015-0899
-
Alta
FALSO
Non si applica alle piastrelle
-
CVE-2015-2992
-
Medio
FALSO
Per puntoni2-core
-
CVE-2016-1181
-
Alta
FALSO
Non si applica a taglib
-
CVE-2016-1182
-
Alta
FALSO
Non si applica a taglib
Fonte: habr.com