Ormai nessuna azienda crea applicazioni o servizi software usando codice sviluppato completamente al suo interno. Anche le software house adottano componenti sviluppati da altri, in particolare elementi open source che sono liberamente disponibili sui principali repository come GitHub. Questo approccio al riuso è corretto e porta molti vantaggi, tanto che si è esteso anche all'utilizzo di componenti software virtualizzate in container. Ha però anche generato un nuovo tipo di attacchi all'integrità dei sistemi, i cosiddetti supply chain attack.

La definizione di supply chain attack è in effetti molto ampia. Indica qualsiasi tipo di attacco verso un'azienda che faccia leva sulla debolezza di un componente della sua supply chain, quale essa sia. Può essere un attacco IT tradizionale ma "laterale", che passa attraverso la rete di un partner commerciale meno attento alla sicurezza. O può essere anche un attacco via hardware, come quello che secondo Bloomberg hanno subito molte aziende americane perché hacker ostili cinesi avrebbero inserito chip-spia nelle schede madri di Supermicro, fornitore di aziende del calibro di Apple e Amazon.

I supply chain attack legati alla "catena del valore" dello sviluppo software hanno una natura specifica. In qualche modo l'attaccante riesce a inserirsi nella sequenza dei passi dello sviluppo software, di solito violando la sicurezza di un repository indipendente e facendo così in modo che molte aziende in un colpo solo usino componenti insicuri. Questi componenti sono fatti in modo da generare falle nella sicurezza o contengono direttamente backdoor tramite cui penetrare nelle aziende-bersaglio.
I vettori principali dei supply chain attack secondo il NIST statunitenseI supply chain attack collegati al software riguardano in maggioranza componenti open source, non perché questo sia più insicuro del software commerciale ma perché è più "produttivo" violare i repository open source rispetto a quelli delle software house commerciali. Un componente open source può essere scaricato e installato decine o centinaia di migliaia di volte al mese, aumentando di conseguenza il numero di bersagli potenziali. Violare la catena di distribuzione di un software commerciale è possibile - è infatti successo molte volte - ma più complesso e per un numero di violazioni potenziali decisamente inferiore.

Sono considerati supply chain attack anche quelli che più semplicemente vedono gli attaccanti sfruttare vulnerabilità generiche dei componenti software usati dalle aziende, ossia vulnerabilità che non sono state create dagli attaccanti stessi. Apache Struts, un framework per la realizzazione di applicazioni web in Java, ha il dubbio onore di essere il simbolo di attacchi di questo genere, dato che una sua vulnerabilità non corretta in tempo ha portato alla violazione dei sistemi di Equifax.

I supply chain attack riguardano anche le piattaforme che gli sviluppatori usano per gestire i loro ambienti di sviluppo o di distribuzione e messa in produzione delle applicazioni. Jenkins, la piattaforma open source di riferimento per le fasi di integration/delivery, è già stata oggetto di attacco. In campo virtualizzazione, sono già state sfruttate vulnerabilità di Kubernetes per attivare container "ombra" nei datacenter di aziende ignare.
Il numero di componenti software differenti ospitati da alcuni repository (da Sonatype)Il 2017 è stato l'anno in cui i supply chain attack sono passati alla ribalta, per il caso Equifax ma anche per diverse violazioni di alcune fonti di primo piano per componenti open source. E questo 2018 ha visto semplicemente rafforzarsi il trend. Gli attacchi sono stati di vario tipo, spaziando dai più ingegnosi a quelli veramente banali. Ecco alcuni esempi significativi.

Typosquatting - Sui repository nbm (per JavaScript) e PyPI (per Python) sono state caricate librerie che avevano un nome quasi identico ad altre lecite, ma progettate per rubare le credenziali degli utenti dei repository stessi. Chi le scaricava non badando alla denominazione leggermente diversa, veniva infettato.
Furto dell'account - Hacker ostili sono riusciti a impadronirsi degli account di gestione di progetti leciti su repository come GitHub o npm. In questo modo hanno potuto distribuire versioni "ostili" dei relativi componenti software.

Componenti-malware - Sui repository più importanti sono stati caricati componenti software che promettevano di svolgere una determinata funzione lecita ma che contenevano anche backdoor per l'installazione di malware. I casi più insidiosi sono quelli in cui il componente "ostile" viene presentato come derivazione di un progetto noto e lecito, anche se non di primo piano per evitare troppa attenzione.
Container-malware - È un po' la nuova frontiera: le tecniche sono quelle già adottate per i repository di librerie e componenti software, ma applicate ai repository di container come DockerHub. Nei casi più noti sono stati scaricati container Docker che integravano una backdoor, usata poi per scaricare altri container che eseguivano operazioni di cryptomining.