Quando i repository di fiducia diventano porte d’ingresso: le nuove minacce alla catena di fornitura software

Introduzione: il ruolo centrale degli artifact repository nei flussi DevOps

Negli ultimi anni l’adozione di pratiche DevOps ha trasformato il modo in cui le organizzazioni sviluppano, testano e distribuiscono software. Strumenti come i repository di artefatti (artifact repository) e i sistemi di controllo versione sono diventati il cuore pulsante della catena di fornitura digitale: essi conservano binari, librerie, dipendenze e script di build che, una volta approvati, vengono propagati automaticamente agli ambienti di produzione. Questa centralizzazione, però, crea un punto di attrazione per gli avversari: compromettere un singolo repository può permettere l’iniezione di codice malevolo in migliaia di downstream, con effetti a catena difficili da contenere.

Le recenti segnalazioni di CISA, pubblicate tra l’8 e l’11 settembre 2026, mostrano proprio come alcune delle vulnerabilità più attivamente sfruttate riguardino questi pilastri dell’infrastruttura di sviluppo. Oltre a ricordare l’importanza di aggiornare tempestivamente i componenti, questi advisories offrono uno spunto per riflettere su come la fiducia riposta negli strumenti di build possa essere trasformata in un vettore di attacco se non accompagnata da controlli di sicurezza adeguati.

Le vulnerabilità recenti nei tool di build: JFrog Artifactory e GitLab

L’11 settembre 2026 CISA ha aggiunto tre nuove voci al suo Known Exploited Vulnerabilities (KEV) Catalog, due delle quali riguardano direttamente JFrog Artifactory, una piattaforma ampiamente utilizzata per la gestione di artefatti binari e dipendenze (Fonte 1). Le CVE identificate sono:

• CVE-2026-42016 – Incorrect Authorization: permette a un utente autenticato con privilegi limitati di eseguire azioni riservate ad amministratori, come la modifica di configurazioni di repository o la cancellazione di artefatti critici.
• CVE-2026-42018 – Improper Authentication: consente a un attaccante di aggirare il meccanismo di autenticazione e ottenere accesso non autorizzato al servizio, potenzialmente permettendo il caricamento di artefatti malevoli o l’estrazione di quelli esistenti.

Queste falle, se sfruttate, possono alterare la catena di fiducia: un artefatto apparentemente legittimo potrebbe essere sostituito con una versione trojanizzata, che poi verrà scaricata ed eseguita da migliaia di pipeline di build.

Sempre l’11 settembre, CISA ha inserito nel KEV una vulnerabilità di path traversal che colpisce GitLab Community Edition e Enterprise Edition (Fonte 2). La CVE-2026-85706 permette a un utente malintenzionato, mediante richieste HTTP accuratamente costruite, di leggere o scrivere file al di fuori della directory prevista del repository GitLab. In un contesto di CI/CD, questo può portare alla divulgazione di chiavi SSH, token di accesso a servizi cloud o script di deploy, facilitando il movimento laterale all’interno dell’infrastruttura di sviluppo.

Entrambe le famiglie di vulnerabilità condividono una caratteristica comune: non richiedono exploit complessi o zero‑day, bensì una manipolazione di funzionalità legittime (autorizzazione, autenticazione, parsing di percorsi) che, se non correttamente limitate, aprono una breccia nella fiducia intrinseca che le organizzazioni ripongono nei propri strumenti di sviluppo.

Come gli attaccanti sfruttano queste falle per infiltrarsi nella catena di fornitura

Una volta ottenuto l’accesso a un repository di artefatti o a un server Git, gli attaccanti possono seguire diversi percorsi:

1. Iniezione di artefatti trojanizzati – Sfruttando la cattiva autorizzazione in Artifactory, un attaccante carica una versione modificata di una libreria ampiamente utilizzata (ad esempio un framework di logging o un driver di database). Poiché molti processi di build scaricano automaticamente le ultime versioni senza verifica di firma, il codice malevolo viene compilato e distribuito negli applicativi a valle.
2. Furto di segreti e credenziali – Grazie al path traversal di GitLab, l’attaccante può estrarre file di configurazione contenenti chiavi API, token di servizio o credenziali di accesso a registri di container, servizi di cloud o sistemi di ticketing. Questi segreti possono poi essere usati per autenticarsi verso sistemi di produzione, spostandosi successivamente dalla fase di build all’ambiente di runtime.
3. Manipolazione di script di pipeline – Alcuni sistemi CI/CD leggono script di build direttamente dal repository. Un attaccante che ottiene privilegi di scrittura può inserire comandi di download di payload aggiuntivi o modificare variabili d’ambiente, facendo sì che l’esecuzione della pipeline lanci codice malevolo nei worker di build o negli agenti di deploy.
4. Distribuzione di backdoor nei container – Se il registro di container è collegato allo stesso artifact repository, un artefatto compromesso può essere caricato come immagine di container. Le piattaforme di orchestrazione (Kubernetes, Docker Swarm) che effettuano pull automatico delle ultime immagini finiranno per eseguire container con backdoor nascoste.

Queste tecniche sono state osservate in diversi incidenti riportati da CISA nello stesso periodo, dove vulnerabilità in prodotti quali Fortinet, Citrix NetScaler e Chromium sono state sfruttate per ottenere un primo punto d’ingresso, successivamente utilizzato per spostarsi verso sistemi di sviluppo e distribuzione (Fonte 8). La combinazione di exploit iniziali su perimetri di rete con attacchi mirati alla catena di fornitura software rappresenta una tattica sempre più comune negli scenari di ransomware e di spionaggio industriale.

Implicazioni per le imprese italiane: casi d’uso e best practice

Le aziende italiane, particolarmente attive nei settori della manifattura avanzata, dei servizi finanziari e della sanità digitale, dipendono fortemente da catene di fornitura software agili. Un attacco che comprometta un artefatto utilizzato in un sistema di controllo qualità o in una piattaforma di trading può avere ripercussioni immediate sulla continuità operativa, sulla reputazione e sulla conformità normativa (ad esempio GDPR o NIS2).

Per mitigare questi rischi, le organizzazioni dovrebbero adottare un approccio a più livelli:

• Verifica dell’integrità degli artefatti – Implementare la firma digitale di tutti gli artefatti (ad esempio con GPG o sigstore) e richiedere la verifica della firma prima dell’uso in qualsiasi fase di build o deploy. Questo impedisce l’uso di artefatti trojanizzati anche se riescono a entrare nel repository.
• Controllo degli accessi basato sul principio del minor privilegio (PoLP) – Revisionare regolarmente le politiche di autorizzazione e autenticazione negli strumenti come Artifactory e GitLab, rimuovendo privilegi eccessivi e applicando l’autenticazione a due fattori (MFA) per tutti gli account di servizio.
• Segmentazione della rete e zero trust – Isolare i sistemi di sviluppo e di build dalla rete aziendale generale, applicando micro‑segmentazione e politiche di privilegi minimi per il traffico east‑west. Anche se un attaccante riesce a compromettere un endpoint di sviluppo, la sua capacità di spostarsi verso sistemi di produzione sarà fortemente limitata.
• Monitoraggio continuo e rilevamento delle anomalie – Implementare soluzioni di SIEM/EDR che analizzino i log di accesso ai repository, cercando schemi anomali come download insoliti di grandi volumi di artefatti, accessi da IP non riconosciuti o modifiche non autorizzate a file di configurazione.
• SBOM (Software Bill of Materials) e tracciabilità – Generare e mantenere un SBOM accurato per ogni build, includendo le dipendenze transitive e le loro versioni. In caso di scoperta di una vulnerabilità in un componente, lo SBOM permette di individuare rapidamente tutti gli artefatti e gli applicativi interessati, accelerando il processo di patch o di rollback.
• Formazione e consapevolezza – Sensibilizzare i team di sviluppo e DevOps sulle tecniche di social engineering e sulle pratiche di sviluppo sicuro, enfatizzando l’importanza di non condividere credenziali in chiaro nei repository e di revisionare le pull request prima del merge.

Queste misure, sebbene richiedano investimenti iniziali in strumenti e processi, riducono significativamente la superficie di attacco e aumentano la resilienza della catena di fornitura software.

Verso una difesa integrata: SBOM, zero trust e monitoraggio continuo

La difesa contro le minacce alla catena di fornitura non può più basarsi esclusivamente sulla gestione delle patch. È necessario costruire un modello di sicurezza che consideri la fiducia come una proprietà da verificare continuamente, non come un presupposto statico. L’adozione di un framework Zero Trust, applicato non solo alle reti ma anche ai flussi di lavoro di sviluppo, garantisce che ogni richiesta di accesso a un artefatto o a un repository sia autenticata, autorizzata e sottoposta a controllo di integrità in tempo reale.

Parallelamente, l’uso diffuso di SBOM sta diventando un requisito normativo in molte giurisdizioni (ad esempio il recente Executive Order negli USA e le linee guida ENISA per l’UE). Le aziende italiane che anticipano questi obblighi non solo si allineano alle migliori pratiche internazionali, ma ottengono anche un vantaggio competitivo: la capacità di rispondere velocemente a incidenti di sicurezza, dimostrando trasparenza verso clienti e regolatori.

Infine, il monitoraggio continuo – alimentato da threat intelligence condivisa e da feed di vulnerabilità quali il KEV di CISA – permette di trasformare le informazioni sulle vulnerabilità sfruttate in azioni concrete di difesa. Quando una nuova CVE viene aggiunta al catalogo, le organizzazioni possono verificare immediatamente se i propri sistemi sono esposti, applicare le mitigazioni consigliate e aggiornare i propri controlli di verifica della firma.

In sintesi, le recenti aggiunte al KEV di CISA ci ricordano che gli attaccanti stanno spostando il loro focus dalle vulnerabilità di sistema tradizionali verso i punti di fiducia della catena di fornitura software. Per le imprese italiane, comprendere queste dinamiche e adottare un approccio integrato basato su SBOM, zero trust e monitoraggio continuo non è più una scelta opzionale, ma una necessità per garantire la continuità del business e la protezione del patrimonio digitale in un contesto di minacce sempre più sofisticate.