Gli attacchi alla supply chain del software stanno diventando sempre più diffusi e devastanti. Ad esempio, Gartner prevede che il 45% di tutte le aziende subirà una violazione entro il 2025. Inoltre, Cybersecurity Ventures sottolinea la gravità di questa minaccia, prevedendo danni annuali pari a ben 138 miliardi di dollari entro il 2031. Nel complesso, queste previsioni evidenziano l'urgente necessità per le organizzazioni di dare priorità software supply chain security e implementare misure efficaci per proteggere dati sensibili, operazioni e reputazione.
Perché moderno pipelinedipendono fortemente da componenti esterni, l'aumento delle librerie di terze parti, cicli di sviluppo software più rapidi, catene di fornitura complesse, mancanza di visibilità, nuove tecniche di attacco, adozione di SaaS e risorse limitate sono tutti fattori che determinano l'aumento di attacchi alla catena di fornitura del softwarePertanto, le organizzazioni devono adottare un approccio completo e attivo per affrontare queste sfide e proteggere le proprie catene di fornitura del software.
Che cos'è un attacco alla catena di fornitura del software?
ENISA definisce Attacco alla catena di fornitura del software as "una compromissione di una risorsa particolare, ad esempio l'infrastruttura di un fornitore di software e un software commerciale, per danneggiare indirettamente un determinato obiettivo o obiettivi, ad esempio i clienti del fornitore di software." In altre parole, un attacco alla supply chain del software è un'attività dannosa che prende di mira la supply chain del software, con l'obiettivo di compromettere e inserire vulnerabilità o malware nel processo di sviluppo e distribuzione. Di conseguenza, questo tipo di attacco sfrutta la rete interconnessa e spesso complessa di processi, strumenti ed entità coinvolti nella creazione e distribuzione del software.
Componenti e concetti chiave relativi a un attacco alla catena di fornitura del software
La letteratura sull'intelligence sulle minacce informatiche e sulla sicurezza informatica spesso fallisce attacchi alla catena di fornitura del software in categorie distinte per una migliore analisi e difesa. Di conseguenza, questa sezione introduce i cinque concetti chiave definiti dall' Catalogo dei modelli di attacco MITREQuesto catalogo struttura i modelli di attacco alla supply chain per facilitare l'analisi utilizzando varie fonti, tra cui le minacce avversarie raccolte dal NIST.
Atto di attacco: il cosa
L'atto di attacco è l'azione specifica che trasmette un payload o un'intenzione dannosa a un sistema. Di conseguenza, produce un danno diretto.
- Esempio 1: Malware inserito nel software di sistema durante il processo di compilazione.
- Esempio 2: Requisiti di sistema o documenti di progettazione modificati in modo fraudolento.
Vettore di attacco: il come
Il vettore di attacco è il metodo utilizzato dagli aggressori per sfruttare vulnerabilità o debolezze dei processi. Di conseguenza, mostra come gli aggressori accedono e sfruttano la superficie di attacco.
- Esempio 1: un aggressore modifica il codice sorgente in un repository compromesso.
- Esempio 2: un aggressore ottiene l'accesso non autorizzato alla documentazione tecnica interna.
Esplora ulteriormente nel nostro Glossario dei vettori di attacco per ulteriori approfondimenti.
Origine dell'attacco: The Who
L'origine identifica la fonte dell'attacco. Pertanto, chiarisce il ruolo, lo stato o la relazione dell'aggressore con il sistema.
- Esempio 1: un insider con accesso privilegiato per creare server modifica uno script.
- Esempio 2: un agente di minaccia esterno carica un pacchetto trojanizzato su un registro pubblico.
Obiettivo di attacco: il perché
L'obiettivo spiega il motivo dell'attacco. Soprattutto, evidenzia ciò che gli avversari vogliono ottenere.
- Interruzione: interruzione di servizi o build.
- Corruzione: riduzione della fiducia mediante la modifica di artefatti o codice sorgente.
- Divulgazione: divulgazione di segreti sensibili o di proprietà intellettuale.
Impatto dell'attacco: le conseguenze
Infine, l'impatto descrive i risultati di un attacco, mostrando le conseguenze per i fornitori di software e i clienti.
- Esempio 1: qualsiasi progetto che utilizzi un programma non valido verrà danneggiato in seguito.
- Esempio 2: le persone installano software dannoso nei loro sistemi di lavoro senza saperlo.
Attacchi più comuni alla catena di fornitura software
Numerosi tipi di attacchi alla catena di fornitura del software esistono e le organizzazioni devono essere consapevoli dei vari vettori di minaccia in ogni fase del ciclo di vita. Sulla base di il framework SLSA, l'Istituto Nazionale di Stati Uniti Standarde tecnologia (NIST)e l'Agenzia per la sicurezza informatica e delle infrastrutture (CISA), queste minacce possono essere raggruppate in quattro categorie: rischi di origine, di build, di pacchetto e di dipendenza.
Attacchi alla catena di fornitura del software nella fase di origine
- Invia codice errato → scopri come Richiesta di Flask. Ottieni uso improprio or difetti di deserializzazione non sicuri creare superfici di attacco diretto.
- Compromettere il repository di origine
- Costruisci da una fonte modificata
- Scrivi codice non sicuro
- Manomissione di file critici → come spiegato in analisi backdoor chmod 777.
Attacchi alla catena di fornitura del software nella fase di sviluppo
Nel Fase di costruzione, gli sviluppatori compilano e integrano il codice in una versione funzionante. Perché questa fase è così critica che i rischi includono il saltare i controlli di sicurezza nel CI/CD pipeline, modificando il codice dopo il controllo della versione o compromettendo il processo di compilazione. conseguentemente, il codice dannoso può intrufolarsi negli artefatti senza essere notato.
- Aggirare CI/CD → collegato a Malware precompilato su GitHub.
- Modificare il codice dopo il controllo del codice sorgente
- Processo di compilazione compromesso → mitigato con Rilevamento precoce degli allarmi DevSecOps.
- Compromettere il repository degli artefatti
Attacchi alla catena di fornitura del software nella fase di confezionamento
Migliori Fase del pacchetto È quando mettiamo insieme tutto il codice per creare il prodotto finale. Questa fase è rischiosa perché qualcuno potrebbe utilizzare pacchetti dannosi o modificare i siti online da cui li reperiamo. Gli aggressori possono persino caricare versioni dannose di pacchetti popolari su questi siti web.
- Usa pacchetto compromesso → coperto in valutazioni degli scanner di malware.
- Compromettere il registro dei pacchetti
- Carica pacchetto modificato → analizzato in Malware generatore falso Namso-gen.
Attacchi alla catena di fornitura del software nella fase di dipendenza
Nel Fase di dipendenza, aggiungiamo librerie e pacchetti di terze parti al nostro software. Questa fase è rischiosa perché eventuali problemi in queste parti possono facilmente e silenziosamente diffondersi al resto del progetto.
- Utilizzare la dipendenza compromessa → spiegato con Rischi DoS nelle dipendenze offuscate.
- Dipendenze obsolete o vulnerabili
- Rischi di dipendenza transitiva
- Registri di pacchetti dannosi → mitigati con Strumenti di sicurezza DevOps and gestione del rischio di terze parti.
Rischi comuni della catena di fornitura in ogni fase della SDLC
| Stage | Minacce tipiche | Esempio |
|---|---|---|
| Fonte |
• Invio di codice dannoso o non sicuro • Manomissione di file critici • Compromissione del repository sorgente |
XcodeGhost (2015): codice dannoso iniettato nel compilatore Xcode di Apple, che si diffonde nelle app iOS. |
| Costruiamo |
• Bypassare CI/CD controlli di sicurezza • Modifica del codice dopo il controllo del codice sorgente • Compromissione dei repository di artefatti |
SolarWinds Orion (2020): gli aggressori si sono infiltrati nella build pipeline, inserendo una backdoor negli aggiornamenti software firmati. |
| CONFEZIONE |
• Caricamento dei pacchetti modificati • Registri dei pacchetti di avvelenamento • Distribuzione di artefatti compromessi |
EventStream NPM (2018): L'aggressore ha inserito una backdoor in un popolare pacchetto NPM scaricato migliaia di volte. |
| Dipendenza |
• Utilizzo di dipendenze obsolete o vulnerabili • Sfruttamento delle dipendenze transitive • Pubblicazione di pacchetti sosia dannosi |
XZ Utils Backdoor (2024): una libreria di compressione trojanizzata è stata quasi distribuita a valle nelle distribuzioni Linux. |
Tecniche comuni di attacco alla catena di fornitura del software
Secondo il CISSecondo un rapporto del NIST, gli attacchi alla supply chain del software rientrano spesso in tre categorie principali.
Tuttavia, recenti incidenti evidenziano ulteriori vettori che gli sviluppatori devono comprendere.
Di seguito approfondiremo le tecniche più rilevanti con esempi pratici.
Aggiornamenti di dirottamento
Gli aggressori compromettono i meccanismi di aggiornamento legittimi per distribuire malware.
Ad esempio, l'attacco NotPetya del 2017 ha abusato del server di aggiornamento del software fiscale ucraino MEDoc, fornendo
malware wiper distruttivo mascherato da patch. Per difendersi da questo rischio, i team dovrebbero applicare rilevamento e risposta alle minacce per DevOps pratiche che segnalano comportamenti anomali nei flussi di aggiornamento.
Minare la firma del codice
Questa tecnica consiste nell'abuso o nel furto di certificati di firma validi per far apparire legittimo il codice dannoso.
Un caso degno di nota è stato il compromesso di CCleaner nel 2017, in cui gli aggressori hanno distribuito software trojanizzato firmato con certificati validi.
Di conseguenza, le organizzazioni necessitano di controlli di integrità unificati come quelli descritti in strategie della piattaforma di sicurezza informatica
Compromettere il codice open source
Gli avversari inseriscono backdoor nei pacchetti open source più diffusi, che vengono poi inseriti in migliaia di progetti.
L'incidente EventStream NPM e la backdoor XZ Utils (2024) dimostrano quanto questo vettore sia diventato critico.
Gli sviluppatori dovrebbero rivedere risorse come Domande frequenti sulla sicurezza NPM and incidenti di pacchi typosquatted per imparare come evitare dipendenze avvelenate.
Confusione delle dipendenze
Descritto per la prima volta da Alex Birsan nel 2021, questo attacco sfrutta le collisioni di nomi tra registri di pacchetti interni e pubblici, inducendo i sistemi di compilazione a estrarre versioni dannose anziché pacchetti interni attendibili.
Typosquatting e pacchetti dannosi
Gli aggressori pubblicano pacchetti dannosi con nomi simili a quelli delle librerie più diffuse (ad esempio, "reqeusts" invece di "requests").
Gli sviluppatori li installano accidentalmente, introducendo malware nei loro progetti.
Un esempio reale è analizzato in Malware Namso-gen e nella nostra lista di scanner antimalware open source.
Costruiamo Pipeline manomissione
Come si è visto nel caso del compromesso SolarWinds Orion, gli aggressori possono infiltrarsi nei server di compilazione per iniettare codice dannoso durante la compilazione.
Ciò rende l'intera catena di artefatti firmati inaffidabile. Le tecniche di prevenzione includono il monitoraggio CI/CD integrità con rilevamento di allerta precoce e analizzare
Campagne anti-malware pre-compilate su GitHub.
Come si manifesta un attacco alla supply chain del software: il caso SolarWinds
Soprattutto, l'attacco SolarWinds Orion è l'esempio più noto di violazione della supply chain del software. Mostra come gli aggressori possano procedere passo dopo passo nel processo di sviluppo e, di conseguenza, diffondere codice dannoso a migliaia di utenti.
Per prima cosa, gli aggressori sono riusciti a entrare nei server di build di SolarWinds.
Dopodiché, hanno aggiunto silenziosamente codice dannoso negli aggiornamenti di Orion.
Poiché questi aggiornamenti venivano firmati e distribuiti come software attendibili, molte aziende li installavano senza essere consapevoli del rischio.
In totale, sono state colpite più di 18,000 organizzazioni e gli aggressori hanno ottenuto l'accesso a sistemi molto sensibili.
Dal punto di vista di uno sviluppatore, questo attacco offre tre semplici lezioni:
- Le difese perimetrali non bastano: gli aggressori hanno cambiato la build pipeline stessa.
- I controlli continui sono fondamentali: sicuro build attestations, i controlli di integrità e il rilevamento delle anomalie aiutano a bloccare le manomissioni.
- Una build avvelenata può diventare globale: un singolo pipeline un compromesso può creare una crisi di sicurezza mondiale.
Xygeni: la piattaforma AppSec all-in-one definitiva
Poiché gli attacchi alla catena di fornitura del software possono colpire in ogni fase del SDLC,
la piattaforma AppSec all-in-one, Xygeni, protegge le fasi di origine, build, pacchettizzazione e dipendenza. Offre a sviluppatori e team di sicurezza un unico punto di riferimento per prevenire, rilevare e correggere i rischi in modo semplice. Di conseguenza, non è più necessario destreggiarsi tra più strumenti: Xygeni copre l'intero ciclo di vita.
Protezione della fase sorgente
Nella fase di origine, i rischi includono la non sicurezza commits, repository avvelenati o file alterati. Xygeni scansiona il codice in tempo reale con profondo SAST e rilevamento dei segreti.
Blocca anche i dannosi commitè finito CI/CD guardrails.
In questo modo, i problemi vengono bloccati prima ancora che lascino il repository.
Protezione della fase di costruzione
Durante la fase di compilazione, gli aggressori potrebbero tentare di aggirare pipelineo alterare gli artefatti.
Xygeni protegge il processo di compilazione con controlli conformi a SLSA, convalida dell'integrità e firme senza chiave. Controlla anche comportamenti insoliti all'interno CI/CD lavori. Di conseguenza, le build manomesse vengono segnalate immediatamente e bloccate prima del rilascio.
Protezione della fase di imballaggio
Nella fase di pacchetto, i registri compromessi o le librerie modificate spesso introducono malware. Rilevamento malware e scansione delle licenze di Xygeni rivedere ogni artefatto, mentre AutoFix suggerisce percorsi di aggiornamento sicuri con la sua analisi del rischio di bonifica. Solo i pacchetti verificati e conformi avanzano nel pipeline.
Protezione della fase di dipendenza
Il codice di terze parti rappresenta la superficie di attacco più grande. Analisi della composizione del software di Xygeni (SCA) Non si limita a elencare i CVE, ma verifica anche se il codice rischioso può essere effettivamente sfruttato. Segnala anche malware nascosti e dipendenze transitive rischiose. Soprattutto, questo garantisce che gli sviluppatori distribuiscano solo dipendenze sicure.
Segreti e sicurezza delle infrastrutture
Oltre al codice e ai pacchetti, gli attacchi spesso sfruttano segreti trapelati o infrastrutture deboli. Xygeni esegue la scansione per individuare chiavi, token e credenziali esposte nel codice, nelle configurazioni e nei livelli Docker. Può anche convalidare e revocare automaticamente i segreti trapelati con Rimedio AutoFix. Allo stesso tempo, IaC scansione impedisce configurazioni errate di cui gli aggressori potrebbero in seguito abusare.
Rilevamento e correzioni più intelligenti
La maggior parte degli strumenti si ferma agli avvisi. Xygeni va oltre. Il suo motore AutoFix crea patch sicure, pull requestso una guida dettagliata a seconda del problema. La visualizzazione del rischio di correzione mostra anche quale versione della patch è più sicura, in modo che i team risolvano i problemi senza aggiungerne di nuovi.
Una piattaforma unificata
Perché Xygeni combina SAST, SCA, rilevamento malware, gestione dei segreti, IaC scansione, rilevamento delle anomalie e controlli di build sicuri in un'unica piattaforma AppSec,
fornisce una copertura completa su tutto il SDLCSia gli sviluppatori che i team di sicurezza ottengono un'unica fonte di verità con visibilità chiara, soluzioni pratiche e una solida protezione contro gli attacchi alla supply chain.
Tutte le cose considerate, Xygeni, la piattaforma AppSec all-in-one definitiva, aiuta i team a sviluppare rapidamente e a rimanere al sicuro. Proteggendo le fasi di origine, build, pacchettizzazione e dipendenza e aggiungendo correzioni automatiche a ogni passaggio, garantisce che gli attacchi alla supply chain del software vengano bloccati prima che raggiungano la produzione.
