Rubrik Code Guardian amplia Project Hourglass, ma le sue affermazioni sulla sicurezza affrontano una prova nel mondo reale

Rubrik ha presentato Rubrik Code Guardian il 9 ottobre, ampliando Project Hourglass oltre i controlli in fase di esecuzione per ispezionare i repository di codice alla ricerca di catene d'attacco sfruttabili. Secondo l'azienda, il servizio in anteprima privata utilizza un modello Anthropic all'interno di un ambiente di test isolato. Punta a un conflitto crescente nello sviluppo software: gli strumenti di programmazione AI aumentano la produttività, mentre i team di sicurezza faticano a esaminare quel risultato con la stessa rapidità.

L'espansione avvicina Rubrik alla sicurezza applicativa, un mercato in cui gli scanner segnalano già codice vulnerabile prima del deployment. Rubrik fa una promessa diversa. Invece di produrre un altro lungo elenco di possibili difetti, Code Guardian è progettato per collegare le debolezze tra file, servizi, identità e confini cloud. Quindi assegna priorità ai percorsi che potrebbero causare danni aziendali significativi.

Questo approccio crea anche il test centrale per Project Hourglass. Un sistema AI può ragionare su un grande repository, ma le aziende hanno comunque bisogno di prove che i suoi risultati siano accurati, riproducibili e più sicuri del codice che esamina. Code Guardian non è generalmente disponibile e Rubrik afferma esplicitamente che le sue funzionalità e prestazioni restano soggette a modifiche.

Rubrik Code Guardian estende Project Hourglass alla base di codice

Project Hourglass si espande dal controllo degli agenti di programmazione in fase di esecuzione all'esame del software che tali agenti contribuiscono a produrre.

Rubrik ha inizialmente lanciato Project Hourglass per aiutare gli integratori di sistemi globali a implementare Rubrik Agent Cloud attorno a Claude Code di Anthropic. Quell'architettura iniziale era incentrata su ciò che un agente AI per la programmazione fa durante il proprio funzionamento.

I suoi controlli includevano guardrail comportamentali, protezione per il contesto dei prompt e Agent Rewind. Rubrik descrive Agent Rewind come un modo per annullare azioni indesiderate compiute da un agente. Queste funzioni affrontano il rischio operativo derivante dal consentire agli agenti software di leggere file, modificare repository, chiamare strumenti e interagire con sistemi aziendali.

Rubrik Code Guardian aggiunge un secondo livello. Esamina una copia clonata del repository di codice sorgente di un cliente in un ambiente air-gapped, ossia una copia isolata dai sistemi di produzione e dalle reti esterne. Rubrik afferma che questo design consente ai team di condurre test di sicurezza aggressivi senza esporre applicazioni operative o codice sorgente sensibile a rischi operativi non necessari.

Secondo il rilascio di Code Guardian dell'azienda, il sistema utilizza Claude Mythos 5 tramite un harness di sicurezza specializzato. Il modello è pensato per ragionare su scenari di minaccia in più fasi anziché ispezionare ogni file come un'unità indipendente.

Questa distinzione è importante perché le vulnerabilità dannose emergono spesso da combinazioni di debolezze altrimenti modeste. Un servizio potrebbe accettare input non sicuri, un ruolo di identità potrebbe avere autorizzazioni eccessive e una risorsa cloud potrebbe essere raggiungibile attraverso un percorso trascurato. Uno strumento convenzionale può segnalare ogni condizione separatamente senza mostrare come un attaccante le collegherebbe.

Rubrik afferma che Code Guardian esaminerà file sorgente, servizi, ruoli di identità e perimetri cloud per identificare queste catene. Verificherà poi se un percorso sospetto sia effettivamente sfruttabile e valuterà il risultato in base alla sua importanza aziendale.

L'obiettivo non è semplicemente trovare più avvisi. È ridurre l'affaticamento da allarmi aiutando i team di ingegneria a determinare quali avvisi meritino attenzione immediata.

Si tratta di un cambiamento importante nella posizione di Rubrik in materia di sicurezza. L'azienda ha tradizionalmente posto l'accento sulla resilienza dei dati, sui backup protetti e sul ripristino dopo gli attacchi. Code Guardian la porta più a monte nel ciclo di vita del software, prima che un'applicazione vulnerabile raggiunga la produzione.

Project Hourglass sta inoltre diventando un'alleanza di delivery più ampia. AHEAD, Trace3 e World Wide Technology si sono uniti ai partecipanti esistenti Cognizant, Deloitte, LTM, HCLTech, NTT DATA e Wipro. Questi partner possono aiutare le aziende a valutare l'architettura, eseguire test controllati e integrare la tecnologia nei processi esistenti di sviluppo e sicurezza.

Rubrik ha annunciato l'espansione al suo GSI Summit a Goa, in India. Il contesto geografico è meno importante del modello di delivery. Le grandi aziende acquistano spesso programmi di sicurezza tramite integratori di sistemi, non attraverso sperimentazioni isolate di prodotti gestite da un singolo team di sviluppo.

I partner potrebbero quindi determinare se Rubrik Code Guardian diventerà un controllo operativo o resterà un'interessante dimostrazione in anteprima privata. Dovranno collegare i suoi risultati con sistemi di ticketing, pipeline software, controlli di identità e strumenti esistenti per la sicurezza applicativa.

L'etichetta di anteprima privata impone un limite netto all'annuncio. Rubrik afferma che il servizio viene offerto a partner di progettazione selezionati su base “as is”. Non è generalmente disponibile e l'azienda non garantisce che ogni capacità descritta arriverà in una release commerciale.

Questa precisazione è centrale nella storia. Rubrik ha delineato un'architettura ambiziosa, ma i clienti non possono ancora valutarla attraverso dati di implementazione su larga scala, benchmark indipendenti o una release stabile in produzione.

Perché la sicurezza del codice AI sta diventando un collo di bottiglia aziendale

La pressione deriva da un divario di velocità sempre più ampio tra la creazione automatizzata di codice e la revisione umana della sicurezza.

Gli assistenti AI per la programmazione possono generare funzionalità, test, file di configurazione e codice infrastrutturale in pochi minuti. Questa velocità cambia l'economia dello sviluppo, ma non elimina la necessità di revisione. Può invece aumentare la quantità di codice che i team di sicurezza devono valutare prima di una release.

Il rischio non è che ogni funzione generata dall'AI contenga una vulnerabilità. Il problema è che un codice plausibile può superare una rapida revisione visiva mantenendo presupposti non sicuri su autorizzazioni, input, dipendenze o confini di sistema.

Una valutazione Veracode del 2025 ha riportato che i modelli testati hanno introdotto una vulnerabilità rilevabile nella OWASP Top 10 nel 45 percento dei risultati delle attività. Lo studio sulla sicurezza del codice dell'azienda ha utilizzato attività di programmazione controllate in cui le implementazioni potevano seguire schemi sicuri o non sicuri.

Questa cifra non dovrebbe essere interpretata come il tasso di vulnerabilità di tutto il software in produzione. Le attività controllate differiscono dai repository aziendali mantenuti, e i risultati dipendono dal linguaggio, dal prompt, dal modello e dal metodo di test. Tuttavia, lo studio illustra perché la correttezza funzionale non possa sostituire la convalida della sicurezza.

Il rischio si estende anche oltre il codice sorgente generato. Gli agenti di programmazione possono accedere a repository, terminali, sistemi di tracciamento delle issue, gestori di pacchetti e strumenti di deployment. Un'istruzione dannosa incorporata in contenuti recuperati può reindirizzare un agente con privilegi eccessivi, mentre un errore ordinario può propagarsi attraverso molti file.

OWASP descrive l'eccessiva agency come una condizione in cui un modello riceve funzionalità, autorizzazioni o autonomia non necessarie. Le sue linee guida sull'eccessiva agency raccomandano di limitare l'accesso agli strumenti, ridurre al minimo le autorizzazioni, richiedere approvazione per azioni consequenziali e convalidare gli output prima dell'esecuzione.

Questi controlli si concentrano su ciò che un agente è autorizzato a fare. Code Guardian affronta una domanda correlata ma distinta: quali debolezze di sicurezza esistono nella base di codice dopo che umani e agenti vi hanno contribuito?

Rubrik cita la propria ricerca Zero Labs per spiegare l'urgenza. L'azienda afferma che l'86 percento dei responsabili di cybersecurity e IT intervistati si aspetta che l'adozione degli agenti AI superi le guardrail di sicurezza delle proprie organizzazioni entro un anno. Poiché quel numero proviene dalla ricerca di Rubrik, i lettori dovrebbero considerarlo una prova della preoccupazione dei clienti piuttosto che una dimostrazione indipendente dell'efficacia di Code Guardian.

La preoccupazione più ampia è ben consolidata. Gli agenti autonomi possono operare con identità macchina, credenziali e autorizzazioni per gli strumenti. Possono inoltre eseguire sequenze di azioni più rapidamente di quanto una persona possa rivedere ogni passaggio.

Questo rende il repository software solo una parte della superficie d'attacco. I team di sicurezza devono proteggere il contesto del modello, le autorizzazioni dell'agente, il codice generato, la pipeline di deployment e i dati interessati da un'azione fallita.

Project Hourglass ora cerca di coprire diversi di questi livelli. Rubrik Agent Cloud si concentra sul comportamento degli agenti e sul ripristino. Code Guardian si concentra sull'analisi dei repository e sulla scoperta delle catene d'attacco. Gli attuali prodotti di resilienza di Rubrik forniscono il livello di ripristino nel caso in cui prevenzione e controlli in fase di esecuzione falliscano.

Questo posizionamento end-to-end è commercialmente interessante, ma solleva anche interrogativi di integrazione. Le aziende utilizzano già test statici di sicurezza applicativa, analisi della composizione software, rilevamento dei segreti, strumenti per la postura di sicurezza cloud e penetration test manuali.

Code Guardian deve dimostrare di apportare qualcosa che questi prodotti non possono fornire in modo efficiente. Individuare una debolezza ipotetica non è sufficiente. Il servizio deve spiegare come un attaccante possa raggiungerla, quali asset vengano esposti e perché il risultato debba avere priorità rispetto ad altri interventi di remediation.

È qui che la sicurezza del codice AI diventa un problema di prioritizzazione. Uno scanner che raddoppia il numero di avvisi senza migliorare le decisioni può rallentare un programma di sicurezza. Un sistema di ragionamento efficace deve ridurre l'incertezza, non limitarsi a produrre report più lunghi.

Per i responsabili dell'ingegneria, la lezione immediata è pratica. Una generazione di codice più rapida richiede controlli più rigorosi a livello di repository, identità e runtime. I team necessitano inoltre di registri duraturi delle decisioni architetturali, delle ipotesi sulle minacce e del lavoro di remediation.

Una base di conoscenza ingegneristica ricercabile può preservare quel contesto tra i team di sicurezza, sviluppo e operazioni. Non sostituisce i test del codice, ma aiuta i revisori a comprendere perché componenti sensibili siano stati progettati in un determinato modo.

Project Hourglass contrappone il ragionamento sulle catene d'attacco al volume di avvisi

La principale scommessa di Rubrik è che l'AI possa assegnare priorità a percorsi d'attacco realistici meglio degli strumenti che esaminano le debolezze isolatamente.

L'analisi statica tradizionale valuta il codice sorgente senza eseguire l'applicazione. Può identificare schemi non sicuri noti, come input non sanitizzati, chiamate di funzione pericolose o scelte crittografiche deboli. L'analisi della composizione software esamina pacchetti esterni e vulnerabilità note nelle dipendenze.

Questi metodi restano essenziali perché sono ripetibili, familiari e adatti alle pipeline di sviluppo automatizzate. Tuttavia, possono generare falsi positivi o risultati isolati privi di contesto aziendale.

Un avviso in un componente di test irraggiungibile non comporta lo stesso rischio di una falla sfruttabile in un servizio di autenticazione esposto a Internet. Eppure entrambi possono comparire nella stessa coda, a meno che una persona o un altro sistema non ricostruisca l'architettura circostante.

Rubrik Code Guardian è progettato per eseguire una parte maggiore di questa ricostruzione. L'azienda afferma che il suo modello può ragionare tra file e servizi, includere relazioni di identità e considerare i confini cloud. L'output risultante dovrebbe descrivere una catena d'attacco anziché un difetto scollegato.

Consideriamo un'ipotetica applicazione enterprise con tre debolezze. Un'API accetta un parametro validato in modo improprio. Un'identità di servizio può leggere un bucket di archiviazione sensibile. Un worker in background considera attendibili i messaggi provenienti dall'API.

Uno scanner a livello di file potrebbe generare tre ticket. L'analisi della catena d'attacco si chiederebbe se un attaccante possa sfruttare il difetto del parametro per controllare un messaggio, attivare il worker, ereditare l'identità di servizio e raggiungere il bucket di archiviazione. Se questa sequenza funziona all'interno della copia isolata, il team di sicurezza ottiene una priorità di remediation più chiara.

Questo è il meccanismo alla base dell'affermazione di Rubrik sull'impatto sul business. Il modello non è prezioso semplicemente perché può leggere più codice. Diventa utile se riesce a distinguere una catena plausibile da una combinazione teorica e a spiegare la propria conclusione ai revisori umani.

Anthropic ha già presentato la scoperta di vulnerabilità assistita da modelli come impiego difensivo di modelli avanzati per la programmazione. Nel febbraio 2026, l'azienda ha dichiarato che Claude Code Security aveva individuato oltre 500 vulnerabilità in progetti open source in produzione. Il suo annuncio sulla ricerca in materia di sicurezza descrive un processo che combina l'analisi del modello con la revisione umana e la divulgazione coordinata.

Anthropic ha inoltre pubblicato una dashboard delle vulnerabilità che registra le segnalazioni dopo il triage esterno e la revisione da parte dei maintainer. Questo flusso di lavoro è importante perché il sospetto iniziale di un modello non equivale a una vulnerabilità confermata.

Rubrik sta portando questa capacità generale in un ambiente enterprise controllato. Anziché analizzare repository open source pubblici, Code Guardian è progettato per esaminare il codice privato dei clienti tramite partner partecipanti.

Il clone air-gapped offre due potenziali vantaggi. In primo luogo, può ridurre la probabilità che il codice proprietario venga esposto a un servizio esterno o raggiunga un sistema di produzione attivo. In secondo luogo, offre al processo di test spazio per sondare in modo aggressivo senza influire su clienti o operazioni.

L'isolamento non risolve ogni questione di sicurezza. Le aziende avranno comunque bisogno di dettagli su come vengono create le copie dei repository, dove avviene l'inferenza del modello, come vengono conservati i risultati e quali membri del personale dei partner possano accedere alle segnalazioni.

Il termine “air-gapped” può inoltre coprire diverse configurazioni tecniche. Un ambiente fisicamente separato, un cloud privato con restrizioni rigorose e una rete logicamente isolata non forniscono le stesse garanzie. L'annuncio pubblico di Rubrik non offre dettagli architetturali sufficienti per confrontare questi modelli.

Il test competitivo sarà incentrato sulla qualità delle prove. I fornitori affermati di sicurezza applicativa possono aggiungere spiegazioni AI e classificazione contestuale ai propri scanner esistenti. I fornitori di sicurezza cloud possono correlare identità, servizi e asset raggiungibili utilizzando la telemetria di produzione.

Rubrik apporta asset diversi. Ha relazioni nell'ambito dei dati enterprise protetti, dei flussi di lavoro di ripristino e della cyber resilience. Project Hourglass le offre inoltre partner system integrator in grado di combinare l'analisi del codice con decisioni più ampie sull'infrastruttura.

La versione più forte della strategia di Rubrik combina questi asset. Code Guardian identificherebbe la catena, Agent Cloud limiterebbe il comportamento degli agenti e i controlli di ripristino di Rubrik ripristinerebbero il codice o i dati interessati dopo un incidente.

La versione più debole crea un'altra console con avvisi sovrapposti. I clienti della private preview dovranno stabilire quale risultato stiano osservando.

La Parte Difficile È Convalidare il Revisore AI

Un sistema AI che esamina codice assistito dall'AI crea un ciclo di verifica che non può essere risolto soltanto dalla fiducia del modello.

Rubrik afferma che Code Guardian verificherà le segnalazioni per determinarne l'effettiva sfruttabilità. Si tratta di un'affermazione più impegnativa rispetto all'identificazione di pattern sospetti. La sfruttabilità dipende dalla configurazione, dallo stato di deployment, dagli input raggiungibili, dalle autorizzazioni delle identità e dai controlli ambientali.

Un repository clonato potrebbe non contenere tutti gli elementi necessari per riprodurre l'ambiente di produzione. Le impostazioni dell'infrastruttura possono risiedere in sistemi separati. Le identità runtime possono differire dai ruoli dichiarati. Le policy di rete possono cambiare dopo la creazione del clone.

Ciò significa che il percorso d'attacco del sistema può essere logicamente coerente pur restando impossibile in produzione. Esiste anche il problema opposto. Un test incentrato sul repository potrebbe non rilevare un percorso pericoloso creato da deriva runtime, un'integrazione non documentata o una credenziale compromessa.

Le sperimentazioni in private preview dovrebbero quindi misurare più del numero di problemi individuati. Dovrebbero tracciare catene sfruttabili confermate, segnalazioni respinte, avvisi duplicati, tempo di convalida, tempo di remediation e difetti non rilevati dal sistema.

Il confronto indipendente sarà particolarmente importante. Un design partner dovrebbe eseguire Code Guardian accanto agli scanner esistenti e al proprio processo di penetration testing. Questo crea una base di riferimento per stabilire se il servizio scopra rischi unici o riconfezioni segnalazioni già note.

I team di sicurezza necessitano inoltre di prove riproducibili. Un report utile dovrebbe identificare i percorsi di codice rilevanti, le autorizzazioni richieste, le precondizioni, gli asset interessati e i passaggi impiegati per convalidare la catena. I revisori devono poter contestare il ragionamento del modello senza accettare un punteggio di rischio black-box.

Rubrik non ha pubblicato risultati di benchmark per tassi di falsi positivi, tassi di falsi negativi, copertura dei repository, tempi di analisi o classi di vulnerabilità. Il suo annuncio non rivela inoltre come cambino le prestazioni con monorepository di grandi dimensioni o linguaggi di programmazione poco comuni.

Queste omissioni sono ragionevoli per una preview iniziale, ma limitano ciò che le aziende possono concludere. Code Guardian è un controllo di sicurezza proposto, non un sostituto delle attività di test della sicurezza applicativa esistenti convalidato in modo indipendente.

Il modello sottostante introduce un ulteriore rischio di concentrazione. Rubrik si affida alla tecnologia Anthropic per ispezionare codice che potrebbe essere stato creato con Claude Code o altri assistenti AI. Un modello capace può comunque condividere punti ciechi con i sistemi che hanno generato il codice.

La diversità dei modelli non risolve automaticamente questo problema, ma metodi di test indipendenti possono essere d'aiuto. Scanner deterministici, penetration tester umani, osservazioni runtime e modelli separati possono ciascuno mettere in discussione assunzioni diverse.

Il più ampio framework di sicurezza degli agenti di OWASP considera i sistemi agentici come combinazioni di modelli, strumenti, identità, memoria e servizi esterni. Questa prospettiva sconsiglia di fare affidamento su un singolo revisore automatizzato.

C'è anche una questione di governance. Un modello può segnalare un percorso come critico per il business solo se riceve informazioni accurate sulla sua importanza aziendale. Il solo repository potrebbe non rivelare quale servizio elabori dati regolamentati, supporti un cliente importante o controlli un flusso operativo critico.

I partner dovranno fornire tale contesto. Farlo richiede cooperazione tra proprietari delle applicazioni, team di sicurezza, amministratori cloud, team di identità e responsabili aziendali.

I system integrator possono coordinare questi gruppi, contribuendo a spiegare la strategia alliance-first di Rubrik. Tuttavia, l'erogazione guidata dai partner può produrre risultati disomogenei se le pratiche di implementazione differiscono. La certificazione e il supporto ingegneristico diretto potrebbero ridurre questa variabilità, ma Rubrik non ha ancora pubblicato dati sugli esiti operativi.

Anche il posizionamento dell'azienda sul ripristino merita attenzione. Il ripristino istantaneo della codebase può ripristinare file noti come sicuri dopo una modifica indesiderata, ma il ripristino del codice non annulla automaticamente ogni conseguenza.

Un agente compromesso potrebbe esporre un segreto, avviare una transazione esterna, alterare un sistema di terze parti o modificare dati di produzione. Questi effetti richiedono una risposta agli incidenti che vada oltre il rollback del repository.

Project Hourglass dovrebbe quindi essere valutato come un controllo a più livelli, non come una garanzia. I guardrail possono ridurre le azioni pericolose. Il test del codice può trovare percorsi vulnerabili. Il ripristino può limitare i danni. Nessuno di questi elimina la necessità di accesso con privilegi minimi, approvazione umana, pratiche di sviluppo sicure e pianificazione degli incidenti.

Questo è il compromesso fondamentale. Il ragionamento AI può esaminare relazioni che gli strumenti basati su regole faticano a collegare, ma il ragionamento stesso richiede convalida. Le aziende guadagnano velocità solo quando l'onere della verifica diventa inferiore al problema che viene automatizzato.

Rubrik Code Guardian Ora Deve Superare Tre Test

Le prossime prove devono provenire dai risultati di deployment, dal confronto indipendente e da un'architettura di produzione chiaramente definita.

Il primo segnale è la qualità dei risultati dei design partner. AHEAD, Trace3, WWT e gli attuali partecipanti a Project Hourglass hanno accesso ad aziende con repository complessi e programmi di sicurezza maturi.

I risultati più utili non saranno dichiarazioni promozionali sull'individuazione di “più” rischi. Gli acquirenti hanno bisogno di esempi anonimizzati che mostrino quali catene d'attacco gli strumenti esistenti non hanno rilevato, come Code Guardian le abbia convalidate e con quale rapidità i team abbiano completato la remediation.

Le segnalazioni confermate rafforzerebbero l'argomentazione di Rubrik secondo cui il ragionamento basato sui modelli migliora la definizione delle priorità. Tassi elevati di rifiuto o ampi carichi di revisione la indebolirebbero.

Il secondo segnale è il percorso dalla private preview alla disponibilità generale. La release attuale di Rubrik include un avviso esplicito secondo cui Code Guardian potrebbe cambiare, arrivare in ritardo o non diventare mai generalmente disponibile.

Una release di produzione dovrebbe chiarire linguaggi supportati, limiti di dimensione dei repository, modelli di deployment, gestione dei dati, policy di aggiornamento dei modelli, controlli di conservazione e integrazione con le pipeline di sviluppo. Dovrebbe inoltre spiegare come i clienti effettuino l'audit delle azioni intraprese durante i test.

La disponibilità generale, da sola, non dimostrerebbe l'efficacia. Tuttavia, documentazione stabile e impegni contrattuali sulla sicurezza mostrerebbero che Rubrik è pronta a superare la fase dell'esperimento controllato.

Il terzo segnale è la risposta competitiva. I fornitori di sicurezza applicativa e cloud possiedono già scanner di codice, database delle vulnerabilità, intelligence sulle dipendenze e contesto di produzione. Hanno forti incentivi ad aggiungere l'analisi agentica delle catene d'attacco.

Se tali fornitori produrranno un ragionamento comparabile attraverso strumenti già utilizzati dai clienti, Rubrik dovrà differenziarsi tramite ripristino, isolamento o delivery dei partner. Se i concorrenti faranno fatica a correlare il codice con identità e impatto sul business, Project Hourglass otterrà un'apertura più forte.

Anche i prodotti di sicurezza di Anthropic rappresentano un ulteriore punto di riferimento. Claude Code Security dimostra che il fornitore del modello considera la scoperta delle vulnerabilità una categoria di prodotto diretta. Rubrik deve spiegare come il suo security harness, il contesto enterprise e l'architettura di ripristino aggiungano valore oltre l'accesso al modello sottostante.

Sviluppatori e acquirenti enterprise dovrebbero osservare questi segnali prima di considerare Rubrik Code Guardian un controllo consolidato. L'annuncio identifica un problema reale e propone un meccanismo credibile, ma le prove restano preliminari.

Per i team di sviluppo, la risposta pratica non dovrebbe attendere il rilascio di un singolo fornitore. Inventariate dove operano gli agenti di coding, limitatene le credenziali, registrate le modifiche rilevanti e mantenete l'approvazione umana per le azioni sensibili. Continuate a utilizzare scanner deterministici e test indipendenti anche quando è disponibile un revisore AI.

I responsabili della sicurezza dovrebbero anche porsi una domanda più difficile: un nuovo strumento accorcia il percorso dall'individuazione alla remediation verificata? Un sistema che scopre catene sofisticate ma sovraccarica i revisori non risolve il collo di bottiglia operativo.

Rubrik Code Guardian sarà importante se Project Hourglass trasformerà il ragionamento del modello in prove ripetibili su cui gli ingegneri possano agire. La sua private preview è l'inizio di questo test, non il risultato. Nei prossimi mesi, gli acquirenti dovrebbero cercare catene d'attacco convalidate, tassi di errore trasparenti e un'architettura di produzione che protegga il codice ispezionato.