{"id":30576,"date":"2026-04-10T13:33:19","date_gmt":"2026-04-10T11:33:19","guid":{"rendered":"https:\/\/www.kaspersky.it\/blog\/?p=30576"},"modified":"2026-04-08T20:00:36","modified_gmt":"2026-04-08T18:00:36","slug":"supply-chain-attacks-in-2025","status":"publish","type":"post","link":"https:\/\/www.kaspersky.it\/blog\/supply-chain-attacks-in-2025\/30576\/","title":{"rendered":"Gli attacchi alla supply chain pi\u00f9 importanti del 2025"},"content":{"rendered":"<p>Gli attacchi alla supply chain rappresentano <a href=\"https:\/\/www.kaspersky.com\/blog\/supply-chain-attacks-in-2024\/52965\/\" target=\"_blank\" rel=\"noopener nofollow\">da anni<\/a> una delle categorie pi\u00f9 pericolose di incidenti di sicurezza informatica. E se il 2025 ci ha insegnato qualcosa, \u00e8 che i criminali informatici stanno raddoppiando la loro presenza. In questo approfondimento, esaminiamo gli attacchi alla supply chain del 2025 che, sebbene non sempre i pi\u00f9 costosi, sono stati sicuramente i pi\u00f9 insoliti e hanno attirato l\u2019attenzione del settore.<\/p>\n<h2>Gennaio 2025: un RAT trovato nell\u2019archivio GitHub DogWifTools<\/h2>\n<p>Come \u201criscaldamento\u201d dopo le vacanze, i criminali informatici hanno sistematicamente <a href=\"https:\/\/www.bleepingcomputer.com\/news\/security\/solana-pumpfun-tool-dogwiftool-compromesso-to-drain-wallets\/\" target=\"_blank\" rel=\"noopener nofollow\">eseguito il backdoor<\/a> di diverse versioni di DogWifTools. Questa \u00e8 un\u2019utilit\u00e0 progettata per il lancio e la promozione vigorosa <a href=\"https:\/\/it.wikipedia.org\/wiki\/Moneta_meme\" target=\"_blank\" rel=\"noopener nofollow\">di monete meme<\/a> basate su Solana su Pump.fun. Dopo aver compromesso l\u2019archivio privato GitHub per DogWifTools, gli autori dell\u2019attacco hanno atteso che gli sviluppatori caricassero una nuova build, hanno iniettato un RAT e quindi poche ore dopo hanno scambiato il programma legittimo con la relativa versione dannosa. Secondo gli sviluppatori, gli autori delle minacce hanno creato trojan delle versioni da 1.6.3 a 1.6.6 di DogWifTools per Windows.<\/p>\n<p>Il finale \u00e8 stato attivato a fine gennaio. Dopo aver utilizzato il RAT per raccogliere un\u2019enorme quantit\u00e0 di dati dai dispositivi infetti, gli autori dell\u2019attacco hanno prosciugato i portafogli di criptovaluta delle vittime. Sebbene le vittime stimino il bottino totale in oltre 10 milioni di dollari in criptovalute, gli stessi autori hanno <a href=\"https:\/\/x.com\/JizzyGroup\/status\/1884395542072959208\" target=\"_blank\" rel=\"noopener nofollow\">contestato<\/a> questa cifra, anche se si sono fermati prima di rivelare esattamente con quanto avevano effettivamente rubato.<\/p>\n<h2>Febbraio 2025: il furto di Bybit da 1,5 miliardi di dollari<\/h2>\n<p>Se gennaio \u00e8 stato un riscaldamento, febbraio \u00e8 stato un tracollo totale. L\u2019<a href=\"https:\/\/www.kaspersky.it\/blog\/bybit-hack-lessons-how-to-do-self-custody-properly\/29507\/\" target=\"_blank\" rel=\"noopener\">hacking dell\u2019exchange di criptovalute Bybit<\/a> ha completamente eclissato gli incidenti precedenti, diventando il pi\u00f9 grande furto di criptovalute della storia. Gli autori dell\u2019attacco sono riusciti a compromettere il software Safe{Wallet}, la soluzione di archiviazione multisig cold su cui si basava lo scambio per gestire le proprie risorse.<\/p>\n<p>I dipendenti Bybit pensavano di firmare una transazione di routine; in realt\u00e0 stavano autorizzando uno smart contract dannoso. Una volta eseguito, ha prosciugato un cold wallet primario, disperdendo i fondi tra diverse centinaia di indirizzi controllati dall\u2019autore dell\u2019attacco. Il bottino finale ha superato i 400.000 ETH\/stETH, con un valore totale sbalorditivo di circa\u2026 1,5 miliardi di dollari statunitensi!<\/p>\n<h2>Marzo 2025: Coinbase nel mirino di una compromissione a cascata di GitHub Actions<\/h2>\n<p>La primavera del 2025 \u00e8 iniziata con un sofisticato attacco che utilizzava una <a href=\"https:\/\/www.kaspersky.com\/blog\/malicious-github-action-changed-files\/53179\/\" target=\"_blank\" rel=\"noopener nofollow\">compromissione di pi\u00f9 GitHub Actions<\/a>, i modelli di flusso di lavoro utilizzati per automatizzare le attivit\u00e0 DevOps standard, come meccanismo di invio principale. Tutto \u00e8 iniziato con il furto di un token di accesso personale appartenente a un manutentore dello strumento di analisi SpotBugs. Utilizzando questo punto d\u2019appoggio, gli autori dell\u2019attacco hanno pubblicato un processo dannoso e sono riusciti a dirottare un token da un responsabile della manutenzione del flusso di lavoro reviewdog\/action-setup, anch\u2019egli coinvolto nel progetto.<\/p>\n<p>In seguito a questa operazione, hanno compromesso una dipendenza, il flusso di lavoro tj-actions\/changed-files, modificandolo per eseguire uno script Python dannoso. Questo script \u00e8 stato progettato per cercare segreti di alto valore, ad esempio chiavi AWS, Azure e Google Cloud, token GitHub e NPM, credenziali del database e chiavi private RSA. Stranamente, lo script ha scritto tutto ci\u00f2 che ha trovato direttamente nei registri di compilazione accessibili pubblicamente. Ci\u00f2 significava che i dati divulgati non erano disponibili solo per gli autori dell\u2019attacco, ma per chiunque fosse abbastanza esperto da cercarli.<\/p>\n<p>L\u2019obiettivo originale di questa operazione era un archivio appartenente allo scambio di criptovalute Coinbase. Fortunatamente, gli sviluppatori hanno colto la minaccia in tempo e ne hanno impedito la compromissione. Dopo essersi apparentemente resi conto che stavano per perdere il controllo della pipeline tj-actions\/changed-files, gli autori dell\u2019attacco sono passati a un approccio spray-and-pray. Questo ha messo 23.000 archivi a rischio di fuga di segreti. Alla fine, <a href=\"https:\/\/thehackernews.com\/2025\/03\/github-supply-chain-breach-coinbase.html\" target=\"_blank\" rel=\"noopener nofollow\">diverse centinaia<\/a> di questi archivi hanno effettivamente visto le proprie credenziali sensibili esposte al pubblico.<\/p>\n<h2>Aprile 2025: una backdoor nelle 21 estensioni di Magento<\/h2>\n<p>Ad aprile \u00e8 stata <a href=\"https:\/\/www.bleepingcomputer.com\/news\/security\/magento-supply-chain-attack-compromises-hundreds-of-e-stores\/\" target=\"_blank\" rel=\"noopener nofollow\">scoperta<\/a> un\u2019infezione in un\u2019intera gamma di estensioni per Magento, una delle piattaforme pi\u00f9 popolari per la creazione di negozi online. La backdoor era integrata in 21 moduli sviluppati da tre fornitori: Tigren, Meetanshi e MGS. Queste estensioni facevano parte dell\u2019infrastruttura di diverse centinaia di aziende di e-commerce, inclusa almeno una multinazionale.<\/p>\n<p>Secondo i ricercatori che l\u2019hanno scoperta, la backdoor \u00e8 stata in realt\u00e0 installata nel lontano 2019. Ad aprile 2025 gli autori dell\u2019attacco l\u2019hanno finalmente attivata per compromettere i siti Web e caricare shell Web. Ci\u00f2 \u00e8 stato possibile tramite una funzione integrata nelle estensioni che eseguiva codice arbitrario estratto da un file di licenza.<\/p>\n<p>Ironia della sorte, i moduli infetti includevano MGS GDPR e Meetanshi CookieNotice. Come suggeriscono i nomi, queste estensioni sono state progettate per aiutare i siti a rispettare le normative sulla privacy degli utenti e sull\u2019elaborazione dei dati. Alla fine, invece di garantire la privacy, il loro utilizzo ha probabilmente portato al furto dei dati degli utenti e delle risorse finanziarie tramite il <a href=\"https:\/\/www.kaspersky.com\/blog\/illicit-code-on-legitmate-sites\/48509\/\" target=\"_blank\" rel=\"noopener nofollow\">Web skimming<\/a>.<\/p>\n<h2>Maggio 2025: ransomware distribuito tramite un MSP compromesso<\/h2>\n<p>A maggio, i responsabili ransomware della banda DragonForce <a href=\"https:\/\/www.theregister.com\/2025\/05\/28\/dragonforce_ransomware_gang_sets_fire\/\" target=\"_blank\" rel=\"noopener nofollow\">hanno ottenuto l\u2019accesso<\/a> all\u2019infrastruttura di un Managed Service Provider (MSP) anonimo e l\u2019hanno utilizzata per distribuire il proprio ransomware e rubare i dati alle organizzazioni client dell\u2019MSP.<\/p>\n<p>Sembra che gli autori dell\u2019attacco abbiano sfruttato diverse vulnerabilit\u00e0 (incluso un difetto critico) in SimpleHelp, lo strumento di gestione e monitoraggio remoti utilizzato dall\u2019MSP. Queste vulnerabilit\u00e0 sono state scoperte nel 2024 e sono state divulgate pubblicamente e dotate di patch <a href=\"https:\/\/thehackernews.com\/2025\/01\/critical-simplehelp-flaws-allow-file.html\" target=\"_blank\" rel=\"noopener nofollow\">nel gennaio 2025<\/a>. Purtroppo, l\u2019MSP ha evidentemente deciso di non affrettare il processo di aggiornamento, un ritardo che il gruppo di ransomware \u00e8 stato pi\u00f9 che felice di sfruttare.<\/p>\n<h2>Giugno 2025: una backdoor in oltre una decina di popolari pacchetti npm<\/h2>\n<p>All\u2019inizio dell\u2019estate, gli autori dell\u2019attacco hanno violato l\u2019account di uno dei gestori della libreria Gluestack e hanno utilizzato un token di accesso rubato per <a href=\"https:\/\/www.bleepingcomputer.com\/news\/security\/supply-chain-attack-hits-gluestack-npm-packages-with-960k-weekly-downloads\/\" target=\"_blank\" rel=\"noopener nofollow\">iniettare backdoor nei pacchetti da 17 npm<\/a>. Il pi\u00f9 popolare di questi pacchetti, @react-native-aria\/interactions, ha registrato 125.000 download settimanali, mentre tutti i pacchetti compromessi messi insieme hanno superato il milione.<\/p>\n<p>Ci\u00f2 che \u00e8 particolarmente interessante in questo caso sono i passaggi eseguiti dagli sviluppatori Gluestack <a href=\"https:\/\/github.com\/gluestack\/gluestack-ui\/issues\/2894#issuecomment-2955003750\" target=\"_blank\" rel=\"noopener nofollow\">in seguito all\u2019incidente<\/a>: in primo luogo, hanno limitato l\u2019accesso all\u2019archivio GitHub per i contributori secondari; in secondo luogo, hanno abilitato l\u2019autenticazione a due fattori (2FA) per la pubblicazione delle nuove versioni; e in terzo luogo, hanno promesso di implementare pratiche di sviluppo sicure come flusso di lavoro basato su richieste pull, revisioni sistematiche del codice, registrazione di controllo e cos\u00ec via. In altre parole, prima dell\u2019incidente un progetto con centinaia di migliaia di download settimanali non prevedeva misure di questo tipo.<\/p>\n<h2>Luglio 2025: popolari pacchetti npm infettati da un attacco di phishing<\/h2>\n<p>A luglio, <a href=\"https:\/\/www.theregister.com\/2025\/07\/24\/not_pretty_not_windowsonly_npm\/\" target=\"_blank\" rel=\"noopener nofollow\">i pacchetti npm sono stati ancora una volta<\/a> i protagonisti dello spettacolo, incluso il pacchetto \u201cis\u201d, ampiamente utilizzato e sinteticamente chiamato, che vanta 2,7 milioni di download settimanali. Questa libreria di utilit\u00e0 JavaScript fornisce un\u2019ampia gamma di funzioni di controllo del tipo e di convalida dei valori. Per mettere a segno un attacco di phishing nei confronti di uno dei proprietari del progetto, gli autori sono riusciti a utilizzare il trucco pi\u00f9 vecchio del libro: il <a href=\"https:\/\/encyclopedia.kaspersky.com\/glossary\/typosquatting\/\" target=\"_blank\" rel=\"noopener\">typosquatting<\/a> (utilizzando il dominio npnjs.com anzich\u00e9 npmjs.com) e un clone del sito Web ufficiale npm.<\/p>\n<p>Hanno quindi utilizzato l\u2019account compromesso per pubblicare diverse versioni del pacchetto con una backdoor incorporata. L\u2019infezione \u00e8 sfuggita al radar per sei ore: un sacco di tempo per un gran numero di sviluppatori per scaricare i pacchetti dannosi npm.<\/p>\n<p>La stessa tattica di phishing \u00e8 stata implementata anche contro altri sviluppatori. Gli autori dell\u2019attacco hanno sfruttato diversi account sviluppatore compromessi per distribuire <a href=\"https:\/\/www.bleepingcomputer.com\/news\/security\/popular-npm-linter-packages-hijacked-via-phishing-to-drop-malware\/\" target=\"_blank\" rel=\"noopener nofollow\">diverse varianti del proprio carico utile dannoso<\/a>. C\u2019\u00e8 anche il forte sospetto che possano aver risparmiato parte del loro bottino per attacchi futuri.<\/p>\n<h2>Agosto 2025: l\u2019attacco s1ngularity e la divulgazione di centinaia di segreti degli sviluppatori<\/h2>\n<p>Alla fine di agosto, <a href=\"https:\/\/www.kaspersky.com\/blog\/nx-build-s1ngularity-supply-chain-attack\/54223\/\" target=\"_blank\" rel=\"noopener nofollow\">un incidente denominato \u201cs1ngularity\u201d<\/a> ha continuato la tendenza a prendere di mira gli sviluppatori JavaScript. Gli autori dell\u2019attacco hanno compromesso Nx, un popolare sistema di build e strumento di ottimizzazione della pipeline CI\/CD. Il codice dannoso \u00e8 stato iniettato nei pacchetti per cercare una vasta gamma di dati sensibili attraverso i sistemi degli sviluppatori infetti, come chiavi di portafogli di criptovaluta, token npm e GitHub, chiavi SSH, chiavi API e altro ancora.<\/p>\n<p>\u00c8 interessante notare che gli autori dell\u2019attacco hanno utilizzato strumenti di IA installati localmente, come Claude Code, Gemini CLI e Amazon Q, per fiutare i segreti nei computer delle vittime. Tutto ci\u00f2 che hanno trovato \u00e8 stato quindi pubblicato in archivi GitHub pubblici creati a nome delle vittime, utilizzando i titoli \u201cs1ngularity-repository\u201d, \u201cs1ngularity-repository-0\u201d e \u201cs1ngularity-repository-1\u201d. Come avrete intuito, \u00e8 da l\u00ec che deriva il nome dell\u2019attacco.<\/p>\n<p>Di conseguenza, i dati privati di centinaia di sviluppatori sono finiti per rimanere in bella vista, dove potevano accedervi non solo gli autori dell\u2019attacco, ma chiunque disponesse di una connessione Internet.<\/p>\n<h2>Settembre 2025: uno stealer di criptovalute colpisce pacchetti npm che hanno 2,6 miliardi di download settimanali<\/h2>\n<p>La tendenza dei compromessi dei pacchetti npm \u00e8 proseguita fino a settembre. A seguito di una nuova campagna di phishing rivolta agli sviluppatori JavaScript, gli autori dell\u2019attacco sono riusciti a iniettare codice dannoso in alcune decine di progetti di alto profilo. Alcuni di questi, in particolare \u201cchalk\u201d e \u201cdebug\u201d, vantano <em>centinaia di milioni<\/em> di download settimanali; complessivamente, i pacchetti infetti stavano accumulando <a href=\"https:\/\/www.kaspersky.com\/blog\/npm-packages-trojanized\/54280\/\" target=\"_blank\" rel=\"noopener nofollow\">oltre 2,6 miliardi di download a settimana<\/a> al momento della violazione e da allora sono diventati sempre pi\u00f9 popolari.<\/p>\n<p>Il carico utile era uno stealer di criptovalute: un malware progettato per intercettare le transazioni di criptovaluta e reindirizzarle ai portafogli degli autori dell\u2019attacco. Fortunatamente, nonostante siano riusciti a rovinare alcuni dei progetti pi\u00f9 famosi al mondo, gli autori dell\u2019attacco sono riusciti in qualche modo a fallire la fase finale della loro operazione. Alla fine hanno ottenuto solo <a href=\"https:\/\/www.theregister.com\/2025\/09\/09\/npm_supply_chain_attack\/\" target=\"_blank\" rel=\"noopener nofollow\">925 dollari statunitensi<\/a>.<\/p>\n<p>Solo una settimana dopo, un altro grave incidente ha colpito: <a href=\"https:\/\/www.kaspersky.com\/blog\/tinycolor-shai-hulud-supply-chain-attack\/54315\/\" target=\"_blank\" rel=\"noopener nofollow\">la prima ondata del malware autopropagante Shai-Hulud<\/a>, che ha infettato circa pacchetti da 150 npm, inclusi i progetti di CrowdStrike. Tuttavia, la seconda ondata, che ha colpito diversi mesi dopo, si \u00e8 rivelata molto pi\u00f9 distruttiva. Daremo un\u2019occhiata pi\u00f9 da vicino al Great Worm un po\u2019 pi\u00f9 in avanti.<\/p>\n<h2>Ottobre 2025: GlassWorm infetta l\u2019ecosistema di Visual Studio Code<\/h2>\n<p>Circa un mese dopo l\u2019attacco Shai-Hulud, <a href=\"https:\/\/thehackernews.com\/2025\/10\/self-spreading-glassworm-infects-vs.html\" target=\"_blank\" rel=\"noopener nofollow\">un malware a propagazione automatica simile denominato GlassWorm<\/a> ha iniziato a infettare le estensioni di Visual Studio Code sia nel registro Open VSX che in Microsoft Extension Marketplace. Gli autori dell\u2019attacco erano alla ricerca di account GitHub, Git, npm e Open VSX, nonch\u00e9 di chiavi di criptovalute.<\/p>\n<p>I creatori di GlassWorm hanno adottato un approccio altamente creativo alla loro infrastruttura di comando e controllo: hanno utilizzato un portafoglio di criptovaluta sulla blockchain di Solana come C2 principale, con Google Calendar come canale di comunicazione di backup.<\/p>\n<p>Oltre al semplice prosciugamento dei portafogli di criptovaluta delle vittime e all\u2019hijacking dei loro account per diffondere ulteriormente il worm, gli autori dell\u2019attacco hanno anche rilasciato un RAT denominato Zombi sui dispositivi infetti, garantendo loro il controllo totale sui sistemi compromessi.<\/p>\n<h2>Novembre 2025: la campagna IndonesianFoods e 150.000 pacchetti spam su npm<\/h2>\n<p>A novembre <a href=\"https:\/\/www.kaspersky.com\/blog\/indonesianfoods-npm-spam-campaign\/55453\/\" target=\"_blank\" rel=\"noopener nofollow\">\u00e8 emerso<\/a> un nuovo fastidio all\u2019interno del registro npm. Una campagna dannosa coordinata denominata IndonesianFoods ha visto gli autori dell\u2019attacco inondare il registro con decine di migliaia di pacchetti inutili.<\/p>\n<p>L\u2019obiettivo principale in questo caso era utilizzare il sistema per gonfiare le metriche e coltivare token su tea.xyz, una piattaforma blockchain progettata per premiare gli sviluppatori open source. Per riuscirci, gli autori dell\u2019attacco hanno costruito una fitta rete di progetti interdipendenti i cui nomi fanno riferimento alla cucina indonesiana, come <a href=\"https:\/\/it.wikipedia.org\/wiki\/Tapai_(gastronomia)\" target=\"_blank\" rel=\"noopener nofollow\">zultapai<\/a> 9-kyuki o <a href=\"https:\/\/it.wikipedia.org\/wiki\/Rendang\" target=\"_blank\" rel=\"noopener nofollow\">andirendang<\/a> 23-breki.<\/p>\n<p>I creatori di questa campagna non si sono preoccupati dell\u2019hijacking degli account. A rigor di termini, i pacchetti spam non contenevano nemmeno un carico utile dannoso, a meno che non si conteggi uno script progettato per generare automaticamente nuovi pacchetti ogni sette secondi. Tuttavia, l\u2019incidente \u00e8 servito a ricordare quanto sia vulnerabile l\u2019infrastruttura npm alle campagne di spam su larga scala.<\/p>\n<h2>Dicembre 2025: Shai-Hulud 2.0 e la fuga di 400.000 segreti degli sviluppatori<\/h2>\n<p>L\u2019headliner assoluto dell\u2019anno, non solo per gli attacchi alla supply chain, ma probabilmente per l\u2019intero campo della sicurezza informatica, \u00e8 stato il malware autopropagante <a href=\"https:\/\/securelist.com\/shai-hulud-worm-infects-500-npm-packages-in-a-supply-chain-attack\/117547\/\" target=\"_blank\" rel=\"noopener\">Shai-Hulud<\/a> (noto anche come Sha1-Hulud) destinato agli sviluppatori.<\/p>\n<p>Questo malware era la logica evoluzione dell\u2019attacco s1ngularity di cui abbiamo parlato prima: setaccia inoltre i sistemi alla ricerca di segreti di ogni tipo e li pubblica in archivi GitHub aperti. Shai-Hulud ha tuttavia aggiunto un meccanismo di auto-propagazione a questa previsione: il worm infetta i progetti controllati da sviluppatori gi\u00e0 compromessi utilizzando le relative credenziali rubate.<\/p>\n<p>La prima ondata di Shai-Hulud ha colpito a settembre, infettando diverse centinaia di pacchetti npm. Ma verso la fine dell\u2019anno \u00e8 arrivata una seconda ondata, soprannominata <a href=\"https:\/\/securelist.com\/shai-hulud-2-0\/118214\/\" target=\"_blank\" rel=\"noopener\">Shai-Hulud 2.0<\/a>.<\/p>\n<p>Questa volta il worm \u00e8 stato aggiornato con la funzionalit\u00e0 wiper. Se il malware non riusciva a trovare token npm o GitHub validi in un sistema infetto, attivava un carico utile distruttivo che cancellava i file dell\u2019utente.<\/p>\n<p>In totale sono stati divulgati <a href=\"https:\/\/www.bleepingcomputer.com\/news\/security\/shai-hulud-20-npm-malware-attack-exposed-up-to-400-000-dev-secrets\/\" target=\"_blank\" rel=\"noopener nofollow\">circa 400.000 segreti<\/a> a seguito dell\u2019attacco. Vale la pena notare che, proprio come con s1ngularity, tutti questi dati sensibili finivano in archivi pubblici dove potevano essere scaricati non solo dagli autori degli attacchi ma da chiunque altro. Ed \u00e8 molto probabile che le ricadute di questo attacco si faranno sentire per molto tempo a venire.<\/p>\n<p>Uno dei primi casi confermati di exploit che utilizzava segreti divulgati da Shai-Hulud \u00e8 stato un furto di criptovaluta rivolto a diverse migliaia di utenti di Trust Wallet. Gli utenti malintenzionati hanno utilizzato questi segreti la vigilia di Natale per caricare una versione dannosa dell\u2019estensione Trust Wallet, completa di un <a href=\"https:\/\/www.kaspersky.it\/blog\/what-is-a-crypto-wallet-drainer\/28517\/\" target=\"_blank\" rel=\"noopener\">crypto drainer<\/a> integrato, nel Chrome Web Store. Alla fine, sono riusciti a cavarsela con 8,5 milioni di dollari in criptovaluta.<\/p>\n<h2>Come proteggersi dagli attacchi supply chain<\/h2>\n<p>Durante l\u2019elaborazione <a href=\"https:\/\/www.kaspersky.com\/blog\/supply-chain-attacks-in-2024\/52965\/\" target=\"_blank\" rel=\"noopener nofollow\">di una retrospettiva simile per il 2024<\/a>, abbiamo riscontrato che attenersi a una struttura \u201cun mese, una minaccia\u201d \u00e8 abbastanza facile. Per il 2025, tuttavia, si trattava di un ordine molto pi\u00f9 alto. L\u2019anno scorso ci sono stati cos\u00ec tanti massicci attacchi alla supply chain che semplicemente non siamo riusciti a inserirli tutti in questa panoramica.<\/p>\n<p>L\u2019anno 2026 si preannuncia come un anno altrettanto intenso, quindi \u00e8 consigliabile consultare il nostro post dedicato sulla <a href=\"https:\/\/www.kaspersky.com\/blog\/supply-chain-attacks-what-are-they-and-how-to-manage-the-risk\/52852\/\" target=\"_blank\" rel=\"noopener nofollow\">prevenzione degli attacchi alla supply chain<\/a>. Nel frattempo, ecco i punti principali da seguire:<\/p>\n<ul>\n<li>Valuta attentamente i fornitori e controlla attentamente il codice integrato nei propri progetti.<\/li>\n<li>Implementa severi requisiti di sicurezza direttamente nei contratti di servizio.<\/li>\n<li>Sviluppa un piano completo di reazione agli incidenti.<\/li>\n<li>Monitora l\u2019infrastruttura aziendale per rilevare attivit\u00e0 sospette utilizzando una <a href=\"https:\/\/www.kaspersky.it\/next?icid=it_kdailyplacehold_acq_ona_smm__onl_b2b_kdaily_prodmen_sm-team___knext___\" target=\"_blank\" rel=\"noopener\">soluzione XDR<\/a>.<\/li>\n<li>Se il team di sicurezza interna \u00e8 ristretto, sfrutta un <a href=\"https:\/\/www.kaspersky.it\/enterprise-security\/managed-detection-and-response?icid=it_kdailyplacehold_acq_ona_smm__onl_b2b_kasperskydaily_wpplaceholder_______\" target=\"_blank\" rel=\"noopener\">servizio esterno per la ricerca proattiva delle minacce e una risposta tempestiva<\/a>.<\/li>\n<\/ul>\n<p>Per saperne di pi\u00f9 sugli attacchi alla supply chain, ti invitiamo a consultare il nostro rapporto analitico <a href=\"https:\/\/kas.pr\/k8rs\" target=\"_blank\" rel=\"noopener\">Reazione della supply chain: proteggere l\u2019ecosistema digitale globale in un\u2019era di interdipendenza<\/a>. Si basa sugli approfondimenti di esperti tecnici e rivela con quale frequenza le organizzazioni affrontano rischi nella supply chain e nelle relazioni di fiducia, dove permangono lacune nella protezione e quali strategie adottare per migliorare la resilienza a questo tipo di minacce.<\/p>\n<input type=\"hidden\" class=\"category_for_banner\" value=\"kaspersky-next\">\n","protected":false},"excerpt":{"rendered":"<p>Nel 2025, proprio come l&#8217;anno precedente, gli attacchi alla supply chain sono rimasti una delle minacce pi\u00f9 gravi per le organizzazioni. Analizziamo gli incidenti pi\u00f9 degni di nota dello scorso anno.<\/p>\n","protected":false},"author":2726,"featured_media":30583,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2364,2955,2956],"tags":[20,3723,3812,775,3779,638,3003,1522,3167,3076,1653,584],"class_list":{"0":"post-30576","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-attacchi","11":"tag-attacco-alla-supply-chain","12":"tag-azienda","13":"tag-backdoor","14":"tag-devops","15":"tag-minacce","16":"tag-open-source","17":"tag-rischi","18":"tag-stealer","19":"tag-supply-chain","20":"tag-sviluppo","21":"tag-vulnerabilita"},"hreflang":[{"hreflang":"it","url":"https:\/\/www.kaspersky.it\/blog\/supply-chain-attacks-in-2025\/30576\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/supply-chain-attacks-in-2025\/31975\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/supply-chain-attacks-in-2025\/41594\/"},{"hreflang":"tr","url":"https:\/\/www.kaspersky.com.tr\/blog\/supply-chain-attacks-in-2025\/14440\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/supply-chain-attacks-in-2025\/55522\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/supply-chain-attacks-in-2025\/24864\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/supply-chain-attacks-in-2025\/33349\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/supply-chain-attacks-in-2025\/30458\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.it\/blog\/tag\/attacco-alla-supply-chain\/","name":"attacco alla supply-chain"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/30576","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\/2726"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/comments?post=30576"}],"version-history":[{"count":1,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/30576\/revisions"}],"predecessor-version":[{"id":30584,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/30576\/revisions\/30584"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/media\/30583"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/media?parent=30576"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/categories?post=30576"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/tags?post=30576"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}