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)

Vulnerability Findings

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

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.