La norma IEC 62304 (Medical Device Software – Software Life Cycle Processes) definisce i processi del ciclo di vita del software medicale, ma non prescrive automaticamente un penetration test: la scelta dipende da come il software è costruito, da quanto è esposto e da quali componenti devono essere verificati con evidenza tecnica.
Quando interfacce, API, componenti SOUP o workflow di aggiornamento sono in scope, il test di sicurezza produce evidenze concrete e spendibili; quando mancano ancora perimetro, classificazione o architettura definiti, partire dal penetration test rischia di produrre output scollegati dal rischio reale del prodotto.
In breve: quando IEC 62304 richiede evidenza tecnica
Il penetration test serve davvero quando IEC 62304 si traduce in software con interfacce esposte, ruoli sensibili, dipendenze critiche o workflow di aggiornamento che possono essere abusati. Serve molto meno come prima attività quando il problema principale è ancora definire architettura, classificazione del software, componenti SOUP o perimetro reale del prodotto.
A chi serve questa guida
Questa pagina è utile per capire:
- quando il penetration test ha senso in un percorso legato a IEC 62304;
- quando bastano code review, assessment architetturale o altri controlli preliminari;
- come scegliere la prova tecnica più credibile per lo scenario specifico;
- come evitare costi o attività scollegate dal rischio reale.
Quando il penetration test è la scelta giusta
Ha senso avviare un penetration test quando:
- Esistono portali, API, app companion o backend che influenzano il comportamento del software medicale;
- Il prodotto dipende da componenti terze o SOUP integrati in flussi sensibili;
- Release, patch o aggiornamenti remoti possono introdurre rischi tecnici concreti;
- Un buyer, un auditor o il team RA/QA richiede prove tecniche, non solo documentazione di processo;
- La remediation deve essere verificata con retest prima o subito dopo il rilascio.
Quando non è la prima attività da avviare
Conviene rimandare il penetration test quando:
- Non è ancora chiaro quali componenti siano realmente in scope;
- Manca una vista architetturale sufficiente di interfacce, dipendenze e trust boundary;
- Il software è poco esposto e il primo dubbio riguarda qualità implementativa o uso di librerie terze;
- Serve prima allineare classificazione del software, rischio residuo e criteri di severità.
Come scegliere la verifica più adatta
| Se il bisogno principale è… | La verifica più utile è… | Perché |
|---|---|---|
| Validare interfacce applicative e API | Web Application Penetration Testing | Verifica sfruttabilità e impatto |
| Capire il rischio tecnico prima del test | Secure Architecture Review | Chiarisce perimetro, dipendenze e trust boundary |
| Verificare codice critico e componenti terzi | Code Review | Intercetta difetti applicativi e punti deboli di implementazione |
| Lavorare sul ciclo di vita del software | Software Assurance Lifecycle | Collega sviluppo, verifica e miglioramento continuo |
L’errore più frequente
Trattare penetration test, assessment architetturale e software assurance come attività alternative è l’errore più comune. In pratica funzionano meglio in sequenza: prima si chiariscono perimetro e dipendenze, poi si testa ciò che incide davvero sul rischio, infine i finding vengono tradotti in remediation e decisioni di release.
Domande frequenti su IEC 62304 e penetration test
- IEC 62304 rende il penetration test obbligatorio?
- Non necessariamente. Dipende da come il software è costruito, da quanto è esposto e da quali componenti digitali devono essere verificati con evidenza tecnica.
- Cosa conviene verificare prima di avviare un penetration test?
- Perimetro, classificazione del software, dipendenze, dati, ruoli e interfacce che incidono davvero sul rischio del prodotto. Senza questa base, il test rischia di produrre finding scollegati dal lifecycle reale.
- Come si valuta se si sta scegliendo l’attività giusta?
- Se l’attività produce un’evidenza utile a chi deve decidere, auditare, rilasciare o acquistare il software, la direzione è corretta. Se produce solo output tecnici scollegati dal lifecycle reale del prodotto, probabilmente no.
Le vulnerabilità delle applicazioni web possono esporre la tua azienda a rischi e attacchi informatici.
Affidati a ISGroup per:
- Web Application Penetration Test efficace e mirato
- Individuazione e correzione preventiva delle falle di sicurezza
- Supporto tecnico da esperti in sicurezza applicativa
Per capire se IEC 62304 richiede un penetration test o prima un’altra forma di verifica, il passo utile è chiarire perimetro, dipendenze e release da proteggere. A seconda del contesto, si può partire da una Secure Architecture Review, approfondire con una Code Review su componenti critici o procedere direttamente con il Web Application Penetration Testing quando interfacce e API sono già definite.
Approfondimenti correlati
- Per il quadro completo su obblighi, scope e metodologia, consulta la guida principale su IEC 62304 e penetration test;
- Per capire quali evidenze produrre in fase di audit o vendor assessment, leggi la guida su IEC 62304 e le evidenze utili per audit e vendor assessment;
- Per definire scope, deliverable e retest in modo coerente con il lifecycle del software medicale, consulta la guida su IEC 62304: scope, deliverable e retest.