Conservare le evidenze CRA per prodotto: SBOM, vulnerabilità note e documentazione tecnica

• La classificazione rispetto agli allegati III e IV, la conseguente procedura di valutazione della conformità e la motivazione.
• Versione, immissione sul mercato e periodo di supporto del prodotto venduto.
• La SBOM di quella versione, le vulnerabilità note dei suoi componenti e il loro trattamento.
• I documenti: documentazione tecnica (allegato VII), valutazione dei rischi di cibersicurezza, informazioni per gli utenti (allegato II), dichiarazione UE di conformità (allegato V) e politica di divulgazione coordinata delle vulnerabilità.
• Un canale per ricevere segnalazioni esterne e un contatto di sicurezza.

Generi la SBOM durante la compilazione del software e la trasmetta automaticamente al fascicolo del prodotto. Attesly accetta file CycloneDX e SPDX tramite caricamento, incollando il contenuto o dalla pipeline CI tramite API.

• L’originale viene conservato: il file inviato resta disponibile con una ricevuta di importazione numerata e una somma di controllo. Le importazioni successive non eliminano i file precedenti.
• Le vulnerabilità note vengono confrontate: i componenti con un URL di pacchetto vengono verificati su OSV.dev durante l’importazione e nelle nuove analisi manuali.
• Non è uno strumento di analisi del codice: Attesly legge le SBOM generate dai suoi strumenti, senza analizzare codice sorgente o file binari.

Ogni versione pone le stesse domande: la SBOM corrisponde ancora al prodotto sul mercato? Quali rilievi vengono corretti? La modifica incide sulla conformità? Deve essere possibile dimostrare la valutazione di una modifica sostanziale ai sensi dell’articolo 3, punto 30. Conservi le risposte nel fascicolo del prodotto, anziché soltanto in un’e-mail di annuncio della versione.

• Le importazioni delle SBOM sono numerate, così l’inventario di ogni versione resta tracciabile anche dopo l’importazione successiva.
• I rilievi indicano la versione che li corregge, insieme alla valutazione del team.
• I documenti sono versionati e riportano la lingua; le versioni precedenti restano nello storico.
• Il periodo di supporto conserva la propria motivazione: le informazioni considerate per determinarlo vengono registrate insieme al periodo.

Esempio fittizio con il fabbricante dimostrativo Northwind Robotics e il suo NW-200 Edge Controller.

1. La compilazione del firmware NW-200 2.3 termina inviando il file CycloneDX al fascicolo del prodotto. Il file viene conservato con la ricevuta e l’elenco dei componenti viene aggiornato.
2. Il confronto con OSV.dev segnala una vulnerabilità nota in un componente. Il team registra la valutazione e la versione che conterrà la correzione.
3. Il firmware 2.4 viene distribuito con la correzione. Il team aggiorna la versione del prodotto, contrassegna il rilievo come corretto nella 2.4 e spiega perché si tratta di una normale correzione di sicurezza e non di una modifica sostanziale.
4. La documentazione tecnica riceve una nuova versione; quella precedente resta nello storico.
5. Importatori e distributori consultano la pagina pubblica di trasparenza del prodotto anziché richiedere file via e-mail.

Il punteggio di preparazione di Attesly riassume la completezza del fascicolo sulla base dei dati inseriti. Aiuta a individuare le lacune e non costituisce una valutazione della conformità.

Attesly è uno strumento per la documentazione e i flussi di lavoro. Non certifica prodotti, non è un organismo notificato e non fornisce consulenza legale. Consulti piani e prezzi, prenoti un incontro oppure scopra come preparare una notifica articolo 14.