diff --git a/doc/security/security-citations.rst b/doc/security/security-citations.rst index 0a1750d4cf407..7a05d0fb51dcd 100644 --- a/doc/security/security-citations.rst +++ b/doc/security/security-citations.rst @@ -47,3 +47,8 @@ Security Document Citations .. [CIIBPB] Core Infrastructure Initiative Best Practices Badge. [Online]. Available: https://github.com/linuxfoundation/cii-best-practices-badge + +.. [CRA24] Regulation (EU) 2024/2847 of the European Parliament and of the Council + of 23 October 2024 on horizontal cybersecurity requirements for products with + digital elements (Cyber Resilience Act). [Online]. + Available: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847 diff --git a/doc/security/standards/cyber-resilience-act.rst b/doc/security/standards/cyber-resilience-act.rst new file mode 100644 index 0000000000000..96a93981cc62b --- /dev/null +++ b/doc/security/standards/cyber-resilience-act.rst @@ -0,0 +1,407 @@ +.. _cra_faq: + +EU Cyber Resilience Act (CRA) +############################# + +.. warning:: + This document is for informational purposes only and does not constitute legal advice. + Consult with competent legal counsel for compliance guidance specific to your situation. + +Overview +******** + +The Cyber Resilience Act ([CRA24]_) is an EU regulation that establishes cybersecurity requirements for +products with digital elements (PDEs) placed on the EU market. +It entered into force on December 10, 2024. + +.. admonition:: Key Dates + :class: important + + * **June 11, 2026**: Assessment bodies operational + * **September 11, 2026**: Manufacturers must report vulnerabilities and incidents + * **December 11, 2027**: Full regulation applies + +This document explains how the Cyber Resilience Act relates both to manufacturers using Zephyr in +commercial products, and to the Zephyr Project itself in its role as an open-source software +steward. + +For Manufacturers Using Zephyr +****************************** + +Does the CRA apply to my product? +================================= + +The CRA applies if you place a product with digital elements (PDE) on the EU market for commercial +purposes. This includes hardware devices with embedded software, and standalone software products. + +Which category does my product belong to? +========================================= + +The CRA classifies products into categories based on risk: **Important Products** (`Annex III`_) and +**Critical Products** (`Annex IV`_). Products not listed in either category are considered +**Default** products and have lower requirements. + +For example, default products can typically rely on self-assessment (see :ref:`compliance_path`) +with fewer documentation and assurance requirements. + +.. list-table:: + :header-rows: 1 + :widths: 15 25 60 + + * - Category + - Short description + - Example Zephyr Use Cases + * - Default + - Products with digital elements that are not listed as "important" or "critical". + - - Wi-Fi smart bulb or switch (e.g., running Matter over Thread/Wi-Fi). + - Wearable activity tracker or smartwatch for personal wellness. + - Bluetooth LE audio accessory or wireless sensor tag. + * - Important (Class I) + - Higher-risk products, often consumer-facing, performing security- or access-relevant + functions. + - - Smart door lock or access control reader for residential use. + - Smart home hub or router managing network traffic. + - Connected alarm system or security sensor. + * - Important (Class II) + - Higher-risk products used in enterprise/industrial/infra contexts or with privileged network + roles. + - - Industrial Programmable Logic Controller (PLC) or robot controller. + - Micro-controllers with Secure Enclave/TEEs used for device identity. + - Industrial IoT gateway performing edge processing. + * - Critical + - Products whose compromise could severely impact critical infrastructure or essential + services. + - - Smart electricity meter or water meter with remote shut-off. + - Hardware Security Module (HSM) or smartcard firmware. + - Safety-critical sensors used in energy or transport grids. + +.. admonition:: Core Functionality vs. Integration + :class: important + + Classification is determined by the **core functionality** of the final product, not by the + individual components it integrates (`Article 7`_). + + * If you build a network firewall using Zephyr, the core function is security, making the + product an Important Product (Class II). + * If you build a coffee machine using Zephyr, and you utilize Zephyr's networking stack features + to protect the device, the core function remains making coffee. This is a "default" product. + + In a nutshell, using security-critical Zephyr features (like cryptography or secure boot) in a + device does **not** elevate that device to a higher risk class. + +For detailed classification, see `Annex III`_ and `Annex IV`_. + +.. _compliance_path: + +Which compliance path must I choose? +==================================== + +The CRA defines different conformity assessment procedures based on your product category. +You must choose the path that corresponds to your classification and reliance on harmonized +standards. + +.. list-table:: CRA Product Categories & Assessment Routes + :widths: 20 55 25 + :header-rows: 1 + + * - Category + - Conformity Assessment Procedure + - Third-Party Audit? + * - Default + - Module A (Internal Control). Self-assessment by the manufacturer. + - No + * - Important Class I + - Module A **ONLY IF** harmonized standards are fully applied. Otherwise: Module B + Module C, + or Module H. + - Yes, if standards not fully used + * - Important Class II + - Module B + Module C, or Module H. (Self-assessment is **NOT** allowed). + - Yes (Mandatory) + * - Critical + - **European Cybersecurity Certification** (e.g., EUCC) or Module B + Module C + Module H + (pending delegate acts). + - Yes (Mandatory) + +The "Modules" refer to specific assessment procedures defined in `Decision No 768/2008/EC`_ +("New legislative framework") and adapted by the CRA in `Annex VIII`_: + +* `Module A`_ (Internal production control): You create the technical documentation, perform the + risk assessment, and declare conformity yourself. No external auditor is required. +* `Module B`_ (EC-type examination) + `Module C`_ (Conformity to type): A Notified Body [#nb]_ + examines the technical design (Module B) and issues a certificate. You then ensure production + conforms to that type (Module C). +* `Module H`_ (Full Quality Assurance): A Notified Body [#nb]_ audits your Quality Management System + (QMS) governing design, production, and testing. + +.. [#nb] Notified Bodies will become operational by **June 11, 2026**. + +What are my main obligations as a manufacturer? +=============================================== + +Regardless of a product's classification, the following core obligations apply to all manufacturers +of products with digital elements. + +**Risk assessment** + Assess and document cybersecurity risks throughout the product lifecycle. + +**Due diligence** + Exercise due diligence when integrating third-party components (including open-source software + like Zephyr). + +**Vulnerability handling** + Handle vulnerabilities for at least 5 years (support period), including receiving reports and + applying updates. + +**Incident reporting** + Report actively exploited vulnerabilities and severe incidents to the relevant CSIRT and ENISA. + +**Technical documentation** + Create documentation per `Article 31`_ and `Annex VII`_. + +**Conformity assessment** + Assess conformity per `Article 32`_ and `Annex VIII`_. + +**CE marking** + Affix CE mark and draw up EU declaration of conformity. + +What are the penalties for non-compliance? +========================================== + +* Up to EUR 15,000,000 or 2.5% of worldwide annual turnover (`Article 13`_ & `Article 14`_ + violations). +* Up to EUR 10,000,000 or 2% of turnover (violations of other obligations). + +.. _cra_vulnerability_reporting_obligations: + +What are the vulnerability reporting obligations? +================================================= + +The CRA distinguishes between "ordinary" vulnerabilities (handled through your normal vulnerability +management process) and cases that trigger strict notification timelines under `Article 14`_: +**actively exploited vulnerabilities** and **severe incidents**. + +The tables below summarize the minimum reporting steps. + +.. list-table:: Actively exploited vulnerabilities (`Article 14`_ (1) and (2)) + :header-rows: 1 + :widths: 20 20 60 + + * - Step + - Deadline + - Content (minimum) + * - Early warning + - Within 24 hours of becoming aware + - Notify via the single reporting platform to your CSIRT coordinator and ENISA that an actively + exploited vulnerability affects your product. Indicate, where known, in which Member States + the product is available. + * - Vulnerability notification + - Within 72 hours of becoming aware + - Provide general information on the affected product, the general nature of the exploit and + the vulnerability, corrective or mitigating measures already taken, and measures users can + take. Indicate, where applicable, how sensitive you consider the notified information to be. + * - Final report + - No later than 14 days after a corrective or mitigating measure is available + - Describe the vulnerability, its severity and impact, any information on malicious actors + exploiting it (if available), and details on the security update or other corrective measures + made available. + +.. list-table:: Severe incidents (`Article 14`_ (3) through (6)) + :header-rows: 1 + :widths: 20 20 60 + + * - Step + - Deadline + - Content (minimum) + * - Early warning + - Within 24 hours of becoming aware + - Notify via the single reporting platform to your CSIRT coordinator and ENISA that a severe + incident impacts the security of your product. Indicate whether it is suspected to be caused + by unlawful or malicious acts and, where known, in which Member States the product is + available. + * - Incident notification + - Within 72 hours of becoming aware + - Provide general information on the nature of the incident, an initial assessment (including + impact/severity as known at the time), corrective or mitigating measures already taken, and + measures users can take. Indicate, where applicable, how sensitive you consider the notified + information to be. + * - Final report + - Within 1 month after the incident notification + - Provide a detailed description of the incident, including severity and impact, the type of + threat or likely root cause, and applied and ongoing mitigation measures. + +How can I obtain an SBOM (Software Bill of Materials)? +====================================================== + +Zephyr can automatically generate SBOMs for your application using the ``west spdx`` command. + +See :ref:`west-spdx` for details on how to configure and use this tool. + +How should I handle Zephyr vulnerabilities? +=========================================== + +As a manufacturer integrating Zephyr into a product, you remain responsible for vulnerability +management and, where applicable, CRA reporting. +Zephyr provides vulnerability information, but you must assess and act on it for your own product. + +A practical workflow is: + +1. **Stay informed**. Register to the `Zephyr Vulnerability Alert Registry`_ to receive + notifications when vulnerabilities are disclosed. + +2. **Assess impact**. For each advisory, use your SBOM and configuration to determine whether the + affected Zephyr component is present, reachable, and security-relevant in your product. + +3. **Plan remediation**. Decide on the appropriate response (e.g., apply a patch, adjust + configuration, ...). + +4. **Deploy fixes**. Integrate, test, and roll out the chosen fix, and update your SBOM and product + documentation as needed. + +5. **Meet reporting obligations**. If the vulnerability affects your product and is actively + exploited, or leads to a severe incident, report it in line with the `Article 14`_ timelines and + as per the previous section, :ref:`cra_vulnerability_reporting_obligations`. + +What timelines does Zephyr follow for vulnerability handling? +============================================================= + +Zephyr operates its own PSIRT process with target timelines for triage, notification, and +disclosure. These are *project* timelines, not legal deadlines for manufacturers. + +Your CRA reporting obligations as per `Article 14`_ are triggered by when *you* become aware that +your product is affected by an actively exploited vulnerability or a severe incident. +This can be **earlier than** some of the Zephyr milestones below, meaning you might have to send an +early warning or incident report even before a Zephyr fix is available or before public disclosure. + +Zephyr uses private GitHub security advisories and an embargo period (at most 90 days) to coordinate +fixes and disclosure. While the full process is described in :ref:`reporting`, the key milestones +are: + +* **Within 7 days**: PSIRT feedback to initial reporter. +* **Within 30 days**: Manufacturers notified via alert registry and fix made available from the + project. +* **Up to 90 days total**: Security-sensitive vulnerabilities are made public after embargo period. + +Do I need to report vulnerabilities I find in Zephyr? +===================================================== + +**Yes**, under `Article 13(6)`_, if you discover a vulnerability in a component (including Zephyr), +you **must** report it to the entity maintaining it. See :ref:`reporting`. + +Additionally, consider voluntary reporting to CSIRT or ENISA per `Article 15`_. + +For Zephyr as an Open Source Steward +************************************ + +What is Zephyr's role under the CRA? +==================================== + +Zephyr is an **"open-source software steward"** under `Article 3`_ (14): a legal person that +systematically provides sustained support for developing PDEs intended for commercial activities. + +Zephyr's obligations under Article 24: + +**Cybersecurity policy** + Document security policies and vulnerability handling. + +**Cooperation** + Work with market surveillance authorities to mitigate risks. + +**Incident reporting** + Report actively exploited vulnerabilities and severe incidents affecting Zephyr's infrastructure + (to the extent Zephyr is involved). + +Does the CRA apply to Zephyr contributors? +========================================== + +**No.** The CRA does not apply to individual contributors to Zephyr (`Recital 18`_). + +Contributors developing features or fixing bugs are not subject to CRA obligations. + +How is Zephyr meeting its steward obligations? +============================================== + +`Article 24(1)`_: Security policy (Complete) + * Documented at :ref:`security-overview` + * Vulnerability reporting process: :ref:`reporting` + * Secure coding guidelines: :ref:`secure code` + +`Article 24(2)`_: Cooperation with authorities (In Progress) + * Registered CVE Numbering Authority (CNA) since 2017 + * Active Zephyr Project Security Incident Response Team (PSIRT) + * **In Progress**: Identifying CSIRT coordinator for EU + +`Article 14(1)`_ & `Article 14(3)`_: Incident reporting (In Progress) + * **In Progress**: Determining if NVD processes work for CSIRT/ENISA reporting + * Plan to align with EU reporting requirements + +`Article 14(8)`_: User notification (Complete) + * Vulnerability Alert Registry for manufacturers and integrators + * CVE publication and security advisories + +`Article 52(3)`_: Corrective actions (Complete) + * Established processes in place with CVE authorities + * Timely response through PSIRT + +External Resources +****************** + +Official CRA documentation +========================== + +* `EU CRA Regulation 2024/2847 + `_ +* `ENISA CRA Requirements-Standards Mapping + `_ + +Educational resources +===================== + +* `Linux Foundation: Understanding the EU CRA + `_ +* `Linux Foundation CRA Readiness Report `_ +* `Linux Foundation CRA Compliance Best Practices + `_ +* `OpenSSF CRA Guidance `_ + +Zephyr-specific resources +========================= + +* :ref:`security-overview` +* :ref:`reporting` +* `Zephyr Vulnerability Alert Registry`_ +* :ref:`Zephyr Vulnerabilities ` + +.. + +.. _`Decision No 768/2008/EC`: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32008D0768 +.. _`Module A`: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32008D0768#d1e41-98-1 +.. _`Module B`: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32008D0768#d1e288-98-1 +.. _`Module C`: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32008D0768#d1e439-98-1 +.. _`Module H`: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32008D0768#d1e1719-98-1 + +.. _`CRA Requirements-Standards Mapping`: https://www.enisa.europa.eu/publications/cyber-resilience-act-requirements-standards-mapping + +.. _`Recital 18`: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#rct_18 + +.. _`Article 3`: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#art_3 +.. _`Article 7`: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#art_7 +.. _`Article 13`: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#art_13 +.. _`Article 13(6)`: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#013.006 +.. _`Article 13(14)`: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#013.014 +.. _`Article 14`: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#art_14 +.. _`Article 14(1)`: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#014.001 +.. _`Article 14(3)`: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#014.003 +.. _`Article 14(8)`: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#014.008 +.. _`Article 15`: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#art_15 +.. _`Article 24(1)`: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#024.001 +.. _`Article 24(2)`: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#024.002 +.. _`Article 31`: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#art_31 +.. _`Article 32`: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#art_32 +.. _`Article 52(3)`: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#052.003 + +.. _`Annex III`: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#anx_III +.. _`Annex IV`: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#anx_IV +.. _`Annex VII`: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#anx_VII +.. _`Annex VIII`: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#anx_VIII + +.. _`Zephyr Vulnerability Alert Registry`: https://www.zephyrproject.org/vulnerability-registry/ diff --git a/doc/security/standards/index.rst b/doc/security/standards/index.rst index 39b9a0c8db03a..ac394657347cf 100644 --- a/doc/security/standards/index.rst +++ b/doc/security/standards/index.rst @@ -3,20 +3,17 @@ Security standards and Zephyr ############################# -For a long period organizations were, more or less, left responsible to deal -with cyber security on their own. This included how to assess the scale and impact -of the problem and who to properly respond it. +Historically, organizations managed cybersecurity independently, defining their own assessment and +response protocols. Today, governments are increasingly regulating this area through new mandates +and security standards. These standards define specific guidelines and compliance requirements for +connected products. -Now, governments started looking how to regulate it and several regulations -and enforcements are rapidly emerging, and consequently, security standards. These -standards provide guidelines and outline requirements that products have to follow -to achieve compliance. - -This section aims to identify and assess which Zephyr project components are impacted -by security standards requirements and provide the right information to enable -organizations developing certifiable products using Zephyr project. +This section evaluates the implications of these security standards for the Zephyr project itself, +as well as downstream product developers. The goal is to provide developers with the information +needed to build certifiable, compliant products using Zephyr. .. toctree:: :maxdepth: 1 + cyber-resilience-act.rst etsi-303645.rst