Se sviluppi plugin WordPress e li distribuisci a utenti europei, c’è una scadenza che non puoi ignorare: dall’11 settembre 2026, il Cyber Resilience Act (CRA) dell’Unione Europea rende obbligatorio il reporting delle vulnerabilità attivamente sfruttate e degli incidenti gravi. Questo significa che ogni plugin commerciale presente su WordPress.org, CodeCanyon o qualsiasi piattaforma accessibile nell’UE deve avere un Vulnerability Disclosure Program (VDP) funzionante e documentato.
Ho passato le ultime settimane a studiare il testo del regolamento, le linee guida della Commissione Europea pubblicate il 3 marzo 2026 e le best practice di settore per implementare un VDP conforme al CRA. In questo articolo vi mostro passo dopo passo come ho strutturato il programma di disclosure per i plugin che gestisco, con codice reale, template pronti all’uso e tutti i riferimenti normativi aggiornati.
Se avete già letto il mio articolo sulla protezione WordPress con virtual patching e Patchstack, considerate questa guida come il complemento normativo e procedurale: lì ci siamo occupati di difendere i siti, qui ci occupiamo di gestire in modo strutturato le segnalazioni di vulnerabilità che arrivano dall’esterno.
Cos’è il Cyber Resilience Act e Perché Impatta WordPress
Il Cyber Resilience Act (Regolamento UE 2024/2847) è il nuovo quadro normativo europeo che impone requisiti di cybersicurezza obbligatori per tutti i prodotti con elementi digitali commercializzati nell’UE. È entrato in vigore il 10 dicembre 2024, ma le scadenze operative sono scaglionate nel tempo.
Ecco la timeline che ogni sviluppatore di plugin deve conoscere:
- 11 giugno 2026 — Entrano in applicazione le disposizioni sulla notifica degli Organismi di Valutazione della Conformità
- 11 settembre 2026 — Scatta l’obbligo di reporting per vulnerabilità attivamente sfruttate e incidenti gravi
- 11 dicembre 2027 — Applicazione completa di tutti i requisiti CRA, incluso il marchio CE obbligatorio
La cosa fondamentale da capire è questa: se crei o distribuisci software che persone nell’UE possono scaricare, acquistare o utilizzare, queste regole si applicano anche se non hai sede in Europa. I plugin e temi WordPress commerciali devono conformarsi al CRA, il che include audit di sicurezza obbligatori, processi formali di vulnerability disclosure e reporting documentato degli incidenti — non è più possibile patchare silenziosamente i problemi di sicurezza.
Le sanzioni non sono da sottovalutare: le autorità possono rimuovere immediatamente i plugin non conformi da WordPress.org, CodeCanyon e da qualsiasi altra piattaforma accessibile agli utenti UE. Per violazioni gravi, possono anche richiedere la notifica a tutti gli utenti esistenti.
Vulnerability Disclosure Program: Cosa Deve Contenere per Essere Conforme al CRA
Un Vulnerability Disclosure Program è un processo formale attraverso il quale i ricercatori di sicurezza possono segnalare vulnerabilità in modo strutturato e coordinato. Per il CRA, il vostro VDP deve includere almeno questi elementi:
- Punto di contatto chiaro — Un canale dedicato e facilmente individuabile per le segnalazioni di sicurezza
- Timeline di disclosure documentata — Tempistiche precise per la gestione della segnalazione
- Processo di patching — Procedura definita per sviluppare e rilasciare correzioni
- Safe Harbor — Clausola che protegge i ricercatori da azioni legali se agiscono in buona fede
- Sistema di reporting verso le autorità UE — Early warning entro 24 ore, notifica completa entro 72 ore, report finale entro 14 giorni dalla disponibilità della patch
La Single Reporting Platform (SRP) gestita da ENISA sarà operativa dall’11 settembre 2026 e diventerà il canale ufficiale per le notifiche. Ogni notifica sarà indirizzata al CSIRT (Computer Security Incident Response Team) dello Stato membro dove avete lo stabilimento principale.
Step 1: Implementare il File security.txt (RFC 9116)
Il primo passo concreto è creare il file security.txt secondo lo standard RFC 9116. È l’equivalente del robots.txt ma per le informazioni di sicurezza: i ricercatori lo cercano come primo punto di contatto. Il file va posizionato in /.well-known/security.txt e servito via HTTPS.
Ecco il template che uso per i miei progetti:
# security.txt per il Plugin WordPress MioPlugin
Contact: mailto:[email protected]
Contact: https://mioplugin.com/security/report
Expires: 2027-03-16T00:00:00.000Z
Encryption: https://mioplugin.com/.well-known/pgp-key.txt
Policy: https://mioplugin.com/security/policy
Preferred-Languages: it, en
Canonical: https://mioplugin.com/.well-known/security.txt
Hiring: https://mioplugin.com/careersSu WordPress potete gestirlo tramite il plugin Security.txt Manager disponibile su WordPress.org, oppure generarlo manualmente dal sito securitytxt.org. Nella mia esperienza, consiglio di gestirlo manualmente per avere il pieno controllo, soprattutto se avete un dominio dedicato al plugin separato dal sito WordPress.
Step 2: Creare la Vulnerability Disclosure Policy
La policy è il documento che definisce le regole del gioco. Deve essere pubblica, chiara e accessibile. Ecco la struttura che ho adottato:
Scope del Programma
Definite con precisione cosa è in scope: versioni del plugin coperte, tipologie di vulnerabilità accettate (SQL Injection, XSS, CSRF, privilege escalation, etc.), ed eventuali esclusioni (ad esempio, vulnerabilità in dipendenze di terze parti già note).
Regole di Engagement
Specificate cosa è permesso e cosa no durante il testing:
- Non eseguire attacchi distruttivi o DoS
- Non accedere o esfiltrare dati di utenti reali
- Non condividere pubblicamente la vulnerabilità prima della correzione
- Fornire un Proof of Concept dettagliato ma minimale
Clausola Safe Harbor
Questo è un elemento cruciale: i ricercatori devono sentirsi protetti legalmente. Una buona clausola Safe Harbor specifica che non intraprenderete azioni legali contro chi agisce in buona fede e nel rispetto delle regole del programma.
Tempistiche di Risposta
Per conformità al CRA, vi consiglio queste tempistiche minime:
- Acknowledgment — Entro 24-48 ore dalla ricezione
- Triage e validazione — Entro 5 giorni lavorativi
- Patch development — Entro 30 giorni per vulnerabilità critiche, 90 per le restanti
- Disclosure pubblica coordinata — Dopo il rilascio della patch
Step 3: Integrare Patchstack come CNA per la Gestione CVE
Uno dei problemi che ho incontrato all’inizio è la gestione delle CVE (Common Vulnerabilities and Exposures). Assegnare un identificativo CVE a ogni vulnerabilità è essenziale per la tracciabilità richiesta dal CRA, ma è un processo che può essere complesso per sviluppatori individuali.
La soluzione che ho adottato è Patchstack: essendo un CNA (CVE Numbering Authority), può assegnare CVE direttamente e gestisce l’intero flusso di disclosure. Il servizio è gratuito per gli sviluppatori di plugin WordPress. Ho configurato la pagina VDP del mio plugin direttamente sulla piattaforma Patchstack, ottenendo:
- Un canale strutturato per ricevere segnalazioni
- Gestione automatica del triage e della comunicazione con i ricercatori
- Assegnazione CVE conforme agli standard internazionali
- Integrazione con il workflow di patching del plugin
Dovete menzionare il canale di segnalazione in almeno tre punti: sul sito web del plugin, nella repository GitHub (tramite il file SECURITY.md) e nel file readme.txt presente sulla pagina WordPress.org. Chi mi segue e ha letto la mia guida sulla governance degli AI Agents in azienda sa quanto tengo alla compliance strutturata — lo stesso approccio vale qui.
Step 4: Generare e Mantenere il Software Bill of Materials (SBOM)
Il CRA richiede esplicitamente ai produttori di redigere un Software Bill of Materials (SBOM) in formato leggibile da macchina, che documenti almeno le dipendenze di primo livello del prodotto. L’SBOM è essenzialmente la lista ingredienti del vostro software: ogni componente, libreria e dipendenza deve essere catalogata con versione, licenza e informazioni di sicurezza.
Per i plugin WordPress che utilizzano Composer, il modo più efficace è integrare la generazione SBOM nella pipeline CI/CD. Ecco come lo faccio con Syft e il formato CycloneDX:
# Genera SBOM dal codice sorgente del plugin
syft dir:./mio-plugin-wordpress -o cyclonedx-json > sbom.json
# Per progetti con Composer
composer require --dev cyclonedx/cyclonedx-php-composer
composer make-bom --output-format=json --output-file=sbom.cdx.json
# Per dipendenze npm (se il plugin include asset JS)
npm install -g @cyclonedx/cyclonedx-npm
cyclonedx-npm --output-file sbom-frontend.jsonL’SBOM non deve essere reso pubblico secondo il CRA, ma deve essere incluso nella documentazione tecnica e fornito alle autorità di sorveglianza del mercato su richiesta. Io lo genero automaticamente a ogni release e lo conservo nel repository privato insieme al changelog di sicurezza.
Senza un SBOM funzionante, la gestione delle vulnerabilità conforme al CRA è sostanzialmente impossibile: non potrete correlare automaticamente i componenti inclusi con i database di vulnerabilità come NVD o WPScan.
Step 5: Configurare il Sistema di Incident Reporting verso ENISA
Dal settembre 2026, in caso di vulnerabilità attivamente sfruttata o incidente grave, dovrete notificare le autorità attraverso la Single Reporting Platform (SRP) di ENISA. Ecco la procedura che ho predisposto:
- Early Warning (entro 24 ore) — Notifica iniziale che descrive il tipo di incidente, la potenziale portata e le prime informazioni disponibili
- Notifica completa (entro 72 ore) — Dettaglio tecnico della vulnerabilità, componenti impattati (riferimento SBOM), valutazione dell’impatto e misure di mitigazione in corso
- Report finale (entro 14 giorni dalla disponibilità della patch) — Analisi root cause, patch rilasciata, lezioni apprese e misure preventive adottate
All’inizio non avevo un workflow chiaro per gestire queste scadenze stringenti, e rischiavo di perdermi nei tempi. Ho risolto creando un template di incident response su Notion con automazioni che mi notificano le scadenze via Slack. Se gestite più plugin, vi consiglio di centralizzare tutto in un unico sistema di tracking.
Per chi gestisce anche server, la preparazione alla compliance è simile a quanto richiesto dalla NIS2 — ne ho parlato nella mia guida su come rendere il server Plesk conforme alla Direttiva NIS2.
Step 6: Security-by-Design e Aggiornamenti Separati
Il CRA introduce un concetto fondamentale: gli aggiornamenti di sicurezza devono essere separati dagli aggiornamenti funzionali. Questo significa che gli utenti devono poter installare una patch di sicurezza senza essere costretti ad aggiornare funzionalità che potrebbero rompere la compatibilità.
In pratica, per un plugin WordPress questo implica:
- Mantenere un branch dedicato per le security releases
- Usare il versionamento semantico rigoroso (MAJOR.MINOR.PATCH)
- Documentare chiaramente nel changelog quale aggiornamento è di sicurezza
- Supportare il rollback alla versione precedente in caso di problemi
WordPress WP Toolkit su Plesk facilita enormemente questo processo permettendo rollback automatici — se usate Plesk, date un’occhiata alla mia guida alla configurazione di Plesk Obsidian per hosting WordPress.
Step 7: Prepararsi al Marchio CE per Plugin WordPress (Entro Dicembre 2027)
Può sembrare surreale parlare di marchio CE per software, ma è esattamente ciò che il CRA richiede entro l’11 dicembre 2027. Il marchio CE indica che il plugin soddisfa i requisiti di cybersicurezza dell’UE e deve essere accompagnato da una Dichiarazione di Conformità UE.
La dichiarazione deve contenere:
- Dati aziendali completi (nome, indirizzo, contatti)
- Identificazione del prodotto (nome plugin, versione, identificativo univoco)
- Riferimento alla normativa CRA applicabile
- Standard armonizzati utilizzati per la valutazione di conformità
- Procedura di conformity assessment seguita (auto-valutazione per la maggior parte dei plugin)
- Classificazione della categoria di rischio (Default, Classe I o Classe II)
Il marchio CE digitale può essere visualizzato nella documentazione del plugin, nei file readme o nell’interfaccia admin. Per la maggior parte dei plugin WordPress, la procedura sarà di auto-valutazione (self-assessment), senza necessità di un ente certificatore esterno — a meno che il vostro plugin non rientri nelle categorie di rischio Classe I o II.
Template SECURITY.md per Repository GitHub
Ecco il template del file SECURITY.md che uso nelle mie repository GitHub:
# Security Policy
## Supported Versions
| Version | Supported |
| ------- | ------------------ |
| 2.x.x | :white_check_mark: |
| 1.x.x | :x: (EOL) |
## Reporting a Vulnerability
We take security seriously. If you discover a vulnerability:
1. **DO NOT** open a public GitHub issue
2. Report via our VDP on Patchstack: https://patchstack.com/vdp/mioplugin
3. Or email: [email protected] (PGP key available)
4. Or use our security.txt: https://mioplugin.com/.well-known/security.txt
### What to expect:
- Acknowledgment within 48 hours
- Triage within 5 business days
- Security patch within 30 days (critical) / 90 days (others)
### Safe Harbor
We will not pursue legal action against researchers who:
- Act in good faith and follow this policy
- Avoid privacy violations and data destruction
- Do not publicly disclose before patch availability
## CRA Compliance
This product complies with EU Cyber Resilience Act (Regulation EU 2024/2847).
SBOM available upon request to market surveillance authorities.
Checklist Completa per la Conformità VDP al Cyber Resilience Act
Riassumo qui tutti i passaggi in una checklist operativa:
- ☐ Creare e pubblicare il file
security.txt(RFC 9116) - ☐ Redigere la Vulnerability Disclosure Policy pubblica con Safe Harbor
- ☐ Configurare Patchstack (o altro CNA) per la gestione CVE
- ☐ Generare l’SBOM in formato CycloneDX o SPDX per ogni release
- ☐ Predisporre il workflow di incident reporting verso ENISA (24h/72h/14gg)
- ☐ Separare gli aggiornamenti di sicurezza da quelli funzionali
- ☐ Documentare il file
SECURITY.mdsu GitHub - ☐ Aggiornare il
readme.txtsu WordPress.org con i riferimenti al VDP - ☐ Implementare il versionamento semantico per le security releases
- ☐ Preparare la Dichiarazione di Conformità UE (entro dicembre 2027)
Open Source e CRA: Quando Si Applica e Quando No
Una delle domande più frequenti riguarda il software open source gratuito. Il CRA ha un approccio specifico: il software free e open source che non viene monetizzato dai suoi sviluppatori è generalmente esentato dai requisiti. Tuttavia, se il software open source viene utilizzato commercialmente — ad esempio un plugin WordPress gratuito mantenuto da un’azienda o monetizzato indirettamente — ricade sotto gli obblighi CRA.
Il regolamento introduce anche il concetto di open-source stewards: entità legali (spesso fondazioni) che forniscono supporto sostenuto allo sviluppo open source. Questi steward sono soggetti a un regime normativo più leggero, specificamente calibrato sulla natura unica dei modelli di sviluppo open source.
In pratica: se il vostro plugin è su WordPress.org, è gratuito e non avete alcuna forma di monetizzazione (nemmeno indiretta tramite servizi premium, upsell o pubblicità), probabilmente siete esenti. Ma se avete anche solo una versione Pro o offrite servizi correlati, dovete conformarvi. Nel dubbio, implementare un VDP è comunque una best practice che migliora la sicurezza del vostro software.
FAQ
Il Cyber Resilience Act si applica anche a sviluppatori di plugin WordPress che non hanno sede nell’UE?
Sì. Il CRA si applica a qualsiasi prodotto con elementi digitali accessibile nel mercato UE, indipendentemente dalla sede dello sviluppatore. Se il vostro plugin può essere scaricato o utilizzato da utenti nell’UE, dovete conformarvi. Le autorità possono rimuovere i plugin non conformi da WordPress.org e da altre piattaforme accessibili agli utenti europei.
Qual è la differenza tra un VDP e un programma Bug Bounty?
Un Vulnerability Disclosure Program fornisce un canale chiaro e sicuro per segnalare vulnerabilità in modo responsabile, senza necessariamente offrire ricompense economiche. Un Bug Bounty incentiva attivamente i ricercatori con premi in denaro. Il CRA richiede un VDP come requisito minimo; il Bug Bounty è un’aggiunta facoltativa ma consigliata per plugin ad alto rischio. Sono strumenti complementari: il VDP garantisce copertura ampia, il Bug Bounty motiva la ricerca di vulnerabilità ad alto impatto.
Cosa succede se non implemento un VDP entro la scadenza del CRA?
Le sanzioni possono essere significative. Le autorità di sorveglianza del mercato possono rimuovere immediatamente il vostro plugin da tutte le piattaforme accessibili nell’UE. Per violazioni gravi, possono richiedere la notifica a tutti gli utenti esistenti e assistere nella rimozione del prodotto. Oltre alle sanzioni economiche, il danno reputazionale può essere devastante per sviluppatori e aziende.
Devo generare un SBOM anche per plugin WordPress semplici senza dipendenze esterne?
Sì, ma in questo caso l’SBOM sarà molto snello. Il CRA richiede di documentare almeno le dipendenze di primo livello. Anche se il vostro plugin non usa Composer o npm, dovrete comunque documentare la versione di PHP e WordPress richiesta, eventuali librerie JS incluse (come jQuery UI o altri componenti) e qualsiasi codice di terze parti integrato nel plugin. L’SBOM non deve essere pubblico, ma va conservato nella documentazione tecnica.
Come gestisco le segnalazioni di vulnerabilità generate dall’AI che sono spesso incomplete o invalide?
Questo è un problema reale nel 2026: gli stessi strumenti AI che creano rischi di sicurezza generano anche volumi elevati di report, molti dei quali sono incompleti o invalidi. La soluzione è utilizzare una piattaforma gestita come Patchstack o HackerOne che offre triage esperto pre-validazione. In questo modo ricevete solo vulnerabilità validate, risparmiando tempo sul rumore di fondo. Se gestite il triage internamente, create template di risposta standardizzati e criteri chiari di validazione per filtrare rapidamente i falsi positivi.
Conclusione: Il VDP Non È Solo Compliance, È Sicurezza Reale
Implementare un Vulnerability Disclosure Program conforme al Cyber Resilience Act è ormai un requisito ineludibile per chiunque sviluppi plugin WordPress distribuiti nel mercato europeo. La scadenza dell’11 settembre 2026 per il reporting obbligatorio è il primo checkpoint, ma vi consiglio di non aspettare l’ultimo momento: la preparazione richiede tempo, soprattutto per la generazione degli SBOM e la configurazione dei workflow di incident reporting.
Nella mia esperienza, il VDP non è solo un adempimento burocratico: i plugin che hanno un programma di disclosure strutturato ricevono correzioni più rapide e consistenti rispetto a quelli senza. È un investimento sulla qualità e sulla fiducia dei vostri utenti.
Per chi vuole approfondire il tema della sicurezza applicativa nel mondo WordPress, vi consiglio di leggere anche il mio articolo su come prevenire ransomware e malware con AI Agents nel 2026 e la guida alle AI integrate in WordPress Core 2026 per capire come anche il core sta evolvendo in termini di sicurezza.
Se avete domande o volete condividere la vostra esperienza con l’implementazione del VDP per i vostri plugin, lasciate un commento qui sotto: il confronto tra sviluppatori è fondamentale in questa fase di transizione normativa.