2. IoT第三方组件资产盘点

IoT设备的软件供应链比传统IT系统更隐蔽：一台摄像头里可能同时存在芯片厂商提供的BSP、模组厂商的AT指令固件、第三方音视频SDK、十几个开源库，以及设备侧SDK所连接的云服务。这些组件往往没有统一的包管理器，也没有集中的依赖声明文件，因此资产盘点的第一步不是"扫描"，而是先明确盘点对象和边界。

一、五类盘点对象及其识别入口

IoT第三方组件可以按来源分为五类，每类的识别入口不同：

• 固件：包括Bootloader、内核、根文件系统、应用分区。识别入口是固件镜像本身，可通过binwalk -e firmware.bin解包，观察文件系统类型（squashfs、ubifs、ext4）和分区布局。
• SDK：芯片原厂SDK（如ESP-IDF、Realtek Ameba）、模组厂商SDK、云厂商设备SDK（如AWS IoT Device SDK、阿里云Link SDK）。识别入口是源码目录中的components/、third_party/、port/等目录及版本说明文件。
• 开源库：如OpenSSL、mbedTLS、cJSON、lwIP、BusyBox、Dropbear。识别入口是二进制中的版本字符串、源码中的LICENSE、README、CHANGELOG。
• 云服务：设备接入的MQTT Broker、OTA服务、设备管理平台、证书服务。识别入口是设备配置中的域名、端口、证书CN字段、SDK默认Endpoint。
• 硬件模块：Wi-Fi/BLE模组、蜂窝模组、安全芯片、传感器。识别入口是模组丝印、AT指令版本、芯片型号及配套固件版本。

这五类对象并非孤立，而是通过"固件承载SDK、SDK引用开源库、设备通过SDK连接云服务、硬件模块提供底层能力"形成一条完整的组件链。盘点时必须沿着这条链逐层展开，否则容易遗漏隐藏在固件深处的开源库。

二、组件清单的构建方法

盘点不是一次性动作，而是一个"采集—归一—关联—验证"的循环。以下以一台运行Linux的IP摄像头为例说明具体做法。

采集阶段：从设备中提取固件镜像，使用binwalk -e解包后得到squashfs根文件系统。挂载后遍历/usr/lib、/usr/bin、/lib，对每个可执行文件和共享库执行strings提取版本信息。例如：

# 提取固件并解包
binwalk -e camera_fw_v2.3.1.bin

# 挂载根文件系统
mkdir /mnt/rootfs
mount -t squashfs -o loop _camera_fw.extracted/squashfs-root.img /mnt/rootfs

# 扫描OpenSSL版本
strings /mnt/rootfs/usr/lib/libssl.so.1.1 | grep -i "OpenSSL 1"
# 输出示例：OpenSSL 1.1.1k  25 Mar 2021

# 扫描BusyBox版本
/mnt/rootfs/bin/busybox 2>&1 | head -1
# 输出示例：BusyBox v1.31.1 (2020-05-12 10:23:45 CST)

归一阶段：将采集到的组件名称、版本、来源路径、许可证类型统一写入结构化清单。建议字段包括：组件名称、版本号、组件类型（固件/SDK/开源库/云服务/硬件模块）、来源路径或Endpoint、许可证、已知CVE编号、责任人。对于无法直接获取版本的组件，可通过哈希比对或特征字符串匹配推断。

关联阶段：将组件清单与设备型号、固件版本、生产批次建立映射。同一款设备的不同固件版本可能引入不同组件，因此清单必须带版本维度。例如摄像头V2.3.1使用OpenSSL 1.1.1k，而V2.4.0升级为OpenSSL 3.0.8，两者的CVE影响范围完全不同。

验证阶段：通过SBOM工具（如Syft、Trivy）对固件镜像生成标准化SBOM，再与人工清单交叉比对，发现遗漏。Syft支持直接扫描目录和容器镜像，输出SPDX或CycloneDX格式。

三、SBOM在IoT场景的落地要点

SBOM（软件物料清单）在IT领域已有较成熟的实践，但IoT场景有其特殊性，落地时需注意以下四点：

• 格式选择：CycloneDX对硬件和固件组件的表达能力更强，支持firmware、device等组件类型；SPDX在许可证合规场景更通用。建议至少支持一种，并在清单中保留原始格式。
• 粒度控制：IoT固件中大量静态链接的库无法通过动态依赖分析发现，需要结合二进制特征扫描。SBOM粒度应至少覆盖到"库名称+版本"，对于安全关键库（如TLS、SSH、Web服务器）应精确到补丁级别。
• 更新机制：设备出厂后组件不会自动更新，SBOM必须与固件版本绑定并随OTA升级同步更新。建议在CI/CD流水线中集成SBOM生成步骤，每次构建自动输出并归档。
• 最小可用字段：对于资源受限设备，完整SBOM可能过大。可定义"最小SBOM"：组件名称、版本、供应商、许可证、已知漏洞编号。其余字段按需扩展。

四、盘点结果的实际判断

完成一轮盘点后，如何判断清单是否可用？可以从三个维度检查：

以某摄像头固件为例，首轮盘点识别出47个第三方组件，其中OpenSSL 1.1.1k、BusyBox 1.31.1、Dropbear 2020.81三个组件存在已知高危CVE。通过SBOM关联发现，该固件版本已出货约1.2万台，安全团队据此优先安排OTA修复。如果缺少版本精确信息，只能笼统判断"使用了OpenSSL"，无法确定是否受特定CVE影响，修复优先级也无从谈起。

盘点的最终产出不是一份静态表格，而是一套可查询、可关联、可更新的组件资产库。它既是漏洞响应的输入，也是供应链准入和合规审计的基础。下一阶段的工作，是在此清单之上建立组件风险评分与修复优先级模型。