Stato aggiornato al 13 settembre 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 sono applicabili dall'11 settembre 2026; l'insieme principale degli obblighi relativi ai prodotti si applica 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à sull'ambito: 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 può emergere 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)
A partire dall'11 settembre 2026, si applicano gli obblighi di segnalazione associati al regime di segnalazione di vulnerabilità e incidenti del CRA, secondo i tempi stabiliti dal Regolamento e dalle linee guida della Commissione per i produttori. Dall'11 dicembre 2027, i principali requisiti di cybersicurezza dei prodotti (inclusi le aspettative di secure-by-design, i processi di gestione delle vulnerabilità e la trasparenza legata all'SBOM per i prodotti con elementi digitali) si applicano più ampiamente. La classificazione esatta del prodotto (predefinito, importante, critico) è una questione legale e di prodotto, non qualcosa che una code review decide.
Considerate quelle date come punti di riferimento per la pianificazione. Se correzioni del Giornale 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 dell'SBOM dal 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 disabilita un contatto di sicurezza, un feed di avvisi o un webhook interno per il triage delle vulnerabilità che il processo allineato al CRA assume esista. Erosione del secure-by-design: una PR di "pulizia" elimina l'autenticazione su una porta admin, disabilita i controlli degli aggiornamenti o disattiva la verifica dell'integrità dei 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: il CI smette di generare l'inventario dei componenti
Un team di piattaforma accorcia il CI di due minuti eliminando un job che eseguiva syft (o equivalente) e caricava un artefatto SBOM per ogni tag di release. Il Dockerfile e l'app continuano a compilarsi. I test rimangono verdi. I commenti di revisione riguardano i costi del 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 non coperti
Questa guida non tratta moduli di valutazione di 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 che abilitate. 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 i requisiti software dell'NIS 2 Art. 21, i controlli di sviluppo sicuro dell'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 vostra base di conoscenza abilitata non li includa.
Mantenete SAST, scanner delle dipendenze e il revisore del codice. La legge CRA sui prodotti è per lo più al di fuori del diff. Il diff rileva solo la parte che silenziosamente elimina ciò che quei programmi assumono sia ancora attivo.