Cyber Resilience Act in pratica per una piccola software house

Dall'11 settembre 2026 l'articolo 14 del Cyber Resilience Act, il Regolamento (UE) 2024/2847, non è più una scadenza futura: è diritto applicabile. Se la tua software house viene a conoscenza di una vulnerabilità attivamente sfruttata in un prodotto che ha immesso sul mercato, ha 24 ore per inviare un early warning attraverso la piattaforma unica europea gestita da ENISA, 72 ore per la notifica completa e 14 giorni dalla disponibilità della correzione per il report finale. Il regolamento è in vigore dal 10 dicembre 2024, ma il grosso degli obblighi (requisiti essenziali, valutazione di conformità, marcatura CE) si applicherà dall'11 dicembre 2027: ed è proprio questa distanza a generare l'equivoco più pericoloso che incontro nelle PMI del software. Si legge "2027" e si archivia la pratica, mentre l'obbligo di segnalazione è già operativo, e riguarda anche i prodotti che stanno sul mercato da anni, non solo quelli nuovi. In un recente progetto di adeguamento normativo per un'azienda del settore servizi digitali ho misurato quanto costa colmare il divario partendo da zero: non settimane di lavoro, ma nemmeno ore. È una procedura, e come tutte le procedure si costruisce una volta e si mantiene. In questo articolo la percorro passo per passo, nella forma che uso davvero: policy di coordinated vulnerability disclosure, file security.txt, triage interno con il clock delle 24 ore, e SBOM generata in automatico dalla CI.

Cosa è già in vigore del Cyber Resilience Act, e cosa arriva a dicembre 2027?

La risposta breve: dall'11 settembre 2026 sono vigenti solo gli obblighi di segnalazione dell'articolo 14, ma valgono per tutti i fabbricanti di prodotti con elementi digitali già sul mercato UE. Tutto il resto, cioè i requisiti essenziali di sicurezza dell'Allegato I, la gestione documentata delle vulnerabilità, la valutazione di conformità e la marcatura CE, diventa applicabile l'11 dicembre 2027, come indica la pagina ufficiale della Commissione europea sul regolamento.

Il punto che una piccola software house deve mettere a fuoco è il perimetro. Il CRA parla di "prodotti con elementi digitali": la formula copre l'hardware connesso, ma anche il software commerciale distribuito come prodotto. Il gestionale che vendi con licenza, il modulo e-commerce che installi presso i clienti, l'app mobile pubblicata sugli store: tutto questo ti rende fabbricante ai sensi del regolamento, con gli obblighi che ne seguono. Ne resta in larga parte fuori il puro SaaS erogato come servizio (che ricade semmai nel perimetro NIS2, su cui il discorso è diverso), mentre i casi ibridi, come un prodotto installato che dipende da un backend remoto per funzionare, vanno valutati sul testo del Regolamento (UE) 2024/2847, non sulle sintesi di terzi. L'errore che vedo più spesso è il ragionamento per esclusione: "non facciamo IoT, quindi il CRA non ci riguarda". Falso. Se distribuisci software nell'ambito di un'attività commerciale, il regolamento ti riguarda, e la parte che ti riguarda per prima è già attiva.

Mi occupo di adeguamenti normativi dal lato tecnico, non da quello legale: NIS2, GDPR e ora CRA visti da chi poi deve implementare i controlli, non solo scriverli su un documento. Nel mio profilo professionale trovi il perimetro esatto di questo lavoro, che parte sempre dallo stesso principio: la compliance che non si traduce in procedure eseguibili è carta.

Passo 1: la policy di coordinated vulnerability disclosure

La coordinated vulnerability disclosure (CVD) è il processo con cui un ricercatore di sicurezza, un cliente o un integratore ti segnala una vulnerabilità in modo ordinato, dandoti il tempo di correggerla prima della divulgazione pubblica. L'Allegato I del CRA la richiederà formalmente dal dicembre 2027, ma costruirla adesso non è zelo: è la mossa che rende gestibile l'obbligo già vigente.

Una CVD policy non è un adempimento: è il canale che ti fa scoprire la vulnerabilità da un ricercatore che collabora, invece che dallo sfruttamento attivo in produzione, quando il clock delle 24 ore è già partito.

La policy che scrivo per i clienti sta in una pagina e contiene sei elementi. Il canale di contatto: una casella dedicata (security@), non il form commerciale, presidiata con un SLA interno di prima risposta (48 ore lavorative è un impegno onesto per una struttura piccola). Lo scope: quali prodotti e versioni sono coperti, cosa è fuori perimetro (ambienti demo, sistemi di terzi). Le regole di ingaggio: cosa chiedi al segnalante, per esempio di non esfiltrare dati reali e di non degradare il servizio. L'impegno di safe harbor: la dichiarazione che non agirai legalmente contro chi segnala in buona fede rispettando le regole; senza questa frase, metà dei ricercatori seri non ti scrive nemmeno. I tempi: entro quanto confermi la ricezione, entro quanto dai una prima valutazione, come coordini la divulgazione. Il riconoscimento: se prevedi o meno una hall of fame o un ringraziamento pubblico (una piccola software house non ha bisogno di un bug bounty a premi: serve chiarezza, non budget).

Il documento va pubblicato a un URL stabile e leggibile, tipo /security/cvd-policy, in italiano e in inglese. La versione inglese non è un vezzo: la maggior parte delle segnalazioni spontanee arriva da ricercatori che non parlano italiano, e una policy che non capiscono equivale a una policy che non esiste.

Passo 2: security.txt, il file che dice ai ricercatori dove scriverti

Scritta la policy, bisogna renderla trovabile da chi cerca un contatto di sicurezza in modo automatico. Lo standard è RFC 9116, un file di testo servito su HTTPS al percorso /.well-known/security.txt. È il primo posto dove un ricercatore (e ormai anche parecchi scanner) guarda per capire a chi segnalare. Questo è il file che deployo, adattato a un dominio di esempio:

Contact: mailto:[email protected]
Expires: 2027-10-01T07:00:00.000Z
Preferred-Languages: it, en
Policy: https://www.esempio-sh.it/security/cvd-policy
Canonical: https://www.esempio-sh.it/.well-known/security.txt
Encryption: https://www.esempio-sh.it/security/pgp-key.txt

Tre dettagli che fanno la differenza fra un file conforme e un file decorativo. Primo: Expires è obbligatorio per la RFC e va tenuto entro un anno; un security.txt scaduto comunica esattamente il contrario di ciò che vorresti, cioè che il canale non è presidiato. Il rinnovo va messo a calendario, o meglio ancora sotto monitoraggio automatico insieme al certificato TLS. Secondo: il campo Contact deve puntare a una casella che sopravvive alle persone; l'indirizzo personale del socio tecnico è un single point of failure anche qui. Terzo: la chiave PGP referenziata da Encryption deve essere valida e importabile, perché un segnalante prudente cifrerà il report; una chiave scaduta interrompe la conversazione sul nascere.

Il costo di tutto il passo 2 è di circa un'ora, rinnovi inclusi. È il miglior rapporto costo-beneficio dell'intero adeguamento.

Passo 3: il triage interno che regge il clock delle 24 ore

Qui sta il cuore dell'articolo 14, ed è la parte che nessun template scaricato risolve. L'obbligo scatta su due famiglie di eventi: le vulnerabilità attivamente sfruttate (qualcuno sta usando la falla del tuo prodotto, non solo l'ha trovata) e gli incidenti gravi con impatto sulla sicurezza del prodotto. Per entrambe, la sequenza fissata dalla pagina della Commissione sugli obblighi di segnalazione è: early warning entro 24 ore da quando ne vieni a conoscenza, notifica completa entro 72 ore, report finale entro 14 giorni dalla disponibilità di una misura correttiva per le vulnerabilità sfruttate, ed entro un mese dalla notifica per gli incidenti. Il tutto passa dalla Single Reporting Platform di ENISA, operativa anch'essa dall'11 settembre 2026, che instrada la segnalazione al CSIRT nazionale competente e a ENISA in un colpo solo: una segnalazione, non ventisette. In parallelo, l'articolo 14 impone di informare tempestivamente gli utenti impattati, e la Commissione ha pubblicato a fine luglio 2026 FAQ e guida pratica sull'implementazione, che valgono più di qualunque riassunto di terze parti.

Perché una struttura da cinque, dieci persone regga questi tempi, servono tre cose decise prima dell'evento. La prima è il criterio di classificazione: chi decide se quella segnalazione arrivata alle 23:40 è "sfruttamento attivo" oppure una vulnerabilità teorica che segue il binario ordinario della CVD? Nella procedura che adotto, la decisione spetta a un ruolo nominato (con un sostituto), su una matrice scritta: evidenza di exploitation in the wild, prodotto e versioni coinvolte, esposizione dei clienti. La seconda è la registrazione preventiva sulla piattaforma ENISA: scoprire il funzionamento del portale durante l'incidente è il modo migliore per bruciare le prime sei ore. La terza è il template dell'early warning già pronto: a 24 ore dalla scoperta non hai l'analisi completa, e infatti nessuno te la chiede; l'early warning è un atto sintetico, e averne lo scheletro compilabile in dieci minuti toglie il panico dall'equazione.

Se hai già lavorato sulla NIS2, questa meccanica ti suona familiare: pre-notifica in 24 ore, notifica in 72, relazione finale. La somiglianza è voluta ma i due binari restano distinti, perché la NIS2 guarda alla tua organizzazione e ai tuoi servizi, il CRA guarda al prodotto che distribuisci: puoi essere fuori dal perimetro NIS2 (verificalo in due minuti con la mia autovalutazione NIS2 per PMI) e pienamente dentro l'articolo 14. Sul fronte organizzativo il lavoro fatto per una si riusa per l'altra: la struttura di risposta che descrivo in incident response in 72 ore per applicazioni Laravel e Symfony è la stessa che regge una segnalazione CRA, cambia il destinatario della notifica.

Passo 4: la SBOM in CI, non in un PDF

L'ultimo pezzo della procedura è la software bill of materials: l'inventario leggibile dalle macchine di tutti i componenti che entrano nel tuo prodotto. L'Allegato I la richiederà dal dicembre 2027, e le autorità di vigilanza potranno chiedertela; ma anche qui l'utilità operativa precede l'obbligo, perché senza SBOM il triage del passo 3 si fa alla cieca. Quando esce la notizia di una vulnerabilità critica in una libreria diffusa, la domanda "quali nostri prodotti e quali versioni la includono?" deve avere una risposta in minuti, non in una giornata di grep sui repository.

Gli standard sono due, CycloneDX e SPDX, entrambi accettabili; per l'ecosistema PHP uso CycloneDX, che ha un plugin Composer ufficiale maturo. La generazione è un comando:

composer require --dev cyclonedx/cyclonedx-php-composer
composer CycloneDX:make-sbom --output-format=JSON \
    --output-file=build/sbom.cdx.json

Per la parte frontend, npm ha il supporto nativo dal client 9.5 in poi: npm sbom --sbom-format=cyclonedx produce l'equivalente per l'albero JavaScript. Il punto non è il comando, è dove lo esegui.

Una SBOM generata a mano è vecchia al primo composer update. L'unico posto sensato dove produrla è la pipeline di CI, a ogni release, come artefatto versionato che vive accanto al tag: la release 3.4.1 ha la sua SBOM, per sempre.

Nel progetto di adeguamento che citavo in apertura, questo passo ha rivelato il beneficio collaterale che lo ripaga da solo: generare la SBOM costringe a guardare l'albero delle dipendenze, e lì dentro c'erano pacchetti abbandonati da anni e versioni ferme a major EOL. Per una fotografia immediata dello stato del tuo composer.json puoi usare il mio audit Composer, che evidenzia dipendenze a fine vita e configurazioni mancanti; per il quadro completo su typosquatting, dependency confusion e pinning ho scritto una guida dedicata alla supply chain security con Composer, che della SBOM è il naturale complemento: l'inventario ti dice cosa hai, la supply chain security ti dice come impedire che ci entri robaccia.

Il calendario realistico da qui a dicembre 2027

Messa in piedi la procedura, resta la pianificazione di ciò che il CRA renderà obbligatorio con l'applicazione principale dell'11 dicembre 2027: i requisiti essenziali dell'Allegato I (sicurezza by default, aggiornamenti di sicurezza per un periodo di supporto che di norma non può essere inferiore a cinque anni, gestione documentata delle vulnerabilità), la valutazione di conformità e la marcatura CE del software. Per la gran parte dei prodotti di una piccola software house la strada sarà l'autovalutazione, ma l'autovalutazione presuppone che i requisiti siano davvero implementati: e requisiti come gli aggiornamenti sicuri o l'hardening di default non si improvvisano in un trimestre. La sequenza che raccomando è pragmatica: i quattro passi di questo articolo subito, perché il primo è già legge e gli altri tre lo rendono sostenibile; l'analisi del gap sull'Allegato I entro la prima metà del 2027, riusando quanto già fatto per la checklist di hardening NIS2-ready dove i controlli si sovrappongono; la documentazione tecnica e la conformità formale nella seconda metà, a ridosso della scadenza ma senza corse.

C'è un ultimo argomento, ed è quello che uso quando il titolare mi chiede se ne vale davvero la pena prima delle sanzioni. Una CVD policy pubblica, un security.txt valido e una SBOM per release sono ormai segnali che i clienti enterprise e le stazioni appaltanti guardano nei questionari di qualifica dei fornitori: arrivare all'11 dicembre 2027 con la procedura rodata da un anno significa rispondere "sì, ecco il link" dove i concorrenti allegano dichiarazioni di intenti. La compliance fatta bene, qui, coincide con il vantaggio commerciale. Se vuoi capire dove sta la tua software house rispetto a questi obblighi, o se la scadenza del 2027 ti sembra lontana ma il dubbio sull'articolo 14 ti è venuto leggendo, contattami per una consulenza: un assessment del gap CRA su un prodotto tipico richiede poche giornate, e trasforma un regolamento di 68 articoli in una lista di attività con date e responsabili.