{"id":1537,"date":"2026-03-16T13:07:44","date_gmt":"2026-03-16T12:07:44","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/vulnerability-disclosure-program-wordpress-plugin-cyber-resilience-act-2026\/"},"modified":"2026-03-16T13:07:44","modified_gmt":"2026-03-16T12:07:44","slug":"vulnerability-disclosure-program-wordpress-plugin-cyber-resilience-act-2026","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/vulnerability-disclosure-program-wordpress-plugin-cyber-resilience-act-2026\/","title":{"rendered":"Come Implemento il Vulnerability Disclosure Program per Plugin WordPress nel 2026: EU Cyber Resilience Act, VDP e Guida Pratica per Sviluppatori"},"content":{"rendered":"<p>Se sviluppi plugin WordPress e li distribuisci a utenti europei, c&#8217;\u00e8 una scadenza che <strong>non puoi ignorare<\/strong>: dall&#8217;11 settembre 2026, il <em>Cyber Resilience Act<\/em> (CRA) dell&#8217;Unione Europea rende obbligatorio il reporting delle vulnerabilit\u00e0 attivamente sfruttate e degli incidenti gravi. Questo significa che ogni plugin commerciale presente su WordPress.org, CodeCanyon o qualsiasi piattaforma accessibile nell&#8217;UE deve avere un <strong>Vulnerability Disclosure Program (VDP)<\/strong> funzionante e documentato.<\/p>\n<p>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 <strong>passo dopo passo<\/strong> come ho strutturato il programma di disclosure per i plugin che gestisco, con codice reale, template pronti all&#8217;uso e tutti i riferimenti normativi aggiornati.<\/p>\n<p>Se avete gi\u00e0 letto il mio articolo sulla <a href=\"https:\/\/darioiannascoli.it\/blog\/protezione-wordpress-vulnerabilita-plugin-virtual-patching-patchstack-waf-monitoraggio-cve\/\">protezione WordPress con virtual patching e Patchstack<\/a>, considerate questa guida come il complemento normativo e procedurale: l\u00ec ci siamo occupati di <em>difendere<\/em> i siti, qui ci occupiamo di <em>gestire in modo strutturato<\/em> le segnalazioni di vulnerabilit\u00e0 che arrivano dall&#8217;esterno.<\/p>\n<h2>Cos&#8217;\u00e8 il Cyber Resilience Act e Perch\u00e9 Impatta WordPress<\/h2>\n<p>Il <strong>Cyber Resilience Act<\/strong> (Regolamento UE 2024\/2847) \u00e8 il nuovo quadro normativo europeo che impone requisiti di cybersicurezza obbligatori per tutti i prodotti con elementi digitali commercializzati nell&#8217;UE. \u00c8 entrato in vigore il 10 dicembre 2024, ma le scadenze operative sono scaglionate nel tempo.<\/p>\n<p>Ecco la timeline che ogni sviluppatore di plugin deve conoscere:<\/p>\n<ul>\n<li><strong>11 giugno 2026<\/strong> \u2014 Entrano in applicazione le disposizioni sulla notifica degli Organismi di Valutazione della Conformit\u00e0<\/li>\n<li><strong>11 settembre 2026<\/strong> \u2014 Scatta l&#8217;obbligo di reporting per vulnerabilit\u00e0 attivamente sfruttate e incidenti gravi<\/li>\n<li><strong>11 dicembre 2027<\/strong> \u2014 Applicazione completa di tutti i requisiti CRA, incluso il marchio CE obbligatorio<\/li>\n<\/ul>\n<p>La cosa fondamentale da capire \u00e8 questa: se crei o distribuisci software che persone nell&#8217;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 <strong>audit di sicurezza obbligatori, processi formali di vulnerability disclosure e reporting documentato degli incidenti<\/strong> \u2014 non \u00e8 pi\u00f9 possibile patchare silenziosamente i problemi di sicurezza.<\/p>\n<p>Le sanzioni non sono da sottovalutare: le autorit\u00e0 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.<\/p>\n<h2>Vulnerability Disclosure Program: Cosa Deve Contenere per Essere Conforme al CRA<\/h2>\n<p>Un <em>Vulnerability Disclosure Program<\/em> \u00e8 un processo formale attraverso il quale i ricercatori di sicurezza possono segnalare vulnerabilit\u00e0 in modo strutturato e coordinato. Per il CRA, il vostro VDP deve includere almeno questi elementi:<\/p>\n<ol>\n<li><strong>Punto di contatto chiaro<\/strong> \u2014 Un canale dedicato e facilmente individuabile per le segnalazioni di sicurezza<\/li>\n<li><strong>Timeline di disclosure documentata<\/strong> \u2014 Tempistiche precise per la gestione della segnalazione<\/li>\n<li><strong>Processo di patching<\/strong> \u2014 Procedura definita per sviluppare e rilasciare correzioni<\/li>\n<li><strong>Safe Harbor<\/strong> \u2014 Clausola che protegge i ricercatori da azioni legali se agiscono in buona fede<\/li>\n<li><strong>Sistema di reporting verso le autorit\u00e0 UE<\/strong> \u2014 Early warning entro 24 ore, notifica completa entro 72 ore, report finale entro 14 giorni dalla disponibilit\u00e0 della patch<\/li>\n<\/ol>\n<p>La <em>Single Reporting Platform<\/em> (SRP) gestita da ENISA sar\u00e0 operativa dall&#8217;11 settembre 2026 e diventer\u00e0 il canale ufficiale per le notifiche. Ogni notifica sar\u00e0 indirizzata al CSIRT (Computer Security Incident Response Team) dello Stato membro dove avete lo stabilimento principale.<\/p>\n<h2>Step 1: Implementare il File security.txt (RFC 9116)<\/h2>\n<p>Il primo passo concreto \u00e8 creare il file <strong>security.txt<\/strong> secondo lo standard RFC 9116. \u00c8 l&#8217;equivalente del <em>robots.txt<\/em> ma per le informazioni di sicurezza: i ricercatori lo cercano come primo punto di contatto. Il file va posizionato in <code>\/.well-known\/security.txt<\/code> e servito via HTTPS.<\/p>\n<p>Ecco il template che uso per i miei progetti:<\/p>\n<pre><code># security.txt per il Plugin WordPress MioPlugin\nContact: mailto:[email protected]\nContact: https:\/\/mioplugin.com\/security\/report\nExpires: 2027-03-16T00:00:00.000Z\nEncryption: https:\/\/mioplugin.com\/.well-known\/pgp-key.txt\nPolicy: https:\/\/mioplugin.com\/security\/policy\nPreferred-Languages: it, en\nCanonical: https:\/\/mioplugin.com\/.well-known\/security.txt\nHiring: https:\/\/mioplugin.com\/careers<\/code><\/pre>\n<p>Su WordPress potete gestirlo tramite il plugin <strong>Security.txt Manager<\/strong> disponibile su WordPress.org, oppure generarlo manualmente dal sito <em>securitytxt.org<\/em>. Nella mia esperienza, consiglio di gestirlo manualmente per avere il pieno controllo, soprattutto se avete un dominio dedicato al plugin separato dal sito WordPress.<\/p>\n<h2>Step 2: Creare la Vulnerability Disclosure Policy<\/h2>\n<p>La policy \u00e8 il documento che definisce le regole del gioco. Deve essere pubblica, chiara e accessibile. Ecco la struttura che ho adottato:<\/p>\n<h3>Scope del Programma<\/h3>\n<p>Definite con precisione cosa \u00e8 in scope: versioni del plugin coperte, tipologie di vulnerabilit\u00e0 accettate (SQL Injection, XSS, CSRF, privilege escalation, etc.), ed eventuali esclusioni (ad esempio, vulnerabilit\u00e0 in dipendenze di terze parti gi\u00e0 note).<\/p>\n<h3>Regole di Engagement<\/h3>\n<p>Specificate cosa \u00e8 permesso e cosa no durante il testing:<\/p>\n<ul>\n<li>Non eseguire attacchi distruttivi o DoS<\/li>\n<li>Non accedere o esfiltrare dati di utenti reali<\/li>\n<li>Non condividere pubblicamente la vulnerabilit\u00e0 prima della correzione<\/li>\n<li>Fornire un Proof of Concept dettagliato ma minimale<\/li>\n<\/ul>\n<h3>Clausola Safe Harbor<\/h3>\n<p>Questo \u00e8 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.<\/p>\n<h3>Tempistiche di Risposta<\/h3>\n<p>Per conformit\u00e0 al CRA, vi consiglio queste tempistiche minime:<\/p>\n<ul>\n<li><strong>Acknowledgment<\/strong> \u2014 Entro 24-48 ore dalla ricezione<\/li>\n<li><strong>Triage e validazione<\/strong> \u2014 Entro 5 giorni lavorativi<\/li>\n<li><strong>Patch development<\/strong> \u2014 Entro 30 giorni per vulnerabilit\u00e0 critiche, 90 per le restanti<\/li>\n<li><strong>Disclosure pubblica coordinata<\/strong> \u2014 Dopo il rilascio della patch<\/li>\n<\/ul>\n<h2>Step 3: Integrare Patchstack come CNA per la Gestione CVE<\/h2>\n<p>Uno dei problemi che ho incontrato all&#8217;inizio \u00e8 la gestione delle CVE (Common Vulnerabilities and Exposures). Assegnare un identificativo CVE a ogni vulnerabilit\u00e0 \u00e8 essenziale per la tracciabilit\u00e0 richiesta dal CRA, ma \u00e8 un processo che pu\u00f2 essere complesso per sviluppatori individuali.<\/p>\n<p>La soluzione che ho adottato \u00e8 <strong>Patchstack<\/strong>: essendo un <em>CNA (CVE Numbering Authority)<\/em>, pu\u00f2 assegnare CVE direttamente e gestisce l&#8217;intero flusso di disclosure. Il servizio \u00e8 gratuito per gli sviluppatori di plugin WordPress. Ho configurato la pagina VDP del mio plugin direttamente sulla piattaforma Patchstack, ottenendo:<\/p>\n<ul>\n<li>Un canale strutturato per ricevere segnalazioni<\/li>\n<li>Gestione automatica del triage e della comunicazione con i ricercatori<\/li>\n<li>Assegnazione CVE conforme agli standard internazionali<\/li>\n<li>Integrazione con il workflow di patching del plugin<\/li>\n<\/ul>\n<p>Dovete menzionare il canale di segnalazione in almeno tre punti: sul sito web del plugin, nella repository GitHub (tramite il file <code>SECURITY.md<\/code>) e nel file <code>readme.txt<\/code> presente sulla pagina WordPress.org. Chi mi segue e ha letto la mia guida sulla <a href=\"https:\/\/darioiannascoli.it\/blog\/governance-ai-agents-azienda-sicurezza-compliance-human-in-the-loop-2026\/\">governance degli AI Agents in azienda<\/a> sa quanto tengo alla compliance strutturata \u2014 lo stesso approccio vale qui.<\/p>\n<h2>Step 4: Generare e Mantenere il Software Bill of Materials (SBOM)<\/h2>\n<p>Il CRA richiede esplicitamente ai produttori di redigere un <strong>Software Bill of Materials (SBOM)<\/strong> in formato leggibile da macchina, che documenti almeno le dipendenze di primo livello del prodotto. L&#8217;SBOM \u00e8 essenzialmente la lista ingredienti del vostro software: ogni componente, libreria e dipendenza deve essere catalogata con versione, licenza e informazioni di sicurezza.<\/p>\n<p>Per i plugin WordPress che utilizzano Composer, il modo pi\u00f9 efficace \u00e8 integrare la generazione SBOM nella pipeline CI\/CD. Ecco come lo faccio con <strong>Syft<\/strong> e il formato <em>CycloneDX<\/em>:<\/p>\n<pre><code># Genera SBOM dal codice sorgente del plugin\nsyft dir:.\/mio-plugin-wordpress -o cyclonedx-json &gt; sbom.json\n\n# Per progetti con Composer\ncomposer require --dev cyclonedx\/cyclonedx-php-composer\ncomposer make-bom --output-format=json --output-file=sbom.cdx.json\n\n# Per dipendenze npm (se il plugin include asset JS)\nnpm install -g @cyclonedx\/cyclonedx-npm\ncyclonedx-npm --output-file sbom-frontend.json<\/code><\/pre>\n<p>L&#8217;SBOM non deve essere reso pubblico secondo il CRA, ma deve essere incluso nella documentazione tecnica e fornito alle autorit\u00e0 di sorveglianza del mercato su richiesta. Io lo genero automaticamente a ogni release e lo conservo nel repository privato insieme al changelog di sicurezza.<\/p>\n<p>Senza un SBOM funzionante, la gestione delle vulnerabilit\u00e0 conforme al CRA \u00e8 sostanzialmente impossibile: non potrete correlare automaticamente i componenti inclusi con i database di vulnerabilit\u00e0 come NVD o WPScan.<\/p>\n<h2>Step 5: Configurare il Sistema di Incident Reporting verso ENISA<\/h2>\n<p>Dal settembre 2026, in caso di vulnerabilit\u00e0 attivamente sfruttata o incidente grave, dovrete notificare le autorit\u00e0 attraverso la <strong>Single Reporting Platform (SRP)<\/strong> di ENISA. Ecco la procedura che ho predisposto:<\/p>\n<ol>\n<li><strong>Early Warning (entro 24 ore)<\/strong> \u2014 Notifica iniziale che descrive il tipo di incidente, la potenziale portata e le prime informazioni disponibili<\/li>\n<li><strong>Notifica completa (entro 72 ore)<\/strong> \u2014 Dettaglio tecnico della vulnerabilit\u00e0, componenti impattati (riferimento SBOM), valutazione dell&#8217;impatto e misure di mitigazione in corso<\/li>\n<li><strong>Report finale (entro 14 giorni dalla disponibilit\u00e0 della patch)<\/strong> \u2014 Analisi root cause, patch rilasciata, lezioni apprese e misure preventive adottate<\/li>\n<\/ol>\n<p>All&#8217;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\u00f9 plugin, vi consiglio di centralizzare tutto in un unico sistema di tracking.<\/p>\n<p>Per chi gestisce anche server, la preparazione alla compliance \u00e8 simile a quanto richiesto dalla NIS2 \u2014 ne ho parlato nella mia guida su come <a href=\"https:\/\/darioiannascoli.it\/blog\/plesk-conforme-direttiva-nis2-logging-action-log-autenticazione-checklist\/\">rendere il server Plesk conforme alla Direttiva NIS2<\/a>.<\/p>\n<h2>Step 6: Security-by-Design e Aggiornamenti Separati<\/h2>\n<p>Il CRA introduce un concetto fondamentale: gli <strong>aggiornamenti di sicurezza devono essere separati dagli aggiornamenti funzionali<\/strong>. Questo significa che gli utenti devono poter installare una patch di sicurezza senza essere costretti ad aggiornare funzionalit\u00e0 che potrebbero rompere la compatibilit\u00e0.<\/p>\n<p>In pratica, per un plugin WordPress questo implica:<\/p>\n<ul>\n<li>Mantenere un branch dedicato per le <em>security releases<\/em><\/li>\n<li>Usare il versionamento semantico rigoroso (MAJOR.MINOR.PATCH)<\/li>\n<li>Documentare chiaramente nel changelog quale aggiornamento \u00e8 di sicurezza<\/li>\n<li>Supportare il rollback alla versione precedente in caso di problemi<\/li>\n<\/ul>\n<p>WordPress WP Toolkit su Plesk facilita enormemente questo processo permettendo rollback automatici \u2014 se usate Plesk, date un&#8217;occhiata alla mia <a href=\"https:\/\/darioiannascoli.it\/blog\/configurare-server-plesk-obsidian-hosting-wordpress-prestazioni-sicurezza-2026\/\">guida alla configurazione di Plesk Obsidian per hosting WordPress<\/a>.<\/p>\n<h2>Step 7: Prepararsi al Marchio CE per Plugin WordPress (Entro Dicembre 2027)<\/h2>\n<p>Pu\u00f2 sembrare surreale parlare di <strong>marchio CE per software<\/strong>, ma \u00e8 esattamente ci\u00f2 che il CRA richiede entro l&#8217;11 dicembre 2027. Il marchio CE indica che il plugin soddisfa i requisiti di cybersicurezza dell&#8217;UE e deve essere accompagnato da una <em>Dichiarazione di Conformit\u00e0 UE<\/em>.<\/p>\n<p>La dichiarazione deve contenere:<\/p>\n<ul>\n<li>Dati aziendali completi (nome, indirizzo, contatti)<\/li>\n<li>Identificazione del prodotto (nome plugin, versione, identificativo univoco)<\/li>\n<li>Riferimento alla normativa CRA applicabile<\/li>\n<li>Standard armonizzati utilizzati per la valutazione di conformit\u00e0<\/li>\n<li>Procedura di conformity assessment seguita (auto-valutazione per la maggior parte dei plugin)<\/li>\n<li>Classificazione della categoria di rischio (Default, Classe I o Classe II)<\/li>\n<\/ul>\n<p>Il marchio CE digitale pu\u00f2 essere visualizzato nella documentazione del plugin, nei file readme o nell&#8217;interfaccia admin. Per la maggior parte dei plugin WordPress, la procedura sar\u00e0 di <strong>auto-valutazione<\/strong> (self-assessment), senza necessit\u00e0 di un ente certificatore esterno \u2014 a meno che il vostro plugin non rientri nelle categorie di rischio Classe I o II.<\/p>\n<h2>Template SECURITY.md per Repository GitHub<\/h2>\n<p>Ecco il template del file <code>SECURITY.md<\/code> che uso nelle mie repository GitHub:<\/p>\n<pre><code># Security Policy\n\n## Supported Versions\n\n| Version | Supported          |\n| ------- | ------------------ |\n| 2.x.x   | :white_check_mark: |\n| 1.x.x   | :x: (EOL)          |\n\n## Reporting a Vulnerability\n\nWe take security seriously. If you discover a vulnerability:\n\n1. **DO NOT** open a public GitHub issue\n2. Report via our VDP on Patchstack: https:\/\/patchstack.com\/vdp\/mioplugin\n3. Or email: [email protected] (PGP key available)\n4. Or use our security.txt: https:\/\/mioplugin.com\/.well-known\/security.txt\n\n### What to expect:\n- Acknowledgment within 48 hours\n- Triage within 5 business days\n- Security patch within 30 days (critical) \/ 90 days (others)\n\n### Safe Harbor\nWe will not pursue legal action against researchers who:\n- Act in good faith and follow this policy\n- Avoid privacy violations and data destruction\n- Do not publicly disclose before patch availability\n\n## CRA Compliance\nThis product complies with EU Cyber Resilience Act (Regulation EU 2024\/2847).\nSBOM available upon request to market surveillance authorities.\n<\/code><\/pre>\n<h2>Checklist Completa per la Conformit\u00e0 VDP al Cyber Resilience Act<\/h2>\n<p>Riassumo qui tutti i passaggi in una checklist operativa:<\/p>\n<ol>\n<li>\u2610 Creare e pubblicare il file <code>security.txt<\/code> (RFC 9116)<\/li>\n<li>\u2610 Redigere la <em>Vulnerability Disclosure Policy<\/em> pubblica con Safe Harbor<\/li>\n<li>\u2610 Configurare Patchstack (o altro CNA) per la gestione CVE<\/li>\n<li>\u2610 Generare l&#8217;SBOM in formato CycloneDX o SPDX per ogni release<\/li>\n<li>\u2610 Predisporre il workflow di incident reporting verso ENISA (24h\/72h\/14gg)<\/li>\n<li>\u2610 Separare gli aggiornamenti di sicurezza da quelli funzionali<\/li>\n<li>\u2610 Documentare il file <code>SECURITY.md<\/code> su GitHub<\/li>\n<li>\u2610 Aggiornare il <code>readme.txt<\/code> su WordPress.org con i riferimenti al VDP<\/li>\n<li>\u2610 Implementare il versionamento semantico per le security releases<\/li>\n<li>\u2610 Preparare la Dichiarazione di Conformit\u00e0 UE (entro dicembre 2027)<\/li>\n<\/ol>\n<h2>Open Source e CRA: Quando Si Applica e Quando No<\/h2>\n<p>Una delle domande pi\u00f9 frequenti riguarda il <strong>software open source gratuito<\/strong>. Il CRA ha un approccio specifico: il software free e open source che non viene monetizzato dai suoi sviluppatori \u00e8 generalmente esentato dai requisiti. Tuttavia, se il software open source viene utilizzato commercialmente \u2014 ad esempio un plugin WordPress gratuito mantenuto da un&#8217;azienda o monetizzato indirettamente \u2014 ricade sotto gli obblighi CRA.<\/p>\n<p>Il regolamento introduce anche il concetto di <em>open-source stewards<\/em>: entit\u00e0 legali (spesso fondazioni) che forniscono supporto sostenuto allo sviluppo open source. Questi steward sono soggetti a un regime normativo pi\u00f9 leggero, specificamente calibrato sulla natura unica dei modelli di sviluppo open source.<\/p>\n<p>In pratica: se il vostro plugin \u00e8 su WordPress.org, \u00e8 gratuito e non avete alcuna forma di monetizzazione (nemmeno indiretta tramite servizi premium, upsell o pubblicit\u00e0), probabilmente siete esenti. Ma se avete anche solo una versione Pro o offrite servizi correlati, dovete conformarvi. Nel dubbio, implementare un VDP \u00e8 comunque una <strong>best practice<\/strong> che migliora la sicurezza del vostro software.<\/p>\n<h2>FAQ<\/h2>\n<h3>Il Cyber Resilience Act si applica anche a sviluppatori di plugin WordPress che non hanno sede nell&#8217;UE?<\/h3>\n<p>S\u00ec. Il CRA si applica a qualsiasi prodotto con elementi digitali accessibile nel mercato UE, indipendentemente dalla sede dello sviluppatore. Se il vostro plugin pu\u00f2 essere scaricato o utilizzato da utenti nell&#8217;UE, dovete conformarvi. Le autorit\u00e0 possono rimuovere i plugin non conformi da WordPress.org e da altre piattaforme accessibili agli utenti europei.<\/p>\n<h3>Qual \u00e8 la differenza tra un VDP e un programma Bug Bounty?<\/h3>\n<p>Un Vulnerability Disclosure Program fornisce un canale chiaro e sicuro per segnalare vulnerabilit\u00e0 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 \u00e8 un&#8217;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\u00e0 ad alto impatto.<\/p>\n<h3>Cosa succede se non implemento un VDP entro la scadenza del CRA?<\/h3>\n<p>Le sanzioni possono essere significative. Le autorit\u00e0 di sorveglianza del mercato possono rimuovere immediatamente il vostro plugin da tutte le piattaforme accessibili nell&#8217;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\u00f2 essere devastante per sviluppatori e aziende.<\/p>\n<h3>Devo generare un SBOM anche per plugin WordPress semplici senza dipendenze esterne?<\/h3>\n<p>S\u00ec, ma in questo caso l&#8217;SBOM sar\u00e0 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&#8217;SBOM non deve essere pubblico, ma va conservato nella documentazione tecnica.<\/p>\n<h3>Come gestisco le segnalazioni di vulnerabilit\u00e0 generate dall&#8217;AI che sono spesso incomplete o invalide?<\/h3>\n<p>Questo \u00e8 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 \u00e8 utilizzare una piattaforma gestita come Patchstack o HackerOne che offre <em>triage esperto<\/em> pre-validazione. In questo modo ricevete solo vulnerabilit\u00e0 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.<\/p>\n<h2>Conclusione: Il VDP Non \u00c8 Solo Compliance, \u00c8 Sicurezza Reale<\/h2>\n<p>Implementare un <strong>Vulnerability Disclosure Program<\/strong> conforme al <em>Cyber Resilience Act<\/em> \u00e8 ormai un requisito ineludibile per chiunque sviluppi plugin WordPress distribuiti nel mercato europeo. La scadenza dell&#8217;11 settembre 2026 per il reporting obbligatorio \u00e8 il primo checkpoint, ma vi consiglio di non aspettare l&#8217;ultimo momento: la preparazione richiede tempo, soprattutto per la generazione degli SBOM e la configurazione dei workflow di incident reporting.<\/p>\n<p>Nella mia esperienza, il VDP non \u00e8 solo un adempimento burocratico: i plugin che hanno un programma di disclosure strutturato ricevono correzioni pi\u00f9 rapide e consistenti rispetto a quelli senza. \u00c8 un investimento sulla qualit\u00e0 e sulla fiducia dei vostri utenti.<\/p>\n<p>Per chi vuole approfondire il tema della sicurezza applicativa nel mondo WordPress, vi consiglio di leggere anche il mio articolo su come <a href=\"https:\/\/darioiannascoli.it\/blog\/prevenire-ransomware-malware-ai-agents-defensive-security-threat-monitoring-detection-2026\/\">prevenire ransomware e malware con AI Agents nel 2026<\/a> e la guida alle <a href=\"https:\/\/darioiannascoli.it\/blog\/wordpress-ai-core-2026-roadmap-wp-ai-client-guardrails-workflow-automatizzati\/\">AI integrate in WordPress Core 2026<\/a> per capire come anche il core sta evolvendo in termini di sicurezza.<\/p>\n<p>Se avete domande o volete condividere la vostra esperienza con l&#8217;implementazione del VDP per i vostri plugin, lasciate un commento qui sotto: il confronto tra sviluppatori \u00e8 fondamentale in questa fase di transizione normativa.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Guida pratica per implementare un Vulnerability Disclosure Program conforme al Cyber Resilience Act UE sui plugin WordPress: VDP, SBOM, security.txt e incident reporting entro settembre 2026.<\/p>\n","protected":false},"author":1,"featured_media":1538,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"VDP WordPress e Cyber Resilience Act 2026: Guida Pratica","_seopress_titles_desc":"Come implementare un Vulnerability Disclosure Program conforme al CRA per plugin WordPress: security.txt, SBOM, incident reporting ENISA. Guida step-by-step.","_seopress_robots_index":"","footnotes":""},"categories":[2],"tags":[455,452,10,454,453,237],"class_list":["post-1537","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-wordpress","tag-cra-compliance","tag-cyber-resilience-act","tag-plugin-wordpress","tag-sbom","tag-vulnerability-disclosure-program","tag-wordpress-security"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/1537","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/comments?post=1537"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/1537\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/1538"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=1537"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=1537"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=1537"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}