UNIVERSITÀ DEGLI STUDI DI TRIESTE

Dipartimento di Ingegnerie e Architettura

Corso di Studi in Ingegneria Elettronica ed Informatica

Analisi statica: uso di SonarQube per la valu-

tazione del grado di sicurezza di una
web application

Laureando: Relatore:
Yvan Joriel Prof. Alberto BARTOLI
NGOUFACK BONING Correlatore:
PhD Marco D’ORLANDO

ANNO ACCADEMICO 2021/2022

1
 Le battaglie della vita non sono vinte dai più forti o dai più bravi,
ma da coloro che non mollano mai!

2
Indice

1 INTRODUZIONE ......................................................................................................... 4
2 Descrizione della web application oggetto di analisi .................................................... 6
2.1 L’applicazione Project ............................................................................................ 6
2.2 Tecnologie di sviluppo ............................................................................................ 7
2.2.1 Project Front-End ............................................................................................ 7
2.2.2 Project Back-End ............................................................................................. 8
2.3 Tecnologie di supporto ........................................................................................... 8
3 Analisi statica ................................................................................................................ 9
3.1 Vantaggi della SAST Analysis................................................................................ 9
3.2 Svantaggi della SAST Analysis ............................................................................ 10
3.3 Tecniche di analisi ................................................................................................ 10
4 SonarQube ................................................................................................................... 11
4.1 Descrizione ........................................................................................................... 11
4.2 Funzionalità .......................................................................................................... 11
4.2.1 Rules .............................................................................................................. 11
4.2.2 Issues ............................................................................................................. 12
4.2.3 Rating ............................................................................................................ 12
4.3 OWASP ................................................................................................................ 13
4.3.1 OWASP Top 10 e SonarQube ....................................................................... 14
5 Analisi statica del codice della web application con SonarQube ................................ 15
5.1 Aggiunta del progetto da GitLab .......................................................................... 15
5.2 Analisi Statica del codice ...................................................................................... 17
5.2.1 Risultati e risoluzione dei problemi ............................................................... 17
5.2.1.1 Security Hotspot ..................................................................................... 18
5.2.1.2 Bugs........................................................................................................ 23
5.2.1.3 Code Smell ............................................................................................. 24
5.2.2 Riepilogo ....................................................................................................... 28
6 Conclusioni .................................................................................................................. 29
7 Riferimenti ................................................................................................................... 30
8 Ringraziamenti ............................................................................................................ 31

3
1 INTRODUZIONE

L' analisi statica è una tecnica di testing software che consente l’analisi del codice di un
software attraverso un processo di valutazione basato sulla struttura, la forma e il conte-
nuto del codice sorgente.
L’obiettivo di questa tesi svolta preso YOROI S.R.L. è stato quello di misurare attraverso dei
meccanismi di analisi statica il livello di sicurezza del codice sorgente di una applicazione
utilizzata all’interno dell’azienda. L’obiettivo è stato altresì quello di apportare le modifiche
necessarie al codice sorgente applicativo al fine di renderlo più robusto e sicuro.
Attualmente, la tecnica di test usata per la valutazione è quella dinamica. Questa tecnica
presenta dei limiti, ad esempio i test impiegano molto tempo, c’è la necessità di eseguire il
codice del software per poter procedere ai test, sono relativamente costosi, e si esegue in
fase di validazione.
L’uso di strumenti automatici per l’analisi statica permette di rilevare problemi sul codice
sorgente senza necessità di eseguirlo e in certi casi si possono identificare e risolvere
problemi suscettibili di causare problemi durante l’esecuzione perciò è meno costosa, più
efficace e richiede meno tempo; anche al livello di rilevazione di bug e vulnerabilità
l'analisi statica consente di raggiungere un buon livello di copertura delle dichiarazioni al
contrario dei test dinamiche verificano solo le parti del software che vengono effettivamente
eseguitenei test.
Ad oggi, adottare anche l’analisi statica come metodo per migliorare il software è di grande
interesse per gli sviluppatori perché di fronte alla crescita esponenziale delle minacce alla
sicurezza dei software e i rischi legati al furto di informazioni sensibili, il codice deve essere
sicuro, affidabile e robusto e prima si individuano le anomalie più facile sarà porne rimedio.
Per poter portare avanti l’attività, il laureando ha valutato le tecnologie utilizzate per lo
sviluppo del software applicativo, dopodiché utilizzando SonarQube come strumento di
analisi statica del codice è stato eseguito dal laureando un primo test, di cui i risultati
hanno per- messo di individuare vulnerabilità, debito tecnico ed altre anomalie presenti
nel codice.
Successivamente è stato fatto un refactoring manuale del codice stesso al fine di risolvere
alcune delle anomalie più critiche emerse, poi è stata fatta un’analisi ulteriore che ha per-
messo la verifica del rientro delle anomalie.
4
Il documento è strutturato come segue:
• Capitolo 2: descrizione della web application oggetto di analisi;
• Capitolo 3: analisi statica;
• Capitolo 4: lo strumento SonarQube;
• Capitolo 5: analisi statica del codice della web application con SonarQube;
• Conclusioni;
• Riferimenti;
• Ringraziamenti

5
2 Descrizione della web application oggetto di
analisi

2.1 L’applicazione Project

Project è una web application usata dai BU Manager di YOROI S.R.L per controllare lo stato
di avanzamento delle commesse di loro pertinenza. A ogni progetto viene associato un va-
lore economico e un numero di giornate per essere erogato e l’applicazione Project con-
sente di valutare gli stati di avanzamento. È un’applicazione sviluppata internamente e viene
utilizzata per estrarre dati e ottenere viste di sintesi mettendo in comunicazione altri
prodotti software interni utilizzati da altri reparti.
L’applicazione raccoglie dati al suo interno integrandosi con diversi sistemi informativi in-
terni e in particolare:
• L’applicazione web di Zucchetti [1] utilizzata da tutti i dipendenti per la rendiconta-
zione settimanale delle ore lavorate sulle diverse commesse o WBS (Work Break-
down Structure);
• SageX3 il software applicativo interno di riferimento dell’Ammistrazione e utilizzato
da Projects per estrarre i valori economici delle commesse o WBS;
• SugarCRM lo strumento interno utilizzato dai Commerciali per tracciare gli ordini
che dovranno essere associati poi alle commesse (WBS) per dare avvio al processo
di delivery o implementazione.
L’applicazione Projects ha diversi componenti che possono essere così raggruppati:
• External Integrations: raccoglie dei microservizi che consentono, attraverso
l’integrazione con i sistemi informativi precedenti, di estrarre giornalmente alcuni
dati salvandoli su un DB locale accessibile all‘applicazione web di Project stesso.
Durante il tirocinio questi componenti non sono stato oggetto di analisi ma
vengono citati

6
 solo al fine di comprendere meglio l’architettura applicativa;
• Front End: rappresenta la parte grafica dell’applicazione web di Project che permette
di visualizzare sul browser delle viste di sintesi con i risultati delle rendicontazioni
delle ore spese sulle diverse WBS;
• Back End: rappresenta l’applicazione stessa lato server che riceve le richieste di dati
dal Front End e con la logica applicativa implementata raccoglie i dati dal DB e li
restituisce all’utente finale.

2.2 Tecnologie di sviluppo

L’applicazione Project è implementata come una Single Page Application (SPA) per dare una
efficace esperienza all’utente finale. Essendo una SPA tutto il codice necessario, come per
esempio quello HTML, JavaScript e CSS viene caricato a partire dalle indicazioni sulla pagina
html principale. Una volta inclusi e scaricati dal browser tutti i JS e CSS l’intera applicazione
è disponibile sull’interfaccia del browser. Le ulteriori interazioni con il Back End riguardano
solamente la richiesta di popolamento di tabelle attraverso specifiche chiamate di tipo HTTP
JSON.

2.2.1 Project Front-End

La parte di interfaccia grafica è sviluppata utilizzando le seguenti tecnologie:

• AngularJS [2]: è una tecnologia molto utilizzata ed è quella su cui si basa il front-
end dell’applicazione Projects;
• TypeScript [3]: è stato usato come linguaggio per la definizione della logica del
front-end applicativo;
• HTML/CSSS: utilizzati per la struttura e la grafica della applicazione finale.

7
2.2.2 Project Back-End

Il Back-End invece utilizza:

• Flask: il back end era stato implementato in Flask storicamente;

• Sqlite3: è stato utilizzato come base dati.

2.3 Tecnologie di supporto

Come IDE di sviluppo è stato utilizzato Visual Studio Code per tutta l’attività di analisi e in-
tegrazione del codice sorgente del front-end dell’applicazione visto che il suo supporto ai
linguaggi TypeScript, JavaScript, HTML, CSS e JSON lo rendeva lo strumento migliore per lo
sviluppo di applicazioni basate su Angular.

8
3 Analisi statica

Secondo il Forrester Report del 2021 sullo stato della sicurezza delle applicazioni [4], com-
missionato dalla Palo Alto Networks, nel 2020 due attacchi informatici su tre provenienti da
fonti esterne sono stati condotti sfruttando anomalie sulle applicazioni web (39% dei casi)
o sfruttando vulnerabilità del software (30% dei casi).
Di fronte a queste statistiche è fondamentale poter individuare tempestivamente le vulne-
rabilità di sicurezza presenti nel codice delle applicazioni web. È importante che le anomalie
vengano segnalate e resi esplicite agli sviluppatori fin dall’inizio del progetto in modo da
consentire la diffusione della cultura del secure coding.
Per lo svolgimento del nostro lavoro, si è deciso di fronteggiare questa problematica di vul-
nerabilità attraverso una tecnica di analisi del codice, principalmente quella statica SAST
(Static Application Security Testing).

3.1 Vantaggi della SAST Analysis

La SAST è caratterizzata dal fatto che può essere fatta senza la necessità di eseguire
programma, a differenza della DAST (Dynamic Application Security Testing), che invece
analizza l’effettivo comportamento del codice a run-time. L’assenza di una necessità di
esecuzione presenta l’innegabile beneficio di poter condurre i test in una fase molto
precoce del ciclo di vita dello sviluppo, e di poter dunque traslare indietro nel tempo
l’individuazione di eventuali vulnerabilità. Alla luce del nostro obiettivo questo era un
vantaggio significativo in ter- mini sia di sviluppo sicuro che di correzione: secondo il NIST
(National Institute of Standards and Technologies), correggere una vulnerabilità una volta
che il codice è in produzione può costare fino a 6 volte rispetto a sistemare una
vulnerabilità scoperta durante le prime fasi dello sviluppo [5].
Tuttavia, è stato notato anche qualche svantaggio.

9
3.2 Svantaggi della SAST Analysis

Durante lo svolgimento dell’attività è emerso il problema della mancanza di contesto ovvero

che l’analisi statica prende solo in considerazione il comportamento del programma non
tenendo conto delle intenzioni dello sviluppatore. Alla luce di alcuni esiti dalle analisi è stato
notato che la SAST sia soggetta all’individuazione di falsi positivi (di cui alcuni esempi sono
stati riportati nel capitolo 5), ossia al fatto che vengono riportate vulnerabilità che, a una
revisione umana, si rivelano essere non rilevanti. In questo senso si è inteso l’analisi statica
come un’attività non totalmente automatizzabile, poiché sono stati necessari controlli
manuali per la finalizzazione.

3.3 Tecniche di analisi

L’altro punto importante offerto dall’analisi statica è la grande diversità di tecniche [6] di
analisi e in base alle nostre esigenze, sono state scelte quattro per lo svolgimento della
nostra attività:
• L’analisi lessicale: è stato utile per la pulizia del codice dai commenti, e la valutazione
della conformità a livello lessicale;
• L’analisi strutturale: è servito nell’esaminare delle strutture specifiche del
linguaggio, e nell’identificazione delle vulnerabilità nel design, nella dichiarazione o
nell’uso di variabili e funzioni, e nella verifica delle inconsistenze rispetto a pratiche
di programmazione sicura;
• Il control-Flow Analysis: è stato di aiuto per il controllo dell’ordine delle operazioni
eseguite, permettendo ad esempio di individuare vulnerabilità nella trasmissione
dei cookies, configurazioni errate prima dell’utilizzo di una variabile, variabili non
inizializzate;
• Il data-Flow Analysis: ha permesso di individuare i punti nel codice in cui si
sarebbero immessi dati non validati.

10
4 SonarQube

In questo capitolo verrà fatta una breve descrizione dello strumento e delle funzionalità che
ci sono state di aiuto durante lo svolgimento del lavoro. Durante lo studio dell’uso dello
strumento si è notato che avere risultati ottimali dai test di sicurezza c’è bisogno di sfruttare
la possibilità che offre lo strumento di integrare plugin. In questo capitolo verrà fatta una
discussione su un plugin di security sviluppato da OWASP ch’è stato integrato allo
strumento.

4.1 Descrizione

SonarQube [7] è uno strumento di analisi statica del codice utile per identificare
vulnerabilità, duplicazioni di codice e bug. L’idea principale è avere uno strumento per
mantenere traccia dei progressi e dei risultati rispetto alle metriche di qualità al fine di
tenere sotto controllo il debito tecnico.
SonarQube utilizza il modello SQALE [8](20/47) (Software Quality Assessment based on Li-
fecycle Expectations) per la valutazione della qualità. Esso permette di definire cosa crea
debito tecnico, lo stima ed offre delle strategie di rientro basate sulla priorità per stabilire
un piano di rientro.

4.2 Funzionalità

4.2.1 Rules

Per analizzare il codice SonnarQube fornisce delle regole (rules) che sono classificate per
rilevare quattro tipologie di anomalie:

11
 • code smell: rientrano nelle caratteristiche che indicano un difetto di programma-
zione ma non rivelano degli errori e dunque non influiscono sull’effettiva correttezza
del software, ma rendono il codice poco mantenibile;
• i bug: sono errori da cui dipende un comportamento inaspettato o incorretto del
programma, riducono l’affidabilità del programma stesso e devono essere corretti
se confermati;
• le vulnerabilità: sono delle debolezze che possono essere sfruttate per
compromettere il livello di sicurezza del sistema;
• i security hotspot sono delle debolezze che non sono problematiche, ma potrebbero
diventare delle vulnerabilità se non vanno sanate.

4.2.2 Issues

Durante l’analisi, vengono definiti delle issues ogni qualvolta un frammento di codice in-
frange una regola.
Ad ogni issue è legato un livello diverso di gravità (Severity): Blocker, Critical, Major, Minor
e può assumere cinque stati: subito dopo la sua creazione (open), una issue diventa confer-
mata (confirmed) quando l’utente indica che il problema è valido. Una issue è risolta (resol-
ved) quando l’utente indica che nella prossima analisi non dovrebbe essere considerata
nuovamente perché sono state apportate modifiche, riaperta (reopened) quando il pro-
blema è stato indicato come risolto ma non è stato veramente corretto. Una issue è chiusa
(closed) quando SonarQube non lo riconosce più l’anomalia come un problema. Un pro-
blema viene chiuso quando è stato corretto (fixed) o perché la relativa regola che lo ricono-
sce non è più disponibile (removed).

4.2.3 Rating

Le metriche utilizzate per definire la qualità del codice sono la complessità, la duplicazione,
la manutenibilità, l’affidabilità, la sicurezza, la dimensione e la copertura dei test.
Alle metriche viene assegnata una valutazione (rating) come segue.

12
Rating affidabilità
A = 0 bug
B = almeno un minor bug
C = almeno un major bug
D = almeno un critical bug
E = almeno un blocker bug
Rating sicurezza
A = 0 vulnerabilità
B = almeno una minor vulnerabilità
C = almeno una major vulnerabilità
D = almeno una critical vulnerabilità
E = almeno una blocker vulnerabilità
Rating debito tecnico: dipende dal "Technical Debt Ratio" (TD ratio) che è il rapporto tra il
debito tecnico (metafora per descrivere le possibili complicazioni che subentrano in un
progetto) e il tempo stimato per lo sviluppo della correzione:
A = TD ratio <= 5%
B = TD ratio tra il 6 e il 10%
C = TD ratio tra il 10 e il 20%
D = TD ratio tra il 21 e il 50%
E = TD ratio >= 50%

4.3 OWASP

L’Open Web Application Security Project (OWASP) è un’iniziativa internazionale open-

source no-profit con lo scopo di realizzare mantenere e diffondere attraverso la linea guida
e strumenti pratici utili a supportare gli sviluppatori nello sviluppo sicuro di web application
e non solo. Periodicamente l’OWASP rilascia un report che descrive i dieci rischi più critici
per la sicurezza di una web application denominato OWASP Top 10 [9].

13
4.3.1 OWASP Top 10 e SonarQube

SonarQube integra Dependency-Check [10]un plugin sviluppato dagli sviluppatori che indica
dove c’è il rischio nel codice, tenta di rilevare le vulnerabilità presente in caso viene generato
un elenco delle voci CVE (Common Vulnerability and Exposure) [11]associate, valuta il ri-
schio e da dei suggerimenti su come correggere il problema.

14
5 Analisi statica del codice della web application
con SonarQube

In questo capitolo verrà illustrata la metodologia utilizzata per condurre il processo di analisi
statica del codice applicativo: l’obiettivo è quello di identificare potenziali vulnerabilità nel
codice ed effettuare poi la revisione manuale dei risultati.

5.1 Aggiunta del progetto da GitLab

Una volta fatto il log in su SonarQube, sono stati eseguiti gli step per importare il codice dal
repository GitLab aziendale verso SonarQube:
• è stato creato manualmente il progetto su SonarQube

15
 • in seguito, si è fatto l’acceso a GitLab, selezionando il codice è stato importato nel
progetto creato nello step precedente ed è stato generato un token univoco per il
progetto Project:

16
5.2 Analisi Statica del codice

È stato utilizzato SonarQube con le policy già predefinite dal il team di sviluppo dell’azienda

5.2.1 Risultati e risoluzione dei problemi

Il report iniziale restituito dopo l’analisi è stato il seguente:

Da questo report emerge che si sono verificati 8 match riguardo i Security Hotspot, 17 bugs
e ben oltre 209 Code Smells, per un totale di 266 anomalie da esaminare.

17
5.2.1.1 Security Hotspot:

Sono state classificate due casistiche di gravità alta (HIGH) e bassa (LOW):

• Authentication:

18
Si è notato che in 3 punti nel codice vengono passate le password in chiaro. Questo
rappresenta un rischio enorme in quanto è facile fare un’estrazione del codice. Questa
anomalia fa riferimento alle seguenti vulnerabilità: CVE-2019-13466 e CVE-2018-15389
Per risolvere il problema le credenziali sono state configurate e passate mediante un file di
configurazione esterno.

• Cross-Site Request Forgery (CSRF) [12]:

19
L’analisi ha rilevato che i moduli server.py e app.py presentano un rischio di attacco CSRF.
Per risolvere il problema è stato aggiunto il modulo CSRFProtect della libreria flask_wtf.csrf:

20
• Encryption of Sensitive Dat

L’uso del modulo smtplib.SMTP è stato rilevato come punto critico perché usa
protocolli di crittografia non sicuri per il trasporto dei dati. Con una cattura del
traffico di rete, infatti, un attaccante può leggere, modificare o corrompere il
contenuto deidati.
Per risolvere il problema è stato necessario utilizzare la modalità sicura (SSL/TLS) del
modulo smtplib:

21
 • Log Injection&Others:

Sono stati identificati 2 potenziali punti critici nella configurazione dei file di log. In partico-
lare, SonarQube ha identificato come “pericolose” le procedure di logging illustrate sopra
poiché i file di log vengono salvate nella directory /tmp e configurate a livello DEBUG. A
questo livello, i log file possono contenere più informazioni di quelle strettamente
necessarie e perciò, un potenziale attaccante che ha la possibilità di esaminarli potrebbe
estrapolare informazioni utili ai suoi fini malevoli. Si è verificato che in passato
configurazioni del genere hanno condotto a delle vulnerabilità, ad esempio: CVE-2000-
1127, CVE-2018-0285, CVE-2015-5742.

È stato raccomandato agli sviluppatori di disattivare la modalità DEBUG durante il deploy in

produzione.

22
5.2.1.2 Bugs

• Blocker:
Gli 11 casi analizzati matchano la policy expects positional arguments.

Dopo verifica, non si sono rilevate anomalie nel passaggio degli argomenti alle funzioni in-
dicate anomale. Ad esempio alla funzione pymssql.connect devono essere passati 4 argo-
menti, come si può notare dalla figura, ci sono effettivamente tutti gli argomenti necessari.
Pertanto, sono stati risolti come falsi positivi.
• Major:
Qui le policy sono state identical sub-expressions e Unexpected duplicate.

23
È stato sufficiente cancellare manualmente i duplicati per risolvere il problema.
• Minor:
La policy è stata la stessa nei 3 casi: Replace this. SonarQube ha suggerito l’uso
del tag <em> al posto del tag <i>.

5.2.1.3 Code Smells

• Critical:
Di Code Smells di severità Critical vengono identificati i seguenti:
-Cognitive Complexity of functions should not be too high;
-Specify an exception class to catch or reraise the exception;
-Define a constant instead of duplicating;
-Unexpected variable
Per quanto riguarda la prima, sono stati identificati 5 casi in cui le funzioni considerate
risultano tropo complesse e quindi poco leggibili e mantenibili, qui di seguito un esempio:

24
come si può notare, la complessità è dovuta ad una serie di condizioni che minano la
leggibilità del codice. Sono stati marcati come falsi positivi.
La seconda criticità riguarda l’uso di exception senza messaggi, sono stati identificati 3 casi
in cui le exception sono inserite senza specificare con precisione la classe che genera
l’eccezione.

Catturare un’exception senza specificarla equivale a catturare una exception di classe Basi-
cException, che non fornisce indicazioni sul tipo di errore avvenuto. Sono stati risolti
facendo un refactoring manuale sul codice:

25
La terza criticità riguarda l’uso di convenzione not compliant per la dichiarazione di variabili
esempio:

in effetti se una variabile viene usata in più funzioni è più corretto dichiararla globalmente,
come si è fatto per risolvere il problema.
La quarta criticità riguarda la presenza di variabili dichiarate ma non usate. È stata fatta
semplicemente una cancellazione di tutte queste variabili.

• Major:
Di Code Smells di severità Major, sono stati identificati i seguenti:
-Remove the unused function parameter;
-Remove this commented out code
Per la prima criticità è stato rilevato solo un caso:

ed è stato rimosso manualmente il parametro.

26
Per la seconda criticità sono stati rilevati 21 casi di commenti nel codice, dopo verifica
manuale sono stati rimossi solo 11, in quanto il resto era necessario agli sviluppatori per
la lettura e comprensione del codice.
• Minor:
È stata trovato un alto match di criticità bassa sul naming di funzioni e variabili:

Le policy di SonarQube prevedono che, per una migliore leggibilità del codice, un metodo
o una variabile deve rispettare la seguente espressione regolare: ^[_a-z][a-z0-9_]*$
Sono stati considerati ininfluenti, per cui sono state segnate come falsi positivi.

27
5.2.2 Riepilogo

Una prima revisione del report di SonarQube ci ha permesso di avere una visione generale
delle potenziali vulnerabilità presenti nel codice. Molte delle criticità mostrate sono state
marcate come ininfluenti, mentre altre sono state confermate ed è stato necessario
effettuare un refactoring del codice. Il report, dopo questa prima selezione si presenta
come segue:

Sono stati quindi confermati:

• 2 Security Hotspots che necessitano un intervento manuale da parte degli sviluppa-
tori:

• La persistenza della duplicazione di due blocchi, che necessitano un’analisi manuale

più profonda del codice da parte degli sviluppatori, per individuare i blocchi e
decidere se effettuarne la cancellazione o meno:

28
6 Conclusioni
L’analisi realizzata ha permesso di individuare le anomalie presenti nel codice della web
application. È stato mostrato come l’uso dello strumento SonarQube possa essere utile per
valutare il grado di sicurezza del codice, riconoscere errori di sintassi e punti critici anche spesso
banali a prima vista ma che potrebbero esserefatali in determinate situazioni. Dal primo report il
codice appariva robusto e non erano vulnerabilità gravi. Tuttavia, è emerso la presenza di alcuni
problemi tra cui 17 bugs, 8 security hotspots, 209 code smells e un debito tecnico di circe 29 ore.
Con il presente lavoro è stato possibile esaminare i problemi emersi e risolverne alcuni.
Per risolvere i problemi è stato revisionato il codice e 11 bugs e 164 code smells sono stati segnati
come falsi positivi perché non erano problemi rilevanti, invece facendo un refactoring manuale
sono state implementate delle funzioni, sono stati rimossi commenti, duplicati e variabili anomale
per risolvere i restanti 7 bugs, 45 code smells e 5 casi di hotspots security; Come conseguenza di
tutte queste correzioni apportate al codice da una seconda analisi fatta si è notato un rientro delle
anomalie e un decremento significativo del valore del debito tecnico ch’è passato da 29 ore a 0.
Dal report di SonarQube di quest’ultima analisi è stato notato anche un miglioramento dei valori di
rating di affidabilità del codice che nella prima analisi aveva come valore E nella secondo aveva A
come valore, e anche il rating di security hotspot è passato da E come valore a B.
Gli obbiettivi sono stati parzialmente raggiunti perché non è stato possibile verificare la risoluzione
di 2 problemi di security hotspot dovuto alle tempistiche.
Con il lavoro fatto è stato possibile valutare il grado di sicurezza dell’applicazione Projects.
Per massimizzare la sua efficacia sarebbe opportuno monitorare periodicamente con
SonarQube il codice dell’applicativo, così da rilevare eventuali casi di regression.
Personalmente mi ritengo molto soddisfatto del lavoro svolto, sono sempre stato affasci-
nato dal mondo della sicurezza informatica e Il progetto che mi è stato proposto dall’azienda
YOROI S.R.L. mi ha dato la possibilità di svolgere un’attività di analisi ai fini della ricerca di
vulnerabilità è stata per me una esperienza molto interessante. Spero di poter lavorare in
contesti simili anche in futuro, sperimentando e proponendo soluzioni innovative per
migliorare situazioni attuali.

29
7 Riferimenti

[1] "Sito Zucchetti: https://www.zucchetti.it/

[2] "Sito AngularJS": https://angularjs.org/.
[3] "TypeScript":https://www.typescriptlang.org/.
[4] Forrester Report 2021. 2021 https://start.paloaltonetworks.com/.
[5] The Economic Impacts of Inadeguate Infastructure for Software Testing
https://www.nist.gov/system/files/documents/director/.

[6] SAST testing: how it works and why do you need it | Snyk
https://snyk.io/learn/application-security/static-application-security-testing/.

[7] SonarQube https://www.sonarqube.org/.

[8] SQALE http://sqale.org/objective/details.
[9] OWASP Top 10 https://owasp.org/www-project-top-ten/.
[10] Plugin OWASP https://marketplace.visualstudio.com/items?itemName=dependency-
check.dependencycheck.

[11] CVE https://cve.mitre.org/.

[12] CSRF https://owasp.org/www-community/attacks/csrf.
[13] Rules SonarQube https://rules.sonarsource.com/.
[14] CPE https://nvd.nist.gov/products/cpe.

30
8 Ringraziamenti

Con la conclusione di questo progetto mi ritrovo alla fine di un lungo percorso che mi ha
dato molte soddisfazioni. Mi è doveroso dedicare questo spazio del mio elaborato alle
persone che hanno contribuito, con il loro instancabile supporto, alla realizzazione dello
stesso.
In primis, un ringraziamento speciale al prof. Alberto Bartoli per il suo compito svolto
come relatore per la sua immensa pazienza e la passione che mi ha trasmesso attraverso
il suo corso, sempre con precisione e dedizione.
Ringrazio Marco D’Orlando di YOROI per avermi seguito in questi mesi dandomi fiducia e lo
spazio per sperimentare e proporre le mie idee, ed anche tutti i miei colleghi per la
disponibilità.
Tutto questo non sarebbe stato possibile senza la mia famiglia che ha sempre creduto in me
e mi ha sempre supportato in tutto, ringrazio i miei genitori per la fiducia, un ringrazio
particolare a mia nonna per tutti i sacrifici e per esserci sempre stata soprattutto nei
momenti di sconforto. Ringrazio di cuore i miei zii Romeo, Lorette e Nathalie per il sostegno
indefettibile e per tutto il supporto che mi hanno portato e mio zio Therance per tutti i
preziosi consigli.
Ringrazio i miei amici in particolare Jordan, Patrick e Dimitri e la mia compagna Hesione
per il loro costante supporto e incoraggiamenti.
Infine, vorrei ringraziare il Prof Franco Obersnel, Alessio e Denis, il loro grande aiuto ha
facilitato la mia integrazione in Italia.

31