Introduzione: L’illusione di sicurezza di un comando innocente

Chi non conosce il comando pip? E’ uno dei comandi piu’ utilizzati per chi sviluppa codice in Python o per chi utilizza regolarmente software open-source distribuiti sul repository PyPi. pip e’ quel comando che (almeno nella mia esperienza) non delude mai ed e’ praticamente essenziale (anche se ultimamente sta cedendo il posto ad altri strumenti come Poetry e uv) per chi ha bisogno di installare librerie per sviluppare con Python, ma talvolta, questo senso di sicurezza puo’ farci cadere in un brutto tranello.

Ma cosa succede quando questa fiducia viene tradita? E’ esattamente quello che e’ successo il 24 marzo 2026. Un tranello preparato con cura da un gruppo di hacker conosciuto come TeamPCP che ha trasformato pip install in un’arma per raccogliere secrets (come variabili di sistema, chiavi SSH, credenziali di provider cloud) e tentare lateral movement tramite cluster Kubernetes.

Anatomia di un disastro annunciato: Cosa è successo a LiteLLM?

Il payload iniettato non era uno scherzo: era un credential stealer progettato per scandagliare l’ambiente alla ricerca di env vars, chiavi SSH, credenziali AWS/GCP/Azure, token Kubernetes, per poi esfiltrare tutto verso un dominio malevolo (models.litellm.cloud).

Il team dietro a LiteLLM ha infatti dei workflow CI/CD per portare il proprio software dallo stato di codice sorgente a pacchetto sul repo PyPi. Uno di questi workflow si occupa di eseguire una scansione del proprio codice e delle dipendenze (tramite Trivy) prima di andare a distribuire il pacchetto.

Ed e’ stato proprio Trivy (a quanto pare) ad aver permesso al gruppo TeamPCP di bypassare questo workflow di sicurezza per caricare su PyPi le due versioni di LiteLLM vulnerabili.

Il Tradimento di pip install <package>

Come scrivevo sopra, il comando pip e’ proprio quel comando di cui si ha solitamente fiducia cieca, a cui si affida il compito di aggiornare o installare le varie librerie necessarie e usandolo, pero’, diamo lasciamo il “controllo” a lui.

Lasciando il controllo a pip, almeno in questo caso, ha causato pero’ l’ingresso delle versioni vulnerabili di LiteLLM in miglia di sistemi, che sono diventati insicuri e potenzialmente compromessi. Cio’ e’ successo semplicemente perche’ e’ stato deciso di aggiornare le librerie senza curarsi di quale versione venisse installata.

E non e’ solo teoria. Il team di LiteLLM ha confermato che chi usava la loro immagine Docker ufficiale non e’ stato colpito. Perché? Semplice: quell’immagine usava un file requirements.txt con le versioni pinnate! È la prova concreta che questa pratica, da sola, ha fatto da scudo a chissà quante aziende.

Esempio di un Dockerfile insicuro

# Dockerfile VULNERABILE
FROM python:3.11-slim
WORKDIR /app
RUN pip install litellm fastapi uvicorn
...

Una build basata su un Dockerfile come questo, eseguita nella finestra temporale dell’attacco, avrebbe installato la versione 1.82.7 senza battere ciglio, aprendo una falla enorme nella sicurezza dell’infrastruttura.

L’Eroe che non ti aspetti: requirements.txt e il potere del pinning

Con il pinning andiamo a dire a pip “installa questa versione e non aggiornarla, mai”. In pratica stiamo fissare virtualmente una specifica versione con una puntina da disegno. Questa non e’ solo una best practice (in Python, cosi’ come in Docker o in altri software di gestione pacchetti) per evitare problemi di breaking changes introdotte nei pacchetti nuovi, ma anche evita l’installazione scosiderata di nuove versioni con potenziali problemi.

Uno di quei problemi che va a prevenire, infatti, (anche se in modo relativo) e’ l’installazione di versioni nuove e non testate e che potenzialmente sono affette da bug importanti o da vulnerabilta'.

Alziamo il livello: Dalla toppa del momento a una strategia di Supply-Chain Security

La sicurezza della supply-chain e’ una delle sfide piu’ critiche per le aziende moderne che si occupano di distribuire software. Parte della sfida e’ che non esiste una definizione univoca e funzionale di sicurezza della supply-chain ed e’ una sfida che si estende su un’area estremamente ampia che include tutto, dalle minacce fisiche alle minacce informatiche (come in questo caso).

Se prendiamo ad esempio un software con LiteLLM che nel file requirements.txt contiene circa 80 righe di dipendenze e se pensiamo che ogni dipendenza usera’ con tutta probabilita’ altre dipendenze, si crea una catena di opportunita’ per un attaccante di infiltrarsi potenzialmente in decine o centinaia di migliaia di host diversi.

Ma allora quali sono i comportamenti da attuare per prevenire un attacco di questo tipo?

• Valutazione dei vendor e delle librerie: e’ necessario valutare attentamente ogni libreria (che sia open-source o commerciale) prima dell’integrazione, controllando la reputazione del maintainer;
• Pratiche di sviluppo sicuro: adottare il framework NIST SSDF per definire requisiti di sicurezza e scansioni automatiche con strumenti quali Dependabot o Snyk e integrare strumenti di code signing per garantire che il software distribuito non sia stato manomesso durante la build o la distribuzione;
• Soluzioni pratiche immediate: usare Sigstore e Codign per code signing nelle pipeline CI/CD per firmare container e binari.

Conclusioni: La fiducia è bene, il controllo è meglio

La fiducia nel mondo open-source e’ sicuramente fondamentale, ma va abbinata a pratiche di sicurezza robuste, come il pinning o tool come Dependabot che verificano le dipendenze usate.

Secondo voi, attacchi di questo tipo diventeranno la nuova normalità nel mondo open-source?

Proteggere la supply-chain del software non è un’opzione, ma una necessità. Se la sicurezza delle tue pipeline di CI/CD è una priorità e vuoi capire come implementare strategie robuste come quelle descritte in questo articolo, visita il mio portfolio per scoprire come posso aiutarti.