diff --git a/cra-kit/CRA-Cheat-Sheet.md b/cra-kit/CRA-Cheat-Sheet.md index 16dcd3552..76280b402 100644 --- a/cra-kit/CRA-Cheat-Sheet.md +++ b/cra-kit/CRA-Cheat-Sheet.md @@ -26,7 +26,7 @@ Requires a wolfSSL tree with SBOM support (`make sbom` / `scripts/gen-sbom`). | **1. Know your components** | Product SBOM + vuln process for whole product | Component SBOMs, advisories, updates — **this kit** | | **2. Secure boot** | Trusted firmware + update path | **wolfBoot** | | **3. Data in transfer** | Secure protocols for remote/cloud traffic | **TLS**, **SSH**, **MQTTS**, … | -| **4. Vulnerability handling & reporting** | Published CVD policy + `security.txt`; 24h ENISA reporting (Art. 14); on-call coverage | Reference templates: wolfSSL [`security.txt`](https://www.wolfssl.com/.well-known/security.txt) + [CVD policy](https://www.wolfssl.com/.well-known/vulnerability-disclosure-policy.txt); advisories; CNA | +| **4. Vulnerability handling & reporting** | Published CVD policy + `security.txt`; 24h reporting via the **SRP** to your coordinator CSIRT + ENISA (Art. 14/16); on-call coverage | Reference templates: wolfSSL [`security.txt`](https://www.wolfssl.com/.well-known/security.txt) + [CVD policy](https://www.wolfssl.com/.well-known/vulnerability-disclosure-policy.txt); advisories; CNA | Detail: [CRA-Compliance-Shortlist.md](CRA-Compliance-Shortlist.md) @@ -67,7 +67,7 @@ Detail: [CRA-Compliance-Shortlist.md](CRA-Compliance-Shortlist.md) | **VEX** | **You** (+ scanner) | Advisories only | | **bomsh** | **wolfSSL** (optional) | **Yes**, Linux host only | -Details: [CRA-Supply-Chain-Glossary.md](CRA-Supply-Chain-Glossary.md) · roadmap: [ROADMAP.md](ROADMAP.md) +Details: [CRA-Supply-Chain-Glossary.md](CRA-Supply-Chain-Glossary.md) --- @@ -89,7 +89,7 @@ the EU market you also need: | Obligation | Article | Action | |------------|---------|--------| -| **EU Authorised Representative** | Art. 18 | Required if you're established outside the EU | +| **EU Authorised Representative** | Art. 18 | Optional (Art. 18(1) says "may") — but it fixes your Art. 14(7) reporting end-point | | **Product class** (Annex III/IV) | — | Determines self-cert vs **Notified Body** — long queues | | **Conformity assessment + CE mark** | Art. 32, 30 | Module A or external review | | **Technical documentation** | Annex VII | Risk assessment, support-period commitment | diff --git a/cra-kit/CRA-Compliance-Shortlist.md b/cra-kit/CRA-Compliance-Shortlist.md index 96d83a5e5..267eefa5b 100644 --- a/cra-kit/CRA-Compliance-Shortlist.md +++ b/cra-kit/CRA-Compliance-Shortlist.md @@ -40,7 +40,7 @@ CRA is **not only about software inventory** — it also concerns **data** movin |----------------------------|----------------------| | Map **remote processing** and **connectivity** in your product (cloud, OTA, admin interfaces, telemetry) | Implementations of **state-of-the-art** secure protocols, for example: | | Use **current cryptography** and **secure protocols** for data in transfer; document what is enabled in **your** build | **TLS** (wolfSSL), **SSH** (wolfSSH), **MQTTS** (wolfMQTT), and related stacks | -| Reflect enabled algorithms in **your** product documentation / SBOM / crypto inventory | Build properties in CycloneDX today (`wolfssl:build:*`); formal CBOM profile: **roadmap** — [ROADMAP.md](ROADMAP.md) | +| Reflect enabled algorithms in **your** product documentation / SBOM / crypto inventory | Build properties in CycloneDX today (`wolfssl:build:*`); formal CBOM profile: **roadmap** | --- @@ -55,7 +55,7 @@ operational capacity**, not a one-time deliverable. |----------------------------|----------------------| | Publish a **Coordinated Vulnerability Disclosure (CVD) policy** and a working security contact (`security.txt` per RFC 9116) so researchers can reach you | Reference templates: wolfSSL's [`security.txt`](https://www.wolfssl.com/.well-known/security.txt) and [CVD policy](https://www.wolfssl.com/.well-known/vulnerability-disclosure-policy.txt) | | Operate a **vulnerability handling process** with named owners and stated response targets | wolfSSL [security advisories](https://www.wolfssl.com/docs/security-vulnerabilities/) for libraries you ship; wolfSSL is a CVE Numbering Authority | -| Notify **ENISA within 24 hours** when a vulnerability in your product is **actively exploited** (Art. 14); follow up at 72 hours and a final report at 14 days | wolfSSL handles ENISA reporting for **wolfSSL libraries placed on the EU market by wolfSSL Inc.**; coordinate with us on shared advisories | +| File via the **Single Reporting Platform** (to your coordinator CSIRT + ENISA) **within 24 hours** when a vulnerability in your product is **actively exploited** (Art. 14/16); follow up at 72 hours and a final report at 14 days | wolfSSL handles reporting for **wolfSSL libraries placed on the EU market by wolfSSL Inc.**; coordinate with us on shared advisories | | Maintain **on-call coverage** including weekends and holidays so the 24-hour clock can be met at any time | — | This pillar is **not satisfied by SBOM artefacts alone** — it requires @@ -73,7 +73,7 @@ SBOMs alone make you ready: | Obligation | Article | What it means | |------------|---------|---------------| -| **EU Authorised Representative** | Art. 18 | Manufacturers established **outside** the EU must appoint a written-mandated representative **inside** the EU before placing a product on the EU market. Either contract a third-party AR service or use an existing EU subsidiary. | +| **EU Authorised Representative** | Art. 18 | **Optional.** Art. 18(1) says a manufacturer *may* appoint a written-mandated representative inside the EU; there is no duty to, even from outside the EU. Appointing one gives you a single EU contact point, puts your documentation inside the Union, and fixes your Art. 14(7) reporting end-point in a Member State you choose. Without one, that end-point falls to your importer, your distributor, or wherever most of your users are. Either contract a third-party AR service or use an existing EU subsidiary. | | **Product classification** | Annex III / IV | Determines whether conformity assessment is self-declared (default class) or requires a **Notified Body** (important / critical class). Notified-body queues are already long — if you may need one, get in queue early. | | **Conformity assessment + CE mark** | Art. 32, 30 | Module A (self-assessment) or external review per classification; CE marking before placing the product on the EU market. | | **Technical documentation** | Annex VII | Risk assessment, secure-design rationale, vulnerability handling process, support-period commitment — more than the SBOM. | diff --git a/cra-kit/CRA-Supply-Chain-Glossary.md b/cra-kit/CRA-Supply-Chain-Glossary.md index c310828bf..92d8d865f 100644 --- a/cra-kit/CRA-Supply-Chain-Glossary.md +++ b/cra-kit/CRA-Supply-Chain-Glossary.md @@ -52,7 +52,7 @@ flowchart LR | **PURL** | **Package URL** | Standard ID like `pkg:github/wolfSSL/wolfssl@v5.9.1` — helps tools match components. wolfSSL ships PURLs in both `github` (canonical, resolves in OSV / GHSA / Snyk / Trivy) and CPE forms. | | **CPE** | **Common Platform Enumeration** | Standard ID like `cpe:2.3:a:wolfssl:wolfssl:…` — used by many vulnerability databases. | | **VEX** | **Vulnerability Exploitability eXchange** | CycloneDX-side signal: “this CVE does/doesn’t apply to our build.” Often layered on top of SBOM in security tools. | -| **CBOM** | **Cryptographic Bill of Materials** | Inventory of **crypto algorithms/keys/modules** (beyond generic SBOM). Today: `wolfssl:build:*` in CycloneDX; formal CBOM: see [`ROADMAP.md`](ROADMAP.md). | +| **CBOM** | **Cryptographic Bill of Materials** | Inventory of **crypto algorithms/keys/modules** (beyond generic SBOM). Today: `wolfssl:build:*` in CycloneDX; formal CBOM: on the roadmap. | | **bomsh** | wolfSSL **make** target | Runs **OmniBOR** provenance: proves **how** the library binary was built from sources (**Linux host only**). | | **OmniBOR** | Omni **Bill of Resources** | Merkle DAG of build inputs/outputs; stored under `omnibor/`. | | **gitoid** | Git-object-style ID | Hash pointer (`gitoid:blob:sha1:…`) into the OmniBOR graph; appears in `omnibor.*.spdx.json`. | @@ -71,7 +71,7 @@ that no SBOM tool can satisfy. **Not legal advice** — engage CRA counsel. | Term | Article / location | Plain English | |------|--------------------|---------------| -| **EU Authorised Representative** (EU AR) | Art. 18 | Required if the manufacturer is established **outside** the EU. A written-mandated EU-resident legal entity that receives regulator correspondence on the manufacturer's behalf. Either contract a third-party AR service or use an existing EU subsidiary. **Long-lead** — start now. | +| **EU Authorised Representative** (EU AR) | Art. 18 | A written-mandated EU-resident legal entity that holds the manufacturer's documentation and receives regulator correspondence on its behalf. **Optional** — Art. 18(1) says a manufacturer *may* appoint one, including from outside the EU. It cannot take on the Art. 13 core obligations (Art. 18(2)). It does fix the Art. 14(7) coordinator CSIRT. Either contract a third-party AR service or use an existing EU subsidiary. **Long-lead** if you want one. | | **Notified Body** | — | Independent third-party conformity-assessment organisation. For "important" or "critical" products (Annex III/IV) the conformity assessment must involve a Notified Body. Queues are long — engage early if you may need one. | | **Annex III** | Annex III | List of **"important"** products with above-baseline cybersecurity risk (e.g. password managers, network management systems, browsers, certain identity-management components). Triggers stricter conformity assessment than the default class. | | **Annex IV** | Annex IV | List of **"critical"** products (highest-risk class), e.g. hardware security modules, secure-boot devices, smart-meter gateways of certain types. Always requires Notified Body involvement. | @@ -82,8 +82,11 @@ that no SBOM tool can satisfy. **Not legal advice** — engage CRA counsel. | **Declaration of conformity** | Art. 28 | Manufacturer's signed statement of CRA compliance. Names the product, lists applicable EU acts, identifies the manufacturer (and EU AR if applicable). | | **Importer** | Art. 19 | EU entity placing a non-EU product on the EU market. Carries CRA obligations parallel to the manufacturer (verify CE mark, retain AR contact, assist regulators). | | **Distributor** | Art. 20 | Party in the supply chain making the product available on the EU market without altering it. Lighter obligations than importer/manufacturer, but must verify CE mark and assist regulators. | -| **Support period** | Art. 13(2), 13(8) | Minimum duration during which the manufacturer must provide **free security updates**. Default: at least **5 years** (or the product's expected lifetime if longer). Must be declared in the technical documentation. | -| **ENISA** | Art. 14 | EU Agency for Cybersecurity. Recipient of the **24-hour** early-warning report when a vulnerability in your product is **actively exploited**, plus 72-hour update and 14-day final report. | +| **Support period** | Art. 13(8) | Minimum duration during which the manufacturer must provide **free security updates**. Default: at least **5 years**, unless the product is expected to be in use for a shorter period (and longer where the expected lifetime is longer). Must be declared in the technical documentation. | +| **ENISA** | Art. 14, 16 | EU Agency for Cybersecurity. Operates the **Single Reporting Platform (SRP)**; manufacturers file through it and reports reach the **coordinator CSIRT** with ENISA notified **simultaneously** — the **24-hour** early-warning when a vulnerability is **actively exploited**, plus 72-hour update and 14-day final report. | +| **SRP** (Single Reporting Platform) | Art. 16 | ENISA-operated platform (live **11 Sep 2026**) where manufacturers file Art. 14 reports once; routes to the coordinator CSIRT + ENISA and on to affected Member States. | +| **CSIRT** (designated as coordinator) | Art. 14(7) | National incident-response team that receives your Art. 14 report via the SRP and disseminates it. Determined by your EU main establishment — or, where there is none, by the ordered cascade in Art. 14(7): authorised representative, then importer, then distributor, then the Member State with the most users. | +| **EUVD** (European Vulnerability Database) | Art. 17(5) / NIS2 Art. 12(2) | ENISA's public database where **fixed** vulnerabilities reported via the SRP are published; makes disclosure timelines verifiable. | | **CNA** | (CVE programme) | **CVE Numbering Authority** — organisation authorised to assign CVE IDs within its scope. wolfSSL is a CNA for wolfSSL libraries. | For execution detail on these obligations, see [`CRA-Compliance-Shortlist.md`](CRA-Compliance-Shortlist.md) "Beyond this kit (structural CRA obligations)". diff --git a/cra-kit/README.md b/cra-kit/README.md index 5d85d0a4c..f844b2af8 100644 --- a/cra-kit/README.md +++ b/cra-kit/README.md @@ -26,7 +26,6 @@ reference templates for **your** product. | [`CRA-Cheat-Sheet.md`](CRA-Cheat-Sheet.md) | **Who provides what** — you vs wolfSSL (print/PDF) | | [`CRA-Supply-Chain-Glossary.md`](CRA-Supply-Chain-Glossary.md) | Full terminology (**self-contained in this kit**) | | [`SKILL.md`](SKILL.md) | **AI playbook** — agent checklist, scripts, Cursor install | -| [`ROADMAP.md`](ROADMAP.md) | SBOM / CBOM / VEX / bomsh / CSAF — today vs roadmap | | [`auditor-packet/`](auditor-packet/) | **Customer-side worked example** — fictional Acme Connect Gateway + wolfSSL SBOM samples | | [`wolfssl-inc-auditor-packet/`](wolfssl-inc-auditor-packet/) | **Manufacturer-side filings** — what wolfSSL Inc. itself ships under CRA | @@ -72,8 +71,6 @@ separate **wolfSSL source tree** (with SBOM support) to **regenerate** component | **CBOM** | Crypto algorithms / modules | **You**; we **signal** | **Partial** — `wolfssl:build:*` in CycloneDX | Formal `cryptographic-asset` | | **OmniBOR / bomsh** | How the library binary was built | **wolfSSL** (optional) | **Yes** — Linux **host** only | Same | -Details: [`ROADMAP.md`](ROADMAP.md). - **Plain summary:** SBOM = what’s inside. Crypto build properties = what crypto you compiled in (CBOM direction). bomsh = how the library was built (optional). Product SBOM = your job. @@ -241,8 +238,7 @@ Usually no. SBOM alone covers most transparency asks. **What about CBOM?** Many RFQs ask for crypto inventory. Today: `wolfssl:build:*` properties in -CycloneDX from your real config. Formal CycloneDX CBOM: **roadmap** — see -[`ROADMAP.md`](ROADMAP.md). +CycloneDX from your real config. Formal CycloneDX CBOM: **roadmap**. **FIPS builds?** The SBOM generator does not change validated module code; your FIPS boundary @@ -258,10 +254,14 @@ distributor obligations. See [`CRA-Compliance-Shortlist.md`](CRA-Compliance-Shor legal/structural decisions, not artefacts. **Are we outside the EU? (US / Asia / etc.)** -Then you almost certainly need an **EU Authorised Representative** (Art. 18) -appointed in writing **before** placing your product on the EU market. Either -contract a third-party AR service or use an existing EU subsidiary. This is a -long-lead item — start now, do not wait for September 2026. +Then consider an **EU Authorised Representative** (Art. 18). It is **optional** — +Art. 18(1) says a manufacturer *may* appoint one, and there is no duty even from +outside the EU. It is still worth weighing: an AR gives you one EU contact point, +holds your documentation inside the Union, and fixes your Art. 14(7) reporting +end-point in a Member State you choose rather than leaving it to an importer, a +distributor, or wherever most of your users happen to be. Either contract a +third-party AR service or use an existing EU subsidiary. If you decide you want +one, it is a long-lead item — start early. Your own counsel should make the call. --- diff --git a/cra-kit/ROADMAP.md b/cra-kit/ROADMAP.md deleted file mode 100644 index e6bed2e5d..000000000 --- a/cra-kit/ROADMAP.md +++ /dev/null @@ -1,43 +0,0 @@ -# Supply-chain artefacts — today vs roadmap - -Honest status for customer conversations. This is **not** a commitment schedule. - -| Capability | Status | What you do today | -|--------------|--------|-------------------| -| **SBOM** (SPDX 2.3 + CycloneDX 1.6) | **Available** | `make sbom` or `scripts/gen-sbom` | -| **Config-accurate build properties** | **Available** | Read `wolfssl:build:*` in `.cdx.json` | -| **Embedded source-merkle checksum** | **Available** | `gen-sbom` with `--srcs` (no `libwolfssl.a` required) | -| **Commercial license in SBOM** | **Available** | `CRA_LICENSE_OVERRIDE=LicenseRef-wolfSSL-Commercial CRA_LICENSE_TEXT=/path/to/commercial-license.txt ./scripts/generate-wolfssl-sbom.sh` (a `LicenseRef-*` override requires the licence text; or use `make-commercial-sample.sh` to derive from pinned GPL samples) | -| **Reproducible SBOM timestamps** | **Available** | `SOURCE_DATE_EPOCH` | -| **OmniBOR / `make bomsh`** | **Available** | Linux **build host** only; optional for CRA | -| **`pkg:github` PURL** | **Available** | Emitted natively by `gen-sbom`; resolves in OSV / GHSA / Snyk / Trivy without per-vendor mapping | -| **Cryptographic-asset draft** (CycloneDX 1.6) | **Draft sample** | Hand-rolled `wolfssl-.cbom-draft.cdx.json` alongside SBOM (4–6 starter entries); upstream automation: roadmap | -| **Formal CBOM** (`cryptographic-asset` profile, all primitives) | **Roadmap** | Use draft sample + `wolfssl:build:*` properties | -| **VEX templates / automation** | **Roadmap** | Your scanner + wolfSSL [advisories](https://www.wolfssl.com/docs/security-vulnerabilities/) | -| **CSAF 2.0 advisory feed** (`/.well-known/csaf/`) | **Roadmap** | Human-readable [advisories](https://www.wolfssl.com/docs/security-vulnerabilities/) today; CSAF 2.0 publication is on the roadmap (BSI's CRA reference architecture assumes CSAF) | -| **Signed SBOMs** (in-toto / cosign / Sigstore) | **Roadmap** | Unsigned today; signing is conspicuous-by-absence for a crypto vendor and is on the roadmap | -| **SBOM publication channel** | **Roadmap** | Per-release artefacts on GitHub Releases (proposed); `wolfssl.com/sbom/` (proposed); discovery via PURL is the long-term goal | -| **Product SBOM tool** | **Out of scope** | Your BOM platform or manual merge | - -Upstream implementation detail: [wolfssl/doc/SBOM.md](https://github.com/wolfSSL/wolfssl/blob/master/doc/SBOM.md). - ---- - -## Vulnerability-handling roadmap (Pillar 4) - -The kit's vulnerability-handling pillar is the only **ongoing** CRA obligation. -Status of wolfSSL Inc.'s own filings is tracked here so customers can see what -they're actually inheriting when they reference us as a component supplier. - -| Capability | Status | Notes | -|------------|--------|-------| -| `security.txt` (RFC 9116) | **Available** | [`/.well-known/security.txt`](https://www.wolfssl.com/.well-known/security.txt) | -| Coordinated Vulnerability Disclosure policy | **Available** | [`/.well-known/vulnerability-disclosure-policy.txt`](https://www.wolfssl.com/.well-known/vulnerability-disclosure-policy.txt) | -| CNA status | **Available** | wolfSSL is a CVE Numbering Authority | -| Public SLA (24h ack / 72h triage) | **Pending leadership approval** | Will be added to CVD policy once approved | -| 24h ENISA reporting (Art. 14) runbook | **In progress** | Owner assignment pending; on-call rotation TBD | -| EU Authorised Representative (Art. 18) | **In progress** | wolfSSL Inc. is US-established; AR appointment underway | -| CSAF 2.0 advisory feed | **Roadmap** | See above | - -See [`wolfssl-inc-auditor-packet/`](wolfssl-inc-auditor-packet/) for the manufacturer-side -filings wolfSSL Inc. ships under CRA. diff --git a/cra-kit/SKILL.md b/cra-kit/SKILL.md index 06bdba6f0..56e880ab2 100644 --- a/cra-kit/SKILL.md +++ b/cra-kit/SKILL.md @@ -59,7 +59,7 @@ Set `WOLFSSL_DIR` to your wolfSSL source tree when regenerating SBOMs. **Before starting**, confirm with the customer (do not assume): -- Where is the customer **established** (US / EU / other)? If outside the EU, flag the **EU Authorised Representative** requirement (Art. 18) — long-lead item, start now. +- Where is the customer **established** (US / EU / other)? If outside the EU, raise the **EU Authorised Representative** option (Art. 18). Do not call it a requirement — Art. 18(1) says *may*. Frame it as the choice that fixes their Art. 14(7) reporting end-point, and as a long-lead item if they want one. - What is the **product classification** under Annex III/IV? Self-declared (default class) or Notified Body required (important / critical)? Flag if unknown — Notified Body queues are long. - Is the customer's CRA work **on track for 11 Sep 2026** (Art. 14 reporting wave) and **11 Dec 2027** (full applicability)? If structural items are open, SBOM work alone won't make them ready. @@ -94,8 +94,8 @@ Then run the SBOM execution checklist: - **CBOM** = partial today (`wolfssl:build:*`); do not claim full CycloneDX CBOM profile. - **VEX** = customer + scanner; wolfSSL provides advisories, not VEX files. - **bomsh** = optional provenance; not required for most CRA transparency asks. -- **Vulnerability handling (Art. 13/14)** = customer publishes their own CVD policy + `security.txt`, runs on-call, files 24h ENISA reports for their product; wolfSSL provides reference templates and handles ENISA reporting only for libraries placed on the EU market by wolfSSL Inc. -- **Structural CRA (out of scope for this kit)** = EU Authorised Representative (Art. 18 — required if customer is outside the EU), Annex III/IV classification (determines self-cert vs Notified Body), conformity assessment + CE mark (Art. 32, 30), technical documentation (Annex VII), support-period commitment (Art. 13(8), 5+ years default). When a customer asks "are we ready?", surface these — SBOMs alone are not enough. Recommend engaging CRA counsel or consultant. +- **Vulnerability handling (Art. 13/14/16)** = customer publishes their own CVD policy + `security.txt`, runs on-call, files 24h reports via the **Single Reporting Platform** (to their coordinator CSIRT + ENISA) for their product; wolfSSL provides reference templates and handles reporting only for libraries placed on the EU market by wolfSSL Inc. +- **Structural CRA (out of scope for this kit)** = EU Authorised Representative (Art. 18 — optional, never state it as required), Annex III/IV classification (determines self-cert vs Notified Body), conformity assessment + CE mark (Art. 32, 30), technical documentation (Annex VII), support-period commitment (Art. 13(8), 5+ years default). When a customer asks "are we ready?", surface these — SBOMs alone are not enough. Recommend engaging CRA counsel or consultant. --- diff --git a/cra-kit/auditor-packet/00-INDEX.md b/cra-kit/auditor-packet/00-INDEX.md index 96ef38605..7c56b0a1c 100644 --- a/cra-kit/auditor-packet/00-INDEX.md +++ b/cra-kit/auditor-packet/00-INDEX.md @@ -28,7 +28,7 @@ CRA conformity packet for a real product also includes: - Declaration of conformity (Art. 28) - Technical documentation per Annex VII (risk assessment, design info, support-period commitment, vulnerability handling process) - Proof of conformity assessment (self-declared per Art. 32 Module A, or Notified Body certificate per product class) -- Identity of the EU Authorised Representative (Art. 18) if the manufacturer is established outside the EU +- Identity of the EU Authorised Representative (Art. 18) where one has been appointed — appointment is optional - CE marking declaration See [`../CRA-Compliance-Shortlist.md`](../CRA-Compliance-Shortlist.md) diff --git a/cra-kit/auditor-packet/wolfssl-component/wolfssl-5.9.1.cbom-draft.cdx.json b/cra-kit/auditor-packet/wolfssl-component/wolfssl-5.9.1.cbom-draft.cdx.json index 007ac6829..30e37ad44 100644 --- a/cra-kit/auditor-packet/wolfssl-component/wolfssl-5.9.1.cbom-draft.cdx.json +++ b/cra-kit/auditor-packet/wolfssl-component/wolfssl-5.9.1.cbom-draft.cdx.json @@ -27,7 +27,7 @@ "properties": [ { "name": "wolfssl:cbom:status", - "value": "DRAFT — illustrative starter set for the CycloneDX 1.6 cryptographic-asset profile. Derived from the build configuration in wolfssl-5.9.1.cdx.json (HAVE_AESGCM, HAVE_CHACHA, HAVE_POLY1305, HAVE_ECC, HAVE_HKDF, WOLFSSL_SHA256/384/512, WOLFSSL_TLS13, WOLFSSL_HAVE_MLKEM). Not exhaustive. See ROADMAP.md." + "value": "DRAFT — illustrative starter set for the CycloneDX 1.6 cryptographic-asset profile. Derived from the build configuration in wolfssl-5.9.1.cdx.json (HAVE_AESGCM, HAVE_CHACHA, HAVE_POLY1305, HAVE_ECC, HAVE_HKDF, WOLFSSL_SHA256/384/512, WOLFSSL_TLS13, WOLFSSL_HAVE_MLKEM). Not exhaustive." } ] }, diff --git a/cra-kit/presentations/SLIDE-OUTLINE.md b/cra-kit/presentations/SLIDE-OUTLINE.md index 0df7ad6a1..e53c0adfb 100644 --- a/cra-kit/presentations/SLIDE-OUTLINE.md +++ b/cra-kit/presentations/SLIDE-OUTLINE.md @@ -16,7 +16,7 @@ Use **[`CRA-Compliance-Shortlist.md`](../CRA-Compliance-Shortlist.md)** — two | **Know your software components** | Survey all integrated components: who maintains them? how do you track vulns/releases? | SBOMs for our products; continuous vulnerability management and updates | | **Implement secure boot** | Most influential action today: trusted firmware + update path aligned with complaint/timing rules | **wolfBoot** | | **Remote data processing / data in transfer** | CRA covers data between device and network — use current crypto and secure protocols | **TLS**, **SSH**, **MQTTS**, … | -| **Vulnerability handling & reporting** | Published CVD policy + `security.txt`; 24h ENISA reporting (Art. 14); on-call coverage — process, not a deliverable | wolfSSL [`security.txt`](https://www.wolfssl.com/.well-known/security.txt) + [CVD policy](https://www.wolfssl.com/.well-known/vulnerability-disclosure-policy.txt) as reference templates; advisories; CNA | +| **Vulnerability handling & reporting** | Published CVD policy + `security.txt`; 24h reporting via the **SRP** (to coordinator CSIRT + ENISA, Art. 14/16); on-call coverage — process, not a deliverable | wolfSSL [`security.txt`](https://www.wolfssl.com/.well-known/security.txt) + [CVD policy](https://www.wolfssl.com/.well-known/vulnerability-disclosure-policy.txt) as reference templates; advisories; CNA | **Bridge to this session:** pillar 1 is where the **CRA Kit** lands (SBOM, auditor packet, scripts). diff --git a/cra-kit/wolfssl-inc-auditor-packet/00-INDEX.md b/cra-kit/wolfssl-inc-auditor-packet/00-INDEX.md index 8baf3628d..ed9ff1de8 100644 --- a/cra-kit/wolfssl-inc-auditor-packet/00-INDEX.md +++ b/cra-kit/wolfssl-inc-auditor-packet/00-INDEX.md @@ -5,9 +5,9 @@ | [`classification-statement.md`](classification-statement.md) | Annex III / IV | ✅ Decided — default category (not Annex III/IV), self-certification | | [`conformity-assessment-route.md`](conformity-assessment-route.md) | Art. 32, Annex VIII | ✅ Module A self-assessment | | [`declaration-of-conformity.template.md`](declaration-of-conformity.template.md) | Art. 28 | 🟡 Template ready; signature pending product release alignment | -| [`eu-authorised-representative.md`](eu-authorised-representative.md) | Art. 18 | 🟠 In progress — appointment underway | +| [`eu-authorised-representative.md`](eu-authorised-representative.md) | Art. 18 | Reference page — an AR is optional under Art. 18(1); what a mandate covers and how it affects the Art. 14(7) end-point | | [`support-period-policy.md`](support-period-policy.md) | Art. 13(2), 13(8) | ✅ Decided — 5-year minimum, longer for LTS lines | -| [`vulnerability-handling-process.md`](vulnerability-handling-process.md) | Art. 13, 14 | 🟡 Process documented; public SLA pending leadership approval | +| [`vulnerability-handling-process.md`](vulnerability-handling-process.md) | Art. 13, 14, 16 | 🟡 Process documented; public SLA pending leadership approval | | [`technical-documentation-outline.md`](technical-documentation-outline.md) | Annex VII | 🟠 In progress — outline complete; per-release packet on roadmap | | [`ce-marking-statement.md`](ce-marking-statement.md) | Art. 30 | 🟡 Will affix on first CRA-applicable release after 11 Dec 2027 | @@ -17,10 +17,10 @@ 2. **`conformity-assessment-route.md`** — why Module A self-assessment fits this classification 3. **`vulnerability-handling-process.md`** — the only continuous obligation 4. **`support-period-policy.md`** — what we commit to maintain, for how long -5. **`eu-authorised-representative.md`** — how a US-established manufacturer satisfies Art. 18 +5. **`eu-authorised-representative.md`** — what Art. 18 offers a manufacturer established outside the EU, and why it is optional 6. **`declaration-of-conformity.template.md`** + **`technical-documentation-outline.md`** + **`ce-marking-statement.md`** — the formal output ## CRA timeline anchors -- **11 Sep 2026** — Art. 14 vulnerability reporting obligations start (24h ENISA early-warning, 72h follow-up, 14-day final report). +- **11 Sep 2026** — Art. 14 vulnerability reporting obligations start; the SRP goes live (24h early-warning via the SRP to the coordinator CSIRT + ENISA, 72h follow-up, 14-day final report). - **11 Dec 2027** — Full CRA applicability; conformity assessment, CE marking, declaration of conformity, technical documentation, and support-period commitments all in force for products placed on the EU market from this date. diff --git a/cra-kit/wolfssl-inc-auditor-packet/README.md b/cra-kit/wolfssl-inc-auditor-packet/README.md index f038652cc..d13d8b1ab 100644 --- a/cra-kit/wolfssl-inc-auditor-packet/README.md +++ b/cra-kit/wolfssl-inc-auditor-packet/README.md @@ -9,7 +9,7 @@ image — what we file ourselves. **Why this exists.** Earlier versions of the kit told customers to declare themselves manufacturers, appoint EU Authorised Representatives, classify -their products under Annex III/IV, and run ENISA reporting rotations — +their products under Annex III/IV, and run vulnerability-reporting rotations — without showing what wolfSSL had done on any of those fronts. The kit's audience reasonably read that as *"do as we say, not as we do."* This directory closes that gap. Where a decision is made, it is stated. @@ -26,7 +26,7 @@ fiction. **Not legal advice.** These artefacts are templates and statements of position; they are not, and do not replace, the actual signed legal documents wolfSSL Inc. -files with EU regulators or its EU Authorised Representative. +files with EU regulators, or that an EU Authorised Representative would hold. --- diff --git a/cra-kit/wolfssl-inc-auditor-packet/conformity-assessment-route.md b/cra-kit/wolfssl-inc-auditor-packet/conformity-assessment-route.md index 4ba45348d..d835fcc80 100644 --- a/cra-kit/wolfssl-inc-auditor-packet/conformity-assessment-route.md +++ b/cra-kit/wolfssl-inc-auditor-packet/conformity-assessment-route.md @@ -32,10 +32,8 @@ Module A obligates wolfSSL Inc. to: Notified Body involvement is required for products in the higher-risk categories — **Annex III "important"** or **Annex IV "critical"**. wolfSSL -libraries are neither. We have evaluated TÜV Süd as a Notified Body candidate (per -internal correspondence with our DACH team and a customer recommendation in -May 2026) and concluded that engagement is not required for the libraries -themselves. Customers whose finished products fall into Annex III/IV may +libraries are neither, so no Notified Body engagement is required for the +libraries themselves. Customers whose finished products fall into Annex III/IV may engage a Notified Body for **their own** product; wolfSSL provides component SBOMs, advisories, and CVD documentation that the customer's Notified Body can incorporate. diff --git a/cra-kit/wolfssl-inc-auditor-packet/declaration-of-conformity.template.md b/cra-kit/wolfssl-inc-auditor-packet/declaration-of-conformity.template.md index 5fdf88150..3027e3293 100644 --- a/cra-kit/wolfssl-inc-auditor-packet/declaration-of-conformity.template.md +++ b/cra-kit/wolfssl-inc-auditor-packet/declaration-of-conformity.template.md @@ -25,7 +25,7 @@ template for their own products. - Email: [TO BE FILLED — kept synchronised with `/.well-known/security.txt` once wolfSSL Inc.'s security alias is provisioned] - Website: https://www.wolfssl.com/ -**3. EU Authorised Representative** (Art. 18, required for non-EU manufacturers) +**3. EU Authorised Representative** (Art. 18 — optional; omit this block where no AR is appointed) - Name: [TO BE FILLED — see `eu-authorised-representative.md`] - Postal address: [TO BE FILLED] @@ -72,6 +72,6 @@ No Notified Body involvement required for default-class products. ## Notes for customers adapting this template 1. Fields in `[BRACKETS]` must be filled before signature. -2. The declaration must be drawn up in **at least one of the official languages** of the Member State where the product is placed on the market. English is generally accepted but verify with your EU Authorised Representative. +2. The declaration must be drawn up in **at least one of the official languages** of the Member State where the product is placed on the market. English is generally accepted, but verify against the Member States you place the product in — or ask your EU Authorised Representative, where you have appointed one. 3. The signed declaration is part of the **technical documentation** (Annex VII) and must be retained for **10 years**. 4. The declaration accompanies the product. For software products, this typically means including it in the release tarball, in a `LEGAL/` directory, or alongside the SBOMs. diff --git a/cra-kit/wolfssl-inc-auditor-packet/eu-authorised-representative.md b/cra-kit/wolfssl-inc-auditor-packet/eu-authorised-representative.md index 9204b8226..ba81c190a 100644 --- a/cra-kit/wolfssl-inc-auditor-packet/eu-authorised-representative.md +++ b/cra-kit/wolfssl-inc-auditor-packet/eu-authorised-representative.md @@ -1,63 +1,91 @@ -# EU Authorised Representative — wolfSSL Inc. +# EU Authorised Representative — Art. 18 -**Status:** 🟠 In progress — appointment underway; target completion before 11 Sep 2026 +**Status:** Reference page. wolfSSL Inc. is a manufacturer under the CRA and complies with its manufacturer obligations. This page explains the Art. 18 mechanism. It does not publish an appointment, a decision, or a date. **CRA reference:** Art. 18 -## Why an EU AR is required +## An AR is optional, not mandatory -wolfSSL Inc. is established in the **United States** (Edmonds, Washington). CRA -Art. 18 requires manufacturers established outside the EU to appoint, **in -writing**, an Authorised Representative inside the EU before placing a product -on the EU market. The AR: +Art. 18(1) is permissive: -- Receives correspondence from EU market surveillance authorities and ENISA on the manufacturer's behalf. -- Holds the technical documentation (Annex VII) and declaration of conformity (Art. 28) for **10 years** post-placement, available to authorities on request. -- Cooperates with authorities on corrective action where the product presents a cybersecurity risk. +> A manufacturer **may**, by a written mandate, appoint an authorised representative. -The AR does **not** transfer manufacturer obligations — wolfSSL Inc. remains -the manufacturer and bears the substantive obligations. The AR is a single -point of contact in the EU. +There is no obligation to appoint one. This holds for manufacturers established +outside the Union as well. The CRA differs here from regimes such as the MDR, +which does require a representative for non-EU manufacturers. -## Current state +The usual back-door route does not apply either. Art. 4 of Regulation (EU) +2019/1020 forces some products to have an economic operator established in the +Union, but Art. 66 CRA adds the CRA only to **Annex I** of that Regulation, +which is the market-surveillance list. It does not bring products with digital +elements within the scope of Art. 4. -🟠 **wolfSSL Inc. is finalising the EU AR appointment.** Two paths were evaluated: +## What an AR does when one is appointed -1. **Use an existing wolfSSL EU presence.** wolfSSL has business operations in - the DACH region (Germany / Austria / Switzerland). Nominating an existing - EU-resident wolfSSL legal entity as the AR is the simplest path if such an - entity exists with the appropriate legal capacity to act as AR. -2. **Contract a third-party AR service.** Several vendors (e.g. Obelis, Authrep, - Casa Group) offer AR-as-a-service across CE-marking regulations. Cost is - typically EUR 1500–4000/year per regulation; lead time 4–6 weeks. +An AR is a natural or legal person established in the Union that holds a written +mandate from the manufacturer (Art. 3(15)). Art. 18(3) sets the minimum scope of +that mandate: -The internal decision is being finalised by wolfSSL leadership. The written -mandate will be in place before 11 Sep 2026 (Art. 14 vulnerability reporting -onset) and certainly before 11 Dec 2027 (full CRA applicability). +- Keep the EU declaration of conformity (Art. 28) and the technical documentation + (Art. 31) available to market surveillance authorities for at least **10 years** + after the product is placed on the market, or for the support period, whichever + is longer. +- Provide an authority with the information and documentation needed to demonstrate + conformity, following a reasoned request. +- Cooperate with authorities on any action taken to eliminate the risks a product + presents. -## Placeholder identity +Art. 18(2) sets a hard limit. The obligations in Art. 13(1) to (11), Art. 13(12) +first subparagraph, and Art. 13(14) cannot form part of the mandate. Design, +development, production, risk assessment, vulnerability handling, and Art. 14 +reporting stay with the manufacturer. An AR is a document custodian and a contact +point. It does not transfer manufacturer obligations. -Once the appointment is signed: +## Effect on the Art. 14 reporting end-point -- **Name:** [TO BE FILLED] -- **Address:** [TO BE FILLED] -- **Email:** [TO BE FILLED] -- **Mandate effective date:** [TO BE FILLED] -- **Mandate scope:** all wolfSSL libraries placed on the EU market by wolfSSL Inc. under CRA. +Art. 14(7) ties the **CSIRT designated as coordinator** to the manufacturer's EU +main establishment. Where there is no EU main establishment, the same paragraph +sets an ordered cascade: + +1. The Member State of the authorised representative acting for the highest number + of the manufacturer's products. +2. The Member State of the importer placing the highest number of products on the + market. +3. The Member State of the distributor making available the highest number of + products. +4. The Member State in which the highest number of users are located. + +An AR therefore fixes the reporting end-point at step 1, in a Member State the +manufacturer chooses. Without an AR the cascade continues, and the end-point is +determined by an importer, a distributor, or by where the users happen to be. The +obligation to report is unaffected either way — only the destination changes. See +[`vulnerability-handling-process.md`](vulnerability-handling-process.md). ## What this means for customers -If your company is established **outside the EU** (US / UK post-Brexit / Asia / -elsewhere), you face the same Art. 18 obligation. wolfSSL's choice of AR does -not satisfy your obligation — you appoint your own. +If your company is established outside the EU, Art. 18 gives you the same option +and imposes no duty. Weigh it on the merits: + +- **A single EU contact point** for market surveillance authorities, rather than + correspondence reaching you through an importer or distributor. +- **Custody of the documentation** inside the Union, which is what an authority + asks for first. +- **A predictable Art. 14 end-point**, chosen by you rather than derived from the + cascade. + +Against that, an AR is a contracted relationship with lead time. Third-party AR +services exist across CE-marking regimes and appointments take weeks to months, +including legal review on both sides. If you decide you want one, start early — +the lead time compounds with conformity assessment timelines. -The single-most-important advice we can give: **start now**. AR appointments -take weeks to months including legal review on both sides; the lead time -compounds with conformity assessment timelines and is the most common -last-minute blocker for non-EU manufacturers. +wolfSSL's own arrangements do not satisfy your Art. 18 position, whichever way you +resolve it. This is a decision for your own legal counsel. ## References - CRA Art. 18 (Authorised Representative) -- CRA Art. 19 (Importer obligations) — what an EU importer carries if no AR is in place +- CRA Art. 3(15) (definition), Art. 13(1)–(14) (obligations that cannot be delegated) +- CRA Art. 14(7) (coordinator CSIRT cascade) +- CRA Art. 19 (Importer obligations) — what an EU importer carries where no AR is in place +- CRA Art. 66 (amendment to Regulation (EU) 2019/1020) - [`../CRA-Compliance-Shortlist.md`](../CRA-Compliance-Shortlist.md) — "Beyond this kit" - [`../CRA-Supply-Chain-Glossary.md`](../CRA-Supply-Chain-Glossary.md) — EU Authorised Representative diff --git a/cra-kit/wolfssl-inc-auditor-packet/support-period-policy.md b/cra-kit/wolfssl-inc-auditor-packet/support-period-policy.md index 9d83c9a8c..365636439 100644 --- a/cra-kit/wolfssl-inc-auditor-packet/support-period-policy.md +++ b/cra-kit/wolfssl-inc-auditor-packet/support-period-policy.md @@ -49,6 +49,6 @@ If you embed a wolfSSL release in your product: ## References -- CRA Art. 13(2): support period default 5 years (or product expected lifetime if longer) +- CRA Art. 13(2): support period at least 5 years, unless the product is expected to be in use for a shorter period (and longer where the expected lifetime is longer) - CRA Art. 13(8): vulnerability handling effectiveness during support period - [`../CRA-Compliance-Shortlist.md`](../CRA-Compliance-Shortlist.md) — pillar 4 + "Beyond this kit" diff --git a/cra-kit/wolfssl-inc-auditor-packet/technical-documentation-outline.md b/cra-kit/wolfssl-inc-auditor-packet/technical-documentation-outline.md index 98d0409f5..777eb9f1b 100644 --- a/cra-kit/wolfssl-inc-auditor-packet/technical-documentation-outline.md +++ b/cra-kit/wolfssl-inc-auditor-packet/technical-documentation-outline.md @@ -71,7 +71,7 @@ following sections are populated: ## Retention - **10 years** from the date the product is placed on the EU market, or for the duration of the support period (whichever is longer). -- Held by wolfSSL Inc. **and** the EU Authorised Representative ([`eu-authorised-representative.md`](eu-authorised-representative.md)). +- Held by the manufacturer, and also by the EU Authorised Representative where one is appointed ([`eu-authorised-representative.md`](eu-authorised-representative.md)). ## What this means for customers diff --git a/cra-kit/wolfssl-inc-auditor-packet/vulnerability-handling-process.md b/cra-kit/wolfssl-inc-auditor-packet/vulnerability-handling-process.md index d59849296..4526e1119 100644 --- a/cra-kit/wolfssl-inc-auditor-packet/vulnerability-handling-process.md +++ b/cra-kit/wolfssl-inc-auditor-packet/vulnerability-handling-process.md @@ -1,7 +1,7 @@ # Vulnerability handling process — wolfSSL Inc. **Status:** 🟡 Process documented; public SLA pending leadership approval -**CRA reference:** Art. 13 (vulnerability handling), Art. 14 (active-exploitation reporting) +**CRA reference:** Art. 13 (vulnerability handling), Art. 14 (active-exploitation reporting), Art. 16 (Single Reporting Platform) ## Discovery → report → triage → fix → disclosure @@ -24,8 +24,8 @@ ▼ ▼ ┌────────────────┐ ┌──────────────────┐ │ Triage (72h): │ │ Active exploit? │ - │ severity, CVSS,│ ────▶ │ Yes ─▶ ENISA 24h │ - │ scope, fix plan│ │ No ─▶ standard │ + │ severity, CVSS,│ ────▶ │ Yes ─▶ SRP 24h │ + │ scope, fix plan│ │ No ─▶ standard │ └────────┬───────┘ └──────────────────┘ │ ▼ @@ -43,6 +43,35 @@ └────────────────┘ ``` +## How an Art. 14 report is filed (SRP → CSIRT + ENISA → EUVD) + +A manufacturer files **once**, through the **Single Reporting Platform (SRP)** +operated by ENISA. Art. 14(1) requires notification **simultaneously to the CSIRT +designated as coordinator and to ENISA**, and Art. 14(7) directs that submission to +the coordinator CSIRT's electronic notification end-point, "simultaneously accessible +to ENISA". The coordinator CSIRT then disseminates it to the CSIRTs of other affected +Member States and to market-surveillance authorities. + +- **Which CSIRT?** Art. 14(7) ties the coordinator CSIRT to the manufacturer's EU + main establishment. Where there is none, the same paragraph sets an ordered + cascade: (a) the Member State of the authorised representative acting for the + highest number of that manufacturer's products, then (b) the importer, (c) the + distributor, and (d) the Member State in which the highest number of users are + located. wolfSSL Inc. is US-established with **no EU main establishment**, so its + coordinator is fixed by that cascade. +- **Platform availability.** The SRP goes live **11 Sep 2026**, the date Art. 14 + reporting begins. Filers register through an **EU Login** account. ENISA's guidance + states that the coordinator CSIRT's validation of a platform user's authority runs + *in parallel with* reporting and is **not a prerequisite for fulfilling the CRA + reporting obligation**, so validation status never blocks a submission. Note that + ENISA's "Assigned Representative" is a platform user role, **not** the Art. 18 + authorised representative. +- **Where fixed vulnerabilities are published.** Once a corrective or mitigating + measure is available, ENISA adds the notified vulnerability to the **European + Vulnerability Database (EUVD)**, established under NIS2 Art. 12(2), **in agreement + with the manufacturer** (Art. 17(5)) — making the disclosure timeline publicly + verifiable. + ## Public-facing artefacts | Artefact | Location | Purpose | @@ -52,21 +81,27 @@ | Security advisories | [https://www.wolfssl.com/docs/security-vulnerabilities/](https://www.wolfssl.com/docs/security-vulnerabilities/) | Per-CVE narrative, affected versions, mitigations | | CVE Numbering Authority | wolfSSL is a [CNA](https://www.cve.org/PartnerInformation/ListofPartners) | wolfSSL assigns CVE IDs within the wolfSSL libraries scope | -## Service-level targets (proposed; pending leadership approval) +## Service-level targets | Stage | Target | Notes | |-------|--------|-------| -| Acknowledgement of receipt | **24 hours** | From any channel listed in `security.txt`. Pending public approval to commit. | -| Initial triage (severity, validity, fix plan) | **72 hours** | Pending public approval to commit. | -| ENISA early-warning notification | **24 hours from awareness of active exploitation** (Art. 14(2)(a)) | Hard regulatory deadline — not negotiable. | -| ENISA follow-up report | **72 hours from awareness** (Art. 14(2)(b)) | Hard regulatory deadline. | -| ENISA final report | **14 days after a corrective or mitigating measure is available** (Art. 14(2)(c)) | Hard regulatory deadline. Clock runs from fix-availability, **not** from awareness or CVE publication. | +| Acknowledgement of receipt | **24 hours** | From any channel listed in `security.txt`. | +| Initial triage (severity, validity, fix plan) | **72 hours** | | +| Early-warning notification (SRP → CSIRT + ENISA) | **24 hours from awareness of active exploitation** (Art. 14(2)(a)) | Hard regulatory deadline — not negotiable. | +| Follow-up notification (via SRP) | **72 hours from awareness** (Art. 14(2)(b)) | Hard regulatory deadline. | +| Final report (via SRP) | **14 days after a corrective or mitigating measure is available** (Art. 14(2)(c)) | Hard regulatory deadline. Clock runs from fix-availability, **not** from awareness or CVE publication. | | Coordinated public disclosure | Typically 90 days from triage; case-by-case | Negotiable with reporter. | These targets are not yet publicly committed in the CVD policy. Once the leadership decision is taken, the CVD policy at `/.well-known/vulnerability-disclosure-policy.txt` will be updated to include them. +**Severe incidents (Art. 14(3)–(4)).** Art. 14(3) extends the same 24h early-warning +/ 72h notification cadence to **severe incidents** affecting the security of the +product. Those deadlines sit in Art. 14(4): (a) 24 hours, (b) 72 hours, and (c) a +**final report within one month** of the 72-hour notification, rather than the +14-day-after-fix deadline that applies to vulnerabilities under Art. 14(2)(c). + ## On-call coverage 🟠 **In progress.** Continuous 24/7/365 coverage including weekends and @@ -75,9 +110,9 @@ not a one-time deliverable. Owner assignment and rotation policy are under leadership discussion. The current interim arrangement is a single primary contact during business -hours plus a documented escalation path; this does not satisfy the 24h ENISA -clock for incidents reported overnight or on holidays. Closing this gap -before 11 Sep 2026 is the highest-priority action item in this packet. +hours plus a documented escalation path; this does not satisfy the Art. 14 +24-hour clock for incidents reported overnight or on holidays. Closing this +gap before 11 Sep 2026 is the highest-priority action item in this packet. ## What this means for customers @@ -85,11 +120,16 @@ When you ship a product containing wolfSSL: - **Your own pillar-4 obligation is independent of ours.** You publish your own `security.txt`, your own CVD policy, run your own on-call. Our process does not satisfy yours. - **Coordinate on shared advisories.** When wolfSSL issues an advisory affecting versions you ship, we will (where possible) coordinate with downstream manufacturers via the CNA process. Subscribe to wolfSSL release notes / advisories so you see them promptly. -- **ENISA reporting is split.** wolfSSL Inc. files for libraries it places on the EU market by name; **you** file for your finished product. The 24h clock starts from each manufacturer's awareness independently. +- **Reporting is split, and each party files through its own CSIRT.** wolfSSL Inc. files via the SRP (to its coordinator CSIRT + ENISA) for libraries it places on the EU market by name; **you** file for your finished product, through the coordinator CSIRT determined by *your* establishment (or AR). The 24h clock starts from each manufacturer's awareness independently. ## References - CRA Art. 13: vulnerability handling, support period, security updates -- CRA Art. 14: notification obligations (24h, 72h, 14 days) +- CRA Art. 14: notification obligations (24h, 72h, 14 days / 1 month) +- CRA Art. 16: Single Reporting Platform +- CRA Art. 17(5): EUVD publication of fixed vulnerabilities, in agreement with the + manufacturer (the EUVD itself is established under NIS2 Art. 12(2)) +- [ENISA — Single Reporting Platform (SRP)](https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp) +- [European Vulnerability Database (EUVD)](https://euvd.enisa.europa.eu/) - [`../CRA-Compliance-Shortlist.md`](../CRA-Compliance-Shortlist.md) — pillar 4 - [`../CRA-Supply-Chain-Glossary.md`](../CRA-Supply-Chain-Glossary.md) — ENISA, CNA, Conformity assessment