WordPress 7.0 Plugin Vulnerability Disclosure Program Compliance EU: La Mia Checklist Cyber Resilience Act, Automated Scanning Integration e VDP Tooling Setup

Se gestisci plugin WordPress commerciali distribuiti nel mercato europeo, devi sapere che a partire dal 11 settembre 2026 la conformità al Cyber Resilience Act (CRA) diventa un obbligo legale con obblighi di segnalazione delle vulnerabilità. 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.

In questo articolo vi mostro come ho strutturato una procedura completa di compliance VDP (Vulnerability Disclosure Program) per i miei clienti plugin developer, integrando scanning automatico, gestione delle segnalazioni e reportistica ENISA secondo i nuovi standard EU.

Perché il VDP è diventato obbligatorio per i plugin WordPress

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. Il Cyber Resilience Act non è una semplice raccomandazione: è una normativa vincolante dell’UE che definisce obblighi specifici per chiunque distribuisca software con componenti digitali in Europa.

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. Il primo milestone è già qui: The reporting obligations for actively exploited vulnerabilities and serious incidents apply starting September 11, 2026.

Se il vostro plugin è commerciale—cioè distribuito a pagamento o con modello freemium—e raggiungibile da utenti europei, dovete conformarvi a prescindere dalla vostra ubicazione legale. Non è facoltativo.

La Timeline CRA e cosa fare adesso

La normativa ha una roadmap ben definita di cui devo parlare chiaramente perché tante aziende ancora non l’hanno recepita:

• 11 giugno 2026: Gli organismi di valutazione della conformità devono essere notificati (vi riguarda solo indirettamente)
• 11 settembre 2026: Scatta l’obbligo di reporting per vulnerabilità sfruttate attivamente e incident gravi
• 11 dicembre 2027: Piena applicazione di tutti gli obblighi CRA

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.

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ù di una scappatoia legale.

Checklist CRA Compliance per Plugin WordPress: I Miei 7 Step

1. Inventario Software Bill of Materials (SBOM)

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’une vulnerability affects a third-party component. Nella mia procedura, genero un SBOM in formato CycloneDX JSON con ogni release del plugin.

Ho automatizzato questo con uno script che analizzo le dipendenze PHP tramite Composer:

php composer.phar show --direct -f json > sbom-dependencies.json

Includo anche le dipendenze JavaScript se il plugin carica librerie esterne da npm. Questo SBOM vi servirà anche per il tracking delle vulnerabilità nelle vostre dipendenze.

2. Definire la Security Policy e il Canale VDP

Ho creato un file SECURITY.md nella root del repository del plugin con:

• Email dedicata per segnalazioni: security@vostrodominio.it (con SPF/DKIM configurati)
• Tempo massimo di risposta: 72 ore per conferma ricezione
• Processo di triage e patch
• Divulgazione responsabile: minimo 90 giorni prima della disclosure pubblica
• Link a piattaforma VDP formale (es. HackerOne, Patchstack mVDP, o custom)

Consiglio fortemente di usare una piattaforma dedicata come Patchstack che offre managed VDP gratuiti per plugin WordPress con integrazione con il loro database di vulnerabilità.

3. Implementare Automated Security Scanning nel CI/CD

Ho integrato nel mio pipeline GitHub Actions una catena di scanner automatici che corre su ogni commit e pull request:

name: Security Scanning
on: [push, pull_request]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      # Semgrep: SAST statico per PHP
      - name: Run Semgrep
        uses: returntocorp/semgrep-action@v1
        with:
          config: p/security-audit
          
      # WPScan CLI per vulnerabilità note
      - name: WPScan Vulnerability Check
        run: |
          npm install -g wpscan
          wpscan --url . --format json --output wpscan-report.json
          
      # Snyk per dipendenze compromesse
      - name: Snyk Security Check
        uses: snyk/actions/php@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
          
      # Upload reports
      - name: Upload SARIF Report
        uses: github/codeql-action/upload-sarif@v2
        with:
          sarif_file: results.sarif

Questo setup mi permette di rilevare automaticamente molte classi di vulnerabilità (XSS, SQL injection, insecure deserialization) prima che raggiungano produzione.

4. Configurare Plugin Check Automation su WordPress.org

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.

Questo significa che WordPress.org fornisce scanning automatico gratuito per il vostro plugin. Dovete però assicurare che il vostro codice passi i controlli:

• Nessuna funzione deprecated
• Escaping corretti su output (`esc_html()`, `esc_attr()`, etc.)
• Nessun file o funzione sospetta
• Struttura plugin conforme agli standard WordPress

Consiglio di eseguire Plugin Check localmente prima di ogni release:

wp plugin install plugin-check --activate
wp plugin-check check ./mio-plugin --output=json > plugin-check-report.json

5. Setup della Piattaforma VDP Formale (Patchstack mVDP)

Ho scelto Patchstack managed VDP program – Ensure compliance with the Cyber Resilience Act, and outsource vulnerability report validation & rewards.

Cosa vi fornisce Patchstack mVDP:

• Numero dedicato per ricevere segnalazioni (triaged e validate da loro)
• Dashboard con cronologia vulnerabilità
• Email alerts quando ricevono segnalazioni
• Integrazione diretta con il database di vulnerabilità Patchstack (visibile a tutti i clienti che usano Patchstack plugin)
• Compliance CRA automatica: Patchstack gestisce il logging e la documentazione per ENISA

Setup è semplicissimo: andate su https://patchstack.com/database/vdp e richiedete un VDP gratuito per il vostro plugin.

6. Implementare il Processo di Triage e Patch Interno

Anche se Patchstack valida le segnalazioni, dovete avere un processo interno robusto:

• Ricezione: Email security@vostro-dominio entra in ticket system (io uso Jira)
• Conferma entro 24 ore: “Grazie, abbiamo confermato la ricezione. Verrà analizzato entro 72 ore”
• Severity Assessment (entro 72 ore): Critical/High/Medium/Low (use CVSS 3.1)
• Patch Development: Se High/Critical, dovete mettere in priorità
• Release Candidate Testing: Almeno 48 ore di testing before release
• Public Disclosure: Pubblicate il patch su WordPress.org, GitHub tag, e notificate ENISA se obbligatorio

Io ho creato un template Jira workflow che rispetta automaticamente i deadline CRA.

7. Documentazione Tecnica (Article 31 CRA)

Compile complete technical documentation in accordance with Article 31. Dovete documentare:

• Threat Modeling: Quali sono i possibili attack vector?
• Security Architecture: Come proteggi dati sensibili?
• Vulnerability Assessment Process: Come le buche vengono trovate e risolte?
• Update & Support Period: Per quanto tempo supporterai il plugin con patch?
• Supply Chain Risk: Dipendenze da terzi come vengono valutate?

Formato consigliato: Markdown o PDF in repo, linkato da SECURITY.md.

Integrare Automated Scanning nel Vostro Flusso Operativo

Una checklist non basta: serve automazione. Nella mia esperienza, ho configurato un sistema di scanning continuativo che monitora:

1. Pre-commit Hooks: Semgrep localmente prima che i developer pushino
2. CI/CD Pipeline: WPScan + Snyk + PHPSTAN su GitHub Actions
3. Scheduled Scans: Ogni notte, scan su dependencies fresh da npm/composer registries
4. Vulnerability Aggregation: Un dashboard centralizzato che raccoglie problemi da tutti i scanner

Su questo tema, rimando al mio articolo precedente su Ransomware Orchestrated Multi-Vector Detection dove spiego come aggregare log di sicurezza in un SIEM—lo stesso approccio vale per il vulnerability scanning di plugin.

Scenari Reali: Quando Ho Dovuto Implementare Questo

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 SQL injection nei filter di ricerca prodotti. Il cliente non aveva VDP configurato, quindi:

• Il researcher ha divulgato la buca pubblicamente subito
• In 48 ore aveva exploit disponibili
• 15 siti erano compromessi
• Perdita reputazionale enorme

Dopo questo, ho implementato il sistema che descrivo sopra. Sei mesi dopo, un’altra ricerca ha trovato un XSS stored 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.

La differenza? Reputazione intatta e conformità CRA provata.

VDP Tooling Setup: Infrastruttura Tecnica

Email Security per il Canale VDP

L’email `security@vostro-dominio` non può essere una casella normale:

• SPF Record: v=spf1 include:sendgrid.net ~all (se usi SendGrid)
• DKIM: Firma tutti gli outbound emails
• DMARC: p=quarantine per prevenire spoofing
• Forwarding Encrypted: Se forwardi a Jira/ticket system, usa un gateway TLS
• Backup**: Due-recipient forwarding nel caso il primo recipient è offline

curl -X POST https://hooks.slack.com/services/YOUR/WEBHOOK/URL 
  -H 'Content-Type: application/json' 
  -d '{
    "text": "🚨 New VDP Report: [CVE Severity] [Plugin Name]",
    "blocks": [
      {
        "type": "section",
        "text": {
          "type": "mrkdwn",
          "text": "*Vulnerability Submission*nSeverity: HighnReceived: 2026-07-11"
        }
      }
    ]
  }'