1. Percezione Vs realtà: Uno
sguardo data-driven
sull'Open Source Risk
Management
Sonatype
1

2. 2

3. Speaker

5. Did you never heard about it?

6. Research Methods
Survey
Data
(n = 662)
App Scan
Data
(Nexus Lifecycle)
OSS Security
Practices
(OpenSSF Scorecard)
Download
Data
(Maven Central)
Statistical Analysis &
Machine Learning

7. Supply and Demand

8. Malicious packages in the supply chain
Dependency
Confusion
Typosquatting
Protestware
Malicious Code
Injections
97,334+
malicious packages
Oct 2022

9. The industry is slow adopting patches

10. Uno sguardo data-driven sulla
gestione del rischio Open Source
Percezione vs Realtà

11. Production Consumption
Open Source Maintainers Enterprise Developers

12. Production
Perception: Open Source is risky
Reality: OSS Can Almost Always Be Secure
35% of releases are vulnerable (Maven Central)
3.5M vulnerable releases
1.2B vulnerable downloads per month
98% of projects have safe versions available
Most vulnerabilities are patched before they’re disclosed
Log4j: Patched in 15 days. Patch was available by the time the CVE went public.

13. Consumption
Perception: We’re good
at managing open source
Reality: Mixed Results
68% are confident they are not using
vulnerable versions
High remediation maturity (self-reported)
68% of applications use a component
with a known vulnerability.
Managers: 3.5x more likely to say
remediation is fast (< 1 day)
We’re great at remediation!
(we think)
remediation
inventory
policy controls
build & release
giving back
supplier hygiene
consumption
transformation

15. Avoidable
Vulnerability
(poor choices)
Vulnerability is largely a consumption-side problem
For 96% of vulnerable downloads,
there was a non-vulnerable
version available
Avoidabilityof vulnerable Maven
Central downloads
Unavoidable
Vulnerability

16. Spring
thymeleaf
Log4Shell SpringShell
Lifecycle Reduces Risk in each stage

17. 150 Dependencies (avg Java project)
10 Releases Per Year (avg per dependency)
x
1500 Updates To Consider 😱

18. Picking Better Components
Where better = “less likely to have a vulnerability”

19. OpenSSF Security Scorecard
• Code Review Security Policy Update Tool
• License File Signed Releases Workflow Permissions
• Branch Protection No Binaries Fuzz Testing
• Pinned Dependencies Active Commits No Unpatched Vulns
• Official Packaging Safe Workflows Best Practices Badge

20. Connection With Security
Predict whether a
project has a known
vulnerability
OpenSSF Scorecard
Machine
Learning
Code Review Security Policy Update Tool
License File Signed Releases Workflow Permissions
Branch Protection No Binaries Fuzz Testing
Pinned Dependencies Active Commits No Unpatched Vulns
Official Packaging Safe Workflows Best Practices Badge

21. Converting To A Rating
Sonatype Safety
Rating
+
Dependency
Hygiene
Rating
(MTTU)
OpenSSF
Scorecard

22. Research-backed rating tool that
predicts with 86%+ accuracy
whether an open source project
contains security vulnerabilities
safety rating

23. 86% Accuracy

24. ● Some binary data checked in
● Dependencies not all pinned
● No binary data
● Uses fuzz testing
Available on Maven Central and OSS Index

25. Production Consumption
Open Source Maintainers Enterprise Developers
● Choose projects with a high Safety
Rating
(and help us make it better)
● Use SCA tools to flag and fix
vulnerable libraries
● Get a realistic view of your
organization’s performance
● Implement Scorecard Best
Practices
● Keep Dependencies Up-to-
date

27. • Un basso livello di sicurezza informatica,
riflesso da vulnerabilità diffuse e dalla
fornitura insufficiente e incoerente di
aggiornamenti di sicurezza per affrontarle;
• Un'insufficiente comprensione e accesso
alle informazioni da parte degli utenti,
impedendo loro di scegliere prodotti con
adeguate proprietà di sicurezza.
• Creare le condizioni per lo sviluppo di prodotti sicuri con
elementi digitali garantendo che i prodotti hardware e
software siano immessi sul mercato con meno vulnerabilità e
garantire che i produttori prendano sul serio la sicurezza
durante l'intero ciclo di vita di un prodotto;
• Creare condizioni che consentano agli utenti di tenere conto
della sicurezza informatica nella scelta e nell'utilizzo di
prodotti con elementi digitali.
La proposta di regolamento sui requisiti di sicurezza
informatica per le applicazioni digitali rafforza le
norme di sicurezza informatica per garantire prodotti
hardware e software più sicuri.

28. Q&A
Useful links:
● Consulta l'ultimo report sulla
sicurezza Open Source
● European Cyber Resilience Act

29. Dove trovarci
DOVE SIAMO
Milano - Torino - Padova - Roma
TELEFONO
Torino 011-0120370
SOCIAL
WEBSITE
www.emerasoft.com
EMAIL
sales@emerasoft.com