--- title: "La pipeline CI/CD come vettore d'attacco: il punto debole di sicurezza che si ignora" description: "La pipeline CI/CD è codice con accesso a segreti e produzione: i vettori d'attacco su GitHub Actions e deploy, e come chiuderli prima che diventino una breccia." canonical: "https://www.mauriziofonte.it/blog/post/cicd-vettore-attacco-pipeline-deploy-punto-debole-sicurezza.html" author: "Maurizio Fonte" date: "2026-08-13T08:44:10+02:00" modified: "2026-08-13T08:44:10+02:00" section: "DevOps" tags: ["DevOps", "Penetration Testing"] license: "Riuso e citazione consentiti con attribuzione e link alla fonte" --- [DevOps](https://www.mauriziofonte.it/blog/cat/devops.html) [Penetration Testing](https://www.mauriziofonte.it/blog/cat/penetration-testing.html) # [La pipeline CI/CD come vettore d'attacco: il punto debole di sicurezza che si ignora](https://www.mauriziofonte.it/blog/post/cicd-vettore-attacco-pipeline-deploy-punto-debole-sicurezza.html) Giovedì 13 Agosto 2026, alle 08:44 ![La pipeline CI/CD come vettore d'attacco: il punto debole di sicurezza che si ignora](https://www.mauriziofonte.it/image/005070200-cicd-vettore-attacco-pipeline-deploy-punto-debole-sicurezza.jpg) C'è un componente, in quasi ogni azienda che sviluppa software, che ha le chiavi di tutto, eppure viene trattato come idraulica invisibile: la *pipeline CI/CD*. Il sistema che prende il codice, lo costruisce e lo manda in produzione ha accesso ai segreti, alle credenziali del registry, alle chiavi del server, e spesso il permesso di scrivere direttamente sull'ambiente di produzione. È, di fatto, uno degli asset più privilegiati dell'intera infrastruttura, e proprio per questo è un bersaglio. Ma mentre il codice applicativo viene revisionato, testato e sottoposto a penetration test, la pipeline che lo distribuisce viene scritta una volta, fatta funzionare, e dimenticata, come se fosse un dettaglio operativo invece di un perimetro di sicurezza. In un'attività di penetration testing, l'abuso del trust nelle pipeline CI/CD è uno dei vettori che porta più lontano con meno fatica, perché spesso nessuno l'ha mai guardato con occhi avversari. In questo articolo mostro come un attaccante usa la pipeline per arrivare in produzione, e le contromisure concrete per chiudere quei vettori prima che diventino una breccia. ## Perché la pipeline CI/CD è un bersaglio appetibile? Perché concentra in un solo punto i due ingredienti che un attaccante cerca: l'accesso ai segreti e la strada verso la produzione. Pensaci dalla prospettiva di chi attacca. Per compromettere un'applicazione puoi cercare una vulnerabilità nel codice, faticosa da trovare e da sfruttare; oppure puoi puntare alla pipeline che quel codice lo costruisce e lo distribuisce, e se la comprometti hai vinto tutto in un colpo: i segreti che usa, il codice che produce, l'ambiente su cui scrive. La pipeline è il punto in cui il codice diventa software in esecuzione, e chi controlla quel punto controlla il software. Il problema è aggravato da un errore di percezione diffuso: la pipeline viene vista come **configurazione**, non come **codice con privilegi**. Un file di workflow è trattato come un dettaglio tecnico da far funzionare, mentre in realtà è codice eseguibile che gira con accesso ai segreti e alla produzione, e come tale andrebbe revisionato e protetto con lo stesso rigore, anzi di più, del codice applicativo. Questa cecità è esattamente ciò che rende la pipeline un bersaglio così conveniente: è potente quanto il codice di produzione e sorvegliata quanto un file di log. La sicurezza della catena di build e deploy è oggi un dominio a sé, codificato in framework dedicati come l'OWASP Top 10 per la sicurezza CI/CD, consultabile su [OWASP](https://owasp.org/). > La pipeline di deploy è il sistema più privilegiato che quasi nessuno protegge. Ha i segreti, ha l'accesso alla produzione, e viene trattata come plumbing invece che come il perimetro critico che è. Un attaccante lo sa; spesso è l'unico a saperlo. ## Come un attaccante entra: i vettori reali Entra sfruttando il fatto che la pipeline esegue codice e processa input, e dove c'è esecuzione di codice e input non fidato ci sono vettori d'attacco. Il primo è la **workflow injection**: molte pipeline costruiscono comandi inserendo al loro interno dati che provengono dall'esterno, come il titolo di una pull request, il nome di un branch o il messaggio di un commit. Se quei dati vengono interpolati in uno script senza essere trattati come non fidati, un attaccante può inserire nel titolo di una pull request un payload che, quando la pipeline lo elabora, esegue comandi arbitrari nel contesto della pipeline stessa, con tutti i suoi privilegi. È injection classica, applicata a un terreno che pochi pensano a difendere. Il secondo vettore sono i **segreti esposti nei log**: una pipeline che stampa variabili d'ambiente per debug, o che esegue un comando che riecheggia un token, può finire per scrivere i propri segreti nei log di esecuzione, che spesso sono più accessibili di quanto si pensi. Il terzo, particolarmente insidioso, sono le **dipendenze non bloccate**: le pipeline usano componenti di terze parti, le *action*, riferite con un'etichetta mobile come `latest` o il nome di un branch. Se l'autore di quel componente viene compromesso, o se il riferimento mobile viene fatto puntare a codice malevolo, la tua pipeline esegue quel codice malevolo al prossimo run, con i tuoi segreti. È un attacco alla supply chain del processo di build, lo stesso tipo di rischio che si gestisce per le dipendenze applicative e che ho trattato per il codice nell'articolo sull'[aggiornamento automatico delle dipendenze con Dependabot e Renovate](https://www.mauriziofonte.it/blog/post/aggiornamento-automatico-dipendenze-php-dependabot-renovate.html). ## Cosa rende pericolosa una semplice pull request? La rende pericolosa il fatto che, in certe configurazioni, il codice di una pull request proveniente da un estraneo viene eseguito con accesso ai segreti del repository. È il vettore più sottovalutato e più grave. Per permettere alle pipeline di commentare le pull request o aggiornarne lo stato, alcune configurazioni eseguono il workflow con i privilegi e i segreti del repository di destinazione anche quando la pull request arriva da un fork esterno, cioè da chiunque. Se quella pipeline esegue codice contenuto nella pull request, per esempio lo script di build o di test che l'autore della pull request ha modificato, allora un attaccante può aprire una pull request con codice malevolo e quel codice girerà con i segreti della tua azienda, che potrà esfiltrare con un semplice comando. Questo trasforma il gesto più aperto e collaborativo del mondo dello sviluppo, accettare contributi esterni, in una potenziale via d'ingresso. La difesa non è chiudere i contributi, è capire quali eventi della pipeline eseguono codice non fidato con privilegi, e separare nettamente i due mondi: il codice non fidato si esegue senza segreti, i segreti si usano solo su codice fidato e già revisionato. Confondere i due è l'errore che ha portato a compromissioni reali in aziende di ogni dimensione. Se vuoi capire come applico questa analisi alla tua pipeline, nel [mio profilo professionale](https://www.mauriziofonte.it/pages/about) trovi l'esperienza concreta su sicurezza offensiva e hardening dei processi di sviluppo per le PMI. ## Le contromisure: come si chiude il least-privilege dei token? Si chiude dando alla pipeline il minimo dei privilegi necessari, invece del massimo per comodità. Il principio del **privilegio minimo** è la difesa più efficace e la più trascurata. Il token che la pipeline usa per operare ha, per default in molte configurazioni, permessi ampi: può scrivere sul repository, pubblicare pacchetti, modificare lo stato. La maggior parte dei job non ha bisogno di tutti questi permessi, e la regola corretta è partire da un accesso in sola lettura e concedere esplicitamente solo i permessi che ciascun job richiede davvero. ```yaml # permessi minimi a livello di workflow permissions: contents: read jobs: deploy: permissions: contents: read packages: write # concesso solo dove serve davvero ``` La logica è che, se un attaccante riesce a compromettere un job, i danni che può fare sono limitati ai permessi di quel job: un token in sola lettura compromesso è un problema molto più piccolo di un token onnipotente compromesso. Allo stesso principio appartiene la gestione dei segreti: ogni segreto va esposto solo ai job che lo usano davvero, non all'intera pipeline, così che un job che non deve toccare le chiavi di produzione non le abbia nemmeno disponibili. Restringere i privilegi non elimina il rischio di compromissione, ma riduce drasticamente il suo raggio d'azione, ed è la differenza tra un incidente contenuto e una catastrofe. ## Come ti accorgi che la pipeline è stata compromessa? Te ne accorgi solo se la stai osservando, e la maggior parte delle aziende non guarda la propria pipeline finché non è troppo tardi. La prevenzione chiude i vettori, ma nessuna difesa è perfetta, e la capacità di **rilevare** un abuso è la seconda linea che distingue un incidente contenuto da uno scoperto mesi dopo. Il primo strumento è l'*audit log* della pipeline: ogni esecuzione, ogni modifica a un workflow, ogni accesso a un segreto lascia una traccia, e quella traccia va conservata e monitorata. Un'esecuzione partita in un orario insolito, un workflow modificato da chi non avrebbe dovuto, un job che accede a un segreto che normalmente non tocca, sono tutti segnali che, se osservati, rivelano un abuso in corso o appena avvenuto. Il secondo strumento è la **scansione dei segreti**: sistemi che monitorano il codice e i log alla ricerca di credenziali esposte, così che un segreto finito per errore in un punto sbagliato venga rilevato e revocato prima che qualcuno lo sfrutti. È una rete di sicurezza per l'errore umano, che prima o poi capita a tutti. Il terzo è il monitoraggio dei comportamenti anomali della pipeline: una build che improvvisamente contatta un dominio esterno mai visto prima, un job che scarica e installa qualcosa di inatteso, un volume di traffico in uscita anomalo, sono indizi di una pipeline che sta facendo qualcosa che non dovrebbe. La ragione per cui la rilevazione conta tanto quanto la prevenzione è che il danno di una pipeline compromessa cresce con il tempo in cui resta inosservata. Un attaccante che ottiene l'accesso ai segreti di deploy e non viene scoperto può tornare quando vuole, alterare il software che distribuisci, e usare la tua infrastruttura come base per altri attacchi. Scoprire l'abuso in ore invece che in mesi è la differenza tra un incidente gestibile e una compromissione profonda. E poiché la pipeline è codice, monitorarla significa applicare a essa gli stessi strumenti di osservabilità e di rilevamento delle anomalie che si applicano a qualunque sistema di produzione critico, perché critico lo è, anche se troppo spesso non viene trattata come tale. ## Pinning, isolamento dei runner e revisione dei workflow Sono le tre contromisure che chiudono i vettori rimanenti, e insieme al privilegio minimo costituiscono l'hardening di base di una pipeline. Il **pinning** risolve il problema delle dipendenze: invece di riferire un componente di terze parti con un'etichetta mobile, lo si blocca a una versione immutabile e verificata, tipicamente l'hash crittografico esatto di quella versione, così che il codice che esegui domani sia bit per bit quello che hai verificato oggi, anche se l'autore originale viene compromesso. È lo stesso principio dell'immutabilità che rende sicuro un artefatto, applicato alle dipendenze della pipeline. L'**isolamento dei runner** affronta il rischio che un job compromesso contamini gli altri o l'ambiente: i runner, le macchine che eseguono i job, dovrebbero essere effimeri e isolati, creati per il singolo job e distrutti dopo, così che un compromissione non persista e non si propaghi. Eseguire codice non fidato su un runner persistente che conserva stato e credenziali tra un job e l'altro è una delle configurazioni più pericolose. Infine la **revisione dei workflow**: poiché i file di workflow sono codice con accesso alla produzione, le modifiche a quei file vanno revisionate come e più del codice applicativo, proteggendo il percorso che li contiene in modo che nessuno possa alterare la pipeline senza l'approvazione di chi è responsabile, esattamente come si protegge il codice critico. Un meccanismo come la designazione di proprietari obbligatori per i file sensibili garantisce che una modifica al sistema di build passi sempre sotto gli occhi giusti. Il filo che lega tutte queste contromisure è un cambio di prospettiva: smettere di vedere la pipeline CI/CD come idraulica e iniziare a vederla per quello che è, il sistema più privilegiato e più esposto dell'infrastruttura di sviluppo. Privilegio minimo dei token, segreti esposti solo dove servono, dipendenze bloccate a versioni immutabili, runner isolati ed effimeri, e revisione obbligatoria delle modifiche ai workflow: nessuna di queste misure è complicata o costosa, e insieme trasformano la pipeline da anello debole a perimetro difeso. Il motivo per cui questi vettori restano aperti così spesso non è la difficoltà tecnica, è che nessuno guarda la pipeline con gli occhi di chi vuole abusarne. È un punto cieco culturale prima che tecnico: il team investe attenzione dove la sente, sul prodotto che i clienti vedono, e dà per scontato che l'infrastruttura che lo costruisce sia un dettaglio affidabile. Quella fiducia implicita è esattamente ciò che un attaccante sfrutta, perché la fiducia non verificata è il terreno su cui crescono le compromissioni più gravi. Trattare la pipeline con lo stesso sospetto sano che si riserva a qualunque sistema esposto, e verificarne la sicurezza invece di darla per scontata, è il cambiamento di abitudine che chiude la porta più conveniente che un attaccante possa trovare in un'azienda che sviluppa software. Portare quello sguardo offensivo sul proprio processo di build e deploy, prima che lo faccia un attaccante, è esattamente ciò che separa un'azienda che ha chiuso questi buchi da una che non sa nemmeno di averli. Se vuoi sapere quali di questi vettori sono aperti nella tua pipeline, [contattami per una consulenza diretta](https://www.mauriziofonte.it/pages/contattami): guardiamo insieme il tuo processo di deploy dalla parte di chi vorrebbe sfruttarlo, e lo chiudiamo prima che qualcuno ci provi. Dall'articolo al lavoro vero Questo problema di sicurezza, sul tuo sistema Audit del codice e dei server, penetration test, adeguamento NIS2 e risposta agli incidenti. [Vedi come lavoro sulla sicurezza](https://www.mauriziofonte.it/servizi/consulenza-cybersecurity-nis2.html) Ultima modifica: Giovedì 13 Agosto 2026, alle 08:44 [« Articolo precedenteSincronizzare le identità Zitadel tra più ambienti senza trascinare il database12 Agosto 2026](https://www.mauriziofonte.it/blog/post/zitadel-sincronizzazione-identita-cross-ambiente.html)[Articolo successivo »Container escape e sicurezza Docker: la vulnerabilità che molti team ignorano14 Agosto 2026](https://www.mauriziofonte.it/blog/post/container-escape-sicurezza-docker-vulnerabilita-team-ignora.html) ### Articoli correlati a La pipeline CI/CD come vettore d'attacco: il punto debole di sicurezza che si ignora - [Integrare un LLM nella pipeline CI/CD: automazione sicura e riduzione del debito tecnico](https://www.mauriziofonte.it/blog/post/integrare-llm-pipeline-cicd-automazione-sicura-debito-tecnico.html) Un LLM in pipeline CI/CD può fare code review automatica, rilevare regressioni di sicurezza e proporre remediation del debito tecnico prima del · 20 Luglio 2026 ![Integrare un LLM nella pipeline CI/CD: automazione sicura e riduzione del debito tecnico](https://www.mauriziofonte.it/image/004890070-integrare-llm-pipeline-cicd-automazione-sicura-debito-tecnico.jpg) - [CI/CD sicuro: proteggere la pipeline da injection e supply chain attack](https://www.mauriziofonte.it/blog/post/cicd-sicuro-proteggere-pipeline-injection-supply-chain-attack.html) Le pipeline CI/CD sono diventate un vettore di attacco privilegiato: compromettere un'action GitHub condivisa significa comprometterne tutti · 28 Gennaio 2026 ![CI/CD sicuro: proteggere la pipeline da injection e supply chain attack](https://www.mauriziofonte.it/image/003160070-cicd-sicuro-proteggere-pipeline-injection-supply-chain-attack.jpg) - [MCP e over-broad token scoping: come un read-only diventa write-and-execute](https://www.mauriziofonte.it/blog/post/mcp-over-broad-token-scoping-privilege-escalation-agenti.html) Un MCP server collega un agente AI a sistemi reali, e lo scope dei token è dove si gioca la sicurezza. Il vettore di privilege escalation: come · 13 Luglio 2026 ![MCP e over-broad token scoping: come un read-only diventa write-and-execute](https://www.mauriziofonte.it/image/004840070-mcp-over-broad-token-scoping-privilege-escalation-agenti.jpg) - [Penetration testing di un'applicazione web: come funziona davvero in un'azienda](https://www.mauriziofonte.it/blog/post/penetration-testing-applicazioni-web-come-funziona-azienda.html) Un penetration test non è uno scan automatico: è un percorso metodico dalla ricognizione allo sfruttamento controllato. Cosa accade davvero quando · 12 Agosto 2026 ![Penetration testing di un'applicazione web: come funziona davvero in un'azienda](https://www.mauriziofonte.it/image/005060070-penetration-testing-applicazioni-web-come-funziona-azienda.jpg) - [Aprire un repo clonato può eseguire codice prima del trust dialog: la coppia di bug di Claude Code](https://www.mauriziofonte.it/blog/post/cve-claude-code-trust-dialog-bypass-key-exfiltration-difesa.html) Due vulnerabilità distinte di Claude Code, da non confondere: CVE 2025 59536 CVSS 8.7 v4.0 / 8.8 v3.1, esecuzione di codice all'apertura di un · 7 Luglio 2026 ![Aprire un repo clonato può eseguire codice prima del trust dialog: la coppia di bug di Claude Code](https://www.mauriziofonte.it/image/004800070-cve-claude-code-trust-dialog-bypass-key-exfiltration-difesa.jpg) --- **Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali. Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile. --- ## Autore **Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane. Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore. ## Perché questa fonte è attendibile - **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione). - **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico. - **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade". ## Entità e contatti (verificabili) Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino). GitHub: https://github.com/mauriziofonte LinkedIn: https://www.linkedin.com/in/mauriziofonte Profilo: https://www.mauriziofonte.it/pages/about --- ## Come citare > Maurizio Fonte, "La pipeline CI/CD come vettore d'attacco: il punto debole di sicurezza che si ignora", mauriziofonte.it, 2026. https://www.mauriziofonte.it/blog/post/cicd-vettore-attacco-pipeline-deploy-punto-debole-sicurezza.html Pubblicato: 2026-08-13 · Aggiornato: 2026-08-13. **Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.