GitHub usa l’IA contro i bug, ma gli hacker colpiscono LiteLLM: è guerra aperta nella Supply Chain

GitHub amplia la propria strategia di sicurezza del codice con un nuovo sistema di rilevamento bug basato su IA integrato in Code Security. La piattaforma combina il motore semantico di CodeQL con modelli intelligenti capaci di estendere la copertura a linguaggi e framework finora più difficili da analizzare. Nello stesso momento, la minaccia alla supply chain open source si intensifica con la compromissione di LiteLLM su PyPI da parte dell’attore TeamPCP, che inserisce una backdoor sofisticata in un pacchetto con circa 95 milioni di download mensili. Le due notizie fotografano con precisione il nuovo equilibrio della sicurezza software. Da una parte, le piattaforme di sviluppo incorporano controlli sempre più avanzati direttamente nel workflow delle pull request. Dall’altra, i threat actor colpiscono dipendenze ad alta diffusione per ottenere accesso a credenziali, ambienti cloud e cluster Kubernetes. La sicurezza del codice non riguarda più solo la qualità del software, ma la tenuta dell’intera catena di sviluppo e distribuzione.

GitHub combina IA e CodeQL per rafforzare la sicurezza nelle pull request

Il nuovo approccio di GitHub si fonda su un modello ibrido che sceglie automaticamente lo strumento più adatto tra CodeQL e il modulo basato su IA in base al tipo di problema e al contesto del codice. L’obiettivo è superare i limiti della static analysis tradizionale, che resta molto efficace nei linguaggi già ben supportati ma incontra difficoltà in ecosistemi meno strutturati o più eterogenei. Il sistema agisce direttamente a livello di pull request, quindi prima che il codice venga fuso nel ramo principale e potenzialmente portato in produzione. Questa impostazione consente agli sviluppatori di intercettare vulnerabilità in una fase molto precoce del ciclo di vita del software. Invece di demandare il controllo a strumenti esterni o a revisioni tardive, GitHub integra la sicurezza nel flusso di sviluppo quotidiano. I risultati emergono nel punto in cui il team prende decisioni operative, cioè nel confronto sul codice in modifica, e questo riduce il rischio che issue importanti vengano ignorate o rimandate.

CodeQL mantiene l’analisi semantica mentre l’IA estende la copertura

Nel nuovo modello, CodeQL continua a rappresentare il motore di analisi semantica profonda per i linguaggi e gli ambienti già supportati in modo maturo. La sua forza resta la capacità di comprendere strutture, flussi di dati e pattern di vulnerabilità con un approccio rigoroso, particolarmente utile nei repository enterprise e nei progetti di grandi dimensioni. L’elemento di novità è però il ruolo assegnato all’IA, che entra in azione nelle aree in cui l’analisi statica tradizionale ha storicamente avuto una copertura più debole. Tra gli ecosistemi citati rientrano Shell, Bash, Dockerfiles, Terraform, PHP e altri framework difficili da inquadrare con sole regole statiche. Qui il modulo IA aiuta a individuare crittografia debole, configurazioni insicure, query SQL non sicure e altri pattern di rischio che spesso sfuggono ai tool tradizionali. Il vantaggio non è solo quantitativo, cioè più copertura, ma qualitativo: la sicurezza riesce a entrare in segmenti di codice che finora ricevevano meno attenzione e che invece risultano spesso centrali nelle pipeline moderne.

GitHub porta i risultati di sicurezza direttamente nel workflow degli sviluppatori

Uno dei punti più forti del modello introdotto da GitHub è la sua natura nativa. Gli alert vengono mostrati direttamente nella pull request, senza richiedere il passaggio a dashboard separate o strumenti terzi. In questo modo il feedback sulla sicurezza arriva nello stesso spazio in cui si discutono qualità del codice, performance, leggibilità e compatibilità. La sicurezza smette quindi di essere un’attività separata, affidata a un team isolato o a controlli posticipati, e diventa una proprietà intrinseca del processo di sviluppo. GitHub evidenzia che questo approccio riduce la probabilità che codice pericoloso entri in produzione e semplifica la remediation. Gli sviluppatori non devono cambiare contesto operativo per analizzare i problemi rilevati, e questo elemento ha un peso concreto in organizzazioni dove velocità di rilascio e pressione produttiva rischiano spesso di comprimere i controlli. Quando la sicurezza è incorporata nel punto esatto in cui si approva il codice, aumentano le possibilità che venga davvero presa sul serio.

I test interni mostrano volumi elevati e feedback positivi

Secondo i dati forniti nel testo, i test interni del nuovo sistema hanno elaborato oltre 170.000 rilevamenti in 30 giorni, con circa l’80 percento di feedback positivo da parte degli sviluppatori. È un dato importante perché segnala due aspetti: la scalabilità del modello e la sua accettazione nel workflow reale. Molti strumenti di sicurezza falliscono infatti non solo perché tecnicamente incompleti, ma perché generano troppo rumore o frizioni e finiscono per essere aggirati o ignorati. Qui invece emerge che la grande maggioranza degli issue segnalati è considerata valida. Questo lascia intendere un rapporto relativamente equilibrato tra copertura e precisione, punto essenziale in ogni sistema di detection. Se un modello produce troppi falsi positivi, i team smettono di fidarsi. Se ne produce troppo pochi, lascia passare codice vulnerabile. GitHub punta evidentemente a posizionarsi in quella zona intermedia in cui l’alert resta utile, leggibile e concretamente azionabile.

Copilot Autofix accelera la remediation e riduce i tempi di correzione

L’integrazione con Copilot Autofix aggiunge un ulteriore livello di automazione. Non ci si limita a segnalare il problema: il sistema suggerisce direttamente una possibile correzione, accorciando il percorso tra rilevamento e risoluzione. In base ai dati riportati, il tempo medio di remediation scende da 1,29 ore a 0,66 ore su un insieme di 460.000 alert di sicurezza raccolti nel 2025. Si tratta di una riduzione significativa, che mostra come il vero valore dell’IA nella sicurezza non stia solo nella detection, ma anche nella capacità di chiudere il ciclo operativo. Questo elemento è cruciale soprattutto nei team che devono gestire grandi volumi di codice, dipendenze e deployment frequenti. Un alert senza contesto o senza proposta di fix tende a trasformarsi in backlog. Un alert accompagnato da una correzione suggerita entra invece molto più facilmente nel flusso reale di lavoro. GitHub costruisce così una sicurezza sempre più orientata all’azione, pensata per intervenire rapidamente prima che una vulnerabilità resti aperta abbastanza a lungo da diventare sfruttabile.

TeamPCP compromette LiteLLM su PyPI in un attacco alla supply chain

Sul versante opposto della sicurezza, la campagna di TeamPCP dimostra quanto il rischio supply chain stia diventando sofisticato e aggressivo. Il gruppo compromette la libreria LiteLLM su PyPI nelle versioni 1.82.7 e 1.82.8, pubblicate il 24 marzo 2026, inserendo una backdoor in un pacchetto estremamente diffuso. LiteLLM è usato come proxy per instradare richieste verso diversi provider di modelli linguistici, il che lo rende un obiettivo strategico: chi compromette questo snodo può intercettare segreti, credenziali e accessi in ambienti di sviluppo e produzione. L’aspetto più insidioso dell’operazione è che le modifiche malevole non compaiono nel repository GitHub upstream, ma vengono introdotte dopo il build nella distribuzione pubblicata su PyPI. Questo passaggio consente agli attaccanti di colpire la supply chain mantenendo un’apparenza di legittimità nel sorgente principale. Per gli sviluppatori e per i team di sicurezza si tratta di uno scenario particolarmente critico, perché la fiducia nel repository non basta più a garantire la sicurezza dell’artefatto installato.

La backdoor modifica proxy_server.py e usa un file .pth per attivarsi

La compromissione tecnica descritta nel testo è estremamente mirata. Il file proxy_server.py viene modificato con l’aggiunta di 12 righe di codice in un punto preciso tra il dizionario REALTIME_REQUEST_SCOPE_TEMPLATE e la funzione showwarning. Nella versione 1.82.8 viene inoltre incluso un file litellm_init.pth di 34.628 byte, progettato per forzare l’esecuzione del payload a ogni avvio dell’interprete Python. Questo schema rende la backdoor più persistente e più difficile da individuare nei controlli superficiali. Il payload è codificato in base64, decodificato al volo e lanciato tramite subprocess come processo detached. Si evita così l’uso di funzioni rumorose come exec o eval, spesso più facilmente intercettabili da scanner e regole di detection. Anche questo dettaglio mostra un livello elevato di sofisticazione operativa: l’obiettivo non è solo eseguire codice malevolo, ma farlo con il minimo possibile di segnali anomali in ambienti reali.

Il payload ruba credenziali, segreti cloud e accessi Kubernetes

La seconda dimensione dell’attacco riguarda la raccolta di dati sensibili. Il payload opera in tre fasi e punta a esfiltrare un insieme molto ampio di asset critici: chiavi SSH, credenziali cloud AWS, GCP e Azure, segreti Kubernetes, file .env, wallet crypto, chiavi TLS e cronologie di shell. Prima dell’esfiltrazione, i dati vengono cifrati con una combinazione di AES-256-CBC e RSA-4096, aumentando la protezione del traffico malevolo e rendendo più complesso l’esame del contenuto rubato. L’invio avviene verso models.litellm.cloud, che nel contesto descritto funge da destinazione dell’esfiltrazione. Se il malware rileva un token di service account Kubernetes, passa a una fase più aggressiva e avvia pod privilegiati su ogni nodo per ampliare l’accesso. Questo passaggio trasforma un’infezione iniziale nella pipeline software in una possibile compromissione dell’infrastruttura runtime, con accesso persistente e movimento laterale in ambienti di produzione.

TeamPCP instaura persistenza silenziosa e polling periodico verso il C2

La terza fase del payload punta a mantenere la presenza dell’attaccante nel sistema compromesso. Il malware installa un dropper di persistenza sotto forma di systemd user service chiamato System Telemetry Service, crea directory nascoste e programma un meccanismo di polling verso checkmarx.zone ogni 50 minuti per scaricare ulteriori binari. L’attivazione avviene dopo un ritardo iniziale di cinque minuti, una scelta che aiuta a sfuggire a controlli immediati o ambienti di test brevi. Il dettaglio della persistenza è importante perché mostra che l’obiettivo non è un semplice furto opportunistico di segreti. TeamPCP punta a un accesso duraturo, utile per sfruttare gli ambienti compromessi in fasi successive. L’attacco quindi non si esaurisce con l’installazione della libreria backdoorata, ma crea una base da cui condurre nuove operazioni, muoversi lateralmente e riutilizzare le credenziali raccolte per propagarsi in altri ecosistemi.

La campagna di TeamPCP colpisce la supply chain su più piattaforme

Il testo colloca l’operazione su LiteLLM all’interno di una campagna più ampia. TeamPCP ha già compromesso in precedenza tool di sicurezza come Trivy e KICS e sfrutta credenziali rubate per muoversi tra GitHub Actions, Docker Hub, npm, OpenVSX e PyPI. Questo schema rivela una strategia chiara: colpire componenti di fiducia, spesso già integrati nei processi CI/CD, per ottenere la massima diffusione con il minimo attrito. L’attore dimostra di comprendere molto bene l’architettura della supply chain moderna. Non serve violare direttamente il bersaglio finale se si può contaminare uno strumento già presente nelle sue pipeline. In questo senso, LiteLLM è un target quasi ideale: è ampiamente usato, gestisce traffico legato a modelli linguistici e può esporre ambienti con privilegi significativi. La lezione è netta: gli attaccanti non cercano più solo server vulnerabili, ma punti di fiducia distribuiti nel software stack.

GitHub amplia la copertura proprio dove gli attacchi diventano più frequenti

L’iniziativa di GitHub assume un significato ancora più forte se letta alla luce di casi come quello di LiteLLM. L’espansione del rilevamento a Dockerfiles, Terraform, script Shell e altri ambienti infrastrutturali risponde infatti a un’evoluzione concreta del rischio. Le configurazioni errate, i secret esposti e i pattern insicuri nei file di automazione e deployment sono oggi tra i vettori più sensibili per attacchi alla supply chain e compromissioni operative. Il modello ibrido non elimina il rischio di manomissione a monte di un pacchetto pubblicato, ma aiuta a ridurre la superficie su cui queste minacce possono prosperare. Se gli sviluppatori ricevono alert tempestivi su codice infrastrutturale e configurazioni deboli, aumenta la probabilità di intercettare anomalie e ridurre le finestre di esposizione. In questo senso, la nuova feature GitHub non è soltanto un miglioramento incrementale: è una risposta strutturale a un panorama in cui codice applicativo, infrastruttura e sicurezza della supply chain si fondono sempre di più.

Sviluppatori e aziende devono verificare dipendenze e reagire subito

Il testo indica chiaramente le prime contromisure operative. Chi utilizza LiteLLM deve verificare immediatamente la versione installata e fare rollback alla 1.82.6 considerata pulita. Le organizzazioni che gestiscono pipeline CI/CD, ambienti cloud e cluster Kubernetes devono controllare log di importazione, processi avviati da Python e segnali compatibili con la persistenza descritta. In parallelo, GitHub raccomanda l’attivazione di Code Security con il nuovo modulo IA nei progetti che includono Docker, Terraform o script shell. Il punto, però, è più ampio della singola remediation. La combinazione tra il rilascio di strumenti più intelligenti da parte delle piattaforme di sviluppo e la crescita di attacchi come quelli di TeamPCP mostra che la sicurezza software sta entrando in una nuova fase. Le aziende non possono più considerare la verifica delle dipendenze, la scansione delle pull request e il monitoraggio della supply chain come attività opzionali o accessorie. Devono trattarle come controlli permanenti, integrati e aggiornati. È lì che oggi si gioca gran parte della difesa del software moderno.