Stato aggiornato all'11 agosto 2026. Il Cyber Resilience Act dell'UE (Regolamento (UE) 2024/2847) stabilisce requisiti di cybersicurezza per i prodotti con elementi digitali immessi sul mercato dell'Unione. Le linee guida pratiche della Commissione sono state pubblicate il 27 luglio 2026. Gli obblighi di segnalazione entrano in vigore dall'11 settembre 2026; l'insieme principale degli obblighi sui prodotti dall'11 dicembre 2027. Questa guida è rivolta agli ingegneri software che lavorano su prodotti potenzialmente in ambito di applicazione, non agli avvocati per la valutazione di conformità.
Onestà sul campo di applicazione: il CRA non sostituisce SOC 2, ISO 27001 o il GDPR. Non è un'altra "casella di controllo per bot di conformità". Molti doveri del CRA riguardano processi del produttore, documentazione e post-vendita. Solo una parte emerge in una pull request tipica: aggiornamento dell'inventario delle dipendenze e SBOM, percorsi di segnalazione delle vulnerabilità e controlli di sicurezza rimossi come codice non utilizzato. Se il team legale o di prodotto non ha confermato che il CRA si applica a ciò che distribuite, fermatevi qui e chiedete loro.
Cosa entra in vigore e quando (calendario per sviluppatori)
Dall'11 settembre 2026 entrano in vigore gli obblighi di segnalazione associati al regime di segnalazione delle vulnerabilità e degli incidenti del CRA, secondo i tempi stabiliti dal Regolamento e dalle linee guida della Commissione per i produttori. Dall'11 dicembre 2027 si applicano i principali requisiti di cybersicurezza dei prodotti (inclusi secure-by-design, processi di gestione delle vulnerabilità e trasparenza legata all'SBOM per i prodotti con elementi digitali). La classificazione esatta del prodotto (predefinito, importante, critico) è una questione legale e di prodotto, non qualcosa che una code review decide.
Trattate quelle date come punti di riferimento per la pianificazione. Se correzioni della Gazzetta ufficiale o ulteriori linee guida le modificano, rivalutate questa pagina (vedere il registro di aggiornamento delle date).
Cosa può effettivamente emergere in una pull request
Aggiornamento delle dipendenze e SBOM: una modifica fissa un componente obsoleto, rimuove la generazione di un software bill of materials dalla CI o smette di pubblicare l'inventario dei componenti su cui si basa il processo di gestione delle vulnerabilità. Percorso di gestione delle vulnerabilità: una modifica rimuove o codifica in modo fisso un contatto di sicurezza, un feed di avvisi o un webhook interno di triage delle vulnerabilità che il processo allineato al CRA presuppone esista. Erosione del secure-by-design: una PR di "pulizia" elimina l'autenticazione su una porta di amministrazione, disabilita i controlli degli aggiornamenti o disattiva la verifica dell'integrità sui pacchetti di aggiornamento perché erano rumorosi.
Questi sono aspetti tecnici. Non costituiscono un fascicolo completo di conformità CRA, una storia di marcatura CE o una valutazione da parte di un organismo notificato.
Esempio pratico: la CI smette di generare l'inventario dei componenti
Un team di piattaforma accorcia la CI di due minuti eliminando un job che eseguiva syft (o equivalente) e caricava un artefatto SBOM per ogni tag di rilascio. Il Dockerfile e l'app continuano a compilarsi. I test rimangono verdi. I commenti di revisione riguardano il costo della pipeline. Settimane dopo, il team di sicurezza non può rispondere a "quali versioni sono state distribuite nella 1.8.3" senza ricostruire dai layer.
Se il prodotto è in ambito CRA e il processo dipende da quell'inventario per la gestione delle vulnerabilità e la trasparenza, l'eliminazione del job non è una semplice operazione di manutenzione. Una revisione consapevole della conformità segnalerebbe la perdita del passaggio di inventario nella PR, in modo che prodotto e sicurezza possano accettare formalmente il rischio o ripristinare il job. heygrc che cita un controllo di framework qui è un segnale, non una determinazione che il prodotto non è conforme.
Obiettivi esplicitamente esclusi
Questa guida non tratta moduli di valutazione della conformità, marcatura CE, registrazione del produttore, redazione della dichiarazione di conformità UE o se il prodotto è "importante" o "critico" ai sensi del CRA. Non afferma che heygrc rende un prodotto conforme al CRA. Non sostituisce il PSIRT, la revisione legale o il piano di risposta alla sorveglianza del mercato.
Se avevate bisogno solo di SOC 2 o ISO 27001 per i clienti, il CRA potrebbe comunque essere irrilevante. Non forzate l'adattamento.
Dove si inserisce heygrc e il limite dell'onestà
heygrc è progettato per evidenziare modifiche rilevanti per i controlli nelle pull request rispetto ai framework abilitati. Per l'igiene ingegneristica correlata al CRA, la sovrapposizione utile è la stessa classe di riscontri del secure development e della gestione delle vulnerabilità previsti da altri framework (ad esempio NIS 2 Art. 21 requisiti software, controlli di sviluppo sicuro ISO 27001): rimozione dei controlli di integrità degli aggiornamenti, autenticazione indebolita, eliminazione di job di inventario. Mappate con attenzione; non inventate numeri di articoli del CRA nei riscontri a meno che la base di conoscenza abilitata non li includa.
Mantenete SAST, scanner delle dipendenze e il revisore del codice. La legge sui prodotti CRA è per lo più al di fuori del diff. Il diff rileva solo la parte che silenziosamente elimina ciò che quei programmi presuppongono sia ancora attivo.