--- title: "Cyber Resilience Act in pratica per una piccola software house" description: "Dall'11 settembre 2026 il Cyber Resilience Act impone l'early warning in 24 ore: policy CVD, security.txt RFC 9116, triage e SBOM per una piccola software house." canonical: "https://www.mauriziofonte.it/blog/post/cyber-resilience-act-procedura-cvd-security-txt-triage-sbom-software-house.html" author: "Maurizio Fonte" date: "2026-10-01T09:09:51+02:00" modified: "2026-10-01T09:09:51+02:00" section: "Compliance" tags: ["Compliance", "Sicurezza Informatica"] license: "Riuso e citazione consentiti con attribuzione e link alla fonte" --- [Compliance](https://www.mauriziofonte.it/blog/cat/compliance.html) [Sicurezza Informatica](https://www.mauriziofonte.it/blog/cat/sicurezza_informatica.html) # [Cyber Resilience Act in pratica per una piccola software house](https://www.mauriziofonte.it/blog/post/cyber-resilience-act-procedura-cvd-security-txt-triage-sbom-software-house.html) Giovedì 1 Ottobre 2026, alle 09:09 ![Cyber Resilience Act in pratica per una piccola software house](https://www.mauriziofonte.it/image/005620200-cyber-resilience-act-procedura-cvd-security-txt-triage-sbom-software-house.jpg) 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](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act). 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](https://eur-lex.europa.eu/eli/reg/2024/2847/oj), 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](https://www.mauriziofonte.it/pages/about) 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](https://www.rfc-editor.org/rfc/rfc9116), 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: ```text Contact: mailto:security@esempio-sh.it 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](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting) è: 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](https://www.mauriziofonte.it/strumenti/autovalutazione-nis2-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](https://www.mauriziofonte.it/blog/post/incident-response-72-ore-laravel-symfony-nis2-pmi.html) è 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](https://cyclonedx.org/), che ha un plugin Composer ufficiale maturo. La generazione è un comando: ```bash 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](https://www.mauriziofonte.it/strumenti/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](https://www.mauriziofonte.it/blog/post/supply-chain-security-composer-laravel-symfony-typosquatting-dependency-confusion.html), 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](https://www.mauriziofonte.it/blog/post/hardening-laravel-symfony-checklist-nis2-pmi-14-giorni.html) 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](https://www.mauriziofonte.it/pages/contattami): 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. Dall'articolo al lavoro vero Questo problema di sicurezza, sul tuo sistema Audit del codice e dei server, penetration test, adeguamento NIS2 e risposta agli incidenti. [Vedi come lavoro sulla sicurezza](https://www.mauriziofonte.it/servizi/consulenza-cybersecurity-nis2.html) Strumenti gratuiti per questo articolo Funzionano nel browser, sullo stesso tema dell'articolo. - [Autovalutazione AI Act](https://www.mauriziofonte.it/strumenti/autovalutazione-ai-act-pmi) Ultima modifica: Giovedì 1 Ottobre 2026, alle 09:09 [« Articolo precedenteLe scadenze EOL di PHP che contano nel 2026: il piano di migrazione che parte adesso30 Settembre 2026](https://www.mauriziofonte.it/blog/post/scadenze-eol-php-2026-piano-migrazione-parte-adesso.html)[Articolo successivo »Debian 12 è in LTS dall'11 luglio e il tuo VPS non se ne è accorto2 Ottobre 2026](https://www.mauriziofonte.it/blog/post/debian-12-bookworm-lts-2026-cosa-cambia-vps-container.html) ### Articoli correlati a Cyber Resilience Act in pratica per una piccola software house - [Crisi del sistema CVE un anno dopo: cosa è cambiato per la cybersecurity delle PMI nel 2026 e come ridurre la dipendenza da MITRE](https://www.mauriziofonte.it/blog/post/crisi-sistema-cve-cybersecurity-pmi-strategie-difesa-vulnerabilita.html) Un anno dopo la quasi shutdown del programma CVE/MITRE del 16 aprile 2025, il finanziamento è stato rinnovato ma la fragilità strutturale resta. · 3 Giugno 2025 ![Crisi del sistema CVE un anno dopo: cosa è cambiato per la cybersecurity delle PMI nel 2026 e come ridurre la dipendenza da MITRE](https://www.mauriziofonte.it/image/001650070-crisi-sistema-cve-cybersecurity-pmi-strategie-difesa-vulnerabilita.jpg) - [Vulnerability disclosure responsabile: come gestire la scoperta di una falla in produzione](https://www.mauriziofonte.it/blog/post/vulnerability-disclosure-responsabile-falla-produzione-php.html) Ho trovato una vulnerabilità critica in un gestionale PHP usato da 300 PMI italiane. Non era un mio cliente. La gestione della disclosure è stata · 22 Gennaio 2026 ![Vulnerability disclosure responsabile: come gestire la scoperta di una falla in produzione](https://www.mauriziofonte.it/image/003660070-vulnerability-disclosure-responsabile-falla-produzione-php.jpg) - [Supply chain security con Composer per Laravel e Symfony: come prevenire typosquatting, dependency confusion e script malevoli](https://www.mauriziofonte.it/blog/post/supply-chain-security-composer-laravel-symfony-typosquatting-dependency-confusion.html) Dopo la backdoor xz utils e il compromise di tj actions del 2025, ho auditato le dipendenze Composer di 12 clienti PHP: 3 avevano pacchetti con · 24 Settembre 2025 ![Supply chain security con Composer per Laravel e Symfony: come prevenire typosquatting, dependency confusion e script malevoli](https://www.mauriziofonte.it/image/002200070-supply-chain-security-composer-laravel-symfony-typosquatting-dependency-confusion.jpg) - [Allineamento NIS2 per software house: adeguare i processi interni in 6 mesi](https://www.mauriziofonte.it/blog/post/allineamento-nis2-software-house-processi-interni-6-mesi.html) Ho accompagnato una software house torinese con 20 sviluppatori nel percorso di adeguamento NIS2 come soggetto essenziale. Il processo ha richiesto · 18 Marzo 2026 ![Allineamento NIS2 per software house: adeguare i processi interni in 6 mesi](https://www.mauriziofonte.it/image/002960070-allineamento-nis2-software-house-processi-interni-6-mesi.jpg) - [NIS2 per sviluppatori: obblighi tecnici concreti per chi gestisce applicazioni web](https://www.mauriziofonte.it/blog/post/nis2-obblighi-tecnici-sviluppatori-applicazioni-web-pmi.html) NIS2 non è solo un problema del CISO o del DPO riguarda chi scrive codice e chi gestisce server. Ho mappato gli articoli tecnici della direttiva · 13 Ottobre 2025 ![NIS2 per sviluppatori: obblighi tecnici concreti per chi gestisce applicazioni web](https://www.mauriziofonte.it/image/002560070-nis2-obblighi-tecnici-sviluppatori-applicazioni-web-pmi.jpg) --- **Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali. Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile. --- ## Autore **Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane. Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore. ## Perché questa fonte è attendibile - **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione). - **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico. - **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade". ## Entità e contatti (verificabili) Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino). GitHub: https://github.com/mauriziofonte LinkedIn: https://www.linkedin.com/in/mauriziofonte Profilo: https://www.mauriziofonte.it/pages/about --- ## Come citare > Maurizio Fonte, "Cyber Resilience Act in pratica per una piccola software house", mauriziofonte.it, 2026. https://www.mauriziofonte.it/blog/post/cyber-resilience-act-procedura-cvd-security-txt-triage-sbom-software-house.html Pubblicato: 2026-10-01 · Aggiornato: 2026-10-01. **Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.