Attacchi alla Supply Chain del Software: minacce nel flusso di sviluppo e come proteggere la tua PMI

Gli attacchi alla supply chain del software rappresentano una delle minacce più insidiose e in crescita nel panorama della cybersecurity globale. Ogni attacco ha una sua storia, alcuni originano da una credenziale esposta in un'immagine Docker, altri dalla compromissione della postazione di uno sviluppatore software. Le possibilità sono infinite. Sentiamo continuamente notizie di package Python malevoli caricati su PyPI, e questo è un bene – non i package malevoli, ovviamente, ma la crescente consapevolezza nella comunità. Tuttavia, come consulente sicurezza informatica specializzato nell'assistere le PMI italiane, sottolineo che non basta cercare package sospetti nelle piattaforme da cui consumiamo le nostre dipendenze. È fondamentale comprendere la natura di un attacco alla supply chain, identificare i punti di esposizione specifici della propria organizzazione e difendersi proattivamente in ogni fase. Gli attaccanti oggi dispongono di numerosi punti di ingresso, dal laptop dello sviluppatore fino al momento in cui il codice viene eseguito in produzione. Questo articolo mira ad aumentare la consapevolezza su questi rischi, analizzando ogni fase del flusso di sviluppo.

Stai cercando un Consulente Cyber Security esperto per la tua Azienda? Nel mio profilo professionale trovi la mia esperienza e le competenze specifiche per aiutarti a proteggere il tuo business. Contattami per una consulenza.

Il flusso di sviluppo software: una catena di potenziali vulnerabilità

Prima di addentrarci nelle minacce specifiche, ricapitoliamo brevemente le fasi tipiche del ciclo di vita dello sviluppo software, ognuna delle quali può nascondere insidie per la supply chain:

1. IDE (Integrated Development Environment): l'ambiente dove lo sviluppatore PHP, sviluppatore Laravel o sviluppatore Symfony scrive il codice.
2. SCM (Source Code Management): sistemi come Git, usati per versionare e archiviare il codice sorgente, spesso su piattaforme come GitHub o GitLab.
3. Registry: le piattaforme da cui si scaricano dipendenze e librerie (es. npm per Node.js, Packagist per PHP/Composer, PyPI per Python, Docker Hub per immagini Docker).
4. CI/CD (Continuous Integration/Continuous Deployment): processi e strumenti (Jenkins, GitHub Actions, Travis CI) che automatizzano la compilazione, il test e il rilascio del software.
5. Artifacts: i package o le immagini compilate, pronte per la distribuzione o l'esecuzione. La sicurezza qui dipende se si è consumatori o fornitori del package.
6. Runtime: l'ambiente di produzione dove il codice viene eseguito (server Debian/Ubuntu, container Docker, cluster Kubernetes).

In questo articolo, esploreremo vulnerabilità e tecniche di attacco reali o potenziali per ciascuna di queste fasi (eccetto il runtime, che meriterebbe una trattazione a parte), basandoci su ricerche e casi concreti.

Fase IDE: quando l'estensione di VS Code diventa un Trojan

L'IDE è il cuore pulsante del lavoro di ogni sviluppatore. Tra i molti editor di codice (Sublime Text, IntelliJ IDEA), Visual Studio Code (VS Code) è il più popolare: secondo un sondaggio di Stack Overflow, oltre il 74% degli sviluppatori lo utilizza come IDE principale. La sua potenza risiede non solo nelle funzionalità native, ma soprattutto nel vasto ecosistema di estensioni disponibili sul Marketplace, che spaziano dalla formattazione del codice all'integrazione con Git e strumenti di debug.

L'installazione è semplice: si cerca l'estensione desiderata sul Marketplace (via web o direttamente da VS Code) e si installa. Ma qui sorge una domanda cruciale per un consulente cyber security: quanto sono sicure queste estensioni?

Il parallelismo con i package npm e la scarsa consapevolezza

Quando si parla di package npm, l'associazione con versioni malevole è quasi immediata. Una ricerca su Google per "malicious npm packages" restituisce innumerevoli risultati su furti di credenziali, token, o installazione di cryptominer. Questa attenzione è positiva. Ma cosa succede cercando "malicious VS Code extensions"? I risultati sono scarsi. Si trovano informazioni su estensioni vulnerabili, ma è importante distinguere: vulnerabile non significa intenzionalmente malevolo.

Un'estensione VS Code ha gli stessi permessi dell'utente che la esegue. Può fare qualsiasi cosa: eseguire ransomware, leggere file sensibili, utilizzare le chiavi SSH dello sviluppatore per connettersi a repository privati su GitHub, diventando un perfetto cavallo di Troia.

Impersonare estensioni popolari: il caso "Prettier"

Per dimostrare la facilità di ingannare gli sviluppatori, alcuni ricercatori hanno scelto di impersonare "Prettier", una delle estensioni VS Code più installate. Hanno caricato sul Marketplace una versione fittizia chiamata "Pretier" (con una 't') e, in un altro caso, una con un nome visualizzato identico ma ID publisher differente.

Confrontando le due pagine sul Marketplace, quella legittima e quella malevola, le differenze erano minime. L'URL presentava una lieve modifica, ma il nome dell'editore e il nome visualizzato dell'estensione (proprietà non univoche) potevano essere resi identici. Anche se il numero di installazioni e le recensioni sono un buon indicatore, possono essere falsificati o gonfiati.

Microsoft stessa, nelle sue linee guida su "Posso fidarmi delle estensioni dal Marketplace?", suggerisce di controllare il repository collegato. Tuttavia, i ricercatori sono riusciti a far puntare la loro estensione malevola allo stesso repository di quella legittima, rendendo questo controllo inutile.

La strategia di typosquatting si è rivelata efficace: cercando "Britier" (con una 't' mancante) sul Marketplace, l'estensione malevola era l'unico risultato, mostrando peraltro il nome visualizzato corretto "Prettier" [con due 't'](cite: 1). Un Proof-of-Concept (POC) caricato come "Pretier" (con una 't') che inviava semplicemente un ping all'installazione ha registrato oltre 1000 installazioni da sviluppatori di tutto il mondo in sole 48 ore. Ognuno di questi sviluppatori avrebbe potuto essere il punto di ingresso per un attacco alla supply chain della propria organizzazione.

La fallacia del "Verified Sign"

Il Marketplace di VS Code presenta un'icona di "Verificato" accanto ad alcuni editori, simile a quella vista su Instagram o Twitter per account autentici. L'associazione intuitiva è che la piattaforma abbia validato l'identità dell'editore. Tuttavia, i requisiti per ottenere questo badge erano sorprendentemente permissivi:

1. Scegliere un editore da verificare.
2. Inserire un dominio idoneo (qualsiasi dominio).
3. Dimostrare la proprietà di quel dominio.

Questo significava che chiunque, come l'utente "SemiCloud" con un'estensione da due installazioni citato nella ricerca, poteva ottenere il badge verificato. Un attaccante avrebbe potuto ottenere il badge e poi modificare il nome visualizzato dell'editore per impersonare un'entità fidata [es. "Prettier"](cite: 1).

A seguito della pubblicazione di questa ricerca, Microsoft ha aggiunto una nota specificando che la modifica del nome visualizzato comporta la revoca del badge. Inoltre, l'estensione "Prettier" originale ha successivamente ottenuto il badge verificato, che prima non aveva. Questi sono passi positivi, ma il problema di fondo sulla reale rappresentatività del badge rimane in parte.

Anatomia di un'estensione VS Code e rischi intrinseci

Un file di estensione VS Code (.vsix) è semplicemente un archivio ZIP. Al suo interno, un file cruciale è package.json, proprio come nei package npm. Un'estensione VS Code è, a tutti gli effetti, un package npm sotto mentite spoglie, ereditandone tutti i rischi, inclusi gli attacchi alle dipendenze delle dipendenze [un tema per un'altra sessione](cite: 1).

Per identificare estensioni VS Code malevole, i ricercatori hanno analizzato BExtsTable, una collezione di package open source malevoli, per identificare pattern comuni. Utilizzando Semgrep, uno strumento SAST (Static Application Security Testing), hanno scritto regole per cercare codice sospetto. Una regola semplice cercava comandi di esecuzione (exec, eval) successivi a un evento HTTP (GET request). Questa analisi ha portato alla scoperta di un'estensione che, all'installazione, contattava un dominio dell'attaccante, prelevava codice e lo eseguiva localmente tramite eval. Al momento della scoperta, il dominio in questione era disponibile per l'acquisto, significando che chiunque avrebbe potuto comprarlo e trasformare un'estensione potenzialmente innocua (ma mal scritta) in un malware attivo. L'estensione è stata segnalata a Microsoft e rimossa.

Infine, la scansione del Marketplace ha rivelato la presenza di segreti esposti all'interno dei file .vsix, come token per accedere al Marketplace stesso (permettendo a un attaccante di pubblicare estensioni malevole a nome di un editore innocente), chiavi AWS e altro.

Mitigazioni per le PMI nella fase IDE

Come consulente web specializzato in sicurezza informatica, suggerisco alle PMI le seguenti contromisure:

• Responsabilità della Piattaforma e degli Editori: le piattaforme come il Marketplace di VS Code dovrebbero rafforzare i controlli per gli upload anonimi. Gli editori dovrebbero utilizzare i meccanismi di verifica (per quanto imperfetti) e scansionare le proprie estensioni per vulnerabilità e segreti prima della pubblicazione.
• Dovere degli Sviluppatori e delle Aziende:
  • Analisi Approfondita: prima di installare un'estensione, specialmente se poco nota o non verificata, esaminare i permessi richiesti, il codice sorgente (se disponibile) e cercare recensioni o segnalazioni.
  • Minimo Privilegio: limitare il numero di estensioni installate a quelle strettamente necessarie.
  • Sicurezza dell'Endpoint: proteggere adeguatamente le macchine di sviluppo.
  • Sandboxing e Monitoraggio: considerare l'uso di ambienti di sviluppo isolati o strumenti di monitoraggio del comportamento delle estensioni.

Questi risultati dimostrano come gli sviluppatori possano essere attaccati "shift left left", ancor prima di scrivere una singola riga di codice del progetto principale. Molte altre piattaforme IDE con i loro marketplace probabilmente presentano falle simili. Per una PMI il cui core business dipende da software sviluppato internamente, magari con Laravel o Symfony, la sicurezza dell'ambiente di sviluppo è tanto critica quanto quella dell'infrastruttura di produzione. Affidarsi a un contractor IT esperto può aiutare a navigare queste complessità; scopri di più sul mio approccio.

Fase SCM: il Pericolo del "Repo Jacking"

Una volta scritto, il codice viene gestito tramite un sistema SCM come Git. Il "Repo Jacking" è una tecnica di attacco che sfrutta la gestione dei nomi dei repository su piattaforme come GitHub.

Immaginiamo un'organizzazione "MiaOrganizzazione" con un repository "MioRepo". L'URL per accedervi sarà github.com/MiaOrganizzazione/MioRepo. Se l'organizzazione decide di cambiare nome in "NuovaOrganizzazione", l'URL diventerà github.com/NuovaOrganizzazione/MioRepo. GitHub, per non rompere i link esistenti, imposta un redirect HTTP dal vecchio al nuovo URL. Il problema sorge perché il vecchio nome "MiaOrganizzazione" diventa disponibile per la registrazione da parte di chiunque. Se un attaccante registra "MiaOrganizzazione" e crea un repository chiamato "MioRepo" al suo interno, il redirect smette di funzionare. Gli utenti che, per errore o a causa di documentazione non aggiornata, accedono al vecchio URL, finiranno sul repository dell'attaccante invece che su quello legittimo. Questo è il cuore del repo jacking.

GitHub ha implementato alcune restrizioni sulla possibilità di riutilizzare nomi di repository precedentemente associati a redirect, ma nel 2022 sono stati documentati numerosi bypass. Ai fini della ricerca presentata nel transcript, un repository con un redirect attivo e il cui vecchio nome è disponibile è stato considerato vulnerabile.

Scenari di sfruttamento del Repo Jacking

Come può un attaccante trarre vantaggio da un repo jacking?

• Link nel Codice: file come go.mod (per Go), package.json (npm), o script di installazione potrebbero contenere URL che puntano al vecchio nome del repository per scaricare risorse o dipendenze. Eseguire npm install o go get da un repository controllato da un attaccante può portare a Remote Code Execution (RCE).
  • Esempio Google Socratic Maps: un progetto Google, "socratic-maps", trasferito sotto l'organizzazione Google, aveva istruzioni nel README che ancora indicavano di clonare da github.com/socraticorg/socratic-maps. Un attaccante, creando l'organizzazione socraticorg e il repository socratic-maps, avrebbe potuto indurre gli utenti a clonare codice malevolo. Un POC ha dimostrato la possibilità di ottenere RCE su utenti e sviluppatori di grandi aziende tramite npm install.
• Guide all'Installazione e Documentazione Obsoleta: istruzioni scritte che non vengono aggiornate dopo un cambio di nome.
  • Esempio Script di Installazione: uno script install.sh scaricava uno ZIP da un repository vulnerabile a repo jacking (yesgraph/dominus), lo decomprimeva ed eseguiva uno script al suo interno. Un attaccante, registrando yesgraph e creando dominus, avrebbe potuto distribuire uno ZIP malevolo.
• Link in Post su Internet: risposte su Stack Overflow, articoli di blog, o post su forum che raccomandano uno strumento linkando al suo vecchio URL GitHub.
• Download di Estensioni o Tool: un caso specifico ha portato i ricercatori ad analizzare le estensioni VS Code: le istruzioni per scaricare un file .vsix (estensione VS Code) puntavano a un URL GitHub vulnerabile a repo jacking.

Reperire i nomi precedenti dei Repository

Per sfruttare su larga scala il repo jacking, un attaccante necessita di conoscere i nomi precedenti dei repository. Il progetto GHTorrent (ora GHArchive potrebbe essere un successore o simile) archivia tutte le attività pubbliche su GitHub, come commit e pull request. Questi dataset, disponibili per il download, sono una miniera d'oro per ricercatori e attaccanti.

Analizzando un campione casuale dell'1% (1.25 milioni di repository) dai dati di giugno 2019 (che contenevano 125 milioni di repository unici), i ricercatori hanno trovato che circa il 3.68% (originariamente 37.000, quindi 2.96% di 1.25M ma il transcript dice "almost 37,000... that is almost three percent" quindi potrebbe esserci un arrotondamento o un errore nel mio calcolo precedente, mi attengo al 3% come indicato dallo speaker) dei repository era vulnerabile a repo jacking. Applicando questa statistica all'intera piattaforma GitHub, si stima che 3 repository su 100 potrebbero essere a rischio.

Mitigazioni per il Repo Jacking nelle PMI

La difesa contro il repo jacking richiede attenzione e policy precise:

• Verifica Continua dei Link: scansionare regolarmente il proprio codice e la documentazione alla ricerca di link a repository GitHub, specialmente quelli esterni.
• Mantenere i Vecchi Nomi Organizzazione/Utente: se si cambia nome a un'organizzazione o utente su GitHub, è consigliabile mantenere il controllo del vecchio nome, magari lasciandolo come placeholder o con un avviso, per impedire che venga registrato da altri.
• Attenzione Durante Fusioni e Acquisizioni: questi eventi spesso comportano rebranding e cambi di nome, aumentando il rischio di repo jacking se non gestiti con cura.
• Utilizzare Strumenti di Gestione delle Dipendenze Sicuri: per le dipendenze software, affidarsi a registry ufficiali e utilizzare meccanismi di lock file (es. composer.lock per PHP, package-lock.json per npm) per fissare le versioni e le fonti delle dipendenze.

La supply chain del software è complessa. Un link interrotto o una dipendenza obsoleta possono sembrare problemi minori, ma in contesti di cybersecurity, possono diventare vettori di attacco significativi. Se la tua PMI gestisce numerosi progetti software, magari con codice PHP legacy o moderne applicazioni Laravel, una revisione della sicurezza dell'SCM è un investimento che dà i suoi frutti.

Per una discussione più approfondita su come la mia consulenza può aiutare la tua PMI a implementare queste mitigazioni, puoi contattarmi direttamente.

Fase Registry: npm tra Package Planting e Timing Attacks

I registry di package, come npm per il mondo JavaScript/Node.js (e quindi anche per molte toolchain di sviluppo frontend e backend), sono cruciali ma anche punti nevralgici per la sicurezza.

Package Planting su npm

In passato, npm permetteva a qualsiasi utente di aggiungere un altro utente come manutentore (owner) di un package senza che quest'ultimo dovesse confermare. Questo ha aperto la strada al "package planting":

1. Un attaccante pubblica un package malevolo su npm (npm publish).
2. Successivamente, aggiunge un utente o un'organizzazione con alta reputazione (es. "npm", "Facebook") come manutentore del package malevolo, usando il comando npm owner add <utente_vittima> <nome_package_malevolo>.
3. Infine, l'attaccante rimuove se stesso dalla lista dei manutentori per far sembrare il package più innocente e legittimo.

Il risultato? Una pagina del package su npm che appare gestita da un'entità fidata. Uno sviluppatore ignaro, imbattendosi in questo package e vedendo il nome del manutentore "famoso", potrebbe essere indotto a installarlo, eseguendo così codice malevolo.

Un effetto collaterale interessante di questa vulnerabilità era che, tentando di aggiungere un utente come owner, npm rivelava lo stato della sua Autenticazione a Due Fattori (2FA). I ricercatori hanno scritto uno script per interrogare lo stato 2FA di molti manutentori popolari, ottenendo statistiche preoccupanti sulla sua adozione.

npm ha successivamente corretto la falla del package planting introducendo un meccanismo di conferma via email: ora, per aggiungere un owner, il nuovo manutentore designato deve approvare la richiesta.

Timing Attack per Scoprire Nomi di Pacchetti Privati npm

npm permette agli utenti e alle organizzazioni di pubblicare package privati, il cui nome e contenuto non dovrebbero essere pubblicamente enumerabili. Un nome di package privato ha sempre un prefisso di scope (il nome utente o organizzazione): @username/private-package-name.

I ricercatori hanno scoperto che npm era vulnerabile a un timing attack che permetteva di inferire l'esistenza o meno di un package privato. Un timing attack sfrutta le differenze, anche minime, nel tempo di risposta di un server a diverse richieste per estrarre informazioni sensibili.

Nel caso di npm:

• Se si interrogava l'API di npm per i metadati di un package privato inesistente (come utente anonimo, ricevendo un 404), il tempo di risposta, dopo circa 5 richieste consecutive, si stabilizzava sotto i 100 millisecondi [grazie a meccanismi di _caching_](cite: 1).
• Se, invece, il package privato esisteva, il tempo di risposta si attestava costantemente intorno ai 600 millisecondi.

Questa differenza permetteva a un attaccante di testare combinazioni di @scope/nome-pacchetto e, misurando i tempi di risposta, scoprire i nomi dei package privati di un'organizzazione. Uno scenario di sfruttamento potrebbe essere la dependency confusion: scoperto un package privato @organizzazione/tool-interno, l'attaccante potrebbe pubblicare un package pubblico chiamato tool-interno (senza scope). Se uno sviluppatore interno, per errore, o a causa di una configurazione errata nel package.json, omette lo scope, potrebbe scaricare e installare il package malevolo pubblico.

È interessante notare che piattaforme come Docker Hub non permettono questo scenario, poiché le immagini non ufficiali devono sempre avere uno scope [il nome utente](cite: 1). Questo evidenzia la necessità di standard di sicurezza unificati tra i diversi registry.

npm ha risposto che, a causa di limitazioni architetturali, non può prevenire questo tipo di timing attack, escludendolo quindi dal loro programma di bug bounty.

Mitigazioni per la Fase Registry (PMI e Sviluppatori)

• Legacy Package Planting: Verificare che tutti i package sotto il proprio scope npm siano legittimi, poiché la falla è esistita in passato.
• Proprietà delle Dipendenze: Essere sempre cauti riguardo ai manutentori delle dipendenze.
• Valutazione OSS: Utilizzare strumenti e servizi come OpenSSF Scorecard (successore spirituale di DevTaps), Socket.dev, Snyk, Dependabot per analizzare la sicurezza e la reputazione dei package open source e delle loro dipendenze.
• Timing Attack Mitigation: Per i package privati npm, la mitigazione più semplice è creare un package placeholder pubblico con lo stesso nome (ma senza scope) per prevenire il typosquatting o la dependency confusion.
• Standard Unificati: Come comunità, spingere per standard di sicurezza più uniformi tra i vari registry.

Fase CI/CD: Segreti Esposti nei Log di Travis CI

I sistemi di Continuous Integration/Continuous Deployment (CI/CD) sono diventati centrali nello sviluppo moderno. Strumenti come Jenkins, Travis CI, GitHub Actions, CircleCI, Azure Pipelines automatizzano il build, test e deploy del software. Tuttavia, configurazioni errate o vulnerabilità in questi sistemi possono esporre segreti critici.

La ricerca presentata nel transcript è iniziata osservando l'aumento di progetti open source che migravano tra diversi provider CI, a volte lasciando "dimenticata" la vecchia infrastruttura CI con log contenenti dati sensibili.

IDOR su Travis CI e Fuga di Token

Analizzando le API di Travis CI, i ricercatori hanno scoperto una vulnerabilità di tipo IDOR (Insecure Direct Object Reference). Semplicemente modificando un numero sequenziale in una chiamata API, un attaccante poteva accedere a qualsiasi log di build pubblico mai esistito su Travis CI. Questi log potevano contenere token di autenticazione, chiavi API e altre credenziali.

Inizialmente, non tutti i log nell'intervallo numerico erano accessibili. Tuttavia, è stata scoperta una seconda API, anch'essa vulnerabile a IDOR, che utilizzava numeri sequenziali a partire da 1 e reindirizzava a bucket S3 contenenti gli stessi log. Questa seconda via ha permesso di bypassare le restrizioni della prima e accedere a un numero ancora maggiore di log, per un totale stimato di oltre 770 milioni di log di build pubblici.

Analizzando un campione dell'1% (circa 8 milioni di log), e utilizzando vari strumenti di scansione e wordlist personalizzate, sono stati scoperti più di 73.000 token e segreti. Questi includevano credenziali per GitHub, AWS, Docker Hub e altre piattaforme popolari, appartenenti a progetti con decine di migliaia di "stelle" su GitHub. La diversità dei token era enorme, e non tutti avevano lo stesso livello di criticità. Per verificare la validità e l'uso dei token, è stato utilizzato il progetto ClearX (probabilmente si riferisce a truffleHog o simili che hanno database di pattern di token).

Travis CI tentava di censurare i segreti nei log, ma la varietà dei formati dei token e il volume dei log rendevano questo sforzo inefficace [es. oltre 20 alias diversi per i soli _token_ GitHub](cite: 1).

La combinazione di token accessibili a chiunque, log con restrizioni bypassabili e un rate limiting permissivo sulle API creava una situazione estremamente pericolosa.

Inizialmente, Travis CI rispose che il problema era "by design" e che non intendevano risolverlo. Solo dopo la pubblicazione diffusa della ricerca, Travis CI ha iniziato a mitigare il rischio, principalmente eliminando i log più vecchi. I ricercatori hanno anche segnalato i token esposti ai rispettivi service provider, che hanno avviato rotazioni delle chiavi o verificato la validità dei token [circa il 50% era ancora valido al momento della segnalazione](cite: 1).

Mitigazioni per la Fase CI/CD nelle PMI

La sicurezza della pipeline CI/CD è fondamentale, anche per una PMI che utilizza framework come Laravel o Symfony e magari Docker per la containerizzazione.

• Pulizia dei Componenti Legacy: eliminare vecchi sistemi CI/CD o build non più in uso, poiché potrebbero contenere log con segreti.
• Rotazione Periodica dei Log e dei Token: i log dovrebbero avere una retention policy definita. I token e le chiavi API dovrebbero essere ruotati regolarmente [alcuni dei _token_ trovati avevano 7 anni!](cite: 1).
• Minimo Privilegio per i Token: i token utilizzati nelle pipeline CI/CD (specialmente quelli di terze parti) devono avere solo i permessi strettamente necessari per il loro compito.
• Scansione degli Output di Build: utilizzare strumenti di secret scanning per analizzare tutti gli output generati dal flusso di sviluppo e dalla pipeline CI. È consigliabile usare più strumenti, poiché ognuno ha euristiche diverse (basate su entropia, pattern regex, ecc.) per ottenere una copertura completa.

La mia consulenza come backend architect e consulente sicurezza informatica si estende alla progettazione e all'hardening di pipeline CI/CD sicure, un aspetto cruciale per qualsiasi PMI che sviluppa software.

Fase Artifacts: un Richiamo alla Cautela

La fase degli artifacts – i package compilati, le immagini Docker, ecc. – condivide molti dei rischi della fase Registry. Che siate consumatori o fornitori di un artifact, la sua integrità e sicurezza sono paramount. Le PMI devono assicurarsi che gli artifacts che consumano provengano da fonti affidabili e siano privi di malware, e che gli artifacts che producono non contengano segreti o vulnerabilità introdotte durante il build.

Ogni fase del flusso di sviluppo software può essere un vettore di attacco alla supply chain

Gli esempi discussi, dalle estensioni VS Code al repo jacking, dal package planting npm ai token esposti nei log CI/CD, fino ai timing attack sui package privati, dimostrano che ogni fase del flusso di sviluppo software può essere un vettore di attacco alla supply chain. Sebbene ogni singola tecnica possa sembrare semplice, le conseguenze per un'organizzazione possono essere catastrofiche.

È imperativo per le PMI garantire la sicurezza in ogni fase:

• Analisi del Rischio e Threat Modeling: Comprendere come la propria organizzazione si inserisce nel flusso di sviluppo e quali sono i rischi specifici a cui è esposta. Questo è un ambito dove la mia esperienza può fornire un valore aggiunto significativo.
• Sicurezza degli Endpoint: Proteggere le postazioni degli sviluppatori PHP, sviluppatori Laravel, sviluppatori Symfony, ecc.
• Gestione Sicura delle Dipendenze: Verificare e validare le dipendenze open source e di terze parti.
• Hardening delle Pipeline CI/CD: Assicurare che i processi di build e deploy siano sicuri e non espongano segreti.
• Formazione e Consapevolezza: Tutti, dagli sviluppatori web ai system administrator (Debian, Ubuntu), devono essere consapevoli di questi rischi.

Per i ricercatori di sicurezza, è cruciale agire con responsabilità quando si pubblicano POC, poiché si può impattare l'intera comunità open source. Infine, l'attenzione della comunità non dovrebbe focalizzarsi solo sulle piattaforme più popolari (npm, PyPI, Go); esistono molti altri registry che potrebbero essere vulnerabili agli stessi problemi ma che attualmente ricevono poca attenzione.

La cybersecurity della supply chain del software è una sfida complessa ma non insormontabile. Richiede vigilanza, processi robusti e, per molte PMI, la guida di un consulente IT esperto e affidabile.