Cyber Resilience Act: obblighi per chi vende plugin WordPress

Chi vende un plugin o un tema WordPress premium a clienti nell'UE è già soggetto al Cyber Resilience Act (CRA). Dall'11 settembre 2026 occorre segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi che riguardano i propri prodotti, a partire da un preallarme entro 24 ore. Il blocco più ampio di obblighi, dai requisiti di sicurezza alla distinta base del software (SBOM), fino agli aggiornamenti di sicurezza e alla marcatura CE, si applica dall'11 dicembre 2027.

Questa guida spiega chi è considerato fabbricante, che cosa comporta in pratica l'obbligo di segnalazione e che cosa fare fin da ora. Il testo giuridico di riferimento è il regolamento (UE) 2024/2847.

Chi è fabbricante ai sensi del Cyber Resilience Act?

Il CRA si applica ai «prodotti con elementi digitali» messi a disposizione sul mercato dell'UE nell'ambito di un'attività commerciale. Un plugin o un tema WordPress premium venduto a clienti dell'UE è un prodotto di questo tipo, e la persona o l'azienda che lo sviluppa e lo vende con il proprio nome ne è il fabbricante. Questo vale sia per chi ha sede nell'UE sia per chi ha sede al di fuori.

Plugin gratuiti, freemium e a pagamento

Il software libero e open source non monetizzato è in genere escluso dal regime dei fabbricanti. Un plugin amatoriale su WordPress.org senza alcuna versione a pagamento, o il codice con cui si contribuisce al progetto di qualcun altro, sono esempi tipici.

Per i modelli freemium il quadro è meno netto. I considerando del CRA elencano alcuni indizi di attività commerciale: chiedere un prezzo per il prodotto, far pagare un supporto tecnico oltre il recupero dei costi, monetizzare tramite una piattaforma o altri servizi, richiedere dati personali come condizione d'uso per motivi diversi da sicurezza, compatibilità o interoperabilità, e accettare donazioni superiori ai costi. Un plugin «lite» gratuito che esiste soprattutto per vendere una versione Pro o un servizio a pagamento può quindi essere considerato commerciale. Se il modello di business è questo, conviene organizzarsi come fabbricante e chiedere una consulenza legale sui dettagli.

Steward del software open source

Il CRA introduce anche gli «steward del software open source» (open-source software stewards): persone giuridiche, come le fondazioni, che sostengono in modo sistematico lo sviluppo di software libero e open source destinato ad attività commerciali, senza esserne il fabbricante. Gli steward sono soggetti a un regime più leggero, e i loro obblighi di segnalazione si applicano dall'11 dicembre 2027.

Perché il sito web non è un prodotto ai sensi del CRA

Un sito web o un servizio in hosting in quanto tale non è, in genere, un «prodotto» ai sensi del CRA. L'elaborazione dati da remoto rientra solo quando è essenziale per una funzione del prodotto. Il sito aziendale, il negozio online e il portale clienti non sono quindi, di norma, prodotti CRA, e gestire un sito WordPress non rende fabbricanti. Un servizio cloud senza il quale il plugin non può funzionare è invece un caso da esaminare con attenzione.

Per i proprietari di siti, il CRA agisce in modo indiretto, attraverso gli obblighi dei fornitori di plugin e temi. I loro obblighi diretti derivano dal GDPR e, per alcuni, dalla NIS2.

Il calendario del CRA per chi vende plugin WordPress

• 10 dicembre 2024: entrata in vigore del CRA.
• 11 giugno 2026: si applicano le disposizioni sugli organismi di valutazione della conformità.
• 11 settembre 2026: si applicano gli obblighi di segnalazione per i fabbricanti.
• 11 dicembre 2027: si applicano gli obblighi principali, tra cui i requisiti essenziali di cybersicurezza, la valutazione della conformità e la marcatura CE.

Segnalazioni dall'11 settembre 2026: 24 ore, 72 ore, 14 giorni

L'obbligo di segnalazione riguarda due tipi di eventi. Una vulnerabilità attivamente sfruttata è una vulnerabilità per la quale esistono prove affidabili che un attore malevolo l'abbia sfruttata in un sistema senza l'autorizzazione del proprietario. Un incidente grave incide sulla sicurezza del prodotto, per esempio perché porta, o può portare, all'introduzione di codice malevolo nel prodotto o nei sistemi degli utenti. Per uno sviluppatore di plugin, un server di aggiornamento o di licenze compromesso che distribuisce una release con una backdoor ne è un esempio evidente.

L'obbligo vale anche per i prodotti immessi sul mercato prima dell'11 dicembre 2027 (art. 69, par. 3). In altre parole, riguarda le versioni del plugin che i clienti usano oggi.

I termini decorrono dal momento in cui si viene a conoscenza della vulnerabilità o dell'incidente. Le segnalazioni passano dalla piattaforma unica di segnalazione dell'ENISA per il CRA, operativa dall'11 settembre 2026, e arrivano al CSIRT dello Stato membro in cui il fabbricante ha lo stabilimento principale nell'UE (in mancanza di uno stabilimento nell'UE valgono altre regole). L'ENISA le riceve contemporaneamente. Occorre inoltre informare gli utenti interessati e, se opportuno, tutti gli utenti del problema e delle misure di mitigazione che possono adottare.

Uno scenario realistico: un ricercatore di sicurezza o una società di hosting segnala che una falla del plugin viene sfruttata in attacchi reali. Da quel momento corre il termine di 24 ore. La nostra guida ai plugin WordPress vulnerabili mostra quanto rapidamente vengono sfruttate queste falle una volta rese pubbliche. Se sono stati esposti anche dati personali, per esempio sul proprio server delle licenze, si applicano in parallelo le regole del GDPR sulle violazioni; si veda la notifica del data breach entro 72 ore ai sensi del GDPR.

Che cosa si applica dall'11 dicembre 2027

Da dicembre 2027 gli obblighi completi del fabbricante si applicano ai plugin e ai temi immessi sul mercato. I prodotti immessi sul mercato prima di quella data rientrano solo se in seguito subiscono una modifica sostanziale (art. 69, par. 2). Gli obblighi principali:

• Sicurezza fin dalla progettazione e nessuna vulnerabilità sfruttabile nota al momento del rilascio.
• Configurazione sicura per impostazione predefinita.
• Un periodo di assistenza durante il quale si gestiscono le vulnerabilità. In genere dura almeno cinque anni, a meno che il prodotto non sia destinato a restare in uso per un periodo più breve, e la data di fine (almeno mese e anno) deve essere chiara al momento dell'acquisto.
• Aggiornamenti di sicurezza distribuiti senza ritardo, gratuitamente e accompagnati da avvisi. Va verificato come questo si concili con un modello di licenza in cui gli aggiornamenti si interrompono alla scadenza dell'abbonamento.
• Un processo di gestione delle vulnerabilità e una politica di divulgazione coordinata delle vulnerabilità (CVD), oltre a un punto di contatto unico che gli utenti possano raggiungere rapidamente.
• Una SBOM in formato leggibile da una macchina, che copra almeno le dipendenze di primo livello. Per un plugin si tratta di pacchetti Composer e npm e di eventuali librerie incluse.
• Documentazione tecnica, una valutazione della conformità e la marcatura CE.

Alcune tipologie di prodotto sono elencate nell'allegato III come «prodotti importanti», con regole più severe per la valutazione della conformità. Comprendono i software che cercano, rimuovono o mettono in quarantena software malevolo, i gestori di password e i software di gestione delle identità e degli accessi privilegiati (classe I), nonché firewall e sistemi di rilevamento e prevenzione delle intrusioni (classe II). Se il plugin è un prodotto di sicurezza, queste categorie vanno verificate con attenzione.

Sanzioni ai sensi dell'articolo 64

La violazione dei requisiti essenziali di cybersicurezza o degli obblighi del fabbricante, compreso l'obbligo di segnalazione, può comportare sanzioni fino a 15 milioni di euro o al 2,5% del fatturato mondiale annuo, se superiore. Un sollievo per i piccoli sviluppatori: le microimprese e le piccole imprese non possono essere sanzionate per il mancato rispetto del termine di 24 ore del preallarme, e gli steward del software open source non possono essere sanzionati in alcun modo ai sensi del CRA. Per i fabbricanti micro e piccoli restano comunque sanzionabili la notifica entro 72 ore e tutti gli altri obblighi.

Lista di cose da fare per chi sviluppa plugin WordPress

• Elencare ogni plugin, tema e add-on a pagamento e ogni prodotto freemium offerto a clienti dell'UE, e stabilire in quali casi si è fabbricanti.
• Predisporre un canale di ricezione delle vulnerabilità che funzioni entro 24 ore: un indirizzo di contatto per la sicurezza, un file security.txt sul sito, una casella di posta monitorata e un sostituto designato per le ferie.
• Mettere per iscritto la procedura di segnalazione: chi decide se una vulnerabilità è attivamente sfruttata, chi presenta la segnalazione sulla piattaforma unica e chi redige l'avviso per gli utenti.
• Preparare modelli per il preallarme, la notifica a 72 ore e la relazione finale.
• Pubblicare una politica di divulgazione coordinata delle vulnerabilità.
• Generare una SBOM per ogni release (CycloneDX e SPDX sono formati diffusi) e conservarla insieme alla build.
• Proteggere la pipeline di rilascio: autenticazione a più fattori su ogni account che può pubblicare codice e server di aggiornamento e di licenze messi in sicurezza.
• Definire un periodo di assistenza per ogni prodotto e pianificare come i clienti con licenza scaduta riceveranno le correzioni di sicurezza.
• Avviare la documentazione tecnica: architettura, flussi di dati, valutazione dei rischi e risultati dei test.
• Verificare se qualche prodotto rientra nell'allegato III.

Come controllo aggiuntivo prima di un rilascio, il plugin gratuito Security Audit & Compliance di secaudit.eu include un'analisi delle vulnerabilità del codice (taint analysis) di plugin e temi. Integra la revisione del codice e i test interni, ma non li sostituisce.

Domande frequenti

Il CRA si applica ai plugin gratuiti su WordPress.org?

In genere no, se il plugin non è monetizzato. Se la versione gratuita fa da canale di vendita per un prodotto o un servizio a pagamento, può configurarsi come attività commerciale: in quel caso conviene farsi consigliare.

Realizzo solo siti web per i clienti. Sono un fabbricante?

Non per il sito in sé: un sito web in quanto tale non è, in genere, un prodotto ai sensi del CRA. Chi vende anche un plugin o un tema sul mercato dell'UE è però fabbricante di quel prodotto.

Questo articolo ha carattere informativo generale e non costituisce consulenza legale.