Il Playbook ENISA Secure by Design: cosa significa per i team di prodotto sotto il CRA

Cos'è il Playbook ENISA Secure by Design?

Il 19 marzo 2026, l'Agenzia dell'Unione europea per la cibersicurezza (ENISA) ha pubblicato il Security by Design and Default Playbook, versione 0.4, rilasciato come bozza per la consultazione pubblica.

È la prima guida ufficiale dell'UE che traduce i requisiti di sicurezza del CRA in checklist ingegneristiche concrete, pensate per le PMI. Il documento non è una guida legale. Fornisce approcci pratici e tecnicamente fondati che i team di prodotto possono applicare durante le fasi di progettazione, sviluppo e distribuzione.

Il playbook si rivolge alle PMI (definite come organizzazioni con meno di 250 dipendenti e fatturato annuo inferiore a 50 milioni di euro) che producono prodotti con elementi digitali. Questo include software embedded, dispositivi IoT, sistemi connessi, software standalone e hardware con componenti programmabili.

ENISA ha sviluppato il playbook analizzando i framework di sicurezza esistenti pubblicati da ENISA e da altre agenzie europee per la cibersicurezza, nonché le linee guida di NIST e OWASP. I requisiti comuni e i pattern di implementazione sono stati identificati e valutati rispetto alle capacità delle PMI per determinarne la fattibilità e i requisiti di adattamento.

L'Allegato C del playbook mappa tutti i 22 principi direttamente ai requisiti essenziali dell'Allegato I del CRA, fornendo un collegamento tracciabile tra le pratiche ingegneristiche e gli obblighi normativi.

A chi è destinato questo playbook?

Il playbook identifica quattro gruppi principali (Sezione 1.3):

• Software Developer e Ingegneri: persone che scrivono codice e hanno bisogno di modi pratici per integrare la sicurezza senza rallentare la delivery
• Technical Product Manager: persone che bilanciano il lavoro sulle funzionalità con i requisiti di sicurezza, cercando di far coesistere entrambi
• Security Lead nelle PMI: persone che traducono i framework enterprise in qualcosa che funziona con budget limitati e team ridotti
• System Architect: persone che progettano sistemi e vogliono la sicurezza integrata fin dall'inizio, non aggiunta in seguito

La sfida comune che ENISA riconosce: la maggior parte delle PMI non ha un team di sicurezza dedicato, dispone di budget limitato per gli strumenti di sicurezza, e il lavoro sulla sicurezza compete costantemente con la delivery delle funzionalità.

La risposta del playbook: checklist strutturate che aiutano i team a identificare i controlli di sicurezza a rapido impatto, implementarli in modo realistico e costruire una baseline ripetibile da migliorare nel tempo.

La sicurezza lungo il ciclo di vita del prodotto

La sicurezza deve essere considerata end-to-end, indipendentemente dal modello di produzione usato (V-model, Agile o altro). Il playbook definisce sei fasi, ciascuna con azioni di sicurezza specifiche e deliverable concreti.

Principi chiave del documento:

• Usare artefatti piccoli e riutilizzabili (note di contesto di una pagina, diagrammi semplici, checklist)
• Preferire i controlli automatizzati nel CI/CD rispetto alle revisioni manuali, riservando le revisioni approfondite ai cambiamenti ad alto rischio
• Introdurre security gate veloci allineati alle cerimonie agili esistenti (Definition of Ready/Done, PR check, release checklist)

Ogni fase produce un deliverable concreto. Non si tratta di indicazioni astratte.

Quali attività di gestione del rischio raccomanda ENISA?

Le attività di gestione del rischio forniscono le fondamenta per tutte le decisioni Secure by Design e Secure by Default. Il playbook non propone un framework formale pesante. Definisce invece un insieme minimo di attività che possono guidare le decisioni di sicurezza senza creare processi onerosi (Sezione 2.2).

Il documento definisce 8 attività (Tabella 2):

1. Contesto e ambito del prodotto: Definire l'uso previsto, gli ambienti di distribuzione, i ruoli utente/amministratore, i tipi/sensibilità dei dati e le principali dipendenze esterne. Deliverable: nota "Product Security Context" di 1-2 pagine (ambito, assunzioni, dipendenze).
2. Identificazione di asset e danni: Elencare i principali asset di dati, hardware o funzionalità (credenziali, dati clienti, PII, controllo del dispositivo) e i principali scenari di danno (violazione della privacy, compromissione, interruzione del servizio, frode, impatto sulla sicurezza). Deliverable: Lista degli asset + lista dei "danni principali" (una pagina).
3. Threat modelling leggero: Vedere la sezione sul threat modelling di seguito.
4. Registro dei rischi: Registrare 10-30 rischi con probabilità/impatto (scala semplice), proprietario, trattamento, stato. Collegare i rischi elevati agli elementi del backlog/controlli. Deliverable: Registro dei rischi dinamico (foglio di calcolo o board dei ticket).
5. Criteri di accettazione del rischio: Definire un insieme di condizioni di rischio non negoziabili. Ad esempio: l'utilizzo improprio degli aggiornamenti software, l'accesso amministrativo non autorizzato, o lo sfruttamento delle credenziali di default NON sono accettabili. Stabilire criteri per accettare i rischi residui che non devono compromettere i requisiti essenziali di cibersicurezza. Deliverable: Policy di accettazione del rischio ed eccezioni di 1 pagina.
6. Baseline dei requisiti di sicurezza: Tradurre i rischi principali in requisiti "must" testabili (authn/authz, default sicuri, segreti, cifratura, logging, aggiornamenti). Deliverable: Checklist dei requisiti di sicurezza per PMI (controlli testabili).
7. Gate di revisione del rischio prima del rilascio: Gate formale pre-rilascio: confermare che la checklist sia completata, i default verificati, le vulnerabilità note categorizzate, i rischi elevati trattati/accettati con motivazione. Decidere go/no-go. Deliverable: Record della revisione di sicurezza del rilascio + eccezioni documentate.
8. Rivalutazione innescata da modifiche: Ripetere i passaggi di contesto/minacce/rischi quando si verificano modifiche significative (architettura, modello di autenticazione, dipendenza/fornitore critico, ambiente di distribuzione, a seguito di incidenti). Deliverable: Nota di contesto aggiornata, shortlist delle minacce e voci del registro dei rischi (con data).

Come dovrebbero approcciare il threat modelling le PMI?

Il playbook si basa sulla metodologia STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) come fondamento per l'identificazione e la classificazione delle minacce (Sezione 2.3).

Mette esplicitamente in guardia contro gli anti-pattern comuni: trattare il threat modelling come un esercizio di conformità una tantum, creare modelli eccessivamente complessi che non influenzano le decisioni di design o secure-by-default, e non rivedere il modello a seguito di modifiche sostanziali al prodotto o cambiamenti nel panorama delle minacce.

Per le PMI, in particolare quelle che sviluppano prodotti destinati ad ambienti non critici o a rischio inferiore, l'obiettivo è un modello "minimum viable": veloce da produrre, facile da aggiornare e strettamente collegato alla delivery (decisioni architetturali, configurazione di default e release gate).

I 5 passi (Tabella 3)

1. Definire ambito, assunzioni e obiettivi di sicurezza: Limitare nel tempo la fase di scoping. Registrare cosa è in/fuori dall'ambito, il contesto di distribuzione e le assunzioni su cui ci si basa (es. "la rete del cliente non è attendibile", "le API cloud sono esposte su internet"). Indicare gli obiettivi di sicurezza rilevanti per il prodotto (confidenzialità, integrità, disponibilità, più privacy/sicurezza se applicabile). Identificare i "gioielli della corona": cosa non deve assolutamente fallire. Deliverable: "Threat Model Scope & Objectives" di 1 pagina.

2. Modellare il sistema a un livello di astrazione utile: Produrre un unico, semplice diagramma architetturale o di flusso dati. Mostrare i componenti principali, le entità esterne, gli archivi di dati e i principali punti di ingresso e flussi di dati. Un diagramma in stile DFD è l'approccio più rapido ad alto valore. Il documento dice "non complicare troppo". Deliverable: Diagramma che copre componenti principali, entità esterne, archivi di dati, punti di ingresso.

3. Contrassegnare i trust boundary e i percorsi privilegiati; identificare gli asset chiave: Annotare il diagramma con i trust boundary (internet-backend, dispositivo-cloud, utente-admin, tenant-tenant) e le operazioni con i maggiori privilegi (aggiornamento firmware/OTA, amministrazione remota, provisioning delle chiavi, emissione di identità). Questo passaggio trasforma "architettura" in "architettura rilevante per la sicurezza". Deliverable: Diagramma con trust boundary, percorsi privilegiati, asset principali.

4. Identificare e prioritizzare le minacce principali (5-10 casi d'abuso): Generare un elenco breve di casi d'abuso realistici mappati ai punti di ingresso e ai boundary (es. "credential stuffing, takeover dell'account", "aggiornamento malevolo", "bypass dell'autorizzazione API", "MITM durante l'onboarding"). Classificarli con uno schema leggero (Alto/Medio/Basso) basato su impatto e plausibilità. OWASP descrive l'identificazione e la classificazione delle minacce come un passaggio centrale nella maggior parte degli approcci di threat modelling. Deliverable: Tabella delle minacce principali con 5-10 casi d'abuso, impatto + probabilità, lista dei "rischi principali".

5. Definire mitigazioni, default sicuri e verifica; impostare i trigger di aggiornamento: Per ogni minaccia principale, specificare la strategia di mitigazione, il/i controllo/i necessario/i e il setting secure-by-default che deve essere distribuito (es. "interfaccia admin disabilitata per default", "nessuna password di default", "aggiornamenti firmati forzati", "ruoli con least privilege", "tentativi di autenticazione con rate limiting"). Mappare ogni controllo a un metodo di verifica (controlli CI, test, validazione della configurazione, release gate). Definire i trigger che richiedono di ripetere il modello (nuova interfaccia esposta su internet, cambio del modello di autenticazione, nuovi dati sensibili, nuova dipendenza critica, modifica architetturale importante). Deliverable: Checklist di Controlli, Default e Verifica.

Quali sono i 22 principi di sicurezza?

Il documento definisce 22 principi di sicurezza (Sezione 3), ciascuno dei quali ha il proprio playbook di una pagina nella Sezione 4. I playbook sono il deliverable principale del documento. Ognuno distilla un singolo principio in una guida orientata all'esecuzione con una checklist, prove minime e criteri di release gate. I principi sono organizzati in due pilastri: Secure by Design (come il sistema viene progettato, 14 principi) e Secure by Default (come il prodotto si presenta e si comporta al primo avvio, 8 principi). Ogni pilastro è ulteriormente diviso in due gruppi.

Fondamenti Architetturali (6 principi)

Si occupano di come il sistema è strutturalmente progettato e costruito:

1. Trust boundary e threat modelling: Rendere il trust esplicito. Definire dove i dati, le identità e i contesti di esecuzione attraversano dalle zone attendibili a quelle non attendibili. Fare threat modelling per identificare cosa potrebbe andare storto a quei boundary.
2. Least privilege: Concedere solo l'accesso minimo necessario. Applicarlo in modo coerente tra account utente, account di servizio, API e ruoli admin. Elevare solo quando necessario, per la durata più breve possibile.
3. Architettura di identità e autenticazione forte: Approccio chiaro per come le identità vengono create, verificate e gestite per utenti, dispositivi, servizi e amministratori. Resistente a credential stuffing, replay e session hijacking.
4. Minimizzazione della superficie di attacco: Ridurre la complessità. Rimuovere gli account di default, disinstallare i pacchetti non usati, chiudere le porte non essenziali, limitare le interfacce di gestione esposte. Vulnerability scanning continuo.
5. Defence in depth: Controlli a strati in modo che il fallimento di uno non significhi una compromissione totale. Controlli preventivi, detective e correttivi. Diversi e indipendenti, non tutti basati sulla stessa tecnologia o assunzione di trust.
6. Design aperto (evitare l'oscurità): Non dipendere dalla segretezza del design per la protezione. Usare algoritmi e protocolli ben studiati, documentazione chiara e design che resistono al scrutinio. La sicurezza deve basarsi su chiavi protette, autenticazione forte e implementazione robusta, non su meccanismi nascosti.

Integrità Operativa (8 principi)

Si occupano di come il sistema viene gestito e mantenuto:

1. Gestione del ciclo di vita: La sicurezza si estende oltre lo sviluppo. Mantenere, aggiornare e ritirare in modo controllato. Applicare il secure by design dallo sviluppo fino alla dismissione.
2. Design centrato sull'utente: La sicurezza deve essere utilizzabile dagli utenti comuni. Una scarsa usabilità porta a workaround insicuri. Setup semplice, cifratura automatica, flussi guidati.
3. Pratiche di secure coding: Seguire gli standard di secure coding consolidati. Strumenti SAST, SCA per le dipendenze, DAST prima della distribuzione. Identificazione precoce, non dopo il rilascio.
4. Logging, monitoraggio e alerting: Generare log rilevanti per la sicurezza, conservarli per un periodo definito e proteggerli dalla manomissione. Rilevare comportamenti sospetti (auth fallita, escalation di privilegi, modifiche di configurazione inattese).
5. Gestione della configurazione e delle modifiche: Le configurazioni devono essere controllate, coerenti e verificabili. Hardening baseline, infrastructure-as-code, processo di modifica con revisione/test/approvazione/rollback.
6. Risposta agli incidenti e recupero: Prepararsi per vulnerabilità, codice compromesso, aggiornamenti malevoli, uso improprio del prodotto. Ruoli definiti, percorsi di escalation, playbook documentati, comunicazione ai clienti.
7. Gestione delle vulnerabilità e delle patch: Pratica, ripetibile, prioritizzata per rischio. Canale di segnalazione semplice (email di sicurezza + processo di disclosure), processo di triage interno, SLA chiari.
8. Controlli sulla supply chain: Proteggere l'integrità del prodotto nei punti ad alto impatto: repository di codice, sistemi di build, chiavi di firma, canali di distribuzione. Al minimo: accesso CI/CD limitato, MFA, revisione tra pari per le modifiche critiche alla sicurezza, SBOM.

Hardening di Default (4 principi)

Garantiscono che i prodotti partano in uno stato sicuro e restrittivo:

1. Minimizzazione dei servizi di default: Funzionalità e servizi non essenziali disabilitati per default. L'utente deve esplicitamente effettuare l'opt-in.
2. Accesso iniziale restrittivo: Eliminare le credenziali universali "admin/admin". Imporre password univoche e cambio obbligatorio al primo avvio.
3. Comunicazione sicura per default: Tutte le comunicazioni esterne cifrate e autenticate dalla prima connessione. Applicare rigorosamente TLS 1.3 o SSH. Nessun fallback HTTP/Telnet.
4. Identità e segreti del dispositivo univoci per default: Distribuire con credenziali per-device univoche e identità crittografica. Nessuna chiave o certificato condiviso tra i prodotti. Protetto contro l'estrazione.

Protezione Guidata (4 principi)

Supportano gli utenti nel mantenimento della sicurezza dopo la distribuzione:

1. Onboarding di sicurezza obbligatorio: Le funzionalità di sicurezza critiche devono far parte della procedura guidata di configurazione iniziale (MFA, chiave di cifratura, configurazione dell'account admin). Non nascondere nelle impostazioni. Bloccare l'operatività finché non è completata.
2. Manutenzione e aggiornamenti automatizzati: Aggiornamenti di sicurezza automatici abilitati per default. Separare gli aggiornamenti di sicurezza da quelli delle funzionalità. Verificati crittograficamente. Modalità di fallimento sicure (non bloccare il dispositivo). Notificare gli utenti.
3. Postura di sicurezza trasparente: Mostrare chiaramente lo stato di sicurezza attuale. Avvertire quando l'utente riduce la sicurezza. Spiegare l'impatto in linguaggio semplice. Offrire un percorso con un clic per ripristinare la baseline sicura.
4. Recupero sicuro e ciclo di vita della proprietà: Recupero guidato (reset delle credenziali, recupero dell'account, factory reset, trasferimento della proprietà). Semplice per gli utenti ma resistente al takeover dell'account e al social engineering. Il factory reset deve rimuovere completamente l'accesso dell'utente precedente.

Collegamento CRA: L'Allegato C del playbook mappa ciascuno di questi 22 principi a specifici requisiti essenziali dell'Allegato I del CRA, mostrando esattamente quali pratiche ingegneristiche supportano quali obblighi legali.

Come funzionano i playbook?

Il formato del playbook

La Sezione 4 è la parte più estesa del documento. Fornisce un modo pratico e leggero per le PMI di implementare la Security by Design and Default senza creare un onere di governance pesante. Ogni playbook distilla un singolo principio di sicurezza in una guida di una pagina, orientata all'esecuzione, che i team possono applicare ripetutamente tra rilasci e linee di prodotto (Sezione 4, p28).

L'intento è tradurre i principi di sicurezza da aspirazioni astratte in azioni ingegneristiche e operative concrete, con aspettative chiare, risultati verificabili e una "definition of done" coerente per la sicurezza. Ogni playbook segue lo stesso formato in cinque sezioni:

• Nome del principio: il concetto di sicurezza da implementare
• Obiettivo: cosa cerca di raggiungere il principio e quali modalità di fallimento riduce
• Checklist: le azioni ad alto impatto da implementare (progettate per essere realizzabili da team snelli)
• Prove minime: il più piccolo insieme di artefatti, log o configurazioni che dimostrano che la checklist è stata implementata
• Release gate: un insieme di criteri pass/fail pronti all'uso, utilizzabili in una revisione del rilascio o nel CI/CD per prevenire regressioni

Usare i playbook

• Trattare il release gate di ogni playbook come un punto fisso nell'agenda delle revisioni di prontezza al rilascio
• Implementare le prove minime come artefatti del repository e output CI dove possibile
• Consentire eccezioni solo con motivazione documentata, proprietario e data di revisione
• Aggiornare periodicamente i playbook in base agli apprendimenti dagli incidenti, ai trend delle vulnerabilità e alle modifiche del prodotto
• Il contenuto deve essere trattato come una baseline, non come uno stato finale. Rivedere e aggiornare man mano che i prodotti evolvono.

Tutti i 22 playbook in sintesi

Fondamenti Architetturali:

Integrità Operativa:

Hardening di Default:

Protezione Guidata:

Approfondimento: Playbook 4.13, Gestione delle vulnerabilità e delle patch

Per mostrare la profondità pratica del formato, ecco il Playbook 4.13 nel dettaglio completo come appare nel documento:

Principio: La gestione delle vulnerabilità e delle patch deve essere pratica, ripetibile e prioritizzata per rischio. I produttori hanno bisogno di un modo semplice per consentire a clienti e ricercatori di segnalare i problemi, e di un processo interno per categorizzare rapidamente i risultati e decidere quali richiedono azione urgente.

Obiettivo: Identificare, prioritizzare e rimediare alle vulnerabilità abbastanza rapidamente da ridurre l'esposizione nel mondo reale, nel codice, nelle dipendenze, nell'infrastruttura e (se applicabile) nei dispositivi/firmware. Il focus è un workflow semplice dall'intake alla correzione, SLA chiari e un meccanismo di aggiornamento che rende affidabile il patching.

Checklist:

Prove minime:

• Board/registro di tracking delle vuln: problema, severità, componenti/versioni interessati, proprietario, stato, data target
• SLA definiti (esempio): Triage Critico entro 48 ore; target di remediation/rilascio entro X giorni (impostare sulla propria realtà)
• Evidenze di scansione: output CI per la scansione delle dipendenze + SAST (e DAST se applicabile)
• Patch proattive delle dipendenze: SBOM o inventario delle dipendenze per rilascio (al minimo per gli artefatti distribuiti)
• Record di rilascio della patch: collegamento dal ticket vuln alla/e PR ai test alla versione di rilascio alla conferma del rollout
• Log delle eccezioni: i rischi accettati hanno proprietario + data di scadenza/revisione e controlli compensativi (se presenti)

Release gate:

• Scansioni delle dipendenze e SAST eseguite per il rilascio; risultati Critici/Alti risolti o documentati con eccezione (proprietario + scadenza)
• SBOM (o inventario delle dipendenze) generato/aggiornato e archiviato per il rilascio
• Le vulnerabilità note che interessano i componenti distribuiti sono categorizzate con severità, proprietario e data target
• Processo di patching validato: correzione revisionata, test superati e note di rilascio aggiornate se necessario
• Per i componenti esposti su internet: mitigazioni o patch per Critici/Alti in atto prima del rilascio
• OTA/aggiornamento (se applicabile) validato per la distribuzione sicura; rollback/recupero documentato
• Il rischio residuo accettato è a tempo determinato e tracciato fino alla chiusura o alla data di revisione

Cosa sono i Machine-Readable Security Manifest?

La Sezione 5 del playbook introduce un nuovo concetto: il passaggio da una conformità statica e basata su documenti a attestazioni di sicurezza verificabili e leggibili da macchina.

Un'attestazione di sicurezza machine-readable è una dichiarazione digitale in JSON o YAML che asserisce che uno specifico controllo di sicurezza, processo o proprietà è stato soddisfatto. A differenza dei report PDF statici, queste attestazioni possono essere generate e consumate da sistemi automatizzati, consentendo aggiornamenti frequenti e validazione automatizzata. Integrate nella pipeline di sviluppo, la sicurezza diventa intrinseca, non una casella da spuntare dopo lo sviluppo.

Quattro proprietà chiave

• Dimostrabilità: capacità proattiva di fornire prove leggibili da macchina che i requisiti di sicurezza siano stati implementati, un passaggio dal "dichiarare" al "dimostrare"
• Verificabilità: una parte indipendente può autenticare e validare programmaticamente l'integrità delle affermazioni di sicurezza, trasparente, a prova di manomissione e mappata a una root of trust riconosciuta
• Riusabilità: usare le attestazioni esistenti per costruire su di esse, integrarle nel ciclo di sviluppo e includerle nei quality gate agile
• Affidabilità: fare affidamento sulle attestazioni per la due diligence di terze parti, semplificando il trust nella supply chain

Il modello a quattro livelli

Il playbook illustra un modello di dati gerarchico in cui ogni affermazione di sicurezza di alto livello è supportata da prove tecniche granulari:

1. Metadati e Attestazione (dominio Identity): identità del prodotto, versionamento, firma crittografica del produttore
2. Control Layer (dominio Governance): obiettivi di sicurezza strutturati allineati a requisiti, principi e normative
3. Implementation Layer / Mappa Minacce-Mitigazioni (dominio Operational): mappa le minacce specifiche alle mitigazioni implementate, ai principi di design, alle impostazioni di default e alle descrizioni leggibili dall'uomo
4. Assessment & Verification Layer (dominio Evidence): risultati pass/fail machine-readable da gate automatizzati, con collegamenti agli SBOM

Il documento descrive anche livelli di controllo degli accessi: un JSON pubblico che fornisce affermazioni di alto livello e un Overlay Tecnico Ristretto contenente configurazioni dettagliate degli strumenti cifrate e telemetria di test.

Ecosistema esistente

Il playbook colloca l'MRSM nel panorama degli standard esistenti:

• OSCAL (NIST): "Compliance as Code", cataloghi standardizzati di controlli di sicurezza, piani di sicurezza dei sistemi, risultati di valutazione
• CycloneDX CDXA (OWASP/ECMA-424): originariamente un formato SBOM, ampliato a uno standard di trasparenza completo. Attestazioni CDXA per le affermazioni di sicurezza, VEX per la sfruttabilità, CBOM per gli asset crittografici
• OpenSSF: Security Insights (fatti di sicurezza machine-readable in YAML), Scorecard (valutazione automatizzata delle best practice)
• OWASP ASVS: Application Security Verification Standard, requisiti sottostanti. MLSVS esteso ad AI/ML
• TC54 (Ecma International): Transparency Exchange API, standardizzazione di come gli SBOM e le attestazioni vengono scoperti e condivisi

L'esempio concreto SafeGate-X1

Il documento include uno scenario completo (pagine 56-61) che mostra come un produttore fittizio di controller hardware implementerebbe l'MRSM: un threat model con 5 minacce (RCE via API web, escalation di privilegi, port scanning, credential stuffing, manomissione dei binari), controlli mappati ai principi e un manifest JSON che mostra come ogni threat_id si mappa a un principio, mitigation_control, secure_by_default_setting e verification_gate con evidence_hash. Include anche una tabella di verifica di terze parti che mostra cosa possono verificare a campione gli auditor.

Come si mappano i principi ai requisiti CRA?

L'Allegato C del playbook fornisce una mappatura completa di tutti i 22 principi ai requisiti essenziali specifici dell'Allegato I del CRA. Questo è il ponte ingegneristico tra le indicazioni del playbook e gli obblighi legali.

L'Allegato I del CRA è diviso in due parti:

• Parte 1 (ANNEX-1.PT1): requisiti di sicurezza del prodotto, che coprono 14 requisiti: valutazione del rischio di cibersicurezza, default sicuri, aggiornamenti, controllo degli accessi, protezione dei dati, integrità, minimizzazione dei dati, disponibilità, limitazione della superficie di attacco, mitigazione degli incidenti, logging e cancellazione sicura dei dati
• Parte 2 (ANNEX-1.PT2): requisiti di gestione delle vulnerabilità, che coprono 8 requisiti: SBOM, remediation tempestiva, test, disclosure, VDP coordinato, intake delle vulnerabilità, distribuzione sicura delle correzioni e divulgazione tempestiva

Ogni principio si mappa a più requisiti CRA. Ecco alcuni esempi selezionati dall'Allegato C:

Collegamento CRA: Il playbook non è una checklist di conformità legale, ma fornisce il ponte ingegneristico verso l'Allegato I del CRA. Se si riesce a dimostrare il rispetto di questi 22 principi, si dispone di prove sostanziali a supporto della valutazione di conformità CRA.

Cosa fare adesso?

1. Iniziare dalla Sezione 2: identificare la fase attuale del ciclo di vita e produrre i deliverable dalla Tabella 1. Anche una nota Security Context di una pagina e un diagramma architetturale di base permettono di essere avanti rispetto alla maggior parte dei team.

2. Eseguire le 8 attività di gestione del rischio (Tabella 2): la maggior parte delle PMI può produrre gli output in 1-2 giorni concentrati. Iniziare con il contesto del prodotto, l'identificazione degli asset/danni e i criteri di accettazione del rischio.

3. Fare un threat model leggero (Tabella 3): anche 2 ore con il team, usando una lavagna e STRIDE, producono risultati concreti. Concentrarsi sui 5-10 casi d'abuso più rilevanti.

4. Scegliere i 3-5 playbook più rilevanti per il prossimo rilascio e usare le checklist. Punti di partenza comuni: 4.9 (Secure coding), 4.13 (Gestione delle vulnerabilità), 4.2 (Least privilege), 4.16 (Accesso iniziale restrittivo).

5. Usare i criteri del release gate come agenda per la revisione di sicurezza pre-rilascio. Questo è il percorso più veloce da "nessun processo di revisione della sicurezza" a "security gate documentati e ripetibili".

6. Scaricare il playbook ENISA completo: si tratta di una bozza v0.4. Inviare il proprio feedback durante il periodo di consultazione.

Fonti ufficiali

• ENISA Security by Design and Default Playbook v0.4 (PDF)

Guide correlate

• CRA Product Classification Guide
• SBOM Requirements Under the CRA
• CRA Technical File (Annex VII) Guide
• CRA Vulnerability Reporting: The 24-Hour Rule
• CRA Conformity Assessment Decision Guide

Questo articolo ha scopo puramente informativo e non costituisce consulenza legale. Per indicazioni specifiche sulla conformità, si consiglia di consultare un professionista legale qualificato.