Terminologia Terminology

Glossario CRA CRA Glossary

Definizioni tecniche precise dei termini fondamentali del Cyber Resilience Act e dell'ecosistema di sicurezza dei prodotti digitali. Precise technical definitions of the fundamental terms of the Cyber Resilience Act and the digital product security ecosystem.

A
Allegato I — Annex I CRA
L'allegato principale del Cyber Resilience Act che definisce i requisiti essenziali di cybersecurity per tutti i prodotti con elementi digitali. Diviso in due parti: Parte I (requisiti di sicurezza del prodotto: Secure by Design, Secure by Default, gestione delle vulnerabilità, aggiornamenti) e Parte II (obblighi del produttore: SBOM, CVD policy, notifica vulnerabilità, politiche di aggiornamento). Tutti i prodotti soggetti al CRA devono soddisfare entrambe le parti.
The main annex of the Cyber Resilience Act that defines the essential cybersecurity requirements for all products with digital elements. Divided into two parts: Part I (product security requirements: Secure by Design, Secure by Default, vulnerability management, updates) and Part II (manufacturer obligations: SBOM, CVD policy, vulnerability notification, update policies). All products subject to the CRA must comply with both parts.
Attack Surface SecDev
La somma di tutti i vettori di attacco attraverso cui un agente malevolo potrebbe interagire con un sistema — API esposte, porte di rete aperte, input accettati, funzionalità accessibili. Il CRA richiede che i produttori minimizzino la superficie di attacco (Annex I, Parte I). La riduzione si ottiene attraverso il principio del minimo privilegio, la disabilitazione dei servizi non necessari, e la gestione rigorosa delle interfacce esterne.
The sum of all attack vectors through which a malicious actor could interact with a system — exposed APIs, open network ports, accepted inputs, accessible functionality. The CRA requires manufacturers to minimise the attack surface (Annex I, Part I). Reduction is achieved through the principle of least privilege, disabling unnecessary services, and strict management of external interfaces.
C
CE Marking CRA
La marcatura CE (Conformità Europea) è il segnale visibile che un prodotto soddisfa i requisiti obbligatori dell'UE e può essere immesso sul mercato europeo. Nel contesto CRA, apporre la marcatura CE su un prodotto con elementi digitali attesta che il prodotto è conforme a tutti i requisiti dell'Allegato I. È responsabilità del produttore (non di terzi) garantire l'accuratezza della dichiarazione. La marcatura CE non è una certificazione volontaria: è un prerequisito legale per la commercializzazione nell'UE.
The CE marking (Conformité Européenne) is the visible signal that a product meets mandatory EU requirements and can be placed on the European market. In the CRA context, affixing CE marking to a product with digital elements attests that the product complies with all Annex I requirements. It is the manufacturer's responsibility (not third parties) to ensure the accuracy of the declaration. CE marking is not a voluntary certification: it is a legal prerequisite for commercialisation in the EU.
CSIRT Organo
Computer Security Incident Response Team. Nel contesto CRA, i CSIRT nazionali (designati ai sensi della Direttiva NIS2) ricevono le notifiche di vulnerabilità attivamente sfruttate dai produttori. Ogni Stato Membro UE ha uno o più CSIRT nazionali. Il produttore deve notificare simultaneamente sia l'ENISA che il CSIRT nazionale dello Stato Membro in cui ha la sede principale.
Computer Security Incident Response Team. In the CRA context, national CSIRTs (designated under the NIS2 Directive) receive notifications of actively exploited vulnerabilities from manufacturers. Each EU Member State has one or more national CSIRTs. The manufacturer must simultaneously notify both ENISA and the national CSIRT of the Member State where it has its main establishment.
CVSS Standard
Common Vulnerability Scoring System. Sistema di scoring standardizzato (attualmente v4.0) per valutare la severità delle vulnerabilità software. Produce un punteggio da 0 a 10 in base a vettori di attacco, complessità, privilegi richiesti, interazione utente, e impatto su confidenzialità, integrità e disponibilità. Il CVSS è lo standard de facto per la prioritizzazione delle vulnerabilità nei processi CVD e nella gestione delle patch. Il CRA non impone esplicitamente CVSS ma è implicito nell'obbligo di gestione delle vulnerabilità.
Common Vulnerability Scoring System. Standardised scoring system (currently v4.0) for assessing software vulnerability severity. Produces a score from 0 to 10 based on attack vectors, complexity, required privileges, user interaction, and impact on confidentiality, integrity, and availability. CVSS is the de facto standard for vulnerability prioritisation in CVD processes and patch management. The CRA does not explicitly mandate CVSS but it is implicit in the vulnerability management obligation.
CVD — Coordinated Vulnerability Disclosure Processo
Processo strutturato per la gestione responsabile della divulgazione delle vulnerabilità di sicurezza. Prevede che i ricercatori di sicurezza notifichino privatamente il fornitore prima di rendere pubblica la vulnerabilità, dando al fornitore tempo per sviluppare e rilasciare una patch. Il CRA (Allegato I, Parte II) rende la CVD policy un obbligo esplicito per tutti i produttori di prodotti con elementi digitali. Standard di riferimento: ISO/IEC 30111 (vulnerability handling) e ISO/IEC 29147 (vulnerability disclosure).
Structured process for responsibly managing the disclosure of security vulnerabilities. Involves security researchers privately notifying the vendor before making the vulnerability public, giving the vendor time to develop and release a patch. The CRA (Annex I, Part II) makes the CVD policy an explicit obligation for all manufacturers of products with digital elements. Reference standards: ISO/IEC 30111 (vulnerability handling) and ISO/IEC 29147 (vulnerability disclosure).
CycloneDX Standard
Standard OWASP per la generazione di SBOM (Software Bill of Materials). Supporta diversi tipi di bill of materials: software (SBOM), hardware (HBOM), service (SaaSBOM), Machine Learning (ML-BOM). Il formato supporta XML e JSON. È lo standard preferito per la generazione automatizzata negli ambienti DevSecOps grazie all'ampio ecosistema di tool (cdxgen, syft, trivy). Il CRA non impone CycloneDX specificamente ma è il formato più adottato nel contesto della conformità al regolamento.
OWASP standard for SBOM (Software Bill of Materials) generation. Supports multiple bill of materials types: software (SBOM), hardware (HBOM), service (SaaSBOM), Machine Learning (ML-BOM). The format supports XML and JSON. It is the preferred standard for automated generation in DevSecOps environments due to the extensive tool ecosystem (cdxgen, syft, trivy). The CRA does not specifically mandate CycloneDX but it is the most widely adopted format in the regulatory compliance context.
D
DAST — Dynamic Application Security Testing Testing
Tecnica di testing di sicurezza che analizza l'applicazione in esecuzione (black-box), simulando attacchi reali senza accesso al codice sorgente. Strumenti principali: OWASP ZAP, Burp Suite, Nuclei. Il DAST è complementare al SAST (che analizza il codice statico) e va integrato nelle fasi di staging/pre-produzione del pipeline CI/CD. Individua vulnerabilità runtime come injection, autenticazione difettosa, CSRF, e misconfiguration.
Security testing technique that analyses a running application (black-box), simulating real attacks without access to the source code. Main tools: OWASP ZAP, Burp Suite, Nuclei. DAST is complementary to SAST (which analyses static code) and should be integrated into the staging/pre-production phases of the CI/CD pipeline. It identifies runtime vulnerabilities such as injection, broken authentication, CSRF, and misconfiguration.
Dichiarazione di Conformità UE — EU DoC CRA
Documento formale (Allegato V del CRA) con cui il produttore dichiara sotto la propria esclusiva responsabilità che il prodotto con elementi digitali è conforme ai requisiti del CRA. Deve contenere: identificazione del prodotto, riferimento alle norme applicate, eventuale riferimento all'Organismo Notificato, nome e firma del responsabile. Deve essere conservata per 10 anni. È diversa e aggiuntiva rispetto alla documentazione tecnica (Allegato VII).
Formal document (CRA Annex V) by which the manufacturer declares under their sole responsibility that the product with digital elements conforms to the CRA requirements. Must contain: product identification, reference to applied standards, any reference to the Notified Body, name and signature of the responsible person. Must be retained for 10 years. It is distinct from and additional to the technical documentation (Annex VII).
E
ENISA Organo
European Union Agency for Cybersecurity. Agenzia dell'UE con sede ad Atene (e ufficio a Bruxelles) responsabile della sicurezza informatica a livello europeo. Nel contesto CRA, l'ENISA: (1) riceve le notifiche di vulnerabilità attivamente sfruttate dai produttori entro 24 ore (Art. 14), (2) mantiene una base dati europea delle vulnerabilità, (3) supporta la Commissione nell'elaborazione di linee guida tecniche, (4) coordina con i CSIRT nazionali. L'ENISA non è un ente di certificazione: non rilascia attestati di conformità CRA.
European Union Agency for Cybersecurity. EU agency headquartered in Athens (with a Brussels office) responsible for cybersecurity at the European level. In the CRA context, ENISA: (1) receives notifications of actively exploited vulnerabilities from manufacturers within 24 hours (Art. 14), (2) maintains a European vulnerability database, (3) supports the Commission in developing technical guidelines, (4) coordinates with national CSIRTs. ENISA is not a certification body: it does not issue CRA compliance certificates.
F
Fabbricante / Produttore — Manufacturer CRA
Persona fisica o giuridica che sviluppa o fa sviluppare prodotti con elementi digitali e li immette sul mercato UE con il proprio nome o marchio commerciale, a pagamento o gratuitamente. È il soggetto su cui ricadono gli obblighi principali del CRA: conformità dell'Allegato I, documentazione tecnica, dichiarazione di conformità, marcatura CE, notifica vulnerabilità, politica CVD. Distinto dall'importatore (che importa da paesi terzi) e dal distributore (che distribuisce senza modificare).
A natural or legal person who develops or has developed products with digital elements and places them on the EU market under their own name or trademark, for payment or free of charge. The entity on which the main CRA obligations fall: Annex I compliance, technical documentation, declaration of conformity, CE marking, vulnerability notification, CVD policy. Distinct from the importer (who imports from third countries) and the distributor (who distributes without modification).
H
HSM — Hardware Security Module Hardware
Dispositivo hardware dedicato alla gestione sicura di chiavi crittografiche, alla generazione di numeri casuali certificata, e all'esecuzione di operazioni crittografiche in un ambiente fisicamente isolato e tamper-resistant. Gli HSM sono classificati come prodotti critici (Classe II) nell'Allegato III del CRA, richiedendo obbligatoriamente la valutazione da parte di un Organismo Notificato. Standard di riferimento: FIPS 140-3, Common Criteria EAL4+.
Hardware device dedicated to the secure management of cryptographic keys, certified random number generation, and cryptographic operations in a physically isolated, tamper-resistant environment. HSMs are classified as critical products (Class II) in CRA Annex III, mandatorily requiring assessment by a Notified Body. Reference standards: FIPS 140-3, Common Criteria EAL4+.
I
ICS / SCADA OT
Industrial Control Systems / Supervisory Control and Data Acquisition. Sistemi di controllo industriale utilizzati per monitorare e controllare processi fisici in settori critici (energia, acqua, produzione, trasporti). I sistemi ICS/SCADA destinati a settori critici sono classificati nell'Allegato III del CRA come prodotti critici. Il framework di riferimento per la sicurezza è IEC 62443 (sicurezza dei sistemi di automazione e controllo industriale).
Industrial Control Systems / Supervisory Control and Data Acquisition. Industrial control systems used to monitor and control physical processes in critical sectors (energy, water, manufacturing, transport). ICS/SCADA systems intended for critical sectors are classified in CRA Annex III as critical products. The reference security framework is IEC 62443 (security of industrial automation and control systems).
M
Marcatura CE → vedi CE Marking
MSA — Market Surveillance Authority Organo
Autorità Nazionale di Vigilanza del Mercato. Ogni Stato Membro UE designa una o più autorità responsabili del controllo della conformità dei prodotti con elementi digitali ai requisiti CRA. Le MSA hanno il potere di: condurre ispezioni, richiedere documentazione tecnica, ordinare test indipendenti, emettere sanzioni amministrative, disporre il ritiro o il richiamo di prodotti non conformi. In Italia, l'autorità è ancora in corso di designazione definitiva (probabilmente ACNCS o MIMIT).
National Market Surveillance Authority. Each EU Member State designates one or more authorities responsible for controlling conformity of products with digital elements to CRA requirements. MSAs have the power to: conduct inspections, request technical documentation, order independent tests, issue administrative penalties, order the withdrawal or recall of non-compliant products. In Italy, the authority is still being definitively designated (likely ACNCS or MIMIT).
N
NIS2 Regolamento
Direttiva (UE) 2022/2555 sulla sicurezza delle reti e dei sistemi informativi (Network and Information Systems 2). Disciplina la sicurezza degli operatori (aziende e infrastrutture critiche) mentre il CRA disciplina la sicurezza dei prodotti. Le due normative si sovrappongono parzialmente: un produttore di prodotti con elementi digitali che è anche operatore di servizi essenziali deve rispettare entrambe. NIS2 si applica a settori: energia, trasporti, bancario, infrastrutture digitali, sanità, acque, spazio.
Directive (EU) 2022/2555 on the security of network and information systems. Governs operator security (companies and critical infrastructure) while the CRA governs product security. The two regulations partially overlap: a manufacturer of products with digital elements who is also an operator of essential services must comply with both. NIS2 applies to sectors: energy, transport, banking, digital infrastructure, healthcare, water, space.
Notified Body — Organismo Notificato Organo
Organismo di valutazione della conformità accreditato e riconosciuto formalmente da uno Stato Membro UE per effettuare audit di terza parte ai sensi del CRA. Gli Organismi Notificati valutano i prodotti "importanti" (Classe I) e "critici" (Classe II) che richiedono verifica indipendente. L'elenco ufficiale degli Organismi Notificati è disponibile nel database NANDO (New Approach Notified and Designated Organisations) della Commissione Europea. La designazione degli ON per il CRA è ancora in corso.
Conformity assessment body accredited and formally recognised by an EU Member State to carry out third-party audits under the CRA. Notified Bodies assess "important" (Class I) and "critical" (Class II) products requiring independent verification. The official list of Notified Bodies is available in the European Commission's NANDO (New Approach Notified and Designated Organisations) database. The designation of NBs for the CRA is still ongoing.
O
OSS Steward — Open Source Steward CRA
Categoria introdotta dal CRA per le persone giuridiche che forniscono supporto sistematico e continuativo allo sviluppo di prodotti open source rilevanti per il CRA, senza essere produttori in senso stretto. Gli OSS Steward hanno obblighi alleggeriti rispetto ai produttori: non devono apporre la marcatura CE ma devono implementare una politica CVD e cooperare con le autorità di vigilanza. La categoria è pensata per fondazioni open source e aziende che maintengono progetti critici come dipendenze di prodotti commerciali.
Category introduced by the CRA for legal entities that provide systematic and continuous support for the development of CRA-relevant open source products, without being manufacturers in the strict sense. OSS Stewards have lighter obligations than manufacturers: they do not need to affix CE marking but must implement a CVD policy and cooperate with surveillance authorities. The category is designed for open source foundations and companies that maintain critical projects as dependencies of commercial products.
P
PSIRT — Product Security Incident Response Team Team
Team interno di un produttore responsabile della ricezione, valutazione, coordinamento e risposta agli incidenti di sicurezza che coinvolgono i propri prodotti. Il PSIRT è la struttura organizzativa che implementa operativamente la CVD policy e gestisce le notifiche all'ENISA/CSIRT richieste dal CRA. Un PSIRT efficace ha: un canale di ricezione segnalazioni dedicato (email security@ + PGP key), SLA di risposta, processo di triage, e capacità di coordinamento con il team di sviluppo per le patch.
Internal team of a manufacturer responsible for receiving, assessing, coordinating, and responding to security incidents involving their products. The PSIRT is the organisational structure that operationally implements the CVD policy and manages notifications to ENISA/CSIRT required by the CRA. An effective PSIRT has: a dedicated reporting channel (security@ email + PGP key), response SLAs, triage process, and coordination capability with the development team for patches.
S
SAST — Static Application Security Testing Testing
Tecnica di testing di sicurezza che analizza il codice sorgente, bytecode o binario senza eseguire l'applicazione (white-box). Identifica vulnerabilità come SQL injection, XSS, buffer overflow, uso di API deprecate, e misconfiguration direttamente nel codice. Strumenti open source: Semgrep, CodeQL (GitHub). Va integrato nel pipeline CI/CD come "security gate" che blocca i merge in caso di finding critici.
Security testing technique that analyses source code, bytecode, or binary without executing the application (white-box). Identifies vulnerabilities such as SQL injection, XSS, buffer overflow, use of deprecated APIs, and misconfiguration directly in the code. Open source tools: Semgrep, CodeQL (GitHub). Should be integrated in the CI/CD pipeline as a "security gate" that blocks merges in case of critical findings.
SBOM — Software Bill of Materials Artefatto
Inventario formale e strutturato di tutti i componenti software di un prodotto: librerie, dipendenze, versioni, licenze, origini. Analogo alla distinta base (BOM) in produzione. Il CRA (Allegato I, Parte I) richiede esplicitamente che i produttori identifichino e documentino le dipendenze software, rendendo l'SBOM uno strumento essenziale per la conformità. Formati standard: CycloneDX (OWASP) e SPDX (Linux Foundation). Deve essere generato automaticamente nella pipeline CI/CD e aggiornato ad ogni release.
A formal, structured inventory of all software components in a product: libraries, dependencies, versions, licences, origins. Analogous to the bill of materials (BOM) in manufacturing. The CRA (Annex I, Part I) explicitly requires manufacturers to identify and document software dependencies, making the SBOM an essential compliance tool. Standard formats: CycloneDX (OWASP) and SPDX (Linux Foundation). Should be automatically generated in the CI/CD pipeline and updated with every release.
SDLC — Secure Development Lifecycle Processo
Insieme strutturato di processi, pratiche e controlli che integrano attività di sicurezza in ogni fase del ciclo di vita di un prodotto software o hardware: Requirements → Design → Implementation → Testing → Deployment → Operations → End of Life. Detto anche S-SDLC o Secure SDLC. Il CRA impone che la sicurezza sia integrata "by design e by default" nel processo di sviluppo (Annex I), rendendo un SDLC formale un requisito di fatto. Framework di riferimento: Microsoft SDL, NIST SSDF (SP 800-218), OWASP SAMM.
A structured set of processes, practices, and controls that integrate security activities into every phase of a software or hardware product lifecycle: Requirements → Design → Implementation → Testing → Deployment → Operations → End of Life. Also called S-SDLC or Secure SDLC. The CRA requires security to be integrated "by design and by default" into the development process (Annex I), making a formal SDLC a de facto requirement. Reference frameworks: Microsoft SDL, NIST SSDF (SP 800-218), OWASP SAMM.
Secure by Default Principio
Principio di progettazione per cui un prodotto viene rilasciato con la configurazione più sicura possibile abilitata per impostazione predefinita, senza richiedere configurazione aggiuntiva da parte dell'utente. Esempi: password univoche per ogni dispositivo (non password universali), porta di rete chiuse per default, crittografia abilitata di default, funzionalità non necessarie disabilitate. Il CRA richiede esplicitamente che i prodotti siano Secure by Default (Annex I, Parte I).
Design principle whereby a product is released with the most secure possible configuration enabled by default, without requiring additional configuration from the user. Examples: unique passwords per device (not universal passwords), network ports closed by default, encryption enabled by default, unnecessary features disabled. The CRA explicitly requires products to be Secure by Default (Annex I, Part I).
Secure by Design Principio
Approccio allo sviluppo in cui la sicurezza è un requisito primario integrato fin dalla fase di progettazione, non un'aggiunta successiva. Implica: threat modeling come attività standard nel design, architetture che minimizzano la superficie di attacco, principio del minimo privilegio applicato a tutti i componenti, e processi di sviluppo che includono revisione di sicurezza sistematica. Contrapposto al "security as afterthought" dove la sicurezza viene aggiunta come strato finale. Il CRA impone Secure by Design come requisito obbligatorio (Annex I, Parte I).
Development approach in which security is a primary requirement integrated from the design phase, not bolted on afterwards. Implies: threat modeling as a standard design activity, architectures that minimise the attack surface, principle of least privilege applied to all components, and development processes that include systematic security review. Contrasted with "security as afterthought" where security is added as a final layer. The CRA mandates Secure by Design as an obligatory requirement (Annex I, Part I).
SPDX — Software Package Data Exchange Standard
Standard ISO/IEC 5962:2021 (Linux Foundation) per la comunicazione di informazioni su componenti software: licenze, copyright, provenance. È lo standard SBOM più diffuso nell'ecosistema open source e tooling Linux. Supporta formati: TV (Tag-Value), JSON, YAML, XML, RDF. Concorrente e parzialmente complementare a CycloneDX: alcuni team usano SPDX per il licensing e CycloneDX per la sicurezza/vulnerabilità. Tool: syft, spdx-sbom-generator.
ISO/IEC 5962:2021 standard (Linux Foundation) for communicating information about software components: licences, copyright, provenance. The most widely adopted SBOM standard in the open source ecosystem and Linux tooling. Supported formats: TV (Tag-Value), JSON, YAML, XML, RDF. Competitor and partial complement to CycloneDX: some teams use SPDX for licensing and CycloneDX for security/vulnerability. Tools: syft, spdx-sbom-generator.
T
TARA — Threat Analysis and Risk Assessment Metodo
Metodologia di analisi delle minacce e valutazione del rischio sviluppata nell'ambito dello standard automotive ISO/SAE 21434 e spesso applicata anche a prodotti IoT e embedded. In TARA si identificano gli asset, si enumerano le minacce (using STRIDE o attack trees), si valuta la fattibilità dell'attacco e l'impatto, si calcola un risk value, e si definiscono i controlli di mitigazione. Rilevante per il CRA perché il regolamento richiede una "analisi del rischio di cybersecurity" (Annex VII) che TARA soddisfa pienamente nel contesto automotive/IoT.
Threat Analysis and Risk Assessment methodology developed within the automotive standard ISO/SAE 21434 and often applied to IoT and embedded products. In TARA, assets are identified, threats are enumerated (using STRIDE or attack trees), attack feasibility and impact are assessed, a risk value is calculated, and mitigation controls are defined. Relevant to the CRA because the regulation requires a "cybersecurity risk analysis" (Annex VII) which TARA fully satisfies in the automotive/IoT context.
Threat Modeling Processo
Processo strutturato di identificazione, enumerazione e prioritizzazione delle potenziali minacce a un sistema in fase di progettazione. L'obiettivo è identificare i rischi prima che il codice venga scritto, riducendo il costo delle correzioni. Metodologie: STRIDE (Microsoft), PASTA, LINDDUN, Attack Tree Analysis. Il threat modeling è una delle attività Secure by Design più raccomandate dal CRA e dalle linee guida ENISA. Dovrebbe produrre: DFD (Data Flow Diagram), trust boundary map, lista di minacce, e piano di mitigazione.
Structured process for identifying, enumerating, and prioritising potential threats to a system during design. The goal is to identify risks before code is written, reducing the cost of fixes. Methodologies: STRIDE (Microsoft), PASTA, LINDDUN, Attack Tree Analysis. Threat modeling is one of the Secure by Design activities most recommended by the CRA and ENISA guidelines. Should produce: DFD (Data Flow Diagram), trust boundary map, threat list, and mitigation plan.
V
VEX — Vulnerability Exploitability eXchange Artefatto
Formato strutturato per comunicare lo stato di exploitability delle vulnerabilità note (CVE) rispetto a un prodotto specifico. Il VEX permette a un produttore di dichiarare che una CVE nota in una dipendenza NON è exploitable nel suo prodotto (perché il codice vulnerabile non è raggiungibile, o la funzionalità non è esposta). Questo riduce il "false positive noise" degli scanner di vulnerabilità. Standard principali: CycloneDX VEX (OWASP), CSAF VEX (OASIS), OpenVEX. Complementare all'SBOM: SBOM dice "cosa c'è", VEX dice "cosa è sfruttabile".
Structured format for communicating the exploitability status of known vulnerabilities (CVEs) with respect to a specific product. VEX allows a manufacturer to declare that a known CVE in a dependency is NOT exploitable in their product (because the vulnerable code is unreachable, or the feature is not exposed). This reduces "false positive noise" from vulnerability scanners. Main standards: CycloneDX VEX (OWASP), CSAF VEX (OASIS), OpenVEX. Complementary to SBOM: SBOM says "what's in it", VEX says "what's exploitable".
Vulnerability Management Processo
Processo continuo di identificazione, classificazione, prioritizzazione, remediation e verifica delle vulnerabilità nei prodotti software e hardware. Il CRA (Annex I, Parte I e Parte II) rende il vulnerability management un obbligo formale che include: monitoraggio continuo delle CVE nelle dipendenze (SCA), SBOM aggiornato, CVD policy, patch release process, e notifiche all'ENISA per le vulnerabilità attivamente sfruttate. Strumenti: Dependabot (GitHub), Renovate, OWASP Dependency-Check, Trivy, Grype.
Continuous process of identifying, classifying, prioritising, remediating, and verifying vulnerabilities in software and hardware products. The CRA (Annex I, Parts I and II) makes vulnerability management a formal obligation that includes: continuous CVE monitoring in dependencies (SCA), updated SBOM, CVD policy, patch release process, and notifications to ENISA for actively exploited vulnerabilities. Tools: Dependabot (GitHub), Renovate, OWASP Dependency-Check, Trivy, Grype.
Z
Zero-Trust Architecture Architettura
Modello di sicurezza basato sul principio "non fidarsi mai, verificare sempre": nessun utente, dispositivo o servizio è considerato affidabile per default, neanche quelli all'interno della rete aziendale. Ogni accesso viene autenticato, autorizzato e verificato continuamente. Rilevante per il CRA perché il principio del minimo privilegio e la minimizzazione della superficie di attacco richiesti dall'Allegato I sono elementi fondanti di un'architettura Zero Trust. Non è un prodotto da acquistare, ma un approccio architetturale.
Security model based on the principle "never trust, always verify": no user, device, or service is considered trustworthy by default, including those within the corporate network. Every access is continuously authenticated, authorised, and verified. Relevant to the CRA because the principle of least privilege and attack surface minimisation required by Annex I are foundational elements of a Zero Trust architecture. It is not a product to buy, but an architectural approach.