uv deduplica le wheel: le tue dipendenze Python non sono ancora sotto controllo

uv ora deduplica ogni wheel nella sua cache, ma questo non ti dice nulla su cosa hai installato

Con la versione 0.12.7, uv ha introdotto una cache content-addressed che elimina i duplicati wheel per wheel e, con la PR #21327 unita il 31 agosto 2026, addirittura file per file. Come racconta l'articolo Why uv Now Deduplicates Every Wheel in Its Cache, ogni file estratto viene ora salvato una sola volta usando il suo hash BLAKE3, con hardlink che ricostruiscono la struttura originale. In un benchmark reale, il risparmio è stato di circa 545 MiB, il 10% della cache.

È una notizia positiva: meno spazio occupato, meno usura del disco, cache più leggere in CI. Ma c'è un equivoco pericoloso che vale la pena chiarire subito. Una cache più pulita e più efficiente non ti dice quali dipendenze hai tirato dentro, da dove provengono e se qualcuna di quelle 200 wheel per progetto contiene una versione vulnerabile.

La deduplicazione ottimizza lo storage. Non fa alcuna valutazione sul contenuto. typing-extensions, httpx, pydantic vengono compattati con la stessa indifferenza con cui verrebbe compattata una libreria abbandonata da due anni o una versione con una CVE aperta.

Cosa significa se il tuo codice l'ha scritto Cursor

Se hai costruito il tuo backend Python con Cursor, probabilmente hai chiesto all'assistente di generare un servizio FastAPI, uno script di ingest dati o un job di background. E Cursor, come tutti gli strumenti di questo tipo, ha aggiunto le dipendenze necessarie al tuo requirements.txt o pyproject.toml mentre scriveva.

Il punto è questo: nessuno ha deciso consapevolmente quelle versioni. Le ha proposte il modello, basandosi su pattern statistici e su ciò che era comune al momento del suo addestramento. Il risultato tipico è un file di dipendenze con:

• versioni pinnate a un numero preciso che nessuno aggiorna più;
• pacchetti aggiunti "al volo" per far girare un esempio e poi mai rimossi;
• range di versioni larghi che al prossimo uv pip install tirano dentro qualcosa di nuovo e non testato.

uv ora conserva tutto questo in modo efficiente. Ma efficienza dello storage e igiene delle dipendenze sono due problemi diversi. Il tuo repository può avere una cache impeccabile e allo stesso tempo dipendere da una libreria con una vulnerabilità nota, oppure trascinare una transitiva che non hai mai scelto.

Perché ora ti serve un audit

Quando lasci che un assistente AI componga il grafo delle dipendenze, deleghi una decisione di sicurezza a un sistema che non conosce il tuo contesto. Non sa se quel pacchetto è mantenuto, se ha una CVE aperta, se esiste un'alternativa più solida. Sa solo che statisticamente "ci sta".

Un audit serve esattamente qui: a mettere un verdetto dove oggi c'è solo un file generato e mai rivisto. Le domande a cui rispondere sono concrete:

• Quali versioni pinnate sono ferme e a rischio?
• Ci sono dipendenze duplicate a versioni diverse nello stesso progetto?
• Il tuo requirements.txt contiene pacchetti che non usi più da nessuna parte nel codice?
• Ci sono transitive che introducono superfici d'attacco che non hai valutato?

VibeInspect funziona in modo diretto: carichi lo ZIP del repository, gli specialisti AI analizzano il codice e le dipendenze, e ricevi un PDF con file, riga ed evidenze. Nessun server coinvolto, il codice sorgente viene cancellato al termine dell'analisi. Non è un pentest e non corregge il codice al posto tuo: ti dà il verdetto che oggi ti manca, in modo che tu sappia esattamente dove intervenire.

Il piano Diagnostic è pensato proprio per questo tipo di problema tecnico specifico: non un giudizio generico, ma l'indicazione puntuale di quale dipendenza in quale file merita attenzione.

Cosa un linter non vede

È facile pensare: "ho già un linter, sono a posto". Ma un linter e un audit rispondono a domande diverse.

Un linter analizza la forma del tuo codice: stile, import inutilizzati nel file, variabili non usate, formattazione. È utilissimo, ma opera dentro il perimetro del sorgente che hai scritto. Non guarda fuori, dove vivono le dipendenze.

Un linter non ti dice:

• se la versione di una libreria che hai installato ha una vulnerabilità nota;
• se una dipendenza transitiva, che tu non hai mai dichiarato, sta introducendo un rischio;
• se il pin di versione nel tuo pyproject.toml è coerente con ciò che uv risolve davvero al momento dell'installazione;
• se un pacchetto è abbandonato e non riceverà più patch di sicurezza.

La cache di uv, per quanto ora deduplicata al livello del singolo file, appartiene allo stesso mondo dello storage: ottimizza come i byte vengono conservati, non giudica cosa quei byte rappresentano per la sicurezza del tuo progetto. Tra "la mia cache è pulita" e "le mie dipendenze sono sicure" c'è una distanza che nessuno strumento di storage colma.

Questo è lo spazio in cui un audit ha valore. Non ottimizza né riscrive: ti restituisce un verdetto sul grafo delle dipendenze che hai ereditato dal tuo assistente AI.

Cosa fare questa settimana

Non ti serve un progetto lungo. Ti servono un paio d'ore ben spese.

1. Apri il tuo file di dipendenze (requirements.txt o pyproject.toml) e conta quante versioni sono pinnate a un numero fisso che non tocchi da mesi.
2. Verifica quali pacchetti usi davvero. Se una dipendenza non compare in nessun import del codice, è candidata alla rimozione: meno superficie, meno rischio.
3. Se usi uv, prova la nuova cache con uv cache size --preview-features content-addressed-cache,cache-physical-space --human per capire quanto spazio recuperi — ma ricordati che è un'informazione sullo storage, non sulla sicurezza.
4. Ottieni un verdetto sul grafo delle dipendenze. Carica lo ZIP del repository su VibeInspect e chiediti quali librerie e quali versioni meritano attenzione, con file e riga alla mano.

L'errore non è aver usato Cursor per costruire in fretta. L'errore è pubblicare senza sapere in che stato sono le dipendenze che qualcun altro — o qualcos'altro — ha scelto per te. Questa settimana, trasforma quel dubbio in un verdetto.

👉 Fai l'audit del tuo repository con VibeInspect