Homebrew 7.0 cambia sicurezza: scanner CVE, sandbox più rigida e GUI nativa su macOS

🐧 Novità principali

• Homebrew 7.0 integra il comando brew vulns e un database di advisory specifico per distinguere vulnerabilità aperte e fix già backportati.
• La sandbox limita maggiormente filesystem e rete durante build e installazione, mentre Linux passa da Bubblewrap a Landlock.
• BrewUI diventa l’interfaccia grafica ufficiale per macOS, ma mostra anche i comandi brew eseguiti per mantenere trasparenza sulle operazioni.

Homebrew 7.0 non è semplicemente la release che porta una GUI al package manager più diffuso nell’ecosistema macOS. La versione pubblicata il 13 settembre 2026 rafforza soprattutto il modello di sicurezza della distribuzione software: introduce un database interno di vulnerabilità, il nuovo comando brew vulns, una sandbox più restrittiva, verifiche delle firme anche sui dati API memorizzati in cache e una separazione più netta tra download e installazione. In parallelo arriva BrewUI, interfaccia grafica nativa che rende Homebrew più accessibile. Il cambiamento più importante resta però sotto la superficie: Homebrew cerca di ridurre la quantità di codice, rete e filesystem a cui un pacchetto può accedere mentre viene installato.

Homebrew porta le vulnerabilità dentro il package manager con brew vulns

La novità più rilevante per amministratori e security team è brew vulns, comando incorporato che controlla le formula installate confrontandole con vulnerabilità note attraverso OSV.dev. La differenza rispetto a uno scanner CVE generico è che Homebrew introduce anche un proprio advisory database, costruito sulle versioni e revisioni realmente distribuite dal progetto. Questo permette di distinguere una vulnerabilità ancora presente da un problema per il quale Homebrew abbia già integrato un backport senza necessariamente modificare la versione upstream del software. Il comando può filtrare per severità, analizzare dipendenze, controllare un Brewfile e soprattutto separare vulnerabilità con correzione disponibile da quelle prive di fix. Il database viene inoltre pubblicato attraverso le API delle formula e come indice scaricabile in formato OSV con licenza CC0, consentendo ai team aziendali di integrarlo nei propri strumenti. È un’evoluzione coerente con la pressione crescente sulla supply chain open source, dove Google ha già raccomandato quarantene temporali e repository intermedi prima dell’adozione delle nuove release. Homebrew porta quella logica direttamente nel package manager: sapere che una CVE esiste non basta, serve capire se la build realmente distribuita sia ancora vulnerabile.

La sandbox separa sempre di più il download dall’installazione

Homebrew 7.0 irrigidisce anche il comportamento delle installazioni. Il progetto sta spostando progressivamente il download delle dipendenze in una fase separata di fetch: durante questa fase sono disponibili rete e cache scrivibili, mentre nella successiva fase di installazione la rete può essere disabilitata e le cache rese read-only. È una separazione rilevante perché limita ciò che un sistema di build compromesso può fare durante brew install. Homebrew blocca inoltre per impostazione predefinita la lettura di parti non necessarie della home directory da parte dei processi sottoposti a sandbox, impedendo per esempio a un build script di curiosare liberamente tra chiavi SSH, credenziali e file personali. Le informazioni necessarie alla preparazione delle installazioni vengono sempre più spesso consegnate come dati strutturati e firmati anziché richiedere il caricamento di codice Ruby arbitrario. Il modello segue la stessa direzione delle difese introdotte nell’ecosistema JavaScript, dove npm 12 ha scelto di bloccare per impostazione predefinita gli script automatici durante l’installazione. In entrambi i casi l’obiettivo è ridurre il potere implicito concesso a una dipendenza semplicemente perché l’utente ne ha chiesto l’installazione.

Leggi anche: Sapphire Sleet compromette 140 pacchetti npm Mastra e trasforma normali aggiornamenti in una supply chain malevola

I tap restano una decisione di fiducia che la sandbox non può eliminare

Il rafforzamento non significa che Homebrew possa rendere sicuro qualsiasi software. La documentazione del progetto è esplicita: installare da un tap significa accordare fiducia agli autori di quel repository. I tap possono fornire formula, cask, comandi esterni e metadati contenenti codice eseguibile. Homebrew 6.0 aveva già introdotto un sistema di tap trust che obbliga a concedere esplicitamente fiducia ai repository non ufficiali; la 7.0 continua su quella strada senza fingere che la sandbox rappresenti un confine assoluto. Un’applicazione installata attraverso un cask viene comunque eseguita con i privilegi dell’utente, mentre gli installer .pkg dei vendor possono operare fuori dalla sandbox e richiedere sudo. Questa distinzione è fondamentale nel panorama macOS attuale. Campagne come PAMStealer hanno già dimostrato quanto sia efficace distribuire applicazioni contraffatte che imitano software open source affidabile, mentre ClickFix ha iniziato a sfruttare annunci sponsorizzati per convincere gli utenti Mac a incollare direttamente comandi nel Terminale. Homebrew può proteggere la propria catena ufficiale, ma non può trasformare un’origine non affidabile in software affidabile.

BrewUI rende Homebrew grafico senza nascondere i comandi eseguiti

La parte più visibile di Homebrew 7.0 è BrewUI, ora rilasciata come interfaccia grafica ufficiale nativa per macOS. L’applicazione permette di cercare pacchetti, navigare nel catalogo e controllare versioni installate senza utilizzare direttamente il Terminale. Può essere installata con brew install homebrew-app e richiede macOS Tahoe 26 o successivo. La scelta interessante è che BrewUI non prova a nascondere Homebrew dietro un’interfaccia completamente astratta: mostra i comandi brew sottostanti alle operazioni richieste. L’utente può quindi vedere quale azione verrebbe normalmente eseguita da riga di comando. La GUI amplia inevitabilmente il pubblico di Homebrew, finora fortemente associato a sviluppatori e utenti tecnici, ma lo fa senza introdurre un secondo sistema di gestione dei pacchetti. BrewUI rimane un front-end del medesimo motore. Questo può avere anche un effetto di sicurezza indiretto: installazioni, aggiornamenti e rimozioni diventano più comprensibili per chi utilizzava Homebrew soltanto copiando comandi trovati online, un comportamento ormai sfruttato sistematicamente dalle campagne ClickFix con fingerprinting dedicate agli utenti macOS.

Linux abbandona Bubblewrap e passa a Landlock

Homebrew 7.0 modifica anche la sandbox su Linux. La versione 6.0 aveva introdotto Bubblewrap, ma il progetto ha incontrato problemi soprattutto nei container, dove bwrap poteva richiedere capacità o configurazioni aggiuntive. La nuova release passa a Landlock, framework di sicurezza integrato nel kernel Linux che permette ai processi di restringere autonomamente l’accesso al filesystem. La conseguenza pratica è una sandbox senza dipendenze aggiuntive e senza la necessità di concedere privilegi Docker specifici soltanto per far funzionare Homebrew. I sistemi con kernel privi del supporto Landlock continuano comunque a funzionare, ma senza sandboxing Linux e con un avviso mostrato da brew doctor. È una scelta pragmatica: Homebrew non interrompe il supporto, ma rende visibile che l’ambiente opera con un livello di isolamento inferiore. Per infrastrutture CI e workstation di sviluppo questo dettaglio conta perché i package manager operano spesso in ambienti contenenti token, repository privati, credenziali cloud e segreti di deployment, precisamente i dati ricercati negli attacchi supply chain come quello che ha compromesso jscrambler su npm attraverso più release malevole consecutive.

Continua con:

• Rust e Firefox sotto attacco mostrano perché package manager ed estensioni sono diventati punti centrali della supply chain
• ClickFix sfrutta npm come hosting fidato e trasforma 24 pacchetti in infrastruttura per il phishing

Homebrew 7.0 riduce il potere implicito concesso a un pacchetto

Il vero cambiamento di Homebrew 7.0 non è quindi il passaggio dal Terminale alla finestra grafica. È il tentativo di rendere più esplicito e limitato ciò che accade tra il comando di installazione e l’esecuzione finale del software. Firma dei metadati, sandbox, separazione tra fetch e install, protezione della home directory, tap trust e vulnerability database intervengono tutti sullo stesso problema: un package manager occupa una posizione privilegiata perché scarica ed esegue codice scelto da altri. Il progetto mantiene però una distinzione importante nel proprio threat model: Homebrew può proteggere l’integrità della propria infrastruttura, delle formula ufficiali, dei bottle e dei processi di installazione, ma non garantisce che il software upstream scelto dall’utente sia sicuro. Una volta avviata l’applicazione installata, la responsabilità torna al sistema operativo e all’utente. È proprio questa separazione a rendere la 7.0 interessante sul piano della supply chain. Dopo anni nei quali gli ecosistemi npm, PyPI, crates.io e altri repository hanno mostrato quanto sia pericoloso affidarsi implicitamente a maintainer, script di installazione e aggiornamenti automatici, Homebrew sta cercando di restringere progressivamente quella fiducia. BrewUI porta nuovi utenti dentro Homebrew; le modifiche di sicurezza cercano contemporaneamente di ridurre ciò che un pacchetto può fare prima ancora che quell’utente decida di eseguirlo.