{"id":30614,"date":"2026-04-20T12:07:11","date_gmt":"2026-04-20T10:07:11","guid":{"rendered":"https:\/\/www.kaspersky.it\/blog\/?p=30614"},"modified":"2026-04-20T15:06:31","modified_gmt":"2026-04-20T13:06:31","slug":"managing-open-source-vulnerabilities","status":"publish","type":"post","link":"https:\/\/www.kaspersky.it\/blog\/managing-open-source-vulnerabilities\/30614\/","title":{"rendered":"Architettura open source di gestione delle vulnerabilit\u00e0"},"content":{"rendered":"<p>Come gi\u00e0 accennato<a href=\"https:\/\/www.kaspersky.it\/blog\/open-source-vulnerabilities-in-ai-era\/30610\/\" target=\"_blank\" rel=\"noopener\"> in un post precedente<\/a>, lo sviluppo di software moderno \u00e8 praticamente impensabile senza l\u2019utilizzo di componenti open-source. Ma negli ultimi anni i rischi associati sono diventati sempre pi\u00f9 diversi, complessi e numerosi. Quando, in primo luogo, le vulnerabilit\u00e0 influiscono sull\u2019infrastruttura e sul codice di un\u2019azienda pi\u00f9 velocemente di quanto vengano sanate; in secondo luogo, i dati sono inaffidabili e incompleti; e in terzo luogo, il malware potrebbe essere in agguato all\u2019interno dei componenti pi\u00f9 diffusi: non \u00e8 sufficiente eseguire la scansione dei numeri di versione e inviare ticket di correzione al team IT. La gestione delle vulnerabilit\u00e0 deve essere estesa per coprire i criteri di download del software, i limiti per gli assistenti IA e l\u2019intera pipeline di build del software.<\/p>\n<h1>Un pool attendibile di componenti open source<\/h1>\n<p>La parte principale della soluzione \u00e8 impedire l\u2019utilizzo di codice vulnerabile e dannoso. \u00c8 necessario implementare le seguenti misure:<\/p>\n<ul>\n<li>Avere un archivio interno degli artefatti. L\u2019unica fonte dei componenti per lo sviluppo interno deve essere un archivio unificato in cui i componenti sono ammessi solo dopo una serie di controlli.<\/li>\n<li>Esecuzione di uno screening rigoroso dei componenti. Questi includono i controlli di: versioni note del componente, versioni note vulnerabili e dannose, data di pubblicazione, cronologia attivit\u00e0 e reputazione del pacchetto e dei relativi autori. \u00c8 obbligatorio eseguire la scansione dell\u2019intero contenuto del pacchetto, incluse le istruzioni per la compilazione, i test case e altri dati ausiliari. Per filtrare il registro durante l\u2019importazione, utilizza scanner open source specializzati o una <a href=\"https:\/\/www.kaspersky.it\/enterprise-security\/cloud-workload-security?icid=it_kdailyplacehold_acq_ona_smm__onl_b2b_kdaily_wpplaceholder_sm-team_______5d2008123d0794cf\" target=\"_blank\" rel=\"noopener\">soluzione completa per la protezione dei carichi di lavoro nel cloud<\/a>.<\/li>\n<li>Esecuzione del blocco delle dipendenze. I processi di compilazione, gli strumenti di intelligenza artificiale e gli sviluppatori non devono utilizzare modelli (ad esempio \u201cpi\u00f9 recenti\u201d) per specificare le versioni. Le build del progetto devono essere basate su versioni verificate. Allo stesso tempo, le dipendenze aggiunte devono essere aggiornate periodicamente alle versioni verificate pi\u00f9 recenti che mantengono la compatibilit\u00e0 e sono prive di vulnerabilit\u00e0 note. Questo riduce significativamente il rischio di <a href=\"https:\/\/www.kaspersky.com\/blog\/npm-packages-trojanized\/54280\/\" target=\"_blank\" rel=\"noopener nofollow\">attacchi alla supply chain dovuti alla compromissione di un pacchetto noto<\/a>.<\/li>\n<\/ul>\n<h1>Miglioramento dei dati sulle vulnerabilit\u00e0<\/h1>\n<p>Per identificare le vulnerabilit\u00e0 in modo pi\u00f9 efficace e <a href=\"https:\/\/www.kaspersky.it\/blog\/cvss-rbvm-vulnerability-management\/29856\/\" target=\"_blank\" rel=\"noopener\">assegnare correttamente le priorit\u00e0<\/a>, un\u2019organizzazione deve definire diversi processi IT e di sicurezza:<\/p>\n<ul>\n<li>Arricchimento dei dati sulle vulnerabilit\u00e0. A seconda delle esigenze dell\u2019organizzazione, questo \u00e8 necessario per arricchire le informazioni combinando i dati di NVD, EUVD, BDU, GitHub Advisory Database e osv.dev, oppure per acquistare un feed commerciale di intelligence sulla vulnerabilit\u00e0 in cui i dati sono gi\u00e0 aggregati e arricchiti. In entrambi i casi, vale la pena monitorare ulteriormente i feed di intelligence sulle minacce per tenere traccia delle tendenze di sfruttamento nel mondo reale e ottenere informazioni dettagliate sul profilo degli autori degli attacchi che prendono di mira vulnerabilit\u00e0 specifiche. Kaspersky fornisce un <a href=\"https:\/\/www.kaspersky.com\/open-source-feed?icid=it_kdailyplacehold_acq_ona_smm__onl_b2b_blo_wpplaceholder________5b01efee969ef9e1\" target=\"_blank\" rel=\"noopener nofollow\">feed di dati specializzati incentrato specificamente sui componenti open source<\/a>.<\/li>\n<li>Analisi approfondita della composizione del software. Gli strumenti specializzati di analisi della composizione del software (SCA) consentono di spostarsi correttamente nella catena delle dipendenze nel codice open source per eseguire un inventario completo delle librerie utilizzate e individuare i componenti obsoleti o non supportati. I dati sui componenti integri sono inoltre utili per arricchire il registro degli artefatti.<\/li>\n<li>Identificazione dell\u2019abandonware. Anche se un componente non \u00e8 formalmente vulnerabile e non \u00e8 stato ufficialmente dichiarato non supportato, il processo di scansione dovrebbe contrassegnare i componenti che non ricevono aggiornamenti da pi\u00f9 di un anno. Questi garantiscono un\u2019analisi separata e una potenziale sostituzione, proprio come i componenti EOL.<\/li>\n<\/ul>\n<h1>Protezione del codice e degli agenti di IA<\/h1>\n<p>Le attivit\u00e0 dei sistemi IA utilizzati nella codifica devono essere racchiuse in un set completo di misure di sicurezza, dal filtraggio dei dati di input alla formazione degli utenti:<\/p>\n<ul>\n<li>Restrizioni sui suggerimenti per le dipendenze. Configurare l\u2019ambiente di sviluppo per assicurarsi che gli agenti e gli assistenti IA possano fare riferimento solo a componenti e librerie del registro degli artefatti attendibili. Se questi non contengono gli strumenti giusti, il modello deve attivare una richiesta per includere la dipendenza nel registro, anzich\u00e9 estrarre qualcosa da PyPI che corrisponda semplicemente alla descrizione.<\/li>\n<li>Filtrare gli output del modello. Nonostante queste restrizioni, tutto ci\u00f2 che viene generato dal modello deve anche essere verificato per garantire che il codice IA non contenga dipendenze obsolete, non supportate, vulnerabili o inventate. Questo controllo deve essere integrato direttamente nel processo di accettazione del codice o nella fase di preparazione della build. Non sostituisce il tradizionale processo di analisi statica: gli strumenti SAST devono ancora essere incorporati nella pipeline CI\/CD.<\/li>\n<li>Formazione per sviluppatori. I team IT e sicurezza devono avere una profonda familiarit\u00e0 con le caratteristiche dei sistemi di IA, i relativi principi operativi e gli errori comuni. A tale scopo, i dipendenti devono completare un <a href=\"https:\/\/xtraining.kaspersky.com\/courses\/large-language-models-security\/?icid=it_kdailyplacehold_acq_ona_smm__onl_b2b_kdaily_wpplaceholder_sm-team___xtraining____887ea33076fd631c\" target=\"_blank\" rel=\"noopener\">corso di formazione specialistica<\/a> adattato al ruolo specifico.<\/li>\n<\/ul>\n<h1>Rimozione sistematica dei componenti EOL<\/h1>\n<p>Se i sistemi di un\u2019azienda utilizzano componenti open source obsoleti, \u00e8 necessario adottare un approccio sistematico e coerente per affrontarne le vulnerabilit\u00e0. Esistono tre metodi principali per eseguire questa operazione:<\/p>\n<ul>\n<li>Migrazione. Questo \u00e8 il metodo pi\u00f9 complesso e costoso dal punto di vista organizzativo, che implica la sostituzione totale di un componente seguita dall\u2019adattamento, la riscrittura o la sostituzione delle applicazioni basate su di esso. Decidere in merito a una migrazione \u00e8 particolarmente scoraggiante quando \u00e8 necessaria una revisione radicale di tutto il codice interno. Questo problema riguarda spesso i componenti principali: \u00e8 impossibile eseguire facilmente la migrazione da Node.js 14 o Python 2.<\/li>\n<li>Supporto a lungo termine (LTS). Esiste un mercato di servizi di supporto dedicato per i progetti legacy su larga scala. Talvolta ci\u00f2 implica un fork del sistema legacy gestito da sviluppatori di terze parti; in altri casi, i team specializzati eseguono il backport delle patch che correggono vulnerabilit\u00e0 specifiche in versioni precedenti e non supportate. La transizione a LTS in genere richiede costi di supporto continui, ma in molti casi pu\u00f2 essere comunque pi\u00f9 conveniente rispetto a una migrazione completa.<\/li>\n<li>Controlli compensativi. In base ai risultati di un\u2019analisi dettagliata, \u00e8 possibile creare un <a href=\"https:\/\/www.kaspersky.com\/blog\/legacy-it-update-troubles-and-mitigations\/48692\/\" target=\"_blank\" rel=\"noopener nofollow\">set di misure di sicurezza avvolgenti per mitigare il rischio di sfruttamento per le vulnerabilit\u00e0 all\u2019interno del prodotto precedente<\/a>. Sia l\u2019efficacia che la fattibilit\u00e0 economica di questo approccio dipendono dal ruolo del software all\u2019interno dell\u2019organizzazione.<\/li>\n<\/ul>\n<p>Sicurezza, IT e azienda devono collaborare per scegliere uno di questi tre percorsi per ogni EOL documentata o componente abbandonato e rispecchiare la scelta effettuata nei registri delle risorse e nelle SBOM dell\u2019azienda.<\/p>\n<h1>Gestione delle vulnerabilit\u00e0 open source basata sul rischio<\/h1>\n<p>Tutte le misure sopra elencate riducono il volume di componenti e software vulnerabili che entrano nell\u2019organizzazione e semplificano il rilevamento e la correzione dei difetti. Nonostante questo, \u00e8 impossibile eliminare ogni singolo difetto: il numero di applicazioni e di componenti sta semplicemente crescendo troppo velocemente.<\/p>\n<p>Pertanto, rimane essenziale <a href=\"https:\/\/www.kaspersky.it\/blog\/cvss-rbvm-vulnerability-management\/29856\/\" target=\"_blank\" rel=\"noopener\">assegnare la priorit\u00e0 alle vulnerabilit\u00e0 in base ai rischi reali<\/a>. Il modello di valutazione dei rischi deve essere espanso per tenere conto delle caratteristiche dell\u2019open source, rispondendo alle seguenti domande:<\/p>\n<ul>\n<li>Il ramo di codice vulnerabile viene effettivamente eseguito nell\u2019ambiente dell\u2019organizzazione? \u00c8 necessario eseguire un\u2019analisi della raggiungibilit\u00e0 per le vulnerabilit\u00e0 rilevate. Molti frammenti di codice difettosi non vengono mai effettivamente eseguiti nell\u2019ambito dell\u2019implementazione specifica dell\u2019organizzazione, rendendo impossibile lo sfruttamento della vulnerabilit\u00e0. Alcune soluzioni SCA possono eseguire questa analisi. Questo stesso processo consente di valutare uno scenario alternativo: cosa succede se le procedure o i componenti vulnerabili vengono rimossi completamente dal progetto? A volte, questo metodo di riparazione si rivela sorprendentemente indolore.<\/li>\n<li>Il difetto viene sfruttato negli attacchi nel mondo reale? \u00c8 disponibile un PoC? Le risposte a queste domande fanno parte di framework standard di assegnazione delle priorit\u00e0 come EPSS, ma il tracciamento deve essere condotto attraverso un set molto pi\u00f9 ampio di fonti di intelligence.<\/li>\n<li>Sono state segnalate attivit\u00e0 dei criminali informatici in questo registro delle dipendenze o in componenti correlati e simili? Si tratta di fattori aggiuntivi per l\u2019assegnazione delle priorit\u00e0.<\/li>\n<\/ul>\n<p>La considerazione di questi fattori consente al team di allocare le risorse in modo efficace e correggere prima i difetti pi\u00f9 pericolosi.<\/p>\n<h1>Trasparenza is the new black<\/h1>\n<p>La barra di sicurezza per il software open source \u00e8 destinata a continuare a crescere. Le aziende che sviluppano applicazioni, anche per uso interno, dovranno far fronte a pressioni normative che richiedono una sicurezza informatica documentata e verificabile all\u2019interno dei propri sistemi. Secondo le <a href=\"https:\/\/www.sonatype.com\/state-of-the-software-supply-chain\/introduction\" target=\"_blank\" rel=\"noopener nofollow\">stime degli esperti Sonatype<\/a>, il 90% delle aziende a livello globale rientra gi\u00e0 in uno o pi\u00f9 requisiti per fornire evidenza dell\u2019affidabilit\u00e0 del software utilizzato; pertanto, gli esperti considerano la trasparenza \u201cla valuta della sicurezza della filiera del software\u201d.<\/p>\n<p>Controllando l\u2019utilizzo di componenti e applicazioni open source, arricchendo l\u2019intelligence sulle minacce e monitorando rigorosamente i sistemi di sviluppo basati sull\u2019intelligenza artificiale, le organizzazioni possono introdurre le innovazioni tanto agognate dall\u2019azienda, il tutto superando il limite stabilito dalle autorit\u00e0 di regolamentazione e dai clienti.<\/p>\n<input type=\"hidden\" class=\"category_for_banner\" value=\"mdr\"><input type=\"hidden\" class=\"placeholder_for_banner\" data-cat_id=\"mdr\" value=\"16021\">\n","protected":false},"excerpt":{"rendered":"<p>Come gestire le vulnerabilit\u00e0 durante lo sviluppo o l&#8217;utilizzo di software open source.<\/p>\n","protected":false},"author":2722,"featured_media":30615,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2364,2955,2956],"tags":[3923,3882,2620,3003,538,3570,584],"class_list":{"0":"post-30614","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"category-smb","10":"tag-agenti-ia","11":"tag-cvss","12":"tag-ia","13":"tag-open-source","14":"tag-patch","15":"tag-strategia","16":"tag-vulnerabilita"},"hreflang":[{"hreflang":"it","url":"https:\/\/www.kaspersky.it\/blog\/managing-open-source-vulnerabilities\/30614\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/managing-open-source-vulnerabilities\/30368\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/managing-open-source-vulnerabilities\/25418\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/managing-open-source-vulnerabilities\/30215\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/managing-open-source-vulnerabilities\/41643\/"},{"hreflang":"tr","url":"https:\/\/www.kaspersky.com.tr\/blog\/managing-open-source-vulnerabilities\/14472\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/managing-open-source-vulnerabilities\/55554\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/managing-open-source-vulnerabilities\/24913\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/managing-open-source-vulnerabilities\/33403\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/managing-open-source-vulnerabilities\/30484\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/managing-open-source-vulnerabilities\/36103\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/managing-open-source-vulnerabilities\/35755\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.it\/blog\/tag\/vulnerabilita\/","name":"vulnerabilit\u00e0"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/30614","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/users\/2722"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/comments?post=30614"}],"version-history":[{"count":3,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/30614\/revisions"}],"predecessor-version":[{"id":30618,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/30614\/revisions\/30618"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/media\/30615"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/media?parent=30614"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/categories?post=30614"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/tags?post=30614"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}