Come generare la SBOM di un sito Drupal con DruBOM per il CRA?

Chi gestisce o distribuisce siti Drupal enterprise ha ora uno strumento open source per produrre e mantenere la distinta base del software direttamente nel CMS. Dopo la lettura potrai valutare se DruBOM è adatto al tuo stack, quali prerequisiti richiede e dove si colloca rispetto agli obblighi del Cyber Resilience Act.

Il 12 ottobre 2026 è uscita DruBOM 1.0.0-beta2. È il modulo open source ideato da Paolo Mainardi, CTO di SparkFabrik, e riscritto da zero in PHP nativo. Il rilascio arriva un mese dopo una scadenza concreta: dall'11 settembre 2026 sono in vigore gli obblighi di segnalazione dell’articolo 14 del Cyber Resilience Act (CRA, Regolamento UE 2024/2847). Al centro di entrambi c’è la SBOM (Software Bill of Materials), cioè la distinta base del software: l’elenco leggibile dalle macchine dei componenti e delle versioni che formano un prodotto.

Inoltre, con la 1.0.0-beta3, uscita il 25 ottobre, DruBOM include nella SBOM anche il runtime PHP e lo confronta con le advisory di sicurezza del progetto PHP. Il rilascio arriva pochi giorni dopo due CVE critiche di PHP, la CVE-2026-109618 e la CVE-2026-109619, che consentono l’esecuzione remota di codice senza autenticazione sui server non aggiornati.

Un preallarme entro 24 ore su una vulnerabilità attivamente sfruttata richiede di sapere in pochi minuti se quel pacchetto gira sul tuo sito. Su Drupal questo significa attraversare le dipendenze Composer, i moduli contrib, i temi custom con le loro dipendenze npm e le librerie di asset dichiarate nei file di definizione. I punti operativi sono quattro: cosa fa il modulo, come si adotta su Drupal 11.3 o Drupal 12, quali limiti ha in fase beta e come è stato costruito con agenti AI sotto supervisione umana.

Perché la SBOM di un sito Drupal va gestita dentro il CMS?

Uno scanner di container o di pipeline vede file e pacchetti. Non sa però quale modulo Drupal ha introdotto una libreria, né se una dipendenza è solo dichiarata o realmente installata. DruBOM legge il sito dal punto di vista di Drupal: collega ogni componente al progetto che lo porta e restituisce un inventario che conserva le relazioni tra le parti.

Un sito Drupal enterprise contiene dipendenze di natura diversa:

• pacchetti Composer;

• moduli, temi e profili;

• librerie di asset dichiarate nei file di definizione;

• dipendenze npm, Yarn e pnpm dentro i temi custom.

Uno scanner generico restituisce un elenco piatto. Ti dice che una libreria vulnerabile esiste, ma non chi l’ha portata e quindi dove intervenire.

Prendiamo un portale e-commerce costruito con Drupal Commerce. Lo scenario tipico riguarda i moduli contrib che integrano un gateway di pagamento: il modulo richiede l’SDK PHP del gateway, che a sua volta richiede Guzzle (guzzlehttp/guzzle), la libreria HTTP più diffusa nell’ecosistema Composer. Guzzle arriva quindi come dipendenza transitiva a due livelli di distanza dal composer.json del progetto. Quando esce un advisory su Guzzle, come quelli pubblicati nel 2022 sulla gestione di cookie e header nei redirect, lo scanner segnala la libreria ma non dice cosa fare: aggiornare il modulo, forzare la versione con un vincolo esplicito, applicare una patch o aspettare che il maintainer dell’SDK rilasci una release compatibile.

Lo stesso accade su un’extranet o su un portale riservato. Ad esempio, un modulo di autenticazione SAML come samlauth si appoggia a onelogin/php-saml, che porta con sé robrichards/xmlseclibs per la firma e la cifratura XML, e un modulo OpenID Connect dipende da librerie di terze parti per validare i token.

Il CRA fissa tre scadenze:

• 10 dicembre 2024: entrata in vigore del regolamento.

• 11 settembre 2026: obblighi di notifica dell’art. 14 per le vulnerabilità attivamente sfruttate. Il preallarme va inviato entro 24 ore, la notifica entro 72 ore e il rapporto finale entro 14 giorni.

• 11 dicembre 2027: piena applicazione di tutti i requisiti.

Il regolamento chiede una SBOM in formato leggibile dalle macchine che copra almeno le dipendenze di primo livello (allegato I, parte II). La SBOM va conservata nella documentazione tecnica prevista dall’allegato VII e consegnata alle autorità su richiesta, senza obbligo di pubblicazione. Per la violazione dei requisiti essenziali le sanzioni arrivano a 15 milioni di euro o al 2,5% del fatturato mondiale annuo.

Ma attenzione: il CRA si applica ai fabbricanti che immettono sul mercato prodotti con elementi digitali nel corso di un’attività commerciale. Un sito istituzionale o un SaaS puro in genere ne resta fuori (ma può ricadere sotto NIS2), salvo i casi di elaborazione remota dei dati legata a un prodotto. È una distinzione che abbiamo esaminato analizzando perimetro e responsabilità del fabbricante. Rientrano invece nel perimetro le software house e i vendor che distribuiscono prodotti basati su Drupal, come distribuzioni, piattaforme white-label e soluzioni installate presso il cliente. Le fondazioni che sostengono progetti open source hanno un regime alleggerito, quello dello steward open source.

Per chi gestisce siti propri, la pressione arriva da altre fonti. La prima è la NIS2, che all’articolo 21 impone misure di sicurezza sulla supply chain. La seconda sono i requisiti contrattuali dei clienti in finanza, sanità e pubblica amministrazione, che chiedono un inventario delle dipendenze in fase di gara o di audit.

Cosa fa DruBOM: inventario, vulnerabilità, VEX ed export SPDX

DruBOM genera l’inventario completo del sito, runtime PHP compreso, e lo confronta con fonti di vulnerabilità pubbliche ed europee. Registra poi le decisioni VEX (Vulnerability Exploitability eXchange) con il relativo storico ed esporta tutto in SPDX 3.0.1. Ogni operazione è disponibile dall’interfaccia di amministrazione di Drupal o da Drush.

Il legame più diretto con il CRA passa da ENISA EUVD, il database europeo delle vulnerabilità, e dal catalogo CISA KEV (Known Exploited Vulnerabilities). L’art. 14 riguarda proprio le vulnerabilità attivamente sfruttate, quindi la status card risponde alla stessa domanda a cui devi rispondere entro 24 ore. Il VEX aggiunge alla mappatura dei rischi delle dipendenze ciò che gli scanner non forniscono: chi ha giudicato non sfruttabile una CVE presente nella SBOM, quando lo ha fatto e con quale motivazione.

Il CRA non impone un formato specifico. SPDX della Linux Foundation e CycloneDX di OWASP, standard Ecma ECMA-424, sono entrambi leggibili dalle macchine. A ottobre 2026 gli standard armonizzati che preciseranno i requisiti sono ancora in fase di definizione.

Quando non riesce a inventariare un componente, DruBOM lo registra come coverage gap e assegna a ogni controllo uno stato esplicito: analizzato, non verificabile oppure nessun dato disponibile. Anche un’estensione PHP richiesta da Composer ma non caricata viene segnalata come coverage gap. Il confronto con le fonti di vulnerabilità esterne è opt-in, e i pacchetti dei repository privati non vengono mai inviati. In sanità, finanza e PA, sapere cosa non è stato verificato conta quanto l’elenco delle CVE. The Drop Times ha dedicato alla release un approfondimento centrato sulla dependency map.

Il caso delle due CVE di PHP mostra come funziona il controllo sul runtime. Sul sito di test del team, con PHP 8.3.15, entrambe compaiono come vulnerabilità critiche accanto a quelle Drupal e npm, nella stessa status card, nel workflow VEX e nell’export SPDX. Il confronto avviene per ramo: una 8.4 già aggiornata non viene segnalata per la fix della 8.5. Un’advisory su un’estensione, come SOAP, o su PHP-FPM conta solo se quella parte è in uso. Se un’advisory non è confrontabile, il controllo risulta parziale e mai superato.

Come si genera e si mantiene la SBOM con DruBOM?

Parti dalla versione del core: DruBOM richiede Drupal 11.3 o Drupal 12, e la procedura qui sotto porta a una SBOM in SPDX 3.0.1 che si aggiorna a ogni rilascio.

1. Verifica il core: controlla di essere su Drupal 11.3 o su Drupal 12. Se il sito è ancora su Drupal 10, serve prima l’upgrade.
2. Installa con Composer: aggiungi drupal/drubom in versione beta e abilitalo.
3. Configura il file system privato: gli snapshot dell’inventario vengono salvati lì, fuori dalla document root.
4. Genera il primo snapshot: puoi farlo dall’interfaccia di amministrazione o da Drush. Prediligi l’ambiente in cui gira il PHP del sito, perché Drush e il web server possono usare build diverse. Prima di tutto, leggi i coverage gap.
5. Attiva il controllo delle advisory: il controllo è opt-in, e le advisory PHP si abilitano a parte nelle impostazioni (“PHP security advisories”). Da qui alimenti la status card e il workflow VEX.
6. Esporta e automatizza: scarica la SBOM in SPDX 3.0.1 e aggiungi il controllo Drush alla pipeline. Il job fallisce quando le vulnerabilità aperte raggiungono la soglia di severità che hai fissato, oppure quando l’inventario risulta incompleto.

Il sesto passo è quello che regge nel tempo. Una SBOM generata una sola volta descrive il sito di quel giorno. Collegata a una pipeline GitLab CI, GitHub Actions o Tekton, invece, si rigenera a ogni rilascio. È il principio di Security Enablement che applichiamo nei progetti di supply chain security: il controllo entra nel flusso che lo sviluppatore usa già, senza un gate manuale aggiunto a valle.

Il modulo è in beta e non copre ancora tutti i casi. In particolare esclude i siti su Drupal 10, il cui supporto di sicurezza termina a dicembre 2026 secondo il calendario di Drupal.org, quindi l’upgrade di versione va comunque messo in agenda. Provalo in staging prima di portarlo in produzione. E non chiedergli il lavoro dell’infrastruttura, perché DruBOM non sostituisce la scansione delle immagini container.

In un cluster Kubernetes, infatti, la SBOM applicativa di DruBOM va affiancata a quella dell’immagine. Quest’ultima si genera in pipeline con Syft o Trivy e si firma come attestazione con Sigstore, così la SBOM consegnata all’auditor ha una provenienza verificabile. Il livello applicativo copre i moduli e i temi npm che lo scanner d’immagine vede come file sparsi. Il livello infrastrutturale copre il sistema operativo di base e i pacchetti di sistema. A partire dalla beta3, anche il runtime PHP e le sue estensioni compaiono nella SBOM di DruBOM. A questi si sommano gli errori di sicurezza e governance nell’adozione di Kubernetes, che nessuna SBOM intercetta.

Come è stato riscritto DruBOM: agenti AI e supervisione umana

DruBOM nasce nell’ottobre 2023 come piccolo modulo a supporto di un talk sulla Software Supply Chain Security a DrupalCon Lille. Nel 2024 il progetto è stato raccontato sul blog di OpenSSF. Quella prima versione era un wrapper di Anchore Syft.¹1 DruBOM (Drupal Bill of Material) è un modulo open source di SparkFabrik per generare una Software Bill Of Materials (SBOM) completa per un’installazione Drupal, incluse tutte le dipendenze PHP e le librerie di altri ecosistemi, come le dipendenze JavaScript. La versione del 2023 integrava Anchore Syft. Dalla 1.0.0-beta2 il modulo funziona in PHP nativo, senza binari esterni. (fonti: Open Source, OpenSSF, Drupal.org) Richiedeva il binario Syft installato sul server e quindi l’abilitazione in PHP di funzioni come proc_open, con rischi simili a quelli di exec. L’interfaccia mostrava un conteggio dei pacchetti e un JSON grezzo. Paolo ricorda che, all’epoca, Copilot in VS Code “sembrava magia”.

La 1.0.0-beta2 è stata riscritta da zero in PHP nativo. Il punto interessante è il metodo, cioè l’AI Native Engineering. Paolo Mainardi ha orchestrato gli agenti AI Claude e Codex da sessioni remote, mentre aspettava il volo di ritorno dall’Open Source Summit di Praga. Perimetro, UX, architettura e ogni merge sono rimasti decisioni umane.

Il risultato: oltre 300 test automatici e circa 34.000 righe tra codice, test e documentazione. Dal primo commit alla beta2 sono passate meno di 48 ore. La velocità va di pari passo alla robustezza, con quattro meccanismi di controllo:

• Test prima della fix: ogni test di regressione viene dimostrato in fallimento prima della correzione.

• CI riprodotta in locale: l’intera pipeline CI di Drupal.org viene eseguita in locale prima di ogni push.

• Test browser su siti reali: l’interfaccia viene verificata con i temi di amministrazione Claro, Gin 4 e Gin 5.

• Agente di revisione indipendente: un secondo agente esamina le modifiche prima del merge.

Per un CTO, la parte trasferibile riguarda il sistema di controllo più che la velocità. Il modello human-in-the-loop usato qui combina test che falliscono prima della fix, CI riprodotta, review indipendente e merge umano. È lo stesso modello che regge una supply chain sicura: il codice scritto da un agente entra nella catena di fornitura e va verificato come qualsiasi dipendenza. Lo stiamo applicando anche al nuovo approccio agentic-first nello sviluppo Drupal, dove l’architettura resta una responsabilità umana.

Anche il formato collega i due temi. Secondo la Linux Foundation, SPDX 3.0 introduce profili dedicati a modelli AI e dataset. Lo stesso standard che DruBOM esporta può quindi descrivere le funzionalità AI integrate in un sito Drupal, per esempio un assistente basato su un modello linguistico.

Questo modo di lavorare porta con sé nuovi rischi da prendere in carico, a cominciare dalla verifica di ciò che gli agenti producono.

Da dove partire se gestisci siti Drupal soggetti al CRA

Il primo passo è stabilire se la tua organizzazione è un fabbricante ai sensi del CRA o se è soggetta alla NIS2. Poi verifichi la versione di Drupal e generi un primo snapshot DruBOM in staging. In questo modo misuri i coverage gap con anticipo sulla piena applicazione del regolamento, fissata all'11 dicembre 2027.

Se distribuisci prodotti basati su Drupal nel mercato UE, gli obblighi di notifica sono attivi dall'11 settembre 2026, mentre la SBOM nella documentazione tecnica diventa obbligatoria dall'11 dicembre 2027. Se invece gestisci siti propri in un settore NIS2, la SBOM ti serve per documentare le misure sulla supply chain. In entrambi i casi conviene avviare l’inventario prima dell’upgrade, anche inserendo Syft in pipeline se il sito è ancora su Drupal 10. Così la migrazione diventa anche l’occasione per eliminare le dipendenze superflue.

1. Versione del core: pianifica il passaggio a Drupal 11.3 o Drupal 12 e fissa una data.
2. Primo snapshot e coverage gap: genera l’inventario in staging e annota cosa resta non verificabile.
3. Controllo in pipeline: integra il controllo Drush nel rilascio e aggiungi la SBOM dell’immagine firmata con Sigstore.

SparkFabrik affianca le aziende su diversi livelli, dall’upgrade a Drupal 11 o 12 e l’integrazione di funzionalità AI fino all’integrazione della SBOM nelle pipeline CI/CD e alla firma degli artefatti. Per i siti Drupal già in produzione si può partire da un audit che analizza performance, sicurezza e architettura e individua le priorità prima dell’upgrade. Il modulo DruBOM è open source e mantenuto dal nostro team su Drupal.org.²2 DruBOM è disponibile su drupal.org all’indirizzo drupal.org/project/drubom con licenza open source. È sviluppato e mantenuto da Paolo Mainardi e altri sviluppatori di SparkFabrik, Marco Primitivo e Luca Lusso. (fonte: Open Source) Se vuoi impostare questo percorso sul tuo stack, parla con il nostro team di supply chain security.

Note e fonti