Attenzione: attacchi mirati contro Rustacean di primo piano

I team di sicurezza di Rust hanno lanciato un severo avvertimento il 17 settembre, dopo che almeno una campagna mirata è passata da videochiamate convincenti alla pubblicazione di crate dannosi. Attenzione: attacchi mirati contro Rustacean di primo piano non è un generico promemoria sul phishing. Gli aggressori si rivolgono ai membri dei progetti Rust e ai proprietari di crate popolari perché un singolo maintainer compromesso può esporre migliaia di ambienti di sviluppo a valle.

La campagna maschera il primo contatto come un'offerta di lavoro, un progetto di consulenza, una discussione su investimenti o un'opportunità contrattuale. Durante o dopo una videochiamata, il bersaglio incontra un presunto problema tecnico. La soluzione proposta comporta l'installazione di un codec audio, l'esecuzione di un comando o l'apertura di un progetto controllato dall'aggressore.

Questo approccio sociale sembra aver già avuto successo. Il 20 agosto, gli aggressori hanno pubblicato versioni dannose di arrayref, internment e append-only-vec attraverso un account di maintainer compromesso. Il loro codice veniva eseguito durante la compilazione, trasformando un normale aggiornamento di dipendenza in una via d'accesso alle workstation degli sviluppatori e ai sistemi di integrazione continua.

Il conflitto centrale non riguarda più semplicemente codice affidabile contro codice dannoso. Riguarda la fiducia personale contro l'autorità di pubblicazione dei pacchetti. Le persone che ricevono queste chiamate dispongono di diritti di pubblicazione capaci di trasformare una compromissione privata in un incidente della supply chain software.

Attenzione: attacchi mirati contro Rustacean di primo piano sono diventati un avvertimento per la supply chain

Il progetto Rust avverte i maintainer perché ritiene che gli aggressori puntino all'accesso di pubblicazione, non solo a singoli file o password.

Adam Harvey ha pubblicato l'avvertimento sugli attacchi mirati per il team crates.io e il gruppo di lavoro sulla risposta alla sicurezza di Rust. I team ritengono che una campagna in corso stia prendendo di mira membri di rust-lang e proprietari di crate popolari.

L'obiettivo sospettato è compromettere dispositivi e account, per poi usare quell'accesso per pubblicare malware. Questa valutazione collega il social engineering privato a un meccanismo di distribuzione pubblico. La workstation di uno sviluppatore, una sessione del browser, un account email o le credenziali crates.io possono diventare il ponte tra i due.

L'approccio segnalato inizia con un'opportunità positiva. Uno sconosciuto propone un lavoro, un progetto, un ruolo di consulenza, una conversazione su investimenti o un contratto. L'invito è abbastanza personalizzato da meritare una risposta e chi chiama può sostenere la storia con un profilo dall'aspetto professionale.

Secondo quanto riportato, gli aggressori hanno creato identità aziendali plausibili e presenze su LinkedIn. Queste risorse non devono superare una seria due diligence. Devono soltanto apparire credibili nel breve intervallo tra un messaggio non richiesto e una chiamata programmata.

La chiamata crea poi un ostacolo artificiale. L'audio apparentemente non funziona, sembra mancare un codec o appare necessario eseguire un comando per ripristinare l'accesso. Un'altra variante colloca un comando negli appunti e invita il bersaglio a incollarlo in un terminale.

Quel momento conta perché riformula l'esecuzione di codice come risoluzione di un problema tecnico. Il bersaglio non ritiene di installare consapevolmente un programma sconosciuto. Crede di risolvere un comune problema di comunicazione mentre un'altra persona attende sullo schermo.

L'avvertimento di Rust chiede ai destinatari di trattare i contatti a freddo con maggiore sospetto e di usare piattaforme di cui si fidano già. Raccomanda che, quando possibile, sia il bersaglio a creare la riunione. Ciò rimuove almeno un componente controllato dall'aggressore dall'interazione.

Ai maintainer viene inoltre chiesto di controllare i propri account per individuare attività inattese e di confermare che l'autenticazione a più fattori sia attivata. Chiunque sia preoccupato per l'accesso a crates.io può contattare il relativo indirizzo di supporto, mentre gli incidenti più ampi possono essere segnalati al team di sicurezza Rust.

Queste raccomandazioni sono volutamente semplici. La parte pericolosa di questa campagna non è un'oscura vulnerabilità di Rust. È un'interazione umana credibile seguita da un'azione ordinaria con conseguenze nascoste.

L'avvertimento non sostiene che ogni incidente segnalato appartenga a un unico operatore. I team Rust affermano esplicitamente di non sapere ancora se i tentativi di giugno, la compromissione di arrayref e l'attività attuale siano un'unica campagna. Questa incertezza dovrebbe limitare l'attribuzione, ma non riduce il rischio immediato.

Ecco perché Attenzione: attacchi mirati contro Rustacean di primo piano ha un peso maggiore di quanto suggerisca la sua formulazione prudente. L'avvertimento segue una compromissione effettiva della pubblicazione, non un modello di minaccia ipotetico.

L'incidente arrayref ha mostrato cosa può sbloccare un solo maintainer compromesso

L'attacco a arrayref ha trasformato il controllo di un singolo account legittimo di maintainer in pubblicazioni dannose su tre pacchetti consolidati.

Alle 7:15 UTC del 20 agosto, il Rust Security Response Team ha ricevuto una segnalazione secondo cui proc-macro1 era dannoso. Gli investigatori hanno confermato che il suo build script scaricava un payload remoto.

Un build script è codice che Cargo, il gestore di pacchetti e sistema di build di Rust, esegue durante la compilazione di un pacchetto. Può svolgere attività di configurazione legittime, ma viene eseguito prima dell'avvio di un'applicazione. Questo lo rende un luogo interessante in cui nascondere malware.

Il team ha scoperto che una nuova release di arrayref dipendeva direttamente da proc-macro1. Anche release pulite recenti erano state ritirate, il che poteva spingere la risoluzione delle dipendenze verso la versione dannosa. L'aggressore ha ripetuto lo schema con internment e append-only-vec, due crate controllati dallo stesso account di maintainer.

L'avviso ufficiale sull'incidente arrayref ha identificato tre release avvelenate. arrayref 0.3.10 è rimasto disponibile per 86 minuti, internment 0.8.7 per 90 minuti e append-only-vec 0.1.9 per 107 minuti.

Queste finestre sembrano brevi su un calendario. Sono abbastanza lunghe perché la risoluzione automatizzata delle dipendenze, le build degli sviluppatori, gli strumenti degli editor e i job di integrazione continua recuperino nuovi pacchetti.

Il team Rust ha eliminato le versioni dannose e sei crate correlati. Ha ripristinato release pulite che l'aggressore aveva ritirato e bloccato l'account del maintainer coinvolto. Il team di risposta ha dichiarato di non ritenere che l'autore legittimo avesse agito in modo dannoso.

Il team ha invece valutato che probabilmente fossero stati compromessi il computer o le credenziali dell'autore. Questa distinzione è importante perché mostra i limiti della reputazione. Un pacchetto noto può contenere codice controllato da un aggressore senza che il suo maintainer riconosciuto scelga di aggiungerlo.

I ricercatori di sicurezza hanno stimato che arrayref avesse circa 245 milioni di download complessivi. internment ne aveva circa 14,4 milioni, mentre append-only-vec circa 4,5 milioni. I totali cumulativi non equivalgono alle installazioni coinvolte, ma mostrano perché la scelta dell'account conta.

Gli aggressori non hanno dovuto distribuire un pacchetto sconosciuto e attendere che venisse adottato. Hanno collocato una dipendenza dannosa dietro progetti che gli sviluppatori già accettavano. I pacchetti genitori avvelenati apparivano per il resto familiari.

I crate ricoprivano inoltre ruoli tecnici diversi. arrayref fornisce macro per ottenere riferimenti ad array di dimensione fissa da slice. internment supporta l'interning, che conserva un'unica copia condivisa di valori ripetuti. append-only-vec fornisce un vettore concorrente le cui voci esistenti non vengono rimosse.

Nessuna di queste funzioni suggerisce naturalmente il download di un eseguibile remoto. Questa discrepanza è diventata visibile soltanto esaminando la nuova dipendenza e il suo comportamento durante la build.

L'incidente ha quindi cambiato il contesto di ogni successiva falsa opportunità. Una richiesta di lavoro rivolta a un maintainer ad alto impatto non può più essere valutata solo come spam personale. Può rappresentare la mossa iniziale di un altro attacco alla supply chain di Rust.

Una truffa con falso colloquio trasforma la cortesia professionale in esecuzione

Gli aggressori sfruttano la disponibilità di un maintainer a valutare un'opportunità, quindi organizzano l'interazione affinché la normale collaborazione esegua il loro codice.

La parte più pericolosa di questa campagna avviene prima che il malware raggiunga crates.io. Inizia con la ricerca sul bersaglio. La proprietà dei pacchetti, le appartenenze ai progetti, le apparizioni alle conferenze e gli interessi professionali sono spesso pubblici.

Queste informazioni aiutano un aggressore a creare un'offerta pertinente. Un messaggio generico da recruiter può essere ignorato. Una proposta che fa riferimento al lavoro del maintainer può meritare una conversazione, soprattutto se supportata da un sito aziendale e da un profilo social plausibili.

Un incidente di giugno documentato dallo sviluppatore Rust Matt Mastracci illustra la preparazione richiesta. Un fittizio rappresentante di investimenti lo ha contattato per un lavoro di consulenza, ha programmato una videochiamata e in seguito ha inviato un esercizio tecnico.

Il repository fornito sembrava contenere un normale progetto TypeScript. Le istruzioni chiedevano al destinatario di eseguire controlli dei tipi, test e build. L'analisi dell'attacco fallito di Mastracci ha individuato codice dannoso nascosto in una patch applicata a TypeScript.

L'esecuzione dei previsti comandi di sviluppo avrebbe attivato il payload. Il repository usava diversi livelli di occultamento, compreso un componente nascosto all'interno di un'immagine e un processo separato. Mastracci ha descritto il risultato come un trojan di accesso remoto capace di eseguire comandi e accedere ai file.

Quel caso non ha compromesso la sua macchina perché ha ispezionato il progetto prima di eseguirlo. Dimostra tuttavia perché i consigli più ovvi sul phishing non sono sufficienti. L'aggressore non ha inviato un rozzo allegato eseguibile. L'azione dannosa era incorporata nel lavoro che il bersaglio doveva svolgere.

Il più recente schema della videochiamata concentra la stessa pressione in un'interazione dal vivo. Qualcuno aspetta mentre il bersaglio risolve il problema. I ritardi diventano scomodi e una soluzione suggerita sembra più semplice che terminare la riunione.

La variante degli appunti è particolarmente utile agli aggressori. Un sito web o un partecipante alla chiamata può fornire un comando senza mostrarne l'effetto completo in un contesto significativo. Incollarlo in una shell trasferisce direttamente la fiducia dalla conversazione al sistema operativo.

Un presunto codec opera in modo analogo. I problemi audio sono abbastanza comuni da rendere la spiegazione ordinaria. Eppure le vere piattaforme per riunioni non dovrebbero richiedere il download personalizzato di un contatto a freddo per far funzionare l'audio di base.

L'interpretazione più sicura non è che ogni riunione sconosciuta sia ostile. È che l'ambiente della riunione non debba ricevere fiducia tecnica automatica dalla persona che l'ha organizzata.

Organizzare la chiamata su una piattaforma nota modifica questo equilibrio. Lo stesso vale per l'apertura di repository inattesi soltanto in ambienti isolati e temporanei, privi di credenziali di produzione. Nessuna delle due misure dimostra che chi chiama sia legittimo, ma entrambe riducono il valore del copione dell'aggressore.

Questa truffa del falso colloquio prende di mira anche più delle password di crates.io. Una macchina di sviluppo può contenere sessioni GitHub, credenziali cloud, chiavi SSH, materiale di firma, cookie del browser, token dei pacchetti e accesso a repository di codice sorgente privati.

Un aggressore può usare una qualunque di queste risorse per ampliare la compromissione. L'eventuale crate dannoso può essere l'esito visibile, mentre le credenziali organizzative rubate rimangono inosservate.

Questo crea il rovesciamento centrale alla base di Attenzione: attacchi mirati contro Rustacean di primo piano. Gli aggressori non stanno sfruttando principalmente il modello di memoria di Rust. Stanno sfruttando la fiducia professionale che circonda le persone che mantengono l'infrastruttura condivisa di Rust.

L'esecuzione al momento della build trasforma una piccola modifica a un pacchetto in un'ampia esposizione

Le release malevole erano pericolose perché Cargo eseguiva la dipendenza dell’attaccante durante la build, prima che gli sviluppatori downstream chiamassero qualsiasi funzione della libreria.

I crate compromessi aggiungevano una dipendenza denominata proc-macro1. Il nome somigliava molto a proc-macro2, un pacchetto legittimo ampiamente usato. Si tratta di typosquatting, in cui un attaccante sceglie un nome pensato per essere scambiato per una dipendenza fidata.

Il pacchetto malevolo copiava gran parte dell’aspetto del progetto legittimo. Il comportamento dannoso risiedeva in build.rs, lo script di build. Questa separazione aiutava i crate principali a mantenere il codice sorgente previsto, introducendo al contempo il payload tramite una riga di dipendenza.

Secondo una analisi tecnica del pacchetto, lo script ricostruiva indirizzi di rete da frammenti codificati e disabilitava la normale convalida dei certificati. Selezionava un payload per Linux, Windows, macOS basato su Intel o macOS con Apple silicon.

Sui sistemi simili a Unix, lo script scriveva un eseguibile in /tmp/rust-setup e lo avviava senza attendere. Su Windows, creava uno script PowerShell e usava uno script Visual Basic per avviarlo in un processo nascosto.

La build poteva altrimenti sembrare riuscita. Questo è cruciale perché un errore visibile spesso attiva un’indagine. Un pacchetto che compila normalmente offre agli sviluppatori meno motivi per ispezionare una dipendenza transitiva.

I ricercatori hanno inoltre osservato che il pacchetto copiato dichiarava dipendenze di build aggiuntive, incluse librerie di rete e crittografia. Tali aggiunte sono sospette quando un piccolo pacchetto di macro non ha un motivo chiaro per contattare Internet.

Un’analisi separata ha recuperato il malware di secondo stadio e rilevato capacità più ampie. Le funzioni riportate includevano profilazione dell’host, ispezione dei dati del browser, persistenza, esecuzione di comandi e metodi di comunicazione di fallback.

L’indagine sul malware di Wiz ha rilevato sovrapposizioni infrastrutturali con operazioni attribuite altrove ad attori nordcoreani. L’analisi ha collegato schemi nei percorsi dei comandi, negli intervalli di hosting e in campagne correlate.

Tuttavia, una sovrapposizione infrastrutturale non equivale a un’attribuzione conclusiva. I server possono essere riutilizzati, copiati, noleggiati o selezionati deliberatamente per confondere gli investigatori. Anche il progetto Rust non si è spinto fino ad affermare che un singolo gruppo identificato fosse responsabile di tutte le attività correlate.

La conclusione prudente resta comunque seria. La catena tecnica era progettata per superare una revisione superficiale del codice sorgente ed essere eseguita durante le comuni operazioni di sviluppo. Era sufficiente compilare un progetto dipendente. Un’applicazione non doveva invocare arrayref, internment o append-only-vec.

Questo amplia il potenziale insieme di vittime oltre i deployment in produzione. Uno sviluppatore che aggiornava un lockfile poteva essere esposto. Lo stesso vale per un runner CI, un processo automatizzato di aggiornamento delle dipendenze o strumenti dell’editor che invocano Cargo durante l’analisi di un progetto.

Un lockfile registra le versioni esatte delle dipendenze selezionate per una build. Se sottoposto a commit e revisione, può rivelare se una delle versioni malevole è entrata in un progetto. Tuttavia, un lockfile pulito oggi non dimostra che nessuna workstation abbia risolto una versione interessata durante la finestra di esposizione.

L’attacco alla supply chain Rust dimostra anche perché i totali di download richiedano un’interpretazione attenta. Centinaia di milioni di download storici non significano centinaia di milioni di infezioni. Le versioni malevole sono rimaste disponibili per poco tempo e molti progetti sono rimasti fissati a release precedenti.

Ciononostante, una release di breve durata può raggiungere sistemi sensibili perché l’installazione dei pacchetti è automatizzata. La popolarità offre all’attaccante molte opportunità indipendenti per ogni minuto in cui una release resta disponibile.

Il percorso del codice e quello sociale si rafforzano quindi a vicenda. Colpire i maintainer fornisce autorità di pubblicazione. L’esecuzione in fase di build trasforma tale autorità in esecuzione immediata del codice negli ambienti downstream.

L’attribuzione resta incerta, ma la conclusione difensiva no

Gli investigatori dispongono di segnali credibili di una campagna coordinata, ma le prove disponibili non dimostrano che ogni incidente Rust condivida lo stesso operatore.

L’avviso di settembre collega tre osservazioni. Gli sviluppatori Rust hanno affrontato approcci mirati a giugno. L’account del maintainer di arrayref è stato compromesso ad agosto. Nuovi contatti sospetti sono proseguiti fino a settembre.

Anche i metodi condividono una struttura riconoscibile. Gli attaccanti costruiscono identità professionali, propongono lavori allettanti, stabiliscono un’interazione in tempo reale e guidano il bersaglio verso l’esecuzione di codice. Le vittime previste dispongono di accessi che possono influenzare altri sviluppatori.

Questa coerenza supporta la valutazione di una campagna. Non stabilisce un’unica struttura di comando, un finanziatore o una famiglia di malware.

I team Rust riconoscono esplicitamente questa lacuna. Il loro avviso afferma di non sapere se il targeting precedente e l’attacco ad arrayref facciano tutti parte della stessa campagna. Una cronaca responsabile deve preservare questa precisazione.

Il collegamento con la RPDC richiede analoga cautela. I ricercatori di sicurezza hanno documentato campagne nordcoreane che usano falsi processi di selezione contro gli sviluppatori software. Secondo quanto riferito, alcune infrastrutture e schemi tecnici nel malware arrayref si sovrappongono a operazioni attribuite in precedenza.

Questi riscontri rendono l’ipotesi rilevante, ma non la trasformano in certezza. Un avviso pubblico non dovrebbe essere interpretato come un’attribuzione ufficiale da parte del progetto Rust.

Un’altra questione aperta riguarda la compromissione iniziale del maintainer di arrayref. Il progetto ritiene che il dispositivo o le credenziali del maintainer siano stati compromessi, ma il suo avviso pubblico sull’incidente non fornisce una cronologia forense completa.

Questo lascia diverse possibilità riguardo a sessioni rubate, credenziali, dati del browser o accesso all’endpoint. Il post di settembre afferma che l’account è stato compromesso tramite attacchi simili, ma non pubblica ogni passaggio tecnico.

Anche il numero di vittime effettive è sconosciuto. Il record pubblico conferma la pubblicazione di pacchetti malevoli e documenta approcci non riusciti. Non rivela quanti maintainer abbiano installato software, eseguito comandi o segnalato privatamente chiamate sospette.

Nemmeno il numero di infezioni downstream è pubblico. I ricercatori possono identificare le versioni malevole dei pacchetti e stimarne la diffusione, ma questo è diverso dal misurare l’esecuzione effettiva durante il periodo limitato di esposizione.

Queste lacune dovrebbero influenzare la risposta agli incidenti. I team dovrebbero evitare di dichiarare un’infezione solo perché un progetto dipende da un crate storicamente interessato. Dovrebbero determinare se una versione interessata sia stata risolta o compilata su una macchina specifica.

L’errore opposto è più pericoloso. Un team non dovrebbe liquidare l’evento perché le release malevole sono state rapidamente eliminate. Cache locali, log CI, cronologia dei lockfile, telemetria degli endpoint e attività delle credenziali possono conservare segnali che i manifest correnti non mostrano più.

Gli sviluppatori che hanno compilato una versione interessata dovrebbero considerare l’ambiente pertinente come potenzialmente compromesso. Rimuovere un crate non annulla il codice già eseguito. I segreti disponibili su quella macchina potrebbero richiedere la revoca da un dispositivo separato e affidabile.

La campagna mette inoltre in discussione l’assunto che l’autenticazione multifattore risolva la sicurezza degli account. L’MFA riduce molti attacchi alle credenziali, ma il malware in esecuzione su una workstation autenticata può rubare sessioni o agire tramite accessi esistenti.

Un’autenticazione dei pacchetti più solida resta importante. Credenziali supportate da hardware, scope minimo dei token, accesso alla pubblicazione di breve durata e separazione tra navigazione quotidiana e operazioni di release possono ridurre l’esposizione. Nessuno di questi accorgimenti rende irrilevante l’ingegneria sociale.

Il vero confine di sicurezza attraversa persone, endpoint, sistemi di identità e registry. Proteggere soltanto l’accesso al registry lascia troppe vie alternative verso l’autorità di pubblicazione.

Questa è la lezione duratura di Be alert: targeted attacks on prominent Rustaceans. L’attribuzione può restare irrisolta mentre i difensori agiscono sul meccanismo confermato e sull’impatto dimostrato.

Cosa dovrebbero monitorare ora i maintainer e i team di engineering

I prossimi segnali decisivi saranno ulteriori segnalazioni dei maintainer, modifiche ai controlli di pubblicazione dei pacchetti e prove che colleghino nuovi contatti a infrastrutture malware note.

Innanzitutto, occorre monitorare ulteriori divulgazioni da parte dei proprietari di crate Rust. Segnalazioni separate che utilizzino gli stessi problemi nelle riunioni, identità aziendali, comandi da incollare negli appunti o modelli di progetto rafforzerebbero il caso di un’operazione coordinata.

Segnalazioni che identifichino malware diversi o obiettivi non correlati indebolirebbero la teoria della singola campagna. Indicherebbero comunque che più gruppi considerano i maintainer open source come preziosi intermediari di accesso.

I maintainer dovrebbero conservare email sospette, link alle riunioni, domini, profili, indirizzi dei repository e timestamp. Questi dettagli aiutano i responder a confrontare le infrastrutture senza richiedere ai singoli di formulare proprie affermazioni di attribuzione.

In secondo luogo, occorre osservare come crates.io e altri registry adeguino i controlli di pubblicazione. I blocchi degli account e l’eliminazione dei pacchetti hanno limitato questo incidente, ma sono intervenuti dopo la comparsa delle versioni malevole.

I controlli futuri potrebbero concentrarsi su comportamenti di release insoliti. Un pacchetto che pubblica la sua prima dipendenza in assoluto, ritira varie versioni stabili o aggiunge componenti di build inattesi capaci di comunicare in rete presenta uno schema verificabile.

I registry devono bilanciare l’intervento con l’indipendenza dei maintainer open source. Un attrito eccessivo può ritardare release di emergenza legittime o imporre altro lavoro a volontari già sovraccarichi.

Il test rilevante è se i nuovi controlli interrompano modifiche ad alto rischio senza rendere la manutenzione ordinaria ingestibile. Si tratta di un compromesso tra autonomia di pubblicazione e contenimento dell’ecosistema.

In terzo luogo, occorre cercare collegamenti tecnici più forti tra gli approcci sociali e il malware recuperato. Corrispondenze tra domini, certificati dei payload, percorsi dei comandi, artefatti del codice sorgente o infrastrutture di hosting renderebbero più precisa l’attribuzione.

Un collegamento confermato con un operatore noto potrebbe migliorare il rilevamento in tutti gli ecosistemi. L’assenza di tale collegamento suggerirebbe che le tecniche si stanno diffondendo tra più gruppi.

Le organizzazioni di engineering non devono attendere queste risposte. Possono verificare chi detiene i diritti di pubblicazione dei pacchetti, dove risiedono le credenziali di release e se tali credenziali condividano una workstation con navigazione quotidiana e videochiamate.

I team dovrebbero inoltre sapere quali build siano state eseguite durante la finestra di esposizione di agosto. Le versioni malevole erano arrayref 0.3.10, internment 0.8.7 e append-only-vec 0.1.9. Qualsiasi presenza di proc-macro1 merita un’indagine.

Questa revisione dovrebbe includere runner CI e cache di sviluppo locali, non soltanto il repository corrente. Un lockfile ripulito può nascondere esecuzioni precedenti se si ignorano i record storici.

Le organizzazioni possono inoltre esaminare gli avvisi relativi a connessioni in uscita inattese, nuovi meccanismi di persistenza, accessi insoliti al browser e utilizzi inspiegati delle credenziali. Un’esecuzione confermata dovrebbe attivare la rotazione delle credenziali e la ricostruzione da sistemi noti come puliti.

I maintainer che ricevono nuove opportunità dovrebbero separare la verifica sociale dalla valutazione tecnica. Verificate un’azienda tramite canali indipendenti, create la riunione su un servizio affidabile e rifiutate codec personalizzati o comandi terminale copiati.

I repository inattesi dovrebbero essere trattati come software non attendibile. Le loro istruzioni per compilare, testare o avviare il progetto sono richieste di eseguire codice, anche quando vengono presentate come normali attività di colloquio.

La domanda finale non è se Rust resti sicuro come linguaggio. La sicurezza della memoria non può impedire a uno script di build fidato di fare esattamente ciò che il sistema operativo consente.

La domanda è se l’ecosistema possa proteggere i maintainer la cui autorità è diventata un bersaglio di alto valore. Attenzione: attacchi mirati contro Rustaceans di primo piano dovrebbero spingere ogni team di ingegneria a individuare queste persone prima che lo faccia un altro aggressore. Verificate gli accessi alla pubblicazione, isolate le credenziali di rilascio e rendete semplice segnalare contatti sospetti.