La crisi della responsabilità dei vendor: quando le patch non arrivano e il coordinamento fallisce

La scorsa settimana il flusso costante di advisory CISA e ICS ha consegnato un messaggio che va ben oltre i singoli CVE: la catena di fiducia tra chi acquista tecnologia e chi la mantiene si sta incrinando. Tra il 29 settembre e il 4 ottobre 2026, l'agenzia statunitense ha pubblicato undici alert che coprono settori trasversali — building automation, ricarica elettrica, controllo accessi fisici, protezione energetica, gateway cellulari, strumenti di analisi di rete e piattaforme cloud IoT consumer. Ciò che colpisce non è solo la gravità tecnica (CVSS fino a 9.8), ma la forbice abissale tra i vendor che assumono la responsabilità del ciclo di vita del prodotto e quelli che la delegano al silenzio.

Per le organizzazioni italiane — che operano in un tessuto di PMI, utility, PA e manifattura avanzata fortemente dipendente da fornitori internazionali — questa asimmetria non è un problema astratto. Significa che lo stesso livello di investimento in una tecnologia può tradursi in una protezione duratura o in un buco nero di rischio residuo, a seconda di una variabile che l'acquirente non controlla: la cultura di sicurezza del fornitore.

Lo spettro delle risposte: da Monta ad Armatura, chi risponde e chi sparisce

Prendiamo due casi emblematici usciti lo stesso giorno, il 1° ottobre. Monta, piattaforma olandese per la gestione di colonnine di ricarica (settori Energy e Transportation), ha quattro vulnerabilità critiche tra cui autenticazione mancante su WebSocket (CVE-2026-95102), gestione sessioni insufficiente e credenziali debolmente protette — CVSS 9.4 (Monta monta.app). La risposta del vendor: mitigazioni immediate (rate limiting, throttling), adozione progressiva di OCPP 1.6 Security Profile 2 con TLS e basic auth, deprecazione pianificata degli accessi non autenticati. Non è una risoluzione istantanea, ma è un percorso trasparente e comunicato.

Stesso giorno, Armatura LLC (USA) per il sistema di controllo accessi fisici Armatura One, usato in Communications, Critical Manufacturing, Energy, Transportation: cinque CVE tra cui la deserializzazione ActiveMQ CVE-2023-46604 (RCE pre-auth come root), chiavi crittografiche hardcoded, credenziali hardcoded, log sensibili (Armatura LLC Armatura One). CVSS 9.8. Il vendor ha rilasciato la versione 4.7.2 che risolve i problemi. Risposta concreta, patch disponibile.

Johnson Controls (Irlanda) per i controller EasyIO Neo Series EC/CW (building automation HVAC, lighting, energy — settori Critical Manufacturing, Commercial Facilities, Government, Transportation, Energy): due advisory separati per trasmissione in chiaro di credenziali e sessioni (CVE-2026-64893, CVSS 5.4) ed esposizione di informazioni sensibili (CVE-2026-64892, CVSS 3.5) (Johnson Controls EasyIO Neo Series EC and CW Controllers) (Johnson Controls EasyIO Neo Series EC and CW Controllers). Il vendor riconosce i problemi, pubblica l'elenco delle versioni interessate, lavora alle correzioni.

ABB (Svizzera) per PCM600 (Protection and Control IED Manager, settore Energy): privilege escalation via servizio scheduler che esegue come LocalSystem (CVE-2026-15952) e path traversal (CVE-2026-15953), CVSS 6.4 (ABB Protection and Control IED Manager PCM600). Workaround documentato (cambiare account del servizio), fix in arrivo.

Lantronix (USA) per gateway cellulari G520 (Transportation, Energy, Water): XSS via metadata di aggiornamento non firmati su HTTP e verifica firma crittografica assente (CVE-2026-84409, CVE-2026-91191), CVSS 7.5 (Lantronix G520 Series Cellular Gateway). Patch rilasciata (2.6.0.7R6) pochi giorni dopo.

In tutti questi casi c'è un denominatore comune: il vendor risponde. C'è un canale, c'è un piano, c'è una versione corretta o in lavorazione. La supply chain della sicurezza regge, seppur con tempi diversi.

Il caso Meari: "No fix planned" come nuovo standard pericoloso

Poi c'è Meari. Piattaforma cloud IoT OpenAPI (settori Commercial Facilities, IT), headquarters in Cina, presenza globale. Due vulnerabilità: autorizzazione mancante che permette a utenti autenticati di manipolare dispositivi altrui (CVE-2026-101104, CVSS 7.7 HIGH) e accesso non autorizzato a credenziali, dettagli proprietari, dati di rete (CVE-2026-96613) (Meari IoT Cloud Platform OpenAPI Service). La colonna "Remediations" nell'advisory CISA recita testualmente: "No fix planned. Meari did not respond to CISA's coordination attempts." Gli utenti sono invitati a contattare il vendor per supporto.

Non è un ritardo. È un rifiuto. Una piattaforma cloud che gestisce dispositivi IoT in tutto il mondo — telecamere, sensori, attuatori — decide che non vale la pena correggere un difetto di autorizzazione che espone il controllo dei device e i dati dei proprietari. E ignora l'ente di coordinamento nazionale statunitense.

Questo non è un caso isolato. È il sintomo di un modello di business in cui la sicurezza è un costo opzionale post-vendita, non un requisito di progettazione né un obbligo contrattuale. Per un'azienda italiana che ha installato telecamere o sensori Meari nei propri uffici, magazzini o siti remoti, l'advisory CISA non è un invito al patching: è una notifica di abbandono. L'unica mitigazione realistica è la dismissione e sostituzione — un costo imprevisto, non budgetizzato, che ricade interamente sul cliente.

Quando lo strumento di sicurezza è vulnerabile: CISA Malcolm e Zammad

La beffa finale arriva dagli strumenti stessi che dovrebbero aiutare a difendersi. CISA Malcolm, la piattaforma open source di analisi traffico di rete sviluppata dalla stessa CISA (settori Energy, IT, Water), ha undici vulnerabilità in versioni precedenti a v26.06.0: XSS riflesso, OS command injection, path traversal, SSRF, authentication bypass, missing authorization, missing authentication, incorrect authorization, default credentials, validazione del certificato assente, open redirect, dipendenze terze vulnerabili, hash di password deboli (CISA Malcolm). CVSS 8.8. Fix: aggiornare alla versione di settembre 2026 o successiva.

Zammad, helpdesk/ticketing system (Zammad GmbH), finisce nel KEV Catalog il 2 ottobre con due vulnerabilità attivamente sfruttate: session fixation (CVE-2026-102489) e improper privilege management (CVE-2026-102490) (CISA Adds Two Known Exploited Vulnerabilities to Catalog). Sono vettori frequenti per attori malevoli.

E nel KEV finiscono anche Citrix NetScaler (CVE-2026-88779, memory buffer restriction, aggiunto il 4 ottobre) (CISA Adds One Known Exploited Vulnerability to Catalog), Fortinet FortiMail (CVE-2026-104286, path traversal, 1° ottobre) (CISA Adds One Known Exploited Vulnerability to Catalog), Cisco Catalyst SD-WAN Manager (CVE-2026-76504, hex encoding, 30 settembre) (CISA Adds One Known Exploited Vulnerability to Catalog). Tutti attivamente sfruttati. Tutti in prodotti core per l'accesso remoto, la posta, la rete definita da software.

Il paradosso è evidente: gli strumenti per gestire la sicurezza (Malcolm), la collaborazione (Zammad), l'accesso remoto (NetScaler, SD-WAN), la posta (FortiMail) diventano essi stessi la superficie d'attacco. E la direttiva BOD 26-04 — che impone alle agenzie federali USA la remediation prioritaria dei KEV su asset esposti pubblicamente — diventa un metro di giudizio implicito anche per il settore privato italiano: se un CVE entra nel KEV, deve essere trattato come emergenza, non come ticket da sprint successivo.

Implicazioni per l'Italia: gestire il rischio vendor in ecosistemi eterogenei

Il tessuto produttivo italiano — Made in Italy manifatturiero, distretti energetici, PA digitalizzata, logistica portuale — è un mosaico di tecnologie eterogenee. Un impianto produttivo può avere controller Johnson Controls per l'HVAC, gateway Lantronix per la connettività remota, colonnine Monta nel parcheggio dipendenti, badge Armatura ai tornelli, analizzatori Malcolm in SOC, helpdesk Zammad per l'IT, FortiMail per la posta, NetScaler per l'accesso remoto, SD-WAN Cisco per le sedi periferiche. Ogni vendor ha un ciclo di vita, una reattività, una trasparenza diversa.

La lezione della settimana è che **il rischio vendor non si gestisce con l'elenco dei CVE, ma con la mappa della risposta attesa**. Significa:

• **Classificare i fornitori per *security maturity***: chi ha un PSIRT (Product Security Incident Response Team) pubblico, chi aderisce a CVD (Coordinated Vulnerability Disclosure), chi pubblica advisory tempestivi, chi rilascia patch in settimane non mesi. Meari sta in fondo alla classe; Monta, Armatura, Lantronix, Johnson Controls, ABB stanno più in alto.
• **Inserire clausole di vulnerability response nei contratti**: SLA per patch critiche, obbligo di notifica, diritto di recesso se "no fix planned" su vulnerabilità ad alto rischio. È una pratica ancora rara negli appalti italiani, ma sta diventando indispensabile.
• **Mantenere un software bill of materials (SBOM) operativo**: non solo per conformità NIS2 o CRA, ma per sapere istantaneamente se un CVE KEV tocca un componente in uso — e da quale vendor dipende la patch.
• **Pianificare la exit strategy per vendor non responsivi**: per ogni componente critico, avere un'alternativa validata. Il costo della migrazione Meari → alternativa va messo a budget prima che l'advisory arrivi.
• Estendere il monitoraggio KEV oltre il perimetro IT: i KEV di ottobre colpiscono NetScaler, FortiMail, SD-WAN (IT), ma anche Malcolm (strumento OT/IT), Zammad (processo), e gli ICS advisory colpiscono building automation, energy, transportation, physical access. La gestione vulnerabilità deve essere unificata.

La direttiva NIS2, il Cyber Resilience Act, la stessa strategia nazionale di cybersicurezza spingono nella direzione della responsabilità condivisa. Ma la responsabilità non si divide a metà: se il vendor sparisce, il peso intero ricade sull'utilizzatore. La settimana appena trascorsa lo dimostra con chiarezza brutale. Le organizzazioni italiane che vogliono trasformare la compliance in resilienza devono iniziare a trattare la risposta del vendor come un requisito d'acquisto non negoziabile — alla pari di funzionalità, prezzo e SLA di uptime. Perché l'unica cosa peggiore di una vulnerabilità critica è una vulnerabilità critica senza padrone.