AI coding agent e supply chain: dipendenze, package e comandi generati automaticamente

Un coding agent può risolvere un errore installando una libreria, cambiando un lockfile, aggiornando una base image o lanciando un comando nel terminale. La feature riparte, i test passano e il team prosegue. Ma ogni pacchetto aggiunto entra nella supply chain del prodotto: codice di terzi, dipendenze transitive, script di installazione, licenze, vulnerabilità e comportamento in pipeline.

Il rischio non riguarda solo i pacchetti vulnerabili. Nasce quando l’agente sceglie componenti e comandi per far funzionare rapidamente una feature senza valutare maturità, manutenzione, licenza, typosquatting, lockfile, container, registry, token, SBOM e controlli di merge.

Per DevOps, security engineer e CTO, la domanda concreta prima del merge è: quali nuove dipendenze ha introdotto l’AI, perché servono, cosa eseguono, quali componenti transitivi portano, quali script lanciano, quali licenze hanno e come verranno monitorate dopo il deploy.

Quando l’AI installa un pacchetto per risolvere un errore

Il pattern è comune: la build fallisce, manca un parser, un SDK non è configurato, un test richiede un mock o un componente frontend ha bisogno di una utility. L’assistente suggerisce npm install, pip install, cargo add o go get, aggiorna package.json, modifica requirements.txt, cambia un lockfile o inserisce una dipendenza nel Dockerfile.

Questa scorciatoia può essere corretta, ma va revisionata come una modifica di sicurezza. Una libreria non è solo una funzione in più: può eseguire codice in fase di installazione, importare decine di pacchetti transitivi, avere una licenza incompatibile, essere poco mantenuta o introdurre vulnerabilità note. La prima domanda non è “il pacchetto funziona?”, ma “serve davvero?”. Se il progetto ha già una libreria equivalente, se il problema si risolve con poche righe di codice chiaro o se la dipendenza entra solo per far passare un test, il costo in termini di supply chain può superare il beneficio.

Dependency sprawl: il costo nascosto del vibe coding

Dependency sprawl significa accumulare librerie perché ognuna risolve un piccolo problema locale. Con gli AI coding agent questo fenomeno accelera, perché l’agente non sente il peso operativo di mantenere pacchetti nel tempo: installa, adatta il codice e passa oltre.

Il costo arriva dopo: aggiornamenti di sicurezza, incompatibilità tra versioni, bundle più grande, build più lente, licenze da gestire, CVE da triaggiare, dipendenze transitive da monitorare, container più pesanti, SBOM più complessa e superficie d’attacco più ampia. Una regola pratica aiuta: ogni nuova dipendenza deve avere una motivazione, un owner e un’alternativa valutata. Se nessuno sa perché è stata aggiunta o quale rischio introduce, non dovrebbe entrare nel merge solo perché l’ha suggerita l’AI.

Typosquatting e pacchetti quasi omonimi

I modelli possono suggerire nomi plausibili che a volte corrispondono al pacchetto corretto, altre volte a un’alternativa poco nota, un wrapper non mantenuto o un package creato per intercettare errori di battitura. Il rischio aumenta quando l’agente installa automaticamente senza far passare la scelta da un controllo umano.

Prima di accettare un package, è necessario verificare registry, repository ufficiale, maintainer, release recenti, issue aperte, volume di download, firma o provenance se disponibile, documentazione e community. Non basta che il nome sembri familiare: in ecosistemi come npm e PyPI, differenze minime nel nome possono portare a pacchetti completamente diversi. Per pacchetti critici, vale la pena valutare anche la catena dei maintainer, perché un progetto legittimo ma abbandonato, acquisito o con release improvvise dopo anni di silenzio richiede cautela sia sul piano tecnico sia su quello della fiducia nella manutenzione.

Dipendenze transitive e lockfile

Il manifest mostra ciò che il team ha dichiarato di voler usare; il lockfile mostra ciò che entrerà davvero nella build. Una singola dipendenza può portare decine o centinaia di pacchetti transitivi, e un aggiornamento automatico può cambiare versioni non previste. Un lockfile rigenerato può nascondere una superficie molto più ampia del diff visibile in package.json.

Il lockfile va revisionato insieme al manifest. Se l’AI aggiorna package-lock.json, pnpm-lock.yaml, yarn.lock, poetry.lock, uv.lock, Pipfile.lock, go.sum o Cargo.lock, il reviewer deve capire cosa è cambiato: nuovi pacchetti, major upgrade, script, sorgenti di registry e dependency tree. Non serve leggere ogni riga manualmente, ma serve avere visibilità su ciò che è entrato. Per ridurre il rumore, conviene separare gli update intenzionali dalle feature: una PR che aggiunge una funzionalità e aggiorna metà lockfile è difficile da validare, quindi è preferibile isolare la dipendenza necessaria, bloccare le versioni ed evitare latest.

Script di installazione e lifecycle hooks

Molti package manager permettono script in fase di installazione o build: preinstall, install, postinstall, prepare, setup script, build script, plugin e hook. Questi script possono eseguire codice sui laptop dei developer, in CI/CD o dentro container. Se l’AI aggiunge un pacchetto senza controllare questi script, sta di fatto autorizzando codice di terzi a girare nel processo di build.

La review deve cercare script nuovi o modificati nei manifest e nei pacchetti aggiunti. Un comando apparentemente innocuo può scaricare binari, generare codice, leggere variabili d’ambiente, inviare telemetry o alterare file. In ambienti CI con token e secret, uno script di installazione malevolo può avere un impatto serio. Quando possibile, è utile adottare policy che limitano l’esecuzione di script, build sandboxate, token con scope minimo e registry controllati.

Licenze e compliance del codice di terzi

La supply chain non riguarda solo le vulnerabilità. Una libreria può essere tecnicamente sicura e commercialmente problematica: licenze copyleft, restrizioni d’uso, obblighi di attribuzione, incompatibilità con la distribuzione proprietaria o con le policy cliente possono rendere una dipendenza inadatta al contesto.

Gli agenti AI non sempre considerano i vincoli di licensing. Se si chiede di aggiungere una libreria per esportare PDF, l’assistente può scegliere ciò che conosce o ciò che funziona, non necessariamente ciò che è compatibile con il modello di business o con il contratto cliente. Per software house e prodotti B2B, ogni nuova dipendenza dovrebbe passare da license scanning o allowlist. Le eccezioni vanno documentate, perché in assenza di policy il rischio emerge tardi: durante due diligence, audit cliente, procurement enterprise o preparazione al rilascio.

Container, base image e pacchetti di sistema

Il rischio supply chain non si ferma al codice applicativo. Un agente può modificare Dockerfile, base image, pacchetti OS, installer, script curl, repository apt, versioni Node o Python, build stage e permessi runtime. Può usare latest, installare tool non necessari o lasciare l’applicazione in esecuzione come root.

Ogni immagine va trattata come un componente del prodotto. Le pratiche raccomandate includono base image minime e mantenute, pin di versione, scanning container, utente non root dove possibile, riduzione dei pacchetti OS, multi-stage build pulite e assenza di secret nei layer. Se l’AI aggiunge un pattern del tipo curl | sh, è necessario fermarsi e verificare fonte, firma, checksum e necessità prima di procedere. Una build che passa perché il container installa “tutto quello che serve” può diventare difficile da patchare e monitorare nel tempo.

Ecosistemi diversi, segnali diversi

Il controllo supply chain cambia in base allo stack. In Node.js il rischio passa spesso da package.json, lockfile, script npm, pacchetti transitivi e bundle frontend. In Python occorre guardare requirements.txt, pyproject.toml, lockfile, wheel, dipendenze native, index privati e pacchetti quasi omonimi. In Go, go.mod e go.sum rendono più chiara la dependency graph, ma vanno comunque controllati module path, replace directive e sorgenti. In Rust, Cargo.toml e Cargo.lock mostrano crate e feature abilitate.

Un agente AI può conoscere la sintassi di tutti questi ecosistemi, ma non conosce le policy del team. Può usare npm audit fix cambiando più versioni del necessario, installare un pacchetto Python non approvato, aggiungere una feature Cargo che porta codice non previsto o modificare un Dockerfile per installare librerie di sistema senza pin. Per ogni ecosistema la regola è la stessa: manifest e lockfile vanno letti insieme, le sorgenti dei package devono essere note e gli aggiornamenti automatici devono essere separati dalle feature. Se il progetto usa registry privati, è importante verificare anche fallback e priorità, perché una configurazione sbagliata può scaricare un pacchetto pubblico invece di quello interno.

Dependency confusion e registry privati

Le aziende che usano pacchetti interni devono considerare il rischio di dependency confusion. Se un pacchetto privato ha un nome che può esistere anche su un registry pubblico, una configurazione errata del package manager può scaricare il componente sbagliato. Gli agenti AI possono aggravare il problema generando configurazioni di registry generiche o rimuovendo impostazioni perché “non servono” alla build locale.

È necessario controllare scope npm, index Python, registry Docker, GitHub Packages, GitLab Package Registry, proxy aziendali e mirror, verificando che i package interni siano risolti dal registry corretto, che i token abbiano scope minimo e che i log non espongano credenziali. Se un agente modifica .npmrc, pip.conf, poetry config, Docker login o workflow di publish, quella modifica va trattata come sensibile. Il test più semplice è riprodurre la build in ambiente pulito e osservare da dove vengono scaricati i pacchetti: una build che funziona sul laptop del developer ma usa sorgenti diverse in CI non è governabile.

Registry, token e credenziali di pubblicazione

Supply chain significa anche chi può scaricare e pubblicare. Token npm, PyPI, GitHub Packages, Docker registry, package registry privati e credenziali CI/CD devono avere scope minimo. Un agente con accesso al terminale o alla pipeline può leggere o usare token se l’ambiente non è adeguatamente separato.

Occorre verificare dove vivono i token di registry, chi può pubblicare, quali branch attivano release, quali pacchetti sono privati, quali namespace sono protetti e quali log possono stampare credenziali. Se l’AI modifica workflow di publish o versioning, quella modifica è sensibile e richiede revisione esplicita. Per i package interni, proteggere naming e namespace è fondamentale: un import ambiguo o una configurazione registry sbagliata può portare a dependency confusion, con il build system che scarica un pacchetto pubblico invece di quello interno previsto.

SBOM, provenance e tracciabilità

Se non si sa cosa è entrato nella build, non è possibile gestirlo nel tempo. Una Software Bill of Materials aiuta a elencare componenti, versioni e dipendenze. CycloneDX è uno standard consolidato per rappresentare SBOM, mentre OpenSSF SLSA fornisce un framework per ragionare su provenance e integrità della build.

Per un MVP piccolo una SBOM può sembrare eccessiva, ma per un prodotto che va a clienti, un SaaS con dati reali o una software house che consegna codice diventa uno strumento pratico: quando esce una CVE, quando un cliente chiede evidenze o quando una dipendenza viene compromessa, sapere cosa è incluso nella release riduce tempi e incertezza. Gli agenti AI aumentano la necessità di tracciabilità perché possono aggiungere e cambiare componenti frequentemente. Senza SBOM o dependency inventory, il team dipende dalla memoria di chi ha accettato il diff.

Scanner automatici: necessari, non sufficienti

SCA, dependency scanning, container scanning e license scanning sono controlli indispensabili: intercettano vulnerabilità note, licenze problematiche e versioni obsolete. Non rispondono però a tutte le domande di sicurezza rilevanti.

Uno scanner non valuta se quella dipendenza serve davvero, se un pacchetto quasi omonimo è stato scelto per errore, se uno script postinstall è coerente con la policy aziendale, se il lockfile è stato rigenerato senza motivo, se una licenza è accettabile per quel cliente o se la build scarica codice in modo non riproducibile. Per questo la review supply chain deve combinare strumenti automatici e giudizio umano: lo scanner dà segnali, ma la decisione di merge richiede contesto.

Monitoraggio dopo il merge

La supply chain non si chiude al merge. Una dipendenza pulita oggi può ricevere una CVE domani, cambiare maintainer, introdurre una release compromessa o diventare incompatibile con una patch di sicurezza. Per questo è necessario sapere quali componenti sono in produzione e chi possiede la remediation.

Il monitoraggio deve collegare SBOM, scanner, vulnerability management, issue tracking e release. Quando emerge una vulnerabilità, il team deve capire rapidamente se il componente è presente, in quale versione, in quale servizio, se è raggiungibile, se esiste un exploit attivo, quale mitigazione applicare e chi deve approvare l’aggiornamento. Gli agenti AI possono aiutare a preparare upgrade, ma non dovrebbero applicarli senza review: un update automatico può correggere una CVE e rompere auth, parsing, serializzazione, upload o compatibilità runtime. La patch va trattata come una modifica di prodotto, non come semplice housekeeping.

Quando il pacchetto tocca la sicurezza applicativa

Alcune dipendenze richiedono attenzione maggiore perché entrano direttamente nei confini di sicurezza: librerie auth, JWT, crypto, sanitizzazione HTML, template engine, parser markdown, upload, validazione input, ORM, database driver, HTTP client, CORS middleware, rate limiting, logging e secret management.

Se l’AI sostituisce o riconfigura una di queste librerie, la review deve leggere anche il comportamento applicativo. Un nuovo parser può cambiare la gestione XSS; un middleware CORS può aprire domini non previsti; un ORM update può modificare query o escaping; un package di upload può accettare MIME type o path in modo diverso; una libreria JWT può richiedere configurazioni esplicite su algoritmo, audience o issuer. Queste dipendenze non vanno approvate solo perché non hanno CVE note: la domanda è se sono configurate correttamente per il prodotto. È qui che supply chain e application security si incontrano.

Comandi generati automaticamente dagli agenti

Quando un agente ha accesso al terminale, può eseguire installazioni, aggiornamenti, migration, test, script di build, comandi cloud e modifiche di configurazione. Il log dei comandi diventa parte della review: non basta guardare il codice finale, bisogna sapere cosa è stato eseguito.

Un comando può modificare file non attesi, aggiornare lockfile, installare pacchetti globali, cambiare configurazioni locali, generare artifact, creare cache o inviare dati a servizi esterni. In ambienti con secret, token o credenziali cloud il rischio aumenta ulteriormente. Per agenti operativi è necessario definire allowlist di comandi, richiedere approvazione per installazioni e deploy, usare ambienti sandbox, token con scope minimo e conservare i log. Se l’agente installa pacchetti senza approvazione, il processo di review parte già in ritardo.

Policy di merge per dipendenze generate dall’AI

Una policy efficace non deve bloccare ogni cambiamento, ma rendere esplicite le decisioni. Ogni nuova dipendenza proposta o installata dall’AI dovrebbe indicare: motivo, package manager, versione, licenza, maintainer, alternative considerate, impatto su lockfile, risultati SCA, eventuali script e owner interno.

Le dipendenze ad alto rischio dovrebbero richiedere approvazione esplicita: pacchetti non mantenuti, librerie con pochi download, wrapper di sicurezza, parser, template engine, upload handler, crypto, auth, networking, package che eseguono script, base image nuove e tool che entrano in CI/CD. Per team che usano AI coding in modo continuativo, questa policy diventa parte del Software Assurance Lifecycle: non serve fare un’eccezione ogni volta, ma avere un percorso ripetibile per installare, valutare, approvare e monitorare.

Come ISGroup verifica supply chain e dipendenze generate dall’AI

ISGroup può verificare una PR, un repository o un processo di rilascio in cui gli agenti AI modificano dipendenze, lockfile, Dockerfile, workflow, script o package registry. Il controllo riguarda sia il codice sia la catena che lo porta in produzione.

Se l’AI ha modificato…	Rischio principale	Controllo consigliato
Manifest, lockfile, package, script, Dockerfile o dependency tree	Dipendenze vulnerabili, non necessarie o non governate	Code Review
Componenti, servizi, librerie e versioni esposte online	Vulnerabilità note sfruttabili	Vulnerability Assessment
Dipendenze e componenti in produzione da monitorare nel tempo	Vulnerabilità ricorrenti e patch management	Vulnerability Management Service
Pipeline, policy di merge, controlli SCA, SBOM e gate di release	Processo non ripetibile sulle release	Software Assurance Lifecycle
Cloud, container registry, IAM, token, artifact e deploy	Misconfiguration o privilegi eccessivi	Cloud Security Assessment

La scelta del controllo dipende dal punto in cui entra il rischio: codice e manifest, componenti esposti, processo di patching, pipeline o cloud. Prima del merge conviene sapere se il pacchetto serve davvero e se la build resta governabile. Se hai una PR generata da AI che aggiunge package, modifica lockfile o cambia pipeline, ISGroup può aiutarti a verificare dipendenze, script, container, SBOM e controlli di merge prima della release.

Evidenze da preparare per una verifica

Per avviare una verifica efficace, è utile raccogliere repository, branch, PR, manifest, lockfile, dependency tree, Dockerfile, workflow CI/CD, scanner usati, report SCA, license report, SBOM se presente, comandi eseguiti dall’agente, token coinvolti, registry usati e motivazione delle nuove dipendenze.

Per ogni package aggiunto, è utile documentare nome, versione, registry, maintainer, repository, licenza, alternative disponibili, motivo tecnico, dipendenze transitive, script di installazione e owner interno. Se l’agente ha eseguito comandi, è importante conservare log e output. Queste evidenze permettono di distinguere una dipendenza necessaria da una scorciatoia generata, un rischio bloccante da un aggiornamento pianificabile e una vulnerabilità nota da un problema di processo.

Quando bloccare il merge

Blocca il merge se una nuova dipendenza è sospetta, non necessaria, non mantenuta, con licenza incompatibile, con script non verificati, con vulnerabilità critica non mitigata, con lockfile troppo ampio senza spiegazione o se la pipeline è stata modificata per aggirare controlli.

Puoi pianificare dopo il merge solo attività con rischio residuo basso: migliorare la documentazione, generare SBOM se il rilascio non è imminente, affinare policy, aggiungere pattern di scanning o ridurre dipendenze non critiche con owner e scadenza. Le dipendenze che eseguono codice, toccano la sicurezza o entrano in produzione devono essere chiare prima.

Checklist supply chain per PR generate da agenti

• Ogni nuova dipendenza ha motivo, owner e alternativa valutata.
• Manifest e lockfile sono revisionati insieme.
• Package name, maintainer, registry e repository sono verificati.
• Script preinstall, install, postinstall, prepare e build sono controllati.
• SCA, license scanning e container scanning sono eseguiti.
• Versioni e base image hanno pin esplicito, senza latest non motivato.
• SBOM generata o aggiornata quando il prodotto lo richiede.
• Token registry e CI/CD hanno scope minimo.
• Comandi eseguiti dall’agente sono loggati e approvati dove necessario.
• Le dipendenze generate dall’AI passano da review obbligatoria prima del merge.

Domande frequenti

• Se lo scanner SCA è pulito, posso accettare la dipendenza?
• Non automaticamente. Lo scanner non valuta necessità, licenza, maintainer, typosquatting, script di installazione, coerenza del lockfile e impatto sul prodotto. È uno strumento di supporto, non un semaforo verde.
• Il lockfile va davvero revisionato?
• Sì. Il lockfile mostra cosa entra davvero nella build, incluse dipendenze transitive e aggiornamenti indiretti che non compaiono nel manifest.
• Un agente può installare pacchetti da solo?
• Può farlo solo se il processo lo consente. In progetti con dati reali o in produzione, installazioni e comandi che modificano dipendenze dovrebbero richiedere approvazione esplicita e log conservati.
• Quando serve una SBOM?
• Quando devi consegnare software, rispondere a clienti enterprise, gestire vulnerabilità nel tempo o sapere rapidamente se una CVE riguarda una release specifica.
• Cosa cambia rispetto a una Code Review normale?
• La Code Review legge il codice. La review supply chain legge anche manifest, lockfile, script, registry, container, SBOM, licenze, comandi eseguiti e pipeline.
• Quando serve il Vulnerability Management Service?
• Quando il problema non è solo controllare una PR, ma monitorare continuamente componenti, versioni e vulnerabilità in produzione nel tempo.

Fonti e riferimenti utili

• OWASP Dependency-Check: https://owasp.org/www-project-dependency-check/
• OWASP CycloneDX: https://owasp.org/www-project-cyclonedx/
• OpenSSF Scorecard: https://openssf.org/scorecard/
• OpenSSF SLSA: https://openssf.org/projects/slsa/
• OWASP SAMM: https://owasp.org/www-project-samm/
• OWASP Top 10 – Vulnerable and Outdated Components: https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/