Attacchi supply-chain: cosa resta esposto nel tuo repo dopo il caso TeamPCP

Due arresti per TeamPCP e oltre mille organizzazioni colpite via supply-chain

Il 26 agosto 2026, in Australia, sono state arrestate due persone di 21 e 23 anni collegate al gruppo TeamPCP, accusato di aver compromesso più di mille organizzazioni nel mondo attraverso attacchi alla supply-chain, con costi di bonifica globali stimati in centinaia di milioni di dollari. La ricostruzione è riportata su dev.to.

Il dettaglio che conta per te non è l'arresto, ma il metodo. Un attacco supply-chain non entra dalla porta principale della tua applicazione: entra da un componente meno protetto della catena, spesso una dipendenza che nessuno guarda più. Non serve bucare il tuo login se un pacchetto che importi porta già dentro qualcosa che non hai scritto tu.

È qui che la notizia smette di riguardare grandi aziende e comincia a riguardare il tuo repository.

Cosa significa se il tuo codice l'ha scritto Lovable

Quando generi un'applicazione con Lovable, lo scaffold arriva con un albero di dipendenze già montato: librerie per l'autenticazione, il client del database, gli helper di rete, i pacchetti di utilità. È comodo, funziona subito, e proprio per questo raramente qualcuno apre il package.json per chiedersi cosa ci sia davvero dentro.

Il problema non è aver usato Lovable. Il problema è che il grafo delle dipendenze cresce da solo, e ogni pacchetto trascina con sé altri pacchetti transitivi che non hai mai scelto in modo consapevole. Un attacco come quello di TeamPCP sfrutta esattamente questo: colpisce l'anello che tu dai per scontato.

Nel codice generato con AI si ripetono alcuni schemi ricorrenti:

• versioni di dipendenze non fissate, che al prossimo install tirano dentro release più recenti e mai verificate;
• pacchetti abbandonati o con un solo maintainer, candidati ideali per un takeover;
• dipendenze installate "per completezza" e mai usate, che allargano la superficie d'attacco senza portare valore;
• script di post-install eseguiti in automatico, di cui non hai mai letto una riga.

Se hai pubblicato senza sapere quali pacchetti gira davvero la tua build, non hai un'app sicura: hai un'app che per ora non è ancora stata colpita.

Perché ora ti serve un audit

Un audit non serve a sapere se un pacchetto è "buono" o "cattivo" in astratto. Serve a darti un verdetto su cosa contiene davvero il tuo repository e su quanto sei esposto oggi.

Quando generi con Lovable e spedisci in produzione, tu vedi l'interfaccia. Non vedi l'albero delle dipendenze, non vedi quali pacchetti vengono eseguiti in fase di build, non vedi dove una libreria trascina un segreto o accede alla rete. È esattamente lo spazio in cui vive un attacco supply-chain: nell'invisibile che dai per scontato.

VibeInspect nasce per questo. Carichi lo ZIP del tuo repository, il codice viene analizzato da specialisti AI e ricevi un PDF con un verdetto chiaro. Nessun server, il codice sorgente viene cancellato al termine dell'analisi. Non è un pentest e non ti promette sicurezza assoluta: ti dice in che stato è il tuo codice adesso, in modo che tu smetta di navigare a vista.

La differenza pratica è netta. Senza audit, la tua risposta alla domanda "le mie dipendenze sono un rischio?" è un'ipotesi. Con un audit, diventa un documento che puoi leggere, mostrare a un socio o a un investitore, e usare per decidere cosa toccare prima.

Puoi partire da VibeInspect.

Cosa un linter non vede

È facile confondere un linter con un controllo di sicurezza. Non lo è, e la differenza è proprio il tipo di rischio di cui parliamo qui.

Un linter guarda lo stile e la forma del codice che hai scritto: indentazione, variabili non usate, import disordinati, pattern sconsigliati. Lavora sulla superficie del tuo sorgente e si ferma lì.

Un attacco supply-chain, invece, vive fuori da quella superficie:

• non è nel tuo codice, è dentro una dipendenza che importi;
• non è una regola di stile, è una release manomessa che passa ogni controllo di formattazione;
• non produce errori di lint, perché il pacchetto è sintatticamente perfetto;
• non emerge da un build andato a buon fine, perché compilare non significa essere puliti.

Un linter ti dice se il codice è ordinato. Non ti dice se il pacchetto che hai installato ieri è ancora quello che credi, chi lo mantiene, quali permessi richiede, quali script esegue e cosa trascina con sé. Un audit ragiona su quel livello: sul grafo reale delle dipendenze e sulle sue conseguenze, con file, riga ed evidenze quando serve indicarti dove intervenire.

È la distanza tra "il codice è scritto bene" e "il codice è sicuro da spedire". Sono due domande diverse, e solo la seconda ti mette al riparo dallo scenario TeamPCP.

Cosa fare questa settimana

Non devi riscrivere l'applicazione. Devi capire su cosa sta girando davvero.

1. Apri il package.json (o l'equivalente del tuo stack) e conta quante dipendenze dirette hai davvero scelto in modo consapevole. Segna quelle che non riconosci.
2. Controlla se le versioni sono fissate o aperte: le versioni aperte sono la porta da cui entra una release compromessa.
3. Rimuovi le dipendenze che non usi più. Ogni pacchetto in meno è una superficie d'attacco in meno.
4. Verifica se qualche pacchetto esegue script in fase di install e se richiede accessi che non ti aspetti.
5. Fai eseguire un audit del repository, così ottieni un verdetto con evidenze su file e riga invece di un elenco di sospetti.

Se stai affrontando un problema tecnico preciso come le dipendenze e vuoi sapere esattamente dove sei esposto, il piano Diagnostic ti dà file, riga ed evidenze. Carica lo ZIP su VibeInspect e trasforma un'ipotesi in un verdetto.