{"id":1974,"date":"2026-05-12T15:07:09","date_gmt":"2026-05-12T13:07:09","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/cyber-resilience-act-2026-sbom-vulnerability-disclosure-hosting-compliance\/"},"modified":"2026-05-12T15:07:09","modified_gmt":"2026-05-12T13:07:09","slug":"cyber-resilience-act-2026-sbom-vulnerability-disclosure-hosting-compliance","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/cyber-resilience-act-2026-sbom-vulnerability-disclosure-hosting-compliance\/","title":{"rendered":"Cyber Resilience Act 2026: Implementazione SBOM, Vulnerability Disclosure e Compliance per Provider Hosting \u2013 Scadenze e Adempimenti"},"content":{"rendered":"

Nel mio lavoro da System Administrator e IT Specialist, affronto quotidianamente la gestione della sicurezza infrastrutturale. Negli ultimi mesi, il Cyber Resilience Act (CRA)<\/strong> \u00e8 diventato un tema centrale: non \u00e8 pi\u00f9 una prospettiva lontana, ma un obbligo concreto che chi fornisce servizi di hosting deve implementare subito<\/em>. Non fra tre anni \u2013 fra pochi mesi. Vi mostro come affrontarlo nella pratica.<\/p>\n

Il CRA, Regolamento (UE) 2024\/2847<\/strong>, \u00e8 entrato in vigore il 10 dicembre 2024, ma questo \u00e8 solo l’inizio. Le principali obbligazioni si applicheranno dal 11 dicembre 2027, mentre gli obblighi di segnalazione entrano in vigore il 11 settembre 2026<\/cite>. Per chi gestisce server, cloud e infrastrutture digitate, questo rappresenta un cambio paradigmatico: la sicurezza non \u00e8 pi\u00f9 opzionale, \u00e8 una condizione di accesso al mercato europeo.<\/p>\n

Il CRA: Una Visione Normativa Nuova<\/h2>\n

Il Cyber Resilience Act \u00e8 un regolamento europeo che impone requisiti minimi di sicurezza informatica per tutti i prodotti digitali immessi nel mercato UE, siano essi hardware o software<\/cite>. Per i provider hosting, questo significa che i servizi devono essere costruiti per la sicurezza sin dalla progettazione, mantenere una bill of materials del software, gestire attivamente le vulnerabilit\u00e0 e segnalare gli incidenti dentro tempi ristretti<\/cite>.<\/p>\n

La novit\u00e0 radicale: il regolamento esige un cambiamento culturale che parte dalle fondamenta, in cui i prodotti devono essere concepiti secondo i principi di secure-by-design e by-default, poich\u00e9 la sicurezza non pu\u00f2 pi\u00f9 essere un’aggiunta finale ma deve essere una caratteristica intrinseca del progetto<\/cite>.<\/p>\n

Scadenze Critiche: Il Calendario 2026-2027<\/h2>\n

Nel mio percorso di compliance finora, ho imparato che le scadenze non sono negoziabili. Ecco le date che contano davvero:<\/p>\n

11 Giugno 2026: Designazione delle Autorit\u00e0 Notificanti<\/h3>\n

Gli Stati membri devono designare entro l’11 giugno 2026 le autorit\u00e0 notificanti responsabili della procedura di valutazione e notificazione degli organismi di valutazione della conformit\u00e0<\/cite>. Per un provider hosting, questo significa che il sistema di certificazione inizia a prendere forma: se il vostro servizio rientra nella categoria “importante” o “critica”, a partire da questa data potrete sapere quali enti terzi controlleranno la vostra conformit\u00e0.<\/p>\n

11 Settembre 2026: Obbligo di Segnalazione Vulnerabilit\u00e0<\/h3>\n

Questa \u00e8 la vera sveglia. A partire dall’11 settembre 2026, i produttori sono tenuti a segnalare vulnerabilit\u00e0 attivamente sfruttate e incidenti gravi. Devono presentare un avviso anticipato entro 24 ore dal rilevamento e una notifica completa entro 72 ore, con un rapporto finale entro 14 giorni da quando \u00e8 disponibile una misura correttiva<\/cite>.<\/p>\n

Nella mia esperienza, affrontare questa tempistica senza automazione \u00e8 impossibile. Ho visto aziende panicate perch\u00e9 avevano il SBOM (Software Bill of Materials) ancora in foglio Excel. Se non avete SBOMs e un processo di gestione delle vulnerabilit\u00e0 in posto prima di settembre 2026, non potete conformarvi, il che rende l’SBOM un requisito di fatto almeno 15 mesi prima della scadenza ufficiale di dicembre 2027<\/cite>.<\/p>\n

11 Dicembre 2027: Piena Applicabilit\u00e0<\/h3>\n

Da questo giorno, nessun prodotto digitale potr\u00e0 essere venduto nell’Unione Europea se non conforme al CRA<\/cite>. Questo non \u00e8 un consiglio, \u00e8 una barriera di mercato. Se il vostro Plesk Obsidian, i vostri container, la vostra piattaforma di hosting non soddisfano gli standard essenziali di cybersecurity, non potete offrirli ai clienti europei.<\/p>\n

SBOM: Il Cuore Operativo del CRA<\/h2>\n

La Software Bill of Materials \u00e8 il documento centrale della conformit\u00e0 CRA. Documenta tutti i componenti di un prodotto software \u2013 incluse le librerie open-source, le dipendenze transitive e le loro licenze \u2013 e il CRA richiede l’SBOM come parte della documentazione tecnica da sottoporre alle autorit\u00e0 di sorveglianza del mercato su richiesta<\/cite>.<\/p>\n

Nel mio setup di Plesk, ho dovuto affrontare questo problema subito. Come accadde con il Log4Shell nel 2021 \u2013 quando gli attaccanti iniziarono lo sfruttamento entro ore \u2013 le aziende non sapevano se Log4j era presente nei loro sistemi, perch\u00e9 appariva come dipendenza transitiva. I team hanno speso giorni a cercare manualmente nei repository. Con un SBOM aggiornato, avreste avuto la risposta in secondi<\/cite>.<\/p>\n

Generazione Automatica dell’SBOM<\/h3>\n

La creazione manuale dell’SBOM non \u00e8 praticabile nei cicli di rilascio agili, quindi la generazione deve essere automatizzata nella pipeline di build<\/cite>. Nella mia procedura su Plesk Obsidian:<\/p>\n

    \n
  1. Integro SBOM nella CI\/CD<\/strong>: Ogni build genera automaticamente un SBOM in formato CycloneDX o SPDX JSON.<\/li>\n
  2. Scansione vulnerabilit\u00e0 continua<\/strong>: Lo SBOM passa a uno scanner (Grype, Trivy, Anchore) che verifica CVE note per ogni componente.<\/li>\n
  3. Archiviazione versionate<\/strong>: Mantengo uno storico SBOM per ogni versione rilasciata, facilmente reperibile da autorit\u00e0 e clienti.<\/li>\n<\/ol>\n

    Formati Standardizzati: CycloneDX vs SPDX<\/h3>\n

    CycloneDX \u00e8 un formato JSON\/XML leggero, specifico per i casi di sicurezza, supporta nativamente i riferimenti a vulnerabilit\u00e0 (VEX) e il mapping delle dipendenze di servizi. \u00c8 consigliato per chi pensa alla sicurezza prima. SPDX \u00e8 uno standard ISO 5962 pi\u00f9 completo, focalizzato su conformit\u00e0 licenze. \u00c8 pi\u00f9 appropriato quando accanto alla sicurezza la conformit\u00e0 alle licenze \u00e8 prioritaria<\/cite>.<\/p>\n

    Nel mio laboratorio, uso CycloneDX 1.5+ in JSON<\/strong> come standard perch\u00e9 si integra meglio con gli scanner di vulnerabilit\u00e0 moderni. Il CRA richiede che i fabbricanti forniscano l’SBOM almeno per le dipendenze dirette, in formato leggibile da macchina (SPDX o equivalente), coprendo le dipendenze di livello superiore<\/cite>.<\/p>\n

    Vulnerability Disclosure: Processo Strutturato<\/h2>\n

    I fabbricanti devono implementare un processo coordinato di disclosure delle vulnerabilit\u00e0 con una mailing list accessibile pubblicamente (ad esempio security.txt secondo RFC 9116), tempi di risposta definiti, una struttura interna di triage e la capacit\u00e0 di fornire patch tempestivamente<\/cite>.<\/p>\n

    Nella pratica di Plesk Obsidian, ho strutturato cos\u00ec:<\/p>\n

    1. Canale di Ricezione: security.txt<\/h3>\n

    Ho creato un file `\/.well-known\/security.txt` su ogni dominio di hosting che fornisco, seguendo RFC 9116:<\/p>\n

    Contact: security@darioiannascoli.it\nExpires: 2027-05-15T00:00:00Z\nPreferred-Languages: it, en\nCanonical: https:\/\/darioiannascoli.it\/.well-known\/security.txt<\/pre>\n
    I ricercatori di sicurezza sanno dove segnalare. Nessun giro di comunicazioni, nessuna confusione.<\/p>\n
    2. Team di Triage Interno (PSIRT)<\/h3>\n
    Per una piccola azienda senza SOC 24\/7, \u00e8 necessario un Product Security Incident Response Team con ruoli chiari, avvisi automatizzati e template di notifica pre-scritti per rispettare i tempi di segnalazione di 24\/72\/14 giorni<\/cite>.<\/p>\n
    Nel mio setup:<\/p>\n