Claude Security è in beta pubblica: cosa dichiara “Scan to Fix” e cosa non dichiara

Il prodotto di sicurezza di Anthropic è ora una beta pubblica per Claude Enterprise, e la sua presentazione in una riga è una sequenza plutôt che un aggettivo: dalla scansione alla correzione, senza soluzione di continuità. I meccanismi alla base di questa frase sono esposti chiaramente nella pagina del prodotto: Claude analizza la tua base di codice con Claude Mythos, convalida i risultati e suggerisce patch che puoi rivedere e approvare. Tre verbi, un nome di modello e un limite di portata che è facile trascurare scorrendo: questa è una beta, ed è pensata per i clienti Enterprise plutôt che per chiunque abbia per caso un repository.

La domanda interessante non è mai stata se un modello linguistico sia in grado di trovare una vulnerabilità. I modelli lo fanno già da un po’, a volte abbastanza bene da mettere in imbarazzo gli esseri umani che hanno scritto il codice. La domanda interessante è cosa succede tra il momento in cui emerge una scoperta e quello in cui viene chiusa, perché è in questo intervallo che vivono gli arretrati di sicurezza: una coda di problemi plausibili, ordinata da nessuno, assegnata a tutti, chiusa per caso. La risposta di Anthropic è una pipeline a quattro fasi, e ogni fase avanza un’affermazione che può essere esaminata autonomamente.

Cosa significa “beta pubblica per Claude Enterprise”

La riga sulla disponibilità è insolitamente diretta, e vale la pena citarla invece di parafrasarla: disponibile in beta pubblica per Claude Enterprise. Sotto di essa ci sono due pulsanti: contatta il reparto vendite e leggi il tutorial. Nessuno dei due è un modulo di registrazione. In pratica questo significa che l'acquirente è un'azienda che ha già un contratto Enterprise e un team di sicurezza con sufficiente autorevolezza per chiedere un nuovo scanner, piuttosto che un singolo ingegnere che vuole puntare qualcosa a un progetto secondario.

C'è una seconda strada, più leggera. Il plugin Claude Security per Claude Code è in beta. È un software diverso, con un diverso modello di distribuzione — scansione, validazione e patch all'interno di Claude Code mantenendo il codice nel proprio ambiente — ed è la versione che conta per un team il cui ostacolo non è il budget, ma una regola su dove è consentito che vada il codice sorgente.

La scansione non si ferma

Il primo comportamento documentato è la scansione iniziale approfondita: Claude la esegue una volta su una base di codice, poi continua a scansionare mentre il codice cambia. È una frase breve con una grande conseguenza operativa. Una scansione una tantum è una fotografia. Le basi di codice non sono fotografie; sono il meteo. Un risultato che era accurato il giorno dell'audit ed è stato corretto a metà da tre merge successivi è peggio di nessun risultato, perché consuma l'attenzione delle persone che devono rileggerlo.

La scansione continua è anche la parte del prodotto più difficile da simulare. Richiede che lo scanner comprenda quali cambiamenti contano, una capacità diversa dal trovare una vulnerabilità in un albero statico. La pagina non descrive come funziona questa prioritizzazione, e questo articolo non azzarderà ipotesi al riguardo.

L'unico asse su cui l'affermazione è specifica

Anthropic afferma che Claude Security traccia i flussi di dati attraverso file e repository per individuare vulnerabilità che gli scanner basati sul pattern matching potrebbero non rilevare. È l’affermazione più verificabile dell’intera descrizione del prodotto, perché indica un meccanismo anziché un risultato.

Il pattern matching, come suggerisce il nome, cerca una forma nota come dannosa: una chiamata di funzione con un argomento contaminato, una stringa concatenata in una query, un'API nota come non sicura. È veloce, è economico, ed è il motivo per cui gli scanner tradizionali sono famosi per due cose contemporaneamente — individuare la stessa classe di bug ovunque si manifesti e seppellire il team sotto risultati che si rivelano irraggiungibili. L'alternativa è seguire un valore da dove entra nel sistema a dove viene usato, attraverso i confini tra file e servizi. È lì che si nascondono i veri bug, ed è anche lì che l'analisi diventa costosa, perché lo strumento deve mantenere più contesto di quanto ne stia in una singola funzione.

Nota però la cautela nella frase. Potrebbe non rilevare. È la parola corretta da usare quando un fornitore non ha un benchmark a cui fare riferimento, ed è anche il motivo per cui questa affermazione dovrebbe essere verificata sulla tua base di codice anziché accettata come una proprietà del prodotto.

Verifica avversariale e un modello di minaccia che puoi modificare

La seconda fase è quella che affronta il problema dei falsi positivi che ogni team di sicurezza conosce. Ogni risultato supera una verifica avversariale prima di raggiungere il team. Qualcosa cerca di confutare il risultato prima che lo veda una persona: dimostrare che l'input non può effettivamente raggiungere il sink, oppure che il percorso è protetto a monte, oppure che il codice in questione è morto.

La seconda metà di quella stessa frase è, senza dare nell'occhio, la decisione di progettazione più interessante della pagina. Un modello di minaccia che il tuo team può modificare stabilisce cosa vale la pena segnalare. In pratica, questo mette la definizione di rilevanza nelle mani del cliente. Uno scanner che decide la gravità da solo è sempre leggermente sbagliato, perché la gravità è contestuale: un endpoint non autenticato in uno strumento di amministrazione interno è un problema diverso dallo stesso endpoint su Internet pubblico, e nessun fornitore può sapere quale dei due sta guardando. Consentire la modifica del modello di minaccia è l’ammissione onesta di questo.

Comporta anche del lavoro. Un modello di minaccia che nessuno mantiene diventa un filtro che nasconde le cose a cui nessuno ha pensato, ovvero l'opposto di ciò a cui serve uno scanner. I team che ne ricaveranno valore saranno quelli che trattano il modello di minaccia come un documento vivo con un responsabile, allo stesso modo in cui trattano i runbook.

Una patch è l'unità di output

Ogni rilevamento include una patch consigliata che il team deve esaminare e approvare, e Claude contrassegna il rilevamento come risolto una volta che la correzione viene rilasciata. In quella frase sono contenute due affermazioni che meritano di essere separate.

Il primo è che l'output di una scansione è una modifica, non un ticket. Questa è la differenza tra dire a un ingegnere che il suo codice ha un problema e mostrargli com'è fatto il codice corretto. Comprime la parte meno piacevole del lavoro di sicurezza — capire il codice di qualcun altro abbastanza bene da correggerlo senza rompere ciò che fa — e lo comprime per la persona che capisce meno il codice. Questo è anche il rischio: una patch che sembra corretta e supera la revisione perché il revisore era stanco è un nuovo bug con un segno di spunta verde.

La seconda affermazione riguarda la chiusura. Claude contrassegna una segnalazione come risolta non appena la correzione viene distribuita, così le segnalazioni si chiudono invece di accumularsi. Il backlog non è un fallimento del rilevamento. È un fallimento della tenuta dei registri: la stessa vulnerabilità viene segnalata sette volte in sette scansioni, e la coda cresce più in fretta di quanto chiunque possa smaltirla. Tracciare una segnalazione fino al commit che la risolve è il meccanismo che rende uno scanner continuo sopportabile anziché demoralizzante.

Anthropic dichiara esplicitamente che l'essere umano resta nel ciclo, con ogni patch che richiede revisione e approvazione. Chiunque lo implementi dovrebbe considerare quella la frase portante, anziché il disclaimer in fondo.

Due release, una direzione

Claude Security non è arrivato isolatamente. Anthropic ha reso disponibile Code Review per il pubblico il 15 ottobre 2026, e la scansione continua di Claude Security con il monitoraggio delle correzioni è arrivata il 21 ottobre 2026 in beta pubblica per Claude Enterprise. Letti insieme, i due annunci dicono qualcosa sulla direzione intrapresa: la revisione sta passando da un cancello che una modifica attraversa alla fine a un processo che accompagna la modifica mentre viene scritta. I giorni tra queste due date sono così pochi che i prodotti dovrebbero essere valutati come un'unica storia su dove sta andando il lavoro sulla sicurezza, non come due rilasci scollegati.

Ciò che non è pubblicato, e il numero che risolverebbe la questione

L'elenco delle incognite qui è più lungo dell'elenco delle affermazioni, e questo è normale per una beta pubblica, non è uno scandalo. Quanto di una base di codice copra una scansione non viene pubblicato. La durata della scansione non viene pubblicata. I tassi di falsi positivi non vengono pubblicati. I benchmark di rilevamento non vengono pubblicati. Non esiste una valutazione indipendente. Il prezzo per utente non viene pubblicato, e nemmeno l'elenco delle lingue supportate.

Tra questi, il benchmark di rilevamento mancante è quello che cambia una decisione d'acquisto. Senza di esso, “intercetta ciò che sfugge agli scanner basati sul pattern matching” è un'affermazione indicativa che non può essere confrontata con lo scanner già presente nel budget. L'elenco delle lingue supportate è il secondo elemento: un repository poliglotta è il caso normale in un'azienda di qualsiasi dimensione, e uno scanner eccellente in tre lingue e assente nelle altre cinque è uno scanner che produce un quadro fuorviante della superficie di rischio.

Niente di tutto questo significa che il prodotto non funzioni. Significa che la valutazione deve essere fatta dall’acquirente, con il codice dell’acquirente stesso, e che una demo non basta.

Come valutarlo comunque

Se il tuo team ha intenzione di provarlo, l'esperimento utile non è un repository nuovo con una debolezza volutamente inserita. È un repository che ha già una storia: un servizio che ha avuto un incidente l'anno scorso, una libreria con una vulnerabilità nota che ha richiesto due settimane per essere chiusa, un modulo di cui tutti hanno un po' paura. Punta la scansione su quello e confronta ciò che trova con i risultati che il tuo team ha già annotato. Il recall sui problemi noti è misurabile anche quando un fornitore non ha pubblicato un benchmark, perché la verità di riferimento è nel tuo stesso registro degli incidenti.

In secondo luogo, tieni d'occhio il modello di minaccia. Se la prima cosa che fa il tuo team è disattivare la maggior parte delle categorie per ridurre la coda, hai imparato che il modello predefinito non corrisponde al rischio che il tuo team si assume realmente, e dovresti correggere il modello anziché il filtro. In terzo luogo, misura la fase che conta: quanto tempo intercorre da quando emerge un finding a quando una patch viene unita. Quel numero è tuo, è confrontabile tra strumenti ed è quello che il prodotto dichiara effettivamente di voler migliorare.

Dove si trova un router e dove no

Il confine va detto chiaramente. Claude Security è un'applicazione di Anthropic. Non la ospitiamo, non la vendiamo e non possiamo dirvi cosa abbia trovato o non trovato nel vostro repository. Lo scanner funziona su Claude Mythos, e non dichiariamo di ospitare quel modello.

Quello che facciamo è eseguire modelli. Un unico endpoint compatibile con OpenAI, una sola chiave, più di 200 modelli dietro, il prezzo di listino del provider trasferito senza alcun ricarico aggiunto e failover automatico tra provider quando uno di essi vacilla. Claude Opus 5.5 è in quel catalogo a 4,00 $ per milione di token in input e 20,00 $ per milione di token in output, con una finestra di contesto da 1M di token e letture della cache a 0,20 $ per milione. Questo è un fatto relativo al nostro catalogo, non un'affermazione riguardo allo scanner.

Dove diventa rilevante è la parte di un programma di sicurezza che non è uno scanner: lo strumento interno che riassume un migliaio di risultati in qualcosa che una persona possa vagliare, l’agente che redige l’avviso, la fase di revisione che un team vuole costruire attorno alle proprie regole. Quelle sono normali chiamate al modello, e un router è un modo ragionevole per effettuarle senza codificare rigidamente un fornitore. Il DSL di routing conta quando un passaggio vuole un modello piccolo per il volume e il successivo ne vuole uno accurato per il giudizio; il failover automatico conta quando la chiamata si trova all’interno di una pipeline che gira alle tre del mattino e nessuno la sta guardando.

Ciò di cui la beta ti sta effettivamente chiedendo di fidarti

Tolta la cornice, il prodotto fa tre scommesse. Che un modello che ragiona sul codice trovi cose che il pattern matching non trova. Che un secondo passaggio adversariale basti a tenere basso il rumore. Che una scoperta sia conclusa solo quando viene rilasciata una patch e la coda si chiude dietro di essa. La terza scommessa è la meno appariscente e la più destinata a rivelarsi giusta, perché è un'affermazione sul processo, non sull'intelligenza.

La prima scommessa è quella da verificare. Anthropic ha pubblicato il meccanismo — la tracciatura del flusso di dati attraverso file e repository — e non ha pubblicato alcun numero che ne mostri l'efficacia. Non è una ragione per scartare il prodotto. È una ragione per provarlo su un repository di cui conosci già la cronologia, e per giudicarlo in base ai risultati che puoi verificare anziché a quelli che fanno colpo in una dimostrazione.