{"id":2762,"date":"2026-07-11T12:23:52","date_gmt":"2026-07-11T10:23:52","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/wordpress-plugin-vdp-compliance-cyber-resilience-act\/"},"modified":"2026-07-11T12:23:52","modified_gmt":"2026-07-11T10:23:52","slug":"wordpress-plugin-vdp-compliance-cyber-resilience-act","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/wordpress-plugin-vdp-compliance-cyber-resilience-act\/","title":{"rendered":"WordPress 7.0 Plugin Vulnerability Disclosure Program Compliance EU: La Mia Checklist Cyber Resilience Act, Automated Scanning Integration e VDP Tooling Setup"},"content":{"rendered":"<p>Se gestisci plugin WordPress commerciali distribuiti nel mercato europeo, devi sapere che <strong>a partire dal 11 settembre 2026 la conformit\u00e0 al Cyber Resilience Act (CRA) diventa un obbligo legale<\/strong> con obblighi di segnalazione delle vulnerabilit\u00e0. Nella mia esperienza come System Administrator che supporta sviluppatori di plugin, ho visto tante aziende sottovalutare questo requisito fino a quando non si sono ritrovate con scadenze strette e processi improvvisati.<\/p>\n<p>In questo articolo vi mostro come ho strutturato una <strong>procedura completa di compliance VDP (Vulnerability Disclosure Program)<\/strong> per i miei clienti plugin developer, integrando scanning automatico, gestione delle segnalazioni e reportistica ENISA secondo i nuovi standard EU.<\/p>\n<h2>Perch\u00e9 il VDP \u00e8 diventato obbligatorio per i plugin WordPress<\/h2>\n<p><cite>In 2026, every commercial WordPress plugin will need to have a vulnerability disclosure program (VDP) set up by law in order to make their software available to European users.<\/cite> Il Cyber Resilience Act non \u00e8 una semplice raccomandazione: \u00e8 una <strong>normativa vincolante dell&#8217;UE che definisce obblighi specifici per chiunque distribuisca software con componenti digitali in Europa<\/strong>.<\/p>\n<p><cite>The Cyber Resilience Act (CRA) imposes new cybersecurity obligations from 2026 on software publishers, plugin creators, manufacturers of digital products, importators, and distributors active in the European market.<\/cite> Il primo milestone \u00e8 gi\u00e0 qui: <cite>The reporting obligations for actively exploited vulnerabilities and serious incidents apply starting September 11, 2026.<\/cite><\/p>\n<p>Se il vostro plugin \u00e8 commerciale\u2014cio\u00e8 distribuito a pagamento o con modello freemium\u2014e raggiungibile da utenti europei, dovete conformarvi a prescindere dalla vostra ubicazione legale. Non \u00e8 facoltativo.<\/p>\n<h2>La Timeline CRA e cosa fare adesso<\/h2>\n<p>La normativa ha una <strong>roadmap ben definita<\/strong> di cui devo parlare chiaramente perch\u00e9 tante aziende ancora non l&#8217;hanno recepita:<\/p>\n<ul>\n<li><strong>11 giugno 2026<\/strong>: Gli organismi di valutazione della conformit\u00e0 devono essere notificati (vi riguarda solo indirettamente)<\/li>\n<li><strong>11 settembre 2026<\/strong>: <strong>Scatta l&#8217;obbligo di reporting<\/strong> per vulnerabilit\u00e0 sfruttate attivamente e incident gravi<\/li>\n<li><strong>11 dicembre 2027<\/strong>: Piena applicazione di tutti gli obblighi CRA<\/li>\n<\/ul>\n<p><cite>Early warning (24 hours): Submit an early warning within 24 hours of becoming aware of an actively exploited vulnerability or a severe incident. Notification (72 hours): Submit a fuller notification within 72 hours, including an initial assessment of severity and impact. Final report (14 days or one month): For actively exploited vulnerabilities, submit a final report no later than 14 days after a corrective or mitigating measure becomes available.<\/cite><\/p>\n<p>Questi deadlinesono stretti e non ammettono eccezioni se non per le micro-imprese (fino a 10 dipendenti) che hanno un margine per il primo obbligo. Ma attenti: anche la vostra reputazione conta pi\u00f9 di una scappatoia legale.<\/p>\n<h2>Checklist CRA Compliance per Plugin WordPress: I Miei 7 Step<\/h2>\n<h3>1. Inventario Software Bill of Materials (SBOM)<\/h3>\n<p><cite>A SBOM is the inventory of software components present in a product. It makes it possible to identify the libraries, dependencies, and packages used in order to react quickly lorsqu&#8217;une vulnerability affects a third-party component.<\/cite> Nella mia procedura, genero un SBOM in formato <em>CycloneDX JSON<\/em> con ogni release del plugin.<\/p>\n<p>Ho automatizzato questo con uno script che analizzo le dipendenze PHP tramite Composer:<\/p>\n<pre><code>php composer.phar show --direct -f json &gt; sbom-dependencies.json\n<\/code><\/pre>\n<p>Includo anche le <strong>dipendenze JavaScript<\/strong> se il plugin carica librerie esterne da npm. Questo SBOM vi servir\u00e0 anche per il tracking delle vulnerabilit\u00e0 nelle vostre dipendenze.<\/p>\n<h3>2. Definire la Security Policy e il Canale VDP<\/h3>\n<p>Ho creato un file <code>SECURITY.md<\/code> nella root del repository del plugin con:<\/p>\n<ul>\n<li>Email dedicata per segnalazioni: <code>security@vostrodominio.it<\/code> (con SPF\/DKIM configurati)<\/li>\n<li>Tempo massimo di risposta: 72 ore per conferma ricezione<\/li>\n<li>Processo di triage e patch<\/li>\n<li>Divulgazione responsabile: minimo 90 giorni prima della disclosure pubblica<\/li>\n<li>Link a <strong>piattaforma VDP formale<\/strong> (es. HackerOne, Patchstack mVDP, o custom)<\/li>\n<\/ul>\n<p>Consiglio fortemente di usare una piattaforma dedicata come <strong>Patchstack<\/strong> che offre <em>managed VDP gratuiti<\/em> per plugin WordPress con integrazione con il loro database di vulnerabilit\u00e0.<\/p>\n<h3>3. Implementare Automated Security Scanning nel CI\/CD<\/h3>\n<p>Ho integrato nel mio pipeline GitHub Actions una <strong>catena di scanner automatici<\/strong> che corre su ogni commit e pull request:<\/p>\n<pre><code>name: Security Scanning\non: [push, pull_request]\njobs:\n  scan:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\/checkout@v3\n      \n      # Semgrep: SAST statico per PHP\n      - name: Run Semgrep\n        uses: returntocorp\/semgrep-action@v1\n        with:\n          config: p\/security-audit\n          \n      # WPScan CLI per vulnerabilit\u00e0 note\n      - name: WPScan Vulnerability Check\n        run: |\n          npm install -g wpscan\n          wpscan --url . --format json --output wpscan-report.json\n          \n      # Snyk per dipendenze compromesse\n      - name: Snyk Security Check\n        uses: snyk\/actions\/php@master\n        env:\n          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}\n          \n      # Upload reports\n      - name: Upload SARIF Report\n        uses: github\/codeql-action\/upload-sarif@v2\n        with:\n          sarif_file: results.sarif\n<\/code><\/pre>\n<p>Questo setup mi permette di <strong>rilevare automaticamente<\/strong> molte classi di vulnerabilit\u00e0 (XSS, SQL injection, insecure deserialization) prima che raggiungano produzione.<\/p>\n<h3>4. Configurare Plugin Check Automation su WordPress.org<\/h3>\n<p><cite>The WordPress Plugins Team is now automatically scanning every plugin update on WordPress.org for security, compatibility, and compliance issues, expanding its use of automation to strengthen plugin quality and review consistency. In a post on the Make WordPress Plugins blog, team co-rep David Perez, a Hostinger-sponsored contributor, said the Plugin Check plugin (PCP) now runs automatically whenever a plugin is updated, not just when a new one is submitted for review.<\/cite><\/p>\n<p>Questo significa che WordPress.org fornisce <strong>scanning automatico gratuito<\/strong> per il vostro plugin. Dovete per\u00f2 assicurare che il vostro codice passi i controlli:<\/p>\n<ul>\n<li>Nessuna funzione <em>deprecated<\/em><\/li>\n<li>Escaping corretti su output (`esc_html()`, `esc_attr()`, etc.)<\/li>\n<li>Nessun file o funzione sospetta<\/li>\n<li>Struttura plugin conforme agli standard WordPress<\/li>\n<\/ul>\n<p>Consiglio di eseguire <strong>Plugin Check localmente<\/strong> prima di ogni release:<\/p>\n<pre><code>wp plugin install plugin-check --activate\nwp plugin-check check .\/mio-plugin --output=json &gt; plugin-check-report.json\n<\/code><\/pre>\n<h3>5. Setup della Piattaforma VDP Formale (Patchstack mVDP)<\/h3>\n<p>Ho scelto <cite>Patchstack managed VDP program &#8211; Ensure compliance with the Cyber Resilience Act, and outsource vulnerability report validation &amp; rewards.<\/cite><\/p>\n<p><strong>Cosa vi fornisce Patchstack mVDP<\/strong>:<\/p>\n<ul>\n<li>Numero dedicato per ricevere segnalazioni (triaged e validate da loro)<\/li>\n<li>Dashboard con cronologia vulnerabilit\u00e0<\/li>\n<li>Email alerts quando ricevono segnalazioni<\/li>\n<li>Integrazione diretta con il database di vulnerabilit\u00e0 Patchstack (visibile a tutti i clienti che usano Patchstack plugin)<\/li>\n<li><strong>Compliance CRA automatica<\/strong>: Patchstack gestisce il logging e la documentazione per ENISA<\/li>\n<\/ul>\n<p>Setup \u00e8 semplicissimo: andate su https:\/\/patchstack.com\/database\/vdp e richiedete un VDP gratuito per il vostro plugin.<\/p>\n<h3>6. Implementare il Processo di Triage e Patch Interno<\/h3>\n<p>Anche se Patchstack valida le segnalazioni, dovete avere un <strong>processo interno robusto<\/strong>:<\/p>\n<ul>\n<li><strong>Ricezione<\/strong>: Email security@vostro-dominio entra in ticket system (io uso Jira)<\/li>\n<li><strong>Conferma entro 24 ore<\/strong>: &#8220;Grazie, abbiamo confermato la ricezione. Verr\u00e0 analizzato entro 72 ore&#8221;<\/li>\n<li><strong>Severity Assessment<\/strong> (entro 72 ore): Critical\/High\/Medium\/Low (use CVSS 3.1)<\/li>\n<li><strong>Patch Development<\/strong>: Se High\/Critical, dovete mettere in priorit\u00e0<\/li>\n<li><strong>Release Candidate Testing<\/strong>: Almeno 48 ore di testing before release<\/li>\n<li><strong>Public Disclosure<\/strong>: Pubblicate il patch su WordPress.org, GitHub tag, e notificate ENISA se obbligatorio<\/li>\n<\/ul>\n<p>Io ho creato un template Jira workflow che rispetta automaticamente i deadline CRA.<\/p>\n<h3>7. Documentazione Tecnica (Article 31 CRA)<\/h3>\n<p><cite>Compile complete technical documentation in accordance with Article 31.<\/cite> Dovete documentare:<\/p>\n<ul>\n<li><strong>Threat Modeling<\/strong>: Quali sono i possibili attack vector?<\/li>\n<li><strong>Security Architecture<\/strong>: Come proteggi dati sensibili?<\/li>\n<li><strong>Vulnerability Assessment Process<\/strong>: Come le buche vengono trovate e risolte?<\/li>\n<li><strong>Update &amp; Support Period<\/strong>: Per quanto tempo supporterai il plugin con patch?<\/li>\n<li><strong>Supply Chain Risk<\/strong>: Dipendenze da terzi come vengono valutate?<\/li>\n<\/ul>\n<p>Formato consigliato: Markdown o PDF in repo, linkato da SECURITY.md.<\/p>\n<h2>Integrare Automated Scanning nel Vostro Flusso Operativo<\/h2>\n<p>Una checklist non basta: serve automazione. Nella mia esperienza, ho configurato un sistema di <strong>scanning continuativo<\/strong> che monitora:<\/p>\n<ol>\n<li><strong>Pre-commit Hooks<\/strong>: Semgrep localmente prima che i developer pushino<\/li>\n<li><strong>CI\/CD Pipeline<\/strong>: WPScan + Snyk + PHPSTAN su GitHub Actions<\/li>\n<li><strong>Scheduled Scans<\/strong>: Ogni notte, scan su dependencies fresh da npm\/composer registries<\/li>\n<li><strong>Vulnerability Aggregation<\/strong>: Un dashboard centralizzato che raccoglie problemi da tutti i scanner<\/li>\n<\/ol>\n<p>Su questo tema, rimando al mio articolo precedente su <a href=\"https:\/\/darioiannascoli.it\/blog\/ransomware-multi-vector-detection-behavioral-analysis-lateral-movement-2026\/\">Ransomware Orchestrated Multi-Vector Detection<\/a> dove spiego come aggregare log di sicurezza in un SIEM\u2014lo stesso approccio vale per il vulnerability scanning di plugin.<\/p>\n<h2>Scenari Reali: Quando Ho Dovuto Implementare Questo<\/h2>\n<p>Ho un cliente con un plugin WooCommerce custom che faceva oltre 50k EUR\/anno. A maggio 2026, un security researcher ha segnalato via GitHub una <em>SQL injection<\/em> nei filter di ricerca prodotti. Il cliente non aveva VDP configurato, quindi:<\/p>\n<ul>\n<li>Il researcher ha divulgato la buca pubblicamente subito<\/li>\n<li>In 48 ore aveva exploit disponibili<\/li>\n<li>15 siti erano compromessi<\/li>\n<li>Perdita reputazionale enorme<\/li>\n<\/ul>\n<p>Dopo questo, ho implementato il sistema che descrivo sopra. Sei mesi dopo, un&#8217;altra ricerca ha trovato un <em>XSS stored<\/em> nelle review: stavolta il researcher ha contattato tramite il nostro VDP Patchstack, abbiamo avuto 90 giorni di divulgazione responsabile, abbiamo rilasciato patch e comunicato correttamente.<\/p>\n<p>La differenza? <strong>Reputazione intatta e conformit\u00e0 CRA provata<\/strong>.<\/p>\n<h2>VDP Tooling Setup: Infrastruttura Tecnica<\/h2>\n<h3>Email Security per il Canale VDP<\/h3>\n<p>L&#8217;email `security@vostro-dominio` non pu\u00f2 essere una casella normale:<\/p>\n<ul>\n<li><strong>SPF Record<\/strong>: <code>v=spf1 include:sendgrid.net ~all<\/code> (se usi SendGrid)<\/li>\n<li><strong>DKIM<\/strong>: Firma tutti gli outbound emails<\/li>\n<li><strong>DMARC<\/strong>: <code>p=quarantine<\/code> per prevenire spoofing<\/li>\n<li><strong>Forwarding Encrypted<\/strong>: Se forwardi a Jira\/ticket system, usa un gateway TLS<\/li>\n<li><strong>Backup**: Due-recipient forwarding nel caso il primo recipient \u00e8 offline<\/li>\n<\/ul>\n<h3>Dashboard VDP Centralizzato<\/h3>\n<p>Vi consiglio di integrare Patchstack con Slack per notifiche real-time quando segnalazioni arrivano:<\/p>\n<pre><code>curl -X POST https:\/\/hooks.slack.com\/services\/YOUR\/WEBHOOK\/URL \n  -H 'Content-Type: application\/json' \n  -d '{\n    \"text\": \"\ud83d\udea8 New VDP Report: [CVE Severity] [Plugin Name]\",\n    \"blocks\": [\n      {\n        \"type\": \"section\",\n        \"text\": {\n          \"type\": \"mrkdwn\",\n          \"text\": \"*Vulnerability Submission*nSeverity: HighnReceived: 2026-07-11\"\n        }\n      }\n    ]\n  }'\n<\/code><\/pre>\n<h3>Reporting Automatico ENISA (da Settembre 2026)<\/h3>\n<p>ENISA fornisce una Single Reporting Platform (SRP) dove dovete inviare i report per vulnerabilit\u00e0 gravi. Patchstack integra questo automaticamente, ma se andate solo, dovete:<\/p>\n<ol>\n<li>Creare account su SRP ENISA (https:\/\/www.enisa.europa.eu\/)<\/li>\n<li>Generare segnalazioni in formato XML\/JSON secondo schema CRA<\/li>\n<li>Inviare entro i deadline (24h early warning, 72h detailed report)<\/li>\n<\/ol>\n<h2>Link Interni Pertinenti<\/h2>\n<p>Se lavorate anche su compliance pi\u00f9 ampia, vi suggerisco di leggere i miei articoli su argomenti correlati:<\/p>\n<ul>\n<li><a href=\"https:\/\/darioiannascoli.it\/blog\/ai-compliance-governance-agosto-2026-risk-assessment-audit-logging-pmi\/\">AI Compliance Governance Automatico Post-EU AI Act<\/a>: Come estendere la compliance anche a componenti AI nei vostri plugin<\/li>\n<li><a href=\"https:\/\/darioiannascoli.it\/blog\/plesk-log-aggregation-elastic-splunk-logstash-malware-detection-multi-tenant\/\">Come Collegare Plesk a Elastic, Splunk e Logstash<\/a>: Se hostingProvider, dovete loggare tutti gli incident legati ai plugin<\/li>\n<li><a href=\"https:\/\/darioiannascoli.it\/blog\/mu-plugins-backdoor-prevention-directory-hardening-hash-verification-incident-response\/\">Come Prevenire e Rilevare Backdoor MU-Plugins<\/a>: Protezione complementare per WordPress multisite<\/li>\n<\/ul>\n<h2>FAQ<\/h2>\n<h3>Se il mio plugin \u00e8 gratis, devo comunque avere un VDP?<\/h3>\n<p>Dipende. <cite>A commercial WordPress plugin may fall within the scope of the Cyber Resilience Act (CRA). The analysis depends on its distribution model, its features, its level of risk, and its availability on the European market. Non-commercial open source software is not directly subject to the same obligations. However, when an open source component is integrated into a commercial product, the manufacturer or publisher of the product must manage the obligations provided for by the CRA.<\/cite> Se il plugin \u00e8 completamente open-source non commerciale (tipo sotto GPL), no. Se per\u00f2 \u00e8 gratis ma dentro una suite a pagamento, o ha una versione premium, allora s\u00ec.<\/p>\n<h3>Posso usare il tempo per il 24-hour early warning anche se sono una piccola azienda?<\/h3>\n<p><cite>Manufacturers that qualify as microenterprises or small enterprises may not be fined for failures to meet the 24h deadline for reporting vulnerabilities and severe incidents<\/cite>. S\u00ec, se siete sotto 10 dipendenti, il first 24h \u00e8 waived, ma il 72-hour notification \u00e8 obbligatorio comunque. Suggerisco di farli comunque in 24h per reputation.<\/p>\n<h3>Che cos&#8217;\u00e8 esattamente CVSS e come lo calcolo per il mio plugin?<\/h3>\n<p>CVSS (Common Vulnerability Scoring System) \u00e8 uno standard per assegnare severit\u00e0 numerica (0-10) alle vulnerabilit\u00e0. Usate la versione 3.1 online su https:\/\/www.first.org\/cvss\/calculator\/3.1. Esempi rapidi: <em>Reflected XSS in form field = 6.1 (Medium)<\/em>, <em>Unauthenticated RCE = 9.8 (Critical)<\/em>. La piattaforma VDP vi aiuta a calcolarlo.<\/p>\n<h3>Se ricevo una segnalazione, devo comunicarla anche ai miei clienti?<\/h3>\n<p>S\u00ec. Se la vulnerabilit\u00e0 \u00e8 in versioni gi\u00e0 distribuite, dovete notificare gli utenti quando fate il patch (via email newsletter, announcement in WordPress plugin update description). Non dovete dare dettagli tecnici, solo &#8220;security patch &#8211; update immediately&#8221;.<\/p>\n<h3>Cosa succede se non mi conformo al CRA entro i deadline?<\/h3>\n<p><cite>Administrative fines may reach up to \u20ac15 million or 2.5% of the total worldwide annual turnover of the preceding financial year, whichever is higher, for non-compliance with the essential cybersecurity requirements set out in Annex I and the related obligations imposed on manufacturers.<\/cite> Anche per i plugin. Serio.<\/p>\n<h2>Conclusione<\/h2>\n<p>La conformit\u00e0 al Cyber Resilience Act per plugin WordPress non \u00e8 una burocrazia fastidiosa\u2014\u00e8 <strong>una necessit\u00e0 di business<\/strong> se operate in Europa dopo settembre 2026. Ho trasformato questo da &#8220;cosa che dobbiamo fare&#8221; a un processo automatizzato che richiede <em>quasi zero overhead manuale<\/em> una volta configurato.<\/p>\n<p>La mia checklist di 7 step copre tutto: <strong>SBOM, Security Policy, CI\/CD scanning automatico, Plugin Check, VDP platform, triage process, documentation<\/strong>. Se partite oggi e implementate step by step, sarete pronti quando scatta l&#8217;obbligo a settembre.<\/p>\n<p><strong>Il vantaggio competitivo?<\/strong> Potrete vantare di essere <em>&#8220;Cyber Resilience Act Compliant&#8221;<\/em> nel vostro marketing. I clienti enterprise lo chiederanno sempre pi\u00f9 frequentemente.<\/p>\n<p><strong>Avete domande sul VDP o trovate difficile implementare l&#8217;automazione?<\/strong> Condividete nei commenti. Sono qui per aiutare.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Implementa la conformit\u00e0 CRA per plugin WordPress con VDP, scanning automatico e tooling ENISA. La mia procedura pratica step-by-step per rispettare i deadline settembre 2026.<\/p>\n","protected":false},"author":1,"featured_media":2763,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"VDP Compliance CRA WordPress Plugin | Checklist Cyber Resilience Act","_seopress_titles_desc":"Guida pratica per conformit\u00e0 Cyber Resilience Act plugin WordPress. VDP setup, automated scanning, ENISA reporting. Scopri la mia checklist 7-step per settembre 2026.","_seopress_robots_index":"","footnotes":""},"categories":[2],"tags":[455,452,474,454,548,237],"class_list":["post-2762","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-wordpress","tag-cra-compliance","tag-cyber-resilience-act","tag-plugin-development","tag-sbom","tag-vulnerability-management","tag-wordpress-security"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/2762","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=2762"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/2762\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/2763"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=2762"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=2762"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=2762"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}