Audit delle dipendenze e SBOM dal tuo file lock
Carica package-lock.json, yarn.lock, requirements.txt, pom.xml o i file Gradle. Vedi gli avvisi di sicurezza noti con le versioni correttive, le classi di licenza e i pacchetti obsoleti — e scarica una distinta base del software (SBOM) in formato CycloneDX.
Se usi già Dependabot, Renovate, Snyk, OSV-Scanner o Dependency-Track nella CI, questo strumento ti serve di rado. È un controllo una tantum per il passaggio di un progetto, una due diligence o una prima SBOM.
YuSMP è una software house; l’analisi è gratuita e automatica. Su richiesta offriamo una revisione manuale delle dipendenze e degli aggiornamenti.
1Aggiungi i file delle dipendenze
I tuoi file restano nel browser. I file lock vengono analizzati in locale. Al passo successivo vedrai quali coppie pacchetto@versione verrebbero inviate al nostro server e da lì al database pubblico di vulnerabilità OSV.dev e a un registro di pacchetti; puoi escludere i pacchetti interni. Non conserviamo questo elenco e non lo scriviamo nei log.
File
| File | Formato | Pacchetti | Stato |
|---|
2Contesto (facoltativo)
3Cosa verrà inviato
| Invia | Pacchetto | Versione | Ambito |
|---|
Controllo in corso
- Ricerca delle vulnerabilità note
- Verifica di date di rilascio e licenze
- Ordinamento delle correzioni
I progetti grandi richiedono fino a un minuto.
Risultati
Da correggere per primi
Scarica una SBOM CycloneDX
La SBOM viene generata nel tuo browser a partire dai componenti qui sopra (i pacchetti esclusi e privati non sono inclusi e vengono conteggiati nel file). Formato: CycloneDX 1.5 JSON.
Cosa copre il file (elementi minimi NTIA)
- ✓Nome, versione e identificativo univoco (purl) del componente
- ◐Relazioni di dipendenza: solo radice → dipendenze dirette
- ✓Autore dei dati SBOM e marca temporale
- ✕Nome del fornitore — assente, i registri non lo forniscono in modo affidabile
- ✕Hash dei componenti — non ancora inclusi
Il CRA richiede ai fabbricanti di documentare i componenti dei loro prodotti, anche con una distinta base del software (SBOM) in un formato di uso comune e leggibile da macchina che copra almeno le dipendenze di primo livello (allegato I, parte II, punto 1).
Lo strumento aiuta ad avviare un inventario dei componenti e a vedere gli avvisi noti. Non è una consulenza legale né una valutazione di conformità.
Ricevi il report PDF
Un PDF con le priorità di correzione, l’impegno in ore, le tabelle di vulnerabilità, licenze e pacchetti obsoleti e il metodo — via email. Vediamo anche che hai eseguito il controllo, per proporti una revisione manuale se è utile.
Revisione manuale di dipendenze e aggiornamenti
Un ingegnere esamina il tuo stack: cosa è realmente raggiungibile, quali aggiornamenti sono sicuri, cosa sostituire e un piano che il tuo team può seguire. Prima call gratuita, NDA su richiesta.
Audit di sicurezzaModernizzazione del softwareCTO frazionale
Cosa questo strumento non fa
- Non analizza il codice sorgente (niente SAST) e non verifica se una funzione vulnerabile viene davvero chiamata.
- Non analizza immagini di container, pacchetti del sistema operativo o registri privati.
- Non corregge nulla e non apre pull request.
- Non conserva i tuoi file né l’elenco dei pacchetti.
- Non è un certificato, un giudizio di audit, una consulenza legale o una valutazione di conformità.
Se hai già una SCA nella CI
Tienila. Strumenti continui come Dependabot, Renovate, OSV-Scanner o Dependency-Track controllano ogni commit; questa pagina serve per uno sguardo una tantum: il passaggio di un progetto da un fornitore, una due diligence, una prima SBOM per un cliente o un codice che nessuno controlla da tempo.
Come funziona
Il browser legge i file ed estrae ogni pacchetto con la sua versione esatta. I pacchetti senza versione esatta (un intervallo in package.json, un requisito non fissato, una proprietà Maven non risolta) compaiono come «versione non fissata» e non vengono cercati: un intervallo non permette una risposta onesta. Aggiungi un file lock per un risultato completo.
I pacchetti interni sono esclusi automaticamente: file:, link:, workspace:, sorgenti git e URL e tutto ciò che proviene da un registro non pubblico. Puoi escluderne altri a mano prima di qualsiasi invio.
Solo dopo «Controlla le dipendenze» l’elenco pacchetto@versione va alla nostra funzione serverless. Questa interroga OSV.dev, il database aperto di vulnerabilità che raccoglie gli avvisi di GitHub, PyPI, npm e altre fonti, e deps.dev (Open Source Insights) per licenze, date di rilascio e deprecazioni. La gravità deriva dal vettore CVSS v3 o dalla valutazione dell’avviso; i duplicati (GHSA, CVE, PYSEC) vengono uniti.
Le priorità pesano la gravità in base alla portata (dipendenza diretta di produzione, transitiva, di sviluppo) e alla presenza di una correzione. L’impegno è una stima di massima in ore, non un preventivo. Fissa le dipendenze e tieni una SBOM: vedi la nostra checklist di sicurezza per le web app.
Dati sulle vulnerabilità: OSV.dev e le sue fonti (CC-BY 4.0). Metadati dei pacchetti: deps.dev (Open Source Insights, CC-BY 4.0).
CRA, SBOM e il tuo prodotto
- Il regolamento sulla cyberresilienza (CRA, regolamento (UE) 2024/2847) è entrato in vigore il 10 dicembre 2024. La segnalazione delle vulnerabilità attivamente sfruttate e degli incidenti gravi si applica dall’11 settembre 2026; la maggior parte degli altri obblighi dall’11 dicembre 2027.
- Il CRA richiede ai fabbricanti di documentare i componenti dei loro prodotti, anche con una distinta base del software (SBOM) in un formato di uso comune e leggibile da macchina che copra almeno le dipendenze di primo livello (allegato I, parte II, punto 1).
- Gli obblighi riguardano i fabbricanti di prodotti con elementi digitali immessi sul mercato UE. Se si applicano al tuo prodotto dipende dal prodotto — questo strumento non lo stabilisce.
Lo strumento aiuta ad avviare un inventario dei componenti e a vedere gli avvisi noti. Non è una consulenza legale né una valutazione di conformità.
FAQ
I miei file vengono caricati?
No. I file vengono letti dal browser e non lo lasciano. Viene inviato solo l’elenco dei nomi di pacchetti pubblici con le versioni esatte che confermi nell’anteprima, e puoi escludere qualsiasi pacchetto prima.
Cosa viene inviato esattamente ai servizi esterni?
Coppie come lodash@4.17.15 con l’ecosistema (npm, PyPI, Maven), se il pacchetto è diretto o di sviluppo e la licenza indicata nel file lock. La nostra funzione inoltra nomi e versioni a OSV.dev e deps.dev (entrambi gestiti negli Stati Uniti). Nomi dei file, percorsi, URL di registri privati e il tuo codice sorgente non vengono inviati. Non conserviamo l’elenco e non lo registriamo nei log.
Cos’è una SBOM e a chi serve?
Una distinta base del software (SBOM) è un elenco leggibile da macchina dei componenti di un prodotto: nomi, versioni, identificativi, licenze. Clienti, investitori e autorità la chiedono sempre più spesso, e il regolamento sulla cyberresilienza la richiede ai fabbricanti di prodotti con elementi digitali.
«Vulnerabilità trovata» significa che il mio prodotto è attaccabile?
No. Significa che un avviso pubblicato riguarda questa versione del pacchetto. Se il tuo codice chiama la funzione vulnerabile, con quale configurazione e con quali input non viene valutato qui — a questo serve la revisione manuale.
«Nessun risultato» significa che è sicuro?
No. Significa che nessun avviso noto corrisponde alle versioni esatte controllate. I pacchetti non fissati, quelli esclusi e tutto ciò che è fuori dai formati supportati non sono stati controllati, e ogni giorno escono nuovi avvisi.
È un controllo di conformità al CRA?
No. Aiuta ad avviare un inventario dei componenti e a vedere gli avvisi noti. Non è una consulenza legale né una valutazione di conformità, e l’applicabilità del CRA dipende dal tuo prodotto.
Quali formati sono supportati e cosa resta escluso?
npm (package-lock.json, npm-shrinkwrap.json, yarn.lock, package.json), PyPI (requirements*.txt / .in) e Maven/Gradle (pom.xml, build.gradle, build.gradle.kts). I file Maven e Gradle elencano solo le dipendenze dichiarate, senza l’albero transitivo e spesso senza versioni risolte. Non ancora supportati: pnpm, Poetry, Pipenv, Go, Rust, Ruby, PHP, .NET, immagini di container e registri privati.
In cosa differisce da Dependabot, Snyk o OSV-Scanner?
Questi strumenti girano di continuo nel repository e nella CI e possono proporre correzioni. Questa pagina è un controllo una tantum senza installare nulla: utile per un passaggio di progetto, una due diligence o una prima SBOM. Se ne usi già uno, tienilo.
Servizi correlati
Audit di sicurezza
Penetration test e revisioni di sicurezza, inclusa una revisione manuale di dipendenze e aggiornamenti.
Modernizzazione del software
Aggiornare i framework e sostituire i pacchetti non mantenuti senza fermare il prodotto.
CTO frazionale
Supervisione tecnica senior per passaggi di progetto, due diligence e decisioni sulla supply chain.