Una pull request quasi cancellava tutto: il rischio nel tuo build

Una pull request quasi trasformava un aggiornamento in un disastro

Una pull request apparentemente normale ha rischiato di inserire in un’estensione distribuita a quasi un milione di sviluppatori un’istruzione capace di cancellare file locali e risorse cloud. È il fatto raccontato da One pull to wipe them all, pubblicato da The New Stack.

Secondo la fonte, il codice malevolo scaricava un file esterno durante la build, inseriva un nuovo prompt nello script di packaging e avviava l’agente senza ulteriori richieste di approvazione. L’esecuzione non è andata a buon fine a causa di un errore di formattazione, ma il punto resta: una modifica al repository poteva cambiare il comportamento dell’agente e arrivare fino alla release ufficiale.

Per un founder, la lezione non è “non usare gli agenti”. È più concreta: il tuo processo di build può eseguire istruzioni che non hai mai approvato esplicitamente.

Cosa significa se il tuo codice l’ha scritto Q Developer

Immagina di aver usato Q Developer per preparare un progetto, aggiornare le dipendenze o configurare una pipeline CI/CD. L’agente legge il repository, modifica alcuni file e il controllo automatico conferma che il progetto compila.

Il rischio tecnico che prendiamo come esempio è uno solo: la pipeline esegue codice o scarica risorse esterne senza verificarne origine e integrità.

Può succedere in diversi punti:

• uno script di build scarica un file da un URL variabile;
• una dipendenza viene installata senza versione fissata;
• un hook postinstall esegue comandi durante npm install;
• una GitHub Action usa un riferimento mobile invece di un commit preciso;
• uno script di packaging passa contenuti generati o recuperati online direttamente a un agente;
• un token con permessi di scrittura viene reso disponibile alla pipeline più a lungo del necessario.

Il progetto può funzionare perfettamente sulla tua macchina. La build può risultare verde. Il pacchetto finale può essere prodotto correttamente. Ma se la pipeline tratta codice esterno o istruzioni recuperate online come materiale fidato, una modifica al repository o a una dipendenza può alterare ciò che viene eseguito prima della distribuzione.

Non serve immaginare un attacco sofisticato. Basta una risorsa cambiata, un riferimento non bloccato o un comando eseguito con permessi eccessivi. Il problema non è Q Developer in sé: è il confine tra ciò che il repository dichiara e ciò che la pipeline permette davvero di eseguire.

Perché ora ti serve un audit del repository

La domanda utile non è: “Q Developer ha scritto codice sicuro?”. È questa: quali istruzioni, file e dipendenze possono influenzare la build, e con quali permessi?

Per rispondere devi seguire il percorso completo dalla modifica al rilascio:

1. individua gli script che partono in installazione, test, build e packaging;
2. verifica quali URL, pacchetti, action e strumenti esterni vengono richiamati;
3. controlla se versioni e riferimenti sono fissati a commit o checksum verificabili;
4. ricostruisci quali segreti vengono passati alla pipeline;
5. verifica se la build può scrivere nel repository, pubblicare artefatti o modificare risorse cloud;
6. separa i passaggi deterministici dalle istruzioni che arrivano da file, issue, dipendenze o contenuti remoti;
7. stabilisci un verdetto sul fatto che una modifica non fidata possa raggiungere il percorso di rilascio.

Qui un audit VibeInspect ha un ruolo preciso. Carichi lo ZIP del repository e ottieni un PDF con score e verdetto. Con il piano Diagnostic ricevi anche file, righe ed evidenze: puoi vedere quale script introduce il contenuto esterno, quale credenziale viene resa disponibile e quale passaggio consente l’esecuzione.

Il valore non è trovare ogni stringa sospetta. È collegare la catena: origine della modifica → build → permessi → artefatto distribuito. Se la catena è controllata, hai una base per un PASS. Se esiste un percorso non verificato, hai un FAIL tecnico su cui intervenire prima del prossimo rilascio.

Un linter non può sostituire questa risposta. Il linter controlla regole locali. L’audit valuta il comportamento del repository come sistema.

Il verdetto deve riguardare la catena di fiducia

Una scansione superficiale può segnalare un curl, una dipendenza o una GitHub Action e fermarsi lì. Ma la presenza del comando non dimostra da sola un problema. Potrebbe scaricare un artefatto da un archivio interno con checksum verificato e permessi minimi.

Al contrario, un riferimento apparentemente innocuo può essere rischioso se punta a un ramo mobile, a un URL senza verifica o a un pacchetto che esegue script durante l’installazione.

Per questo l’evidenza deve rispondere a quattro domande:

• Che cosa viene eseguito?
• Da dove arriva?
• Come viene verificato?
• Che cosa può modificare se viene alterato?

Lo stesso principio vale per gli agenti. Se uno script costruisce un prompt prendendo dati da una pull request, da un file generato o da una risorsa remota, quel contenuto non dovrebbe diventare automaticamente un’autorizzazione. L’agente può interpretarlo come istruzione; la pipeline deve invece trattarlo come input non fidato e applicare un controllo separato.

Il nemico è l’assenza di verdetto. “La build passa” descrive un risultato funzionale, non dimostra che la catena di provenienza sia sotto controllo.

Cosa un linter non vede

Un linter può verificare formattazione, tipi, import e alcuni pattern pericolosi. Può segnalare una configurazione sospetta, ma normalmente non sa se un file scaricato durante la build è stato verificato con un checksum o se un riferimento esterno può cambiare domani.

Non ricostruisce sempre la differenza tra una dipendenza dichiarativa e uno script che esegue comandi con accesso ai segreti della CI. Non sa quale identità usa la pipeline per pubblicare un pacchetto. Non valuta automaticamente il blast radius di una pull request che modifica sia il codice sia lo script di packaging.

Anche i test possono passare. I test dimostrano che il progetto produce l’output atteso in uno scenario noto. Non dimostrano che un riferimento mobile non sia stato alterato, che un hook non esegua codice inatteso o che un token di pubblicazione abbia permessi eccessivi.

Il linter ti dice se alcune regole locali sono rispettate. L’audit ti dice se il percorso dal commit all’artefatto è verificabile e se una modifica non fidata può trasformarsi in un’azione reale.

Cosa fare questa settimana

1. Elenca tutti gli script eseguiti da installazione, test, build, release e packaging.
2. Cerca download durante la build e controlla URL, versioni, checksum e firme disponibili.
3. Fissa dipendenze, GitHub Action e immagini a versioni o commit immutabili.
4. Disabilita gli hook di installazione non necessari e documenta quelli indispensabili.
5. Verifica quali segreti sono disponibili in ogni job e riduci i permessi al minimo.
6. Separa la build dalla pubblicazione: un job che compila non dovrebbe poter modificare arbitrariamente il repository o l’infrastruttura.
7. Aggiungi una revisione obbligatoria per le modifiche a workflow, script di packaging e configurazioni dei permessi.
8. Se hai usato Q Developer e non sai formulare un verdetto sul percorso di rilascio, esegui un audit Diagnostic prima di distribuire una nuova versione.

Non devi rinunciare a Q Developer. Devi evitare che la velocità con cui produce modifiche diventi la velocità con cui una pipeline esegue istruzioni non verificate.

Carica lo ZIP del repository e ottieni un verdetto con evidenze tecniche: avvia un audit Diagnostic.