Vulnerabilità di sicurezza MCP: verifica l'esposizione prima di applicare la patch

Quando nel proprio feed compare una vulnerabilità MCP, la prima domanda operativa non è “quanto è grave il problema segnalato?”, bensì: questo avviso riguarda un componente effettivamente in esecuzione nel proprio percorso dell’agente? Rispondi a questa domanda prima di eseguire un exploit, aggiornare in massa tutti i pacchetti o dichiarare sufficiente una scansione che non ha rilevato nulla. Un verdetto difendibile si basa su cinque elementi di prova: 1. l'identificativo esatto dell'avviso e del pacchetto; 2. la versione installata e avviata ; 3. il risultato relativo all'intervallo interessato fornito dall'editore della nota informativa; 4. la raggiungibilità del punto di accesso vulnerabile ed eventuali misure di mitigazione temporanee; 5. uno strumento di verifica post bonifica e una ricevuta attestante il risultato previsto dell'intervento. Tale unione produce un piccolo insieme di stati utili: absent , unknown , not affected , affected not reachable , exposed , patched unverified , remediation regression o remediated . Inoltre, impedisce due scorciatoie pericolose: considerare la presenza del pacchetto come un’esposizione confermata e considerare un comando di aggiornamento riuscito come un ripristino. Creare il join di esposizione prima di scegliere la risposta Un catalogo delle vulnerabilità è utile per l'individuazione, ma non costituisce l'inventario dell'ambiente di esecuzione. L'avviso potrebbe indicare un pacchetto presente solo in un file di blocco, in un ambiente abbandonato, in un livello di container che non viene mai avviato o in una dipendenza transitiva di sviluppo. Il caso opposto è ancora peggiore: un client MCP può avviare un pacchetto tramite un wrapper o un'installazione globale che la scansione del repository non ha mai controllato. Raccogli le prove dal confine di esecuzione a cui appartiene il processo MCP. Non caricare prompt, argomenti degli strumenti, token, percorsi assoluti o dati aziendali. Una ricevuta sintetica potrebbe presentarsi così: Il codice matchStatus dovrebbe provenire da un gestore di pacchetti, da uno strumento SBOM o da un feed di avvisi strutturato che riconosca la sintassi delle versioni dell’ecosistema. Non confrontare le stringhe di versione a livello lessicale. L’avviso GitHub sottoposto a revisione per mcp remote , ad esempio, indica = 0.0.5, < 0.1.16 come versione interessata e 0.1.16 come prima versione corretta. L'avviso rivisto relativo a @modelcontextprotocol/server filesystem contiene sia una gamma tradizionale che una linea basata sulle date, con 2025.7.1 come prima versione aggiornata di tale linea. Un unico comparatore scritto a mano non è lo strumento più adatto per normalizzare entrambi gli schemi. Le informazioni relative al pacchetto e alla versione continuano a non chiarire la raggiungibilità. L'attuale versione Migliori pratiche di sicurezza per MCP illustra perché la configurazione è importante. La sua analisi del caso del “vice confuso” elenca diverse condizioni che devono verificarsi contemporaneamente, tra cui l’utilizzo da parte di un proxy di un ID cliente statico di terze parti, la registrazione dinamica del cliente, un cookie di consenso e la mancanza del consenso specifico per ciascun cliente. Le stesse linee guida e il Specifiche di autorizzazione MCP impedire il passaggio diretto del token e richiedere al server delle risorse di verificare che sia stato emesso un token specifico per quella risorsa. Tali controlli dovrebbero diventare campi in una ricevuta specifica per l’esposizione, non una casella di controllo generica “sicurezza abilitata”. Per un avviso di autorizzazione, raccogliere la convalida del pubblico, la corrispondenza dei reindirizzamenti, la titolarità del consenso e il comportamento del proxy. Per un avviso relativo al filesystem, raccogliere la versione del server avviato, le radici consentite, la superficie degli strumenti raggiungibili e la misura di mitigazione esatta che rende indisponibile il punto di ingresso interessato. Per un avviso relativo all’iniezione di comandi, raccogliere informazioni sul wrapper client, sulla versione, sul confine di fiducia del server remoto e sull’eventualità che tale percorso di connessione possa essere invocato. Il componente interessato con un punto di ingresso disabilitato verificato è affected not reachable , non not affected . Si tratta di una prova utile a dimostrare il contenimento, ma ha una validità limitata. È necessario registrare il responsabile e la scadenza per l'applicazione della patch, poiché una modifica alla configurazione, un rollback della distribuzione o un nuovo client potrebbero rendere nuovamente accessibile il percorso. Esegui un classificatore privo di contenuto, non un exploit Non è necessario un carico utile offensivo per gestire l'incidente. La seguente regola decisionale è volutamente prudente: I nomi degli stati indicano la decisione successiva: Stato Cosa dimostrano le prove Azione successiva limitata absent Il componente indicato non è presente nel confine di esecuzione ispezionato Registra l'ambito dell'inventario e chiudi per questo confine unknown Mancano o sono in conflitto i dati relativi a identità, versione, corrispondenza dell'avviso o raggiungibilità Mantenere l'incertezza; risolvere il primo campo mancante not affected Il componente installato non rientra nell'intervallo interessato dall'editore Conservare l'origine e la freschezza; non dedurre che il prodotto sia protetto solo perché il nome della confezione è simile affected not reachable Il codice interessato esiste, ma il punto di ingresso indicato è bloccato da un contenimento verificato Mantenere il contenimento, assegnare il responsabile della patch e impostare una data di scadenza exposed La versione interessata e il punto di ingresso raggiungibile coincidono Contenere il percorso, revocare le autorizzazioni non necessarie e applicare le patch patched unverified La versione è uscita dal campo di rilevamento, ma le prove funzionali sono incomplete Esegui un test con lo strumento Canary in modalità sicura e verifica che la destinazione sia quella prevista remediation regression La patch o il contenimento ha compromesso lo strumento o il risultato richiesto Limitare l'impatto del percorso rischioso; ripristinare la compatibilità o utilizzare un rollback verificato remediated La versione, il comportamento sicuro dello strumento e il risultato previsto sono tutti conformi Controlla la freschezza e chiudi la pratica con la ricevuta di consegna Ho applicato quella regola a otto casi privi di contenuto, uno per ogni stato. Tutti e otto hanno dato il risultato previsto. Il caso “scomodo” è quello più significativo: @modelcontextprotocol/server filesystem è presente nella versione corretta dell’avviso, ma il test di sicurezza dello strumento fallisce. Il classificatore restituisce remediation regression , non remediated . Questo limite è importante perché gli interventi di sicurezza possono causare un incidente relativo allo stato di salute dell’agente. Un aggiornamento delle dipendenze può modificare un comando di avvio, uno schema delle funzionalità, il root consentito, il flusso OAuth o la compatibilità del client. Il codice vulnerabile potrebbe essere stato rimosso, mentre il funzionamento dell’agente potrebbe essere ancora compromesso. La ricevuta presenta alcune limitazioni. Non dimostra che un exploit sconosciuto non possa colpire il componente. Non sostituisce le prove forensi in caso di sospetta compromissione. Dipende inoltre dall’accuratezza dell’identità del pacchetto e dall’aggiornamento dei dati delle avvertenze; se due fonti non concordano, restituire unknown e conservare entrambi i riferimenti. Il Record NVD relativo a CVE 2025 6514, ad esempio, fornisce un record aggiuntivo con data relativa al problema di iniezione di comandi mcp remote , ma l'intervallo dei pacchetti dovrebbe comunque essere associato all'avviso specifico sottoposto a revisione utilizzato dal proprio sistema di corrispondenza. Applicare una patch in una sequenza che preservi l'integrità dell'agente Le misure di contenimento e di bonifica richiedono autorizzazioni distinte poiché i rispettivi raggi d'azione dell'esplosione sono diversi. Una sequenza pratica è la seguente: 1. Blocca l'identità. Registra l'ID dell'avviso, il pacchetto, la versione lanciata, il proprietario del client o del server e l'ora della segnalazione. 2. Limitare il percorso specificato. Disattivare il server, la connessione remota, lo strumento o il percorso di autorizzazione vulnerabile apportando la modifica reversibile minima possibile. 3. Ridurre i privilegi. Revocare le credenziali e le autorizzazioni non necessarie associate a quel componente. Effettuare la rotazione di un segreto solo quando vi siano prove di esposizione o quando le politiche lo richiedano; la rotazione può distruggere prove utili e causare interruzioni di servizio non correlate. 4. Installa la correzione fornita dal produttore. Utilizza la versione con la correzione specificata, non una versione più recente a caso, e mantieni il risultato ottenuto con il gestore di pacchetti. 5. Riavviare il vero proprietario. L'aggiornamento di un file di blocco o di un tag immagine non è sufficiente se un client agente in esecuzione da molto tempo detiene ancora la proprietà del vecchio processo. 6. Eseguire un test di sicurezza dello strumento. Utilizzare un bersaglio sintetico con i privilegi minimi. Non riprodurre l'exploit né indirizzare il canary verso i dati di produzione. 7. Verificare il risultato finale. Accertarsi che il file, il biglietto, il record, il messaggio o qualsiasi altro risultato atteso esista e sia corretto. 8. Monitorare una finestra di stabilità. Verificare che il componente rimanga accessibile nei momenti previsti, non rientri nell'intervallo di vulnerabilità e non presenti errori ripetuti dopo l'applicazione della patch. È necessario distinguere la verifica dello strumento dalla ricevuta di esito. Uno strumento del filesystem può restituire un esito positivo pur scrivendo nella radice consentita errata. Uno strumento di ticket può accettare una richiesta, anche se il record viene successivamente rifiutato. Un trasporto MCP può risultare integro anche se il risultato dell’agente è mancante. La prima ricevuta dimostra che la funzionalità riparata è in grado di funzionare in modo sicuro; la seconda dimostra che il lavoro dell’utente è effettivamente pervenuto. Chiudere l'incidente solo quando tutte le prove più attendibili disponibili concordano: l'avviso non corrisponde più al componente lanciato, il percorso precedentemente vulnerabile è sotto controllo, il canary di sicurezza supera il test e si è ottenuto il risultato previsto. Se un campo è obsoleto o contraddittorio, mantenere lo stato esplicito invece di contrassegnarlo in verde. Sidewisp è attualmente in anteprima privata. L'orientamento di questo prodotto è quello di fungere da "strato di salute" per i runtime degli agenti esistenti: fornire prove concrete, distinguere tra stato attivo, in attesa o bloccato, mantenere l'approvazione umana al limite dell'azione e verificare i risultati dopo l'intervento. L'esperienza pubblica attuale è una dimostrazione in accesso anticipato, non uno scanner MCP, un adattatore di monitoraggio o un motore di ripristino automatizzato già disponibili sul mercato.