# SBOM Vulnerability Mapper > Generate and validate a Software Bill of Materials (SBOM) and draft CRA-compliant technical documentation for connected products in the EU market. Checks software components against the NIST NVD for known critical vulnerabilities. Covers product classification, Annex I essential cybersecurity requirements, vulnerability handling, conformity assessment, and ENISA reporting readiness. Tags: Cybersecurity, IoT, Consumer Electronics, Compliance, SBOM, Cyber Resilience Act ## Example Prompts - Generate an SBOM for our smart home hub and check for known CVEs - Draft CRA technical documentation for a connected fitness tracker entering the EU market - Classify our IoT gateway under the CRA and determine the conformity assessment path URL: https://rakenne.app/skills/sbom-vulnerability-mapper/index.md Try this skill: https://rakenne.app/a/?skill=sbom-vulnerability-mapper ## Overview Generate and validate a Software Bill of Materials (SBOM) and draft CRA-compliant technical documentation for connected products in the EU market. Checks software components against the NIST NVD for known critical vulnerabilities. Covers product classification, Annex I essential cybersecurity requirements, vulnerability handling, conformity assessment, and ENISA reporting readiness. The EU Cyber Resilience Act (Regulation 2024/2847) requires manufacturers to produce **technical documentation before placing products on the market**, including an SBOM with no known exploitable vulnerabilities. This skill targets the three most documentation-intensive areas: - **SBOM generation and vulnerability scanning** — Produces a CycloneDX SBOM and checks every component against the NIST NVD for critical CVEs, ensuring CRA Article 13(6) compliance. - **Essential cybersecurity requirements mapping** — Walks through all 14 Annex I Part I requirements plus the 8 vulnerability handling obligations, documenting how the product addresses each one. - **Conformity assessment preparation** — Classifies the product (default, important, critical), determines the assessment module (A, B+C, or H), and drafts the EU Declaration of Conformity. ## Getting Started Add your product's dependency information (package manager lockfile, existing SBOM, or manual component list) and any available design documentation to the project workspace. Then activate the *SBOM Vulnerability Mapper* skill. The agent will guide you through product classification, SBOM generation, vulnerability scanning, risk assessment, and full technical documentation assembly. ## Example Conversation Below is an example of how a typical CRA documentation session unfolds. The agent scopes the product, classifies it under the CRA, generates the SBOM, checks for vulnerabilities, and assembles the technical documentation. > **You:** We need CRA technical documentation for our smart home hub — the "HomeConnect Pro". It runs Linux with a Node.js application layer, connects via Wi-Fi and Zigbee, and has a companion mobile app that communicates through our cloud API. We're launching in the EU market in Q3 2027. > > **Agent:** I'll guide you through the CRA technical documentation process. Let me confirm some details: > > 1. **Firmware/software version:** What version of the product software are you documenting? > 2. **Cloud dependency:** Is the cloud API integral to the product's core function, or is it supplementary? > 3. **Security features:** Does the hub include any firewall, intrusion detection, or VPN functionality? > 4. **Existing SBOM:** Do you have a package.json / package-lock.json or any existing SBOM for the Node.js application? > 5. **Support period:** How long will you provide security updates? > > **You:** Version 2.4.1. The cloud API is integral — the hub won't work without it for remote control, though local Zigbee control works offline. No firewall or IDS — it's a consumer hub. We have a package-lock.json. Support period will be 6 years. > > **Agent:** Based on this, your product classification is **Important — Class I**. Smart home hubs that act as central gateways for IoT devices are listed in CRA Annex III Part I. This means: > > - **If you apply harmonized standards** (e.g., EN 18031-1 once published) **in full**, you can self-assess under **Module A** > - **Otherwise**, you'll need a Notified Body under **Module B+C or H** > > Your 6-year support period exceeds the 5-year minimum — that's compliant. > > I see your package-lock.json. Let me generate the SBOM and check for vulnerabilities. > > I've generated the CycloneDX SBOM at `output/sbom.json` with 47 top-level dependencies. Running the `cve_realtime_lookup` tool now... > > **Critical finding:** The scan found **2 critical** and **3 high-severity** CVEs: > > 1. **CVE-2025-29103** — `node-mqtt@4.3.7` (CVSS 9.8, CRITICAL) — Remote code execution via malformed MQTT packet. Patch available in v4.3.9. > 2. **CVE-2025-31842** — `express@4.18.2` (CVSS 9.1, CRITICAL) — Prototype pollution leading to authentication bypass. Patch available in v4.19.1. > 3. **CVE-2025-28417** — `ws@8.14.1` (CVSS 7.5, HIGH) — DoS via crafted WebSocket frame. Patch available in v8.14.3. > > CRA Article 13(6) requires no known exploitable vulnerabilities at market placement. The two critical CVEs **must** be remediated before you can declare conformity. > > **You:** We'll update those three packages immediately. Can you also check `openssl` 3.1.4 which is in our Linux base image? > > **Agent:** I've updated the SBOM with the patched versions and added openssl@3.1.4. Re-running the scan... > > **All clear.** The updated SBOM shows no critical or high-severity CVEs. The openssl@3.1.4 has two medium-severity CVEs (CVSS 5.3 and 4.7) — I'll document these in the risk register with your mitigation approach. Shall we proceed to the cybersecurity risk assessment? ## Sample Output Excerpt Below is a representative excerpt from a CVE scan report, showing the component inventory and vulnerability findings — the first thing a market surveillance authority would check when verifying CRA compliance. --- ### CVE Real-Time Lookup — HomeConnect Pro v2.4.1 **SBOM format:** CycloneDX **Components checked:** 47 / 47 **CVSS threshold:** ≥ 7.0 **CVEs found:** 5 #### Component Inventory (excerpt) | Component | Version | Status | |-----------|---------|--------| | node-mqtt | 4.3.7 | 2 CVE(s) | | express | 4.18.2 | 1 CVE(s) | | ws | 8.14.1 | 1 CVE(s) | | zigbee-herdsman | 0.35.1 | 1 CVE(s) | | fastify | 4.26.0 | CLEAR | | mqtt-packet | 8.3.0 | CLEAR | | serialport | 12.0.0 | CLEAR | | ... (40 more) | | CLEAR | #### Vulnerability Findings | Component | CVE | CVSS | Severity | Description | |-----------|-----|------|----------|-------------| | node-mqtt@4.3.7 | CVE-2025-29103 | 9.8 | CRITICAL | Remote code execution via malformed MQTT packet | | express@4.18.2 | CVE-2025-31842 | 9.1 | CRITICAL | Prototype pollution leading to auth bypass | | ws@8.14.1 | CVE-2025-28417 | 7.5 | HIGH | DoS via crafted WebSocket frame | | zigbee-herdsman@0.35.1 | CVE-2025-30055 | 7.2 | HIGH | Buffer overflow in Zigbee frame parser | | node-mqtt@4.3.7 | CVE-2025-27841 | 7.1 | HIGH | Information disclosure via diagnostic topic | #### CRA Compliance Assessment - **[CRITICAL]** 2 critical vulnerabilities found. CRA Article 13(6) requires products placed on the market to have NO known exploitable vulnerabilities. These MUST be remediated before conformity declaration. - **[HIGH]** 3 high-severity vulnerabilities found. CRA Annex I §1(2) requires appropriate cybersecurity risk mitigation. Remediate or document risk acceptance with justification. **RESULT: FAIL** — Critical vulnerabilities detected. ## Built-in Validation Tools The skill includes an extension tool that automates vulnerability scanning of the software supply chain against the NIST National Vulnerability Database. ### What the tool checks | Check Category | `cve_realtime_lookup` | |---------------|:---------------------:| | **SBOM format detection** | CycloneDX JSON, SPDX JSON, markdown table | | **Component extraction** | Name, version, supplier, CPE/PURL identifiers | | **NVD API lookup** | Real-time query per component against NIST NVD v2.0 | | **CVSS scoring** | v3.1, v3.0, v2.0 (in preference order) | | **Severity classification** | Critical (≥9.0), High (≥7.0), Medium (≥4.0), Low (<4.0) | | **CRA compliance assessment** | Article 13(6) no-known-vulnerability check | | **Component inventory** | Full inventory with per-component status (CLEAR / CVE count / LOOKUP FAILED) | | **Rate limit handling** | Automatic delay and retry for NVD API rate limits | ### Severity levels - **CRITICAL** — CVSS ≥ 9.0. Known exploitable vulnerability that blocks CRA conformity declaration. Must be remediated before market placement. - **HIGH** — CVSS ≥ 7.0. Significant vulnerability requiring documented risk assessment and mitigation per CRA Annex I Part I §1. - **MEDIUM** — CVSS ≥ 4.0. Should be documented in the risk register with risk acceptance justification if not patching. - **LOW** — CVSS < 4.0. Document for completeness; generally acceptable with monitoring. ### Example validation output ``` ====================================================================== CVE REAL-TIME LOOKUP REPORT NIST National Vulnerability Database (NVD) — EU CRA Compliance ====================================================================== SBOM file: output/sbom.json SBOM format: CycloneDX Components in SBOM: 47 Components checked: 30 CVSS threshold: ≥ 7.0 CVEs found: 0 --- COMPONENT INVENTORY --- fastify@4.26.0 — CLEAR mqtt-packet@8.3.0 — CLEAR serialport@12.0.0 — CLEAR node-mqtt@4.3.9 — CLEAR express@4.19.1 — CLEAR ws@8.14.3 — CLEAR zigbee-herdsman@0.35.2 — CLEAR ... (23 more components) --- CRA COMPLIANCE ASSESSMENT --- [PASS] No vulnerabilities found at or above the CVSS threshold. Component inventory is consistent with CRA Annex I §1(2) requirements. --- SUMMARY --- Components checked: 30 / 47 Total CVEs found: 0 Critical: 0 High: 0 Medium: 0 Low: 0 Errors: 0 RESULT: PASS — No high/critical vulnerabilities found. SBOM is consistent with CRA cybersecurity requirements for the checked components. ====================================================================== ``` The agent runs the `cve_realtime_lookup` tool iteratively — first on the initial SBOM to identify vulnerabilities, then again after remediation to verify clean results — and surfaces findings inline so you can resolve issues before conformity declaration. --- Back to [Skill Library](https://rakenne.app/skills/index.md)