FDA 524B: che cosa deve contenere l'SBOM di una domanda premarket

Ultimo aggiornamento: 2026-09-30

La sezione 524B del FD&C Act (21 U.S.C. 360n-2) prevede che chi presenta una domanda premarket (sponsor) per un cyber device fornisca una distinta base del software che includa i componenti software commerciali, open source e disponibili sul mercato (off-the-shelf). La legge non indica né formato né campi. Le linee guida della FDA del febbraio 2026 raccomandano un SBOM leggibile da un dispositivo automatico con gli attributi di base dell'NTIA, più il livello di supporto e la data di fine supporto di ogni componente.

Che cosa dice il testo

Le citazioni di questa guida provengono da fonti statunitensi e restano in inglese.

La legge, 21 U.S.C. 360n-2(b)(3). Lo sponsor deve:

"provide to the Secretary a software bill of materials, including commercial, open-source, and off-the-shelf software components; and"

In italiano, in sintesi: fornire al Segretario (Secretary) una distinta base del software che comprenda i componenti software commerciali, open source e off-the-shelf.

I dispositivi interessati, 21 U.S.C. 360n-2(c). Un cyber device è un dispositivo che:

"(1) includes software validated, installed, or authorized by the sponsor as a device or in a device;"

"(2) has the ability to connect to the internet; and"

"(3) contains any such technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats."

In italiano, in sintesi: (1) include software convalidato, installato o autorizzato dallo sponsor come dispositivo o in un dispositivo; (2) è in grado di connettersi a internet; e (3) contiene qualsiasi caratteristica tecnologica di questo tipo, convalidata, installata o autorizzata dallo sponsor, che potrebbe essere vulnerabile a minacce alla cibersicurezza.

Linee guida FDA "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions" (3 febbraio 2026; sostituiscono le linee guida del 27 giugno 2025), sezione V.A.4(b):

"manufacturers should provide machine-readable SBOMs consistent with the minimum elements (also referred to as “baseline attributes”) identified in the October 2021 National Telecommunications and Information Administration (NTIA) Multistakeholder Process on Software Component Transparency document “Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM).”"

In italiano, in sintesi: i fabbricanti dovrebbero fornire SBOM leggibili da un dispositivo automatico, coerenti con gli elementi minimi (detti anche "baseline attributes") indicati nel documento dell'ottobre 2021 del Multistakeholder Process on Software Component Transparency dell'NTIA, "Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM)".

La stessa sezione, per ogni componente software:

"The software level of support provided through monitoring and maintenance from the software component manufacturer (e.g., the software is actively maintained, no longer maintained, abandoned); and"

"The software component’s end-of-support date."

In italiano, in sintesi: il livello di supporto del software fornito dal fabbricante del componente attraverso monitoraggio e manutenzione (per esempio: il software è mantenuto attivamente, non è più mantenuto, è abbandonato); e la data di fine supporto del componente software.

NTIA, "The Minimum Elements For a Software Bill of Materials (SBOM)" (12 luglio 2021), campi di dati:

"Supplier, Component Name, Version of the Component, Other Unique Identifiers, Dependency Relationship, Author of SBOM Data, and Timestamp."

In italiano, in sintesi: fornitore, nome del componente, versione del componente, altri identificativi univoci, relazione di dipendenza, autore dei dati dell'SBOM e timestamp (data e ora).

Che cosa significa in pratica

L'obbligo di fornire un SBOM è nella legge; i dettagli sono nelle linee guida. Le linee guida stesse precisano che documenti di questo tipo "should be viewed only as recommendations, unless specific regulatory or statutory requirements are cited", cioè che vanno considerati solo raccomandazioni, salvo che vi siano citati specifici requisiti regolamentari o di legge.
Le linee guida richiamano il documento Framing dell'NTIA dell'ottobre 2021. I suoi attributi di base sono Author Name, Timestamp, Supplier Name, Component Name, Version String, Component Hash, Unique Identifier e Relationship. Il rapporto NTIA del luglio 2021 elenca sette campi di dati, senza l'hash del componente.
Il livello di supporto e la data di fine supporto sono raccomandati per ogni componente. Le linee guida consentono ai fabbricanti di indicarli nell'SBOM o a parte, "such as in an addendum", per esempio in un'appendice.
Nessun formato è prescritto: "Industry-accepted formats of SBOMs are encouraged.", cioè sono incoraggiati i formati SBOM accettati dal settore.
Le linee guida raccomandano anche di individuare tutte le vulnerabilità note, comprese quelle del Known Exploited Vulnerabilities Catalog della CISA, con una valutazione del rischio e le misure di controllo del rischio per ciascuna. Un file SBOM non contiene queste informazioni.
Secondo le linee guida, la sezione 524B si applica dal 29 marzo 2023 e riguarda le domande 510(k), PMA, PDP, De Novo e HDE.
Il regolamento sulla ciberresilienza non si applica ai prodotti a cui si applicano i regolamenti dell'UE sui dispositivi medici (regolamento (UE) 2024/2847, articolo 2, paragrafo 2, lettere a) e b)).
Lo U.S. Code, edizione 2024, riporta la sezione 360n-2 come introdotta dalla Pub. L. 117–328 e non indica modifiche successive.

Che cosa conservare come prova

L'SBOM della versione del dispositivo oggetto della domanda, leggibile da un dispositivo automatico, così come è stato generato, con il suo autore e il suo timestamp (data e ora).
Per ogni componente: fornitore, nome, versione, altri identificativi e relazioni, il livello di supporto e la data di fine supporto.
Le vulnerabilità note alla data della domanda, comprese le voci del catalogo della CISA, con la vostra valutazione di ciascuna.

Il ruolo di DevKit Dossier

DevKit Dossier ha un'esportazione FDA 524B, inclusa nel piano Business: un file ZIP per versione con sbom.json (l'SBOM byte per byte come caricato), vulnerabilities.json (ogni componente con le sue rilevazioni) e un README.txt che rileva e conteggia gli elementi minimi NTIA presenti nel vostro SBOM (i file SPDX 3.0 non vengono ancora conteggiati). DevKit Dossier non aggiunge il livello di supporto né la data di fine supporto; se il vostro SBOM non li contiene già, li aggiungete voi nella domanda, per esempio in un'appendice, come le linee guida consentono, insieme alla valutazione del rischio di ogni vulnerabilità. L'SBOM proviene dall'archivio per release, che la vostra CI alimenta con JSON CycloneDX o SPDX generati da Syft o Trivy; DevKit Dossier non è uno scanner. Vi aiuta a conservare le vostre prove documentali: non dice nulla su come la FDA valuterà una domanda, non fornisce consulenza legale e non certifica nulla. È ospitato nell'UE ed è self-service, a un prezzo fisso per organizzazione di 49, 99 o 249 EUR al mese, con una prova di 14 giorni.

Iscriviti alla lista d'attesa

Fonti

Questa guida contiene informazioni generali e non costituisce consulenza legale.