Software bill of materials: strumenti e analisi di progetti open source dell’amministrazione pubblica

Software bill of materials: strumenti e analisi di progetti open source
dell’amministrazione pubblica
Tesi Magistrale in Ingegneria Elettronica e Informatica
Studente:
Federico Boni
Relatore:
Prof. Alberto Bartoli
21 Novembre 2022
Federico Boni Università degli Studi di Trieste
1 / 28

Introduzione Dati Metodologia Criticità Risultati e analisi Conclusioni Domande aperte e lavori futuri
Supply Chain
Definizione
Si definisce Supply Chain di un software l’insieme di elementi
coinvolti durante il ciclo di vita del software stesso.
Gli elementi della Supply Chain possono essere strumenti di
sviluppo, package manager, librerie...
L’utilizzo di librerie di terze parti favorisce il riuso del codice.
2 / 28

Vulnerabilità
Un software è soggetto alla presenza di vulnerabilità.
Vulnerabilità negli elementi della Supply Chain si riflettono
in potenziali rischi per il software.
Identificare gli elementi della Supply Chain è importante per
un’organizzazione.
L’Executive Order 266471
sottolinea l’importanza della
tracciabilità degli elementi della Supply Chain.
1
Presidential Document 26647, 2021-10460. Executive Order on Improving the Nation’s
Cybersecurity. Mag. 2021.
3 / 28

Software Bill of Materials
Definizione
Il termine Software Bill of Materials o SBoM indica un registro
formale contenente dettagli e relazioni degli elementi della Supply
Chain utilizzati nella costruzione del software.
File SBoM machine readable permettono di analizzare
dipendenze e vulnerabilità programmaticamente.
Esistono diversi standard SBoM, come CycloneDX o SPDX.
4 / 28

Software Bill of Materials
Esempio di SBoM in formato json (standard SPDX 2.2):
1 {
2 "SPDXID": "SPDXRef-DOCUMENT",
3 "name": "SBOM-SPDX-2d85f548-12fa-46d5-87ce-5e78e5e111f4",
4 "spdxVersion": "SPDX-2.2",
5 "dataLicense": "CC0-1.0",
6 "packages": [{
7 "SPDXID": "SPDXRef-Package-hello-server-src",
8 "name": "hello-server-src",
9 "versionInfo": "0.1.0",
10 "licenseDeclared": "Apache-2.0",
11 "externalRefs": [{
12 "referenceCategory": "PACKAGE-MANAGER",
13 "referenceLocator": "pkg:deb/debian/libselinux1-dev@3.1-3",
14 "referenceType": "purl"
15 }]
16 }]
17 ...
18 }
5 / 28

SBoM - Strumenti
Microsoft sbom-tool (creazione):
Input: folder con sorgenti.
Output: SBoM in formato json (standard SPDX 2.2).
Dipendenze sono pacchetti di ecosistemi di linguaggi di
programmazione2
.
Dipendenze estratte dai manifest.
A seconda dell’ecosistema, le dipendenze sono solo dirette o
anche transitive.
Grype (analisi):
Input: SBoM nei formati SPDX, CycloneDX.
Output: vulnerabilità dei componenti specificati nei file SBoM.
2
Ecosistemi: CocoaPods, Conda, Gradle, Go, Maven, npm, Yarn, NuGet, PyPi,
Poetry, Ruby, Cargo.
6 / 28

Obbiettivi
Questo lavoro si pone i seguenti obbiettivi:
Comprendere caratteristiche e limiti degli strumenti di
creazione e analisi di file SBoM.
Analizzare dipendenze e potenziali vulnerabilità di
progetti Open Source dell’amministrazione pubblica di diversi
paesi.
7 / 28

Amministrazione pubblica e GitHub
La pagina GitHub & Government3
contiene una lista di
organizzazioni GitHub di agenzie governative.
La lista viene scaricata l’11 Ottobre 2022.
Se possibile, ad un organizzazione viene associato un Paese.
Si trovano 73 Paesi con almeno una organizzazione e 102
organizzazioni non associate ad alcun Paese.
3
GitHub e Government. https://government.github.com/community.
8 / 28

Paesi e repository GitHub
Figura 1: Numero di repository per i primi 16 Paesi per numero di organizzazioni.
Il primo Paese ha quasi il doppio delle repository del secondo.
9 / 28

Dataset
Si costruiscono 4 dataset:
Dataset IT: repository del Paese Italia (713).
Dataset DE: repository del Paese Germania (1 308).
Dataset UK: repository del Paese U.K.4
(1 563).
Dataset US: repository del Paese U.S.5
(937).
4
Solo repository dell’organizzazione alphagov
5
Solo repository dell’organizzazione GSA
10 / 28

Dataset - Linguaggi
(a) IT (b) DE
Figura 2: Distribuzione dei linguaggi delle repository per i dataset IT e DE.
11 / 28

Dataset - Linguaggi
(a) UK (b) US
Figura 3: Distribuzione dei linguaggi delle repository per i dataset UK e US.
12 / 28

Metodologia
Costruzione SBoM e raccolta dipendenze
Per ogni repository dei 4 dataset:
1 Download da GitHub.
2 Esecuzione sbom-tool → raccolta dipendenze come tuple
(repository, pacchetto, versione).
3 Raccolta dipendenze da istruzioni di importazione (solo
repository Python e JavaScript).
Dalle istruzioni di importazione si ottengono dipendenze non
ottenibili da sbom-tool perché non presenti nei file manifest.
13 / 28

Metodologia
Costruzione SBoM e raccolta dipendenze
Per ogni repository, si ottengono dipendenze:
Manifest: dipendenze da sbom-tool.
Parsed: dipendenze da istruzioni di importazione.
Dipendenze Python parsed sono anche dipendenze transitive.
14 / 28

Metodologia
Raccolta vulnerabilità
Si ottengono poi 3 set di vulnerabilità da:
2 esecuzioni di Grype con parametri differenti.
Utilizzo delle API di OSV6
.
Vengono utilizzate solo le vulnerabilità presenti in tutti e 3 i set.
6
OSV. A distributed vulnerability database for Open Source. https://osv.dev/.
15 / 28

Criticità
Dipendenze condizionali
Una dipendenza si dice condizionale se la sua presenza
dipendende da una condizione sul sistema.
Il formato SPDX 2.2 non supporta la descrizione di
dipendenze condizionali.
Nel gestire le dipendenze condizionali, sbom-tool si comporta
diversamente in base all’ecosistema.
16 / 28

Criticità
Vincoli di versione
Gli standard SBoM richiedono versioni specificate con
precisione.
Alcuni manifest permettono la specifica di intervalli.
requirements.txt
tensorflow-gpu >= 2.9.0
sbom-tool fissa le versioni di tipo ’≥’ all’ultima versione pubblicata
al momento della costruzione dello SBoM.
17 / 28

Criticità
Vulnerabilità Java
L’utilizzo di Grype con SBoM di sbom-tool non permette di trovare
vulnerabilità di pacchetti Java.
Queste vulnerabilità sono presenti nel database di Grype.
Utilizzando il database di Grype, le vulnerabilità vengono
aggiunte programmaticamente.
18 / 28

Risultati e analisi
Dipendenze
(a) IT (b) DE
Figura 4: Distribuzione delle dipendenze per i dataset IT e DE.
Le dipendenze JavaScript (npm) sono la maggioranza.
19 / 28

Risultati e analisi
Dipendenze
(a) UK (b) US
Figura 5: Distribuzione delle dipendenze per i dataset UK e US.
Il 17.7% delle dipendenze UK sono dipendenze Ruby (gem).
20 / 28

Risultati e analisi
Dipendenze
Figura 6: Distribuzione
della percentuale di
repository x con
almeno y dipendenze.
Quasi il 20% delle
repository
JavaScript ha più di
1 000 dipendenze.
21 / 28

Risultati e analisi
Dipendenze
JavaScript Python
Dataset man. par. tot. man. par. tot.
IT 5.93 3.14 7.33 10.77 16.84 22.56
DE 27.4 9.95 30.89 11.62 12.76 17.51
UK 22.34 6.28 24.26 20.71 16.16 25.08
US 12.74 7.16 15.18 6.73 6.90 10.77
Tabella 1: Percentuale di repository con almeno una dipendenza.
Nel dataset IT solo il 7% delle repository JavaScript hanno una
dipendenza.
Nei dataset IT e UK più del 16% delle repository Python hanno
dipendenze non trovate da sbom-tool.
22 / 28

Risultati e analisi
Vulnerabilità
Figura 7: Repository con almeno una vulnerabilità High o Critical.
Il 40% delle repository UK ha una o più vulnerabilità High o Critical7
.
Le percentuali unresolved sono di poco inferiori a quelle all.
7
Le vulnerabilità sono categorizzate dal sistem CVSS.
23 / 28

Risultati e analisi
Vulnerabilità
Package manager Vulnerable pairs (%)
pypi 7.35
npm 3.23
maven 8.23
gem 11.44
Tabella 2: Percentuale di coppie pacchetto-versione vulnerabili.
Solo il 3% delle coppie JavaScript sono vulnerabili.
Pochi pacchetti sono responsabili di tutte le repository
potenzialmente vulnerabili.
24 / 28

Risultati e analisi
Vulnerabilità
Vulnerability ID Severity Package Repos. (%)
CVE-2022-3517 High minimatch (npm) 443 (9.80)
CVE-2021-43809 High bundler (gem) 392 (8.67)
CVE-2021-44906 Critical minimist (npm) 374 (8.27)
GHSA-2qc6-mcvw-92cw Medium nokogiri (gem) 351 (7.76)
CVE-2020-28469 High glob-parent (npm) 303 (6.70)
CVE-2020-36327 High bundler (gem) 276 (6.10)
CVE-2021-3918 Critical json-schema (npm) 263 (5.81)
CVE-2022-30122 Medium rack (gem) 263 (5.81)
CVE-2022-30123 High rack (gem) 263 (5.81)
CVE-2022-29181 High nokogiri (gem) 260 (5.75)
Tabella 3: Prime 10 vulnerabilità per numero di repository potenzialmente vulnerabili.
Il 20% di tutte le repository è potenzialmente vulnerabile a causa di
almeno una delle vulnerabilità evidenziate in tabella.
25 / 28

Conclusioni
JavaScript è il linguaggio con più dipendenze trovate fra tutti i
dataset.
Il 40% delle repository UK hanno almeno una vulnerabilità
High o Critical.
Pochi pacchetti sono responsabili di tutte le repository
potenzialmente vulnerabili.
3 vulnerabilità rendono potenzialmente vulnerabili il 20% di
tutte le repository.
26 / 28

Conclusioni
Non è stato possibile definire una procedura per la creazione e
l’analisi degli SBoM per una repository GitHub che sia:
Accurata: Pacchetti senza versione precisa sono inseriti con
l’ultima versione pubblicata alla creazione dello SBoM.
Consistente: fra ecosistemi differenti; le dipendenze
condizionali non sono gestite allo stesso modo.
Completa: partendo da uno SBoM, le vulnerabilità dei
pacchetti Java non vengono trovate.
27 / 28

Domande aperte e lavori futuri
Capire il reale impatto di una potenziale vulnerabiità di una
repository GitHub.
Comprendere se i gestori di una repository siano a
conoscenza delle potenziali vulnerabilità e del loro impatto.
Studiare il ciclo di vita di una vulnerabilità rispetto alle date
dei commit di una repository.
Studiare le motivazioni dietro alle differenze sul numero di
vulnerabilità fra repository.
28 / 28

Appendice
Paesi e organizzazioni GitHub
Figura 8: Numero di organizzazioni GitHub per i primi 16 Paesi per numero di organizzazioni.
Stati Uniti e Regno Unito sono i Paesi con più organizzazioni GitHub.

Appendice
Dipendenze da istruzioni di importazione
Per le dipendenze da istruzioni di importazione:
Se la repository è una repository Javascript:
Esecuzione check-imports8
.
Dipendenze collezionate programmaticamente.
Se la repository è una repository Python:
Esecuzione pipreqsnb9
.
Dipendenze aggiunte in requirements.txt.
Esecuzione di sbom-tool.
8
Finom. check-imports 0.1.12. https://www.npmjs.com/package/check-imports.
9
Ivan Lengyel. pipreqsnb 0.2.4. https://pypi.org/project/pipreqsnb/.

Appendice
Vulnerabilità Grype
Si ottengono 2 set di vulnerabilità utilizzando Grype:
grype - Esecuzione di Grype su ogni SBoM.
grype_cpe - Esecuzione di Grype su ogni SBoM.
Parametro add-cpe-if-none.
Grype assegna nome CPE10
ai pacchetti.
Il set grype è un sottoinsieme del set grype_cpe.
10
Common Platform Enumeration System. https://cpe.mitre.org.

Appendice
Vulnerabilità
Il sistema CVSS11
assegna a una vulnerabilità una severità da 0 a
10:
Basata su caratteristiche intrinsiche.
Composta dalle metriche Exploitability e Impact.
Lo stesso sistema categorizza poi le vulnerabilità come segue:
Low: severità in [0.1; 3.9]
Medium: severità in [4.0; 6.9]
High: severità in [7.0; 8.9]
Critical: severità in [9.0; 10.0]
11
CVSS System. https://nvd.nist.gov/vuln-metrics/cvss.

Software bill of materials: strumenti e analisi di progetti open source dell’amministrazione pubblica

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Software bill of materials: strumenti e analisi di progetti open source dell’amministrazione pubblica

Similar a Software bill of materials: strumenti e analisi di progetti open source dell’amministrazione pubblica (20)

Software bill of materials: strumenti e analisi di progetti open source dell’amministrazione pubblica