Individuare le vulnerabilità e documentarlo per l'audit
In questo articolo vedremo come strutturare un approccio alla ricerca delle vulnerabilità coerente con EN 18031, concentrandoci su metodologia, evidenze e test, lasciando da parte l'elenco degli strumenti specifici da utilizzare.
17 gennaio 2026
Introduzione ai requisiti EN 18031
Dal 1° agosto 2025 sono entrati in vigore i requisiti di cybersicurezza previsti dalla Direttiva RED 2014/53/UE (Art. 3(3) d/e/f) per specifiche categorie di apparecchiature radio, secondo quanto stabilito dal Regolamento Delegato (UE) 2022/30.
La norma EN 18031 è stata progettata per dimostrare che l'apparecchiatura radio, insieme all'ecosistema che la supporta (app, cloud, API), protegge adeguatamente:
la rete e le sue risorse (Art. 3(3)(d))
i dati personali e la privacy (Art. 3(3)(e))
la prevenzione delle frodi nei trasferimenti di valore o moneta virtuale (Art. 3(3)(f))
Quando un laboratorio o un valutatore esamina la gestione delle vulnerabilità, verifica tipicamente che l'organizzazione abbia:
la capacità di identificare vulnerabilità note (CVE, supply chain) prima del rilascio del prodotto
la capacità di rilevare vulnerabilità proprie (bug, configurazioni errate, problemi di design)
un processo post-market per gestirle efficacemente (triage, correzione, aggiornamenti sicuri, tempistiche definite, documentazione delle evidenze)
Questo approccio rispecchia le linee guida operative che accompagnano i test EN 18031, dove devi esistere una combinazione equilibrata di test, documentazione e prontezza organizzativa.
Per il quadro completo delle misure di cybersicurezza richieste dalla EN 18031, consulta la nostra guida alle misure essenziali di cybersicurezza RED per l'IoT.
Le quattro famiglie di vulnerabilità
Per rendere l'analisi davvero efficace, è utile distinguere le vulnerabilità in quattro categorie principali. Ciascuna richiede tecniche di individuazione specifiche:
1 - Dipendenze vulnerabili (CVE)
Librerie open source, SDK, componenti di terze parti, immagini container, librerie crittografiche e simili.
2 - Bug nel codice applicativo
Injection, bypass dell'autenticazione, deserializzazione non sicura, path traversal, gestione inadeguata degli errori, e così via.
3 - Vulnerabilità di configurazione ed esposizione runtime
TLS configurato in modo debole, API esposte senza necessità, configurazioni cloud errate, porte o servizi inutilizzati attivi, interfacce di debug accessibili.
4 - Vulnerabilità di parsing e protocolli
Crash, corruzione della memoria, bug innescati da input malformati, particolarmente comuni nei dispositivi embedded e IoT.
Per soddisfare i requisiti di EN 18031, è necessario dimostrare una copertura ragionata di tutte le aree che possono avere impatti su reti, dati e valore economico.
Comprendere quali asset di sicurezza espone il tuo dispositivo e fondamentale per definire efficacemente l'ambito della ricerca di vulnerabilita.
Il toolbox minimo per individuare le vulnerabilità
A) SCA su SBOM: identificare le vulnerabilità pubbliche e note
La SBOM (Software Bill of Materials) rappresenta la distinta base del software: elenca componenti, versioni e dipendenze in modo strutturato.
In pratica, il processo funziona così: si genera una SBOM ad ogni release, la si analizza tramite Software Composition Analysis (SCA) e si ottiene l'elenco delle CVE (Common Vulnerability Exposure) che impattano il prodotto.
Per EN 18031, la SBOM si rivela particolarmente preziosa perché produce evidenze chiare e tracciabili:
release X → generazione SBOM → report CVE → triage → correzione/mitigazione → release X+1
Anche se la SBOM non è un obbligo esplicito della norma, rappresenta una delle evidenze più solide per dimostrare che non si sta immettendo sul mercato un prodotto con CVE note non gestite. Le checklist e le guide di readiness orientate a EN 18031 puntano proprio sull'avere un processo strutturato e una documentazione accurata.
B) SAST: individuare i bug nel codice prima che diventino exploit
L'analisi statica del codice serve a intercettare pattern ricorrenti di vulnerabilità: injection, errori di validazione, credenziali hardcoded, uso scorretto della crittografia.
Il vantaggio principale è la facilità di integrazione nei flussi di continuous integration: pull request → scansione → correzione → nuova scansione
Dal punto di vista metodologico, vale la pena citare l'ETSI TR 104 117, che menziona esplicitamente l'uso di strumenti e processi per valutare sicurezza e resilienza nel contesto dell'ecosistema di rischio e vulnerabilità.
C) DAST: testare API e applicazioni dall'esterno
L'analisi dinamica, spesso combinata con test manuali, è quella che permette di individuare: bypass di autenticazione e autorizzazione, gestione debole delle sessioni, assenza di rate limiting (esposizione a bruteforce), e errori di validazione degli input su endpoint reali.
Questa componente è particolarmente allineata con EN 18031 perché dimostra la protezione di rete e dati attraverso prove realistiche, documentate tramite log e tracce delle richieste/risposte.
D) Fuzzing: la tecnica spesso trascurata (con conseguenze costose)
Il fuzzing applicato a parser e protocolli, anche quelli interni, è spesso il metodo più efficace per individuare crash e denial of service, bug di parsing, e corruzione della memoria (particolarmente critica in ambienti C/C++/embedded).
Un messaggio importante da trasmettere: se il prodotto include stack radio/protocolli o parsing complesso, l'assenza di fuzzing rappresenta una lacuna significativa nella copertura dei test di sicurezza.
E) Hardening review: vulnerabilità senza bug
Questa categoria copre problemi che impattano direttamente i requisiti (d) ed (e) della RED, pur non essendo bug veri e propri: servizi non necessari ma esposti, configurazioni TLS/cipher/protocolli deboli, interfacce di debug non protette, e policy di password e autenticazione incoerenti.
Un aspetto da tenere presente: le restrizioni applicate dalla Commissione alla pubblicazione di EN 18031 evidenziano alcuni punti particolarmente delicati (ad esempio, aspetti legati a password e controllo degli accessi) dove la presunzione di conformità non è automatica.
Il ruolo dell'HBOM
L'HBOM (Hardware Bill of Materials) è molto utile per quanto riguarda le apparecchiature radio, perchè è fondamentale per controllare:
varianti e SKU (SoC, moduli radio, secure element diversi comportano superfici di attacco diverse)
vulnerabilità specifiche di chipset e moduli (Wi-Fi, Bluetooth, modem)
tracciabilità "as-built" (cosa è stato effettivamente montato su uno specifico lotto di produzione)
Per chi cerca un riferimento sul fronte supply chain, il framework HBOM di CISA offre una buona base concettuale, senza che questo implichi che EN 18031 lo imponga esplicitamente.
Rendere tutto audit-ready
Per strutturare un approccio verificabile e documentabile, può essere utile seguire uno schema logico che collega obiettivi, controlli, evidenze, test e output finali.
La gestione post-market delle vulnerabilità
Con EN 18031, il lavoro non si conclude con l'apposizione della marcatura CE. È necessario garantire:
un monitoraggio continuo delle vulnerabilità (CVE, advisory dei fornitori)
un canale per ricevere segnalazioni (PSIRT o sistema di coordinated disclosure)
la capacità di rilasciare correzioni attraverso aggiornamenti sicuri
una documentazione completa e tracciabile di tutte queste attività
Le linee guida operative legate a EN 18031 insistono proprio su questa visione integrata: processo strutturato, test verificabili e documentazione accurata come pilastri fondamentali.
Come RedComply semplifica la gestione delle vulnerabilità per EN 18031
Trovare e gestire tutte le vulnerabilità in modo conforme a EN 18031 è molto complicato e dispendioso, sia in termini economici sia di tempo. Servono competenze specifiche, parecchio tempo e una documentazione che regga all'audit.
Per tante aziende, soprattutto quelle senza un team di sicurezza interno, dover coordinare SBOM, SCA, SAST, DAST, fuzzing e hardening review diventa rapidamente un problema che blocca l'uscita del prodotto sul mercato.
Ma c'è un modo per rendere tutto questo più gestibile.
RedComply è una piattaforma basata su intelligenza artificiale che abbiamo costruito proprio per questo: rendere più semplice e veloce la conformità EN 18031 e RED Cybersecurity.
Generazione automatica della SBOM
La piattaforma crea in automatico la SBOM (Software Bill of Materials) per il tuo progetto, che tu stia lavorando su software per processori standard o firmware per microcontrollori embedded.
Una volta pronta la SBOM, RedComply identifica automaticamente tutte le vulnerabilità note (CVE) nei componenti che stai usando e ti accompagna attraverso i requisiti normativi necessari per la conformità.
Quello che normalmente richiederebbe settimane di lavoro si riduce a pochi giorni, con una riduzione del tempo fino al 93%!
Hai già una SBOM? Nessun problema
Se hai già generato una SBOM con altri strumenti, puoi caricarla direttamente sulla piattaforma. Supportiamo diversi formati standard e da lì parte subito l'analisi delle vulnerabilità e il percorso verso la conformità.
Fatti aiutare da noi!
Visita redcomply.com o contattaci direttamente per scoprire come automatizzare il processo di scoperta delle vulnerabilità e conformità EN 18031, per ridurre i tempi e i costi della certificazione.