没有源码的软件,怎么查漏洞?

先讲一个真事。

一家公司买了某品牌的工业网关，用了三年。今年Heartbleed级别的OpenSSL漏洞又上新闻，老板把IT负责人叫来，问了一句话：我们那台网关里的OpenSSL是什么版本？受不受影响？

IT负责人答不上来。打电话问厂商，厂商让提交工单。三天后工单回复：请提供设备序列号，我们会评估。

源码不在你手里，固件是编译好的二进制，连对方用了哪些开源组件都说不清。这台设备就这样运行在你最核心的网络里，你对它一无所知。

这不是个例。这是所有买软件、买设备、接手旧系统的公司共同的处境。

一、固件的成分清单，为什么这么难列

Web应用想列个软件清单（SBOM），敲一句npm list就完了。固件不行。

第一道坎，固件里的库大多是静态编译进去的。没有package.json，没有requirements.txt，没有任何机器可读的清单留下来。库和你的代码烧成了一整块bin。

第二道坎，二进制通常被strip过。符号表删掉了，版本号只能靠字符串常量和文件哈希去猜。OpenSSL会留版本串，libpng不一定留，自己改过的库什么都不留。

第三道坎，你连文件系统都得自己拆。固件镜像多半是squashfs、JFFS2、cramfs这类嵌入式文件系统，得先解包才能看到里面的东西。不少消费级路由器还加密固件包，解密都成问题。

一句话总结：软件SBOM是"生成"出来的，固件SBOM是"逆向"出来的。这俩根本不是一种工作。

难归难，法规可不等你想明白。欧盟CRA附件一明确要求，SBOM必须以通用机器可读格式覆盖产品"至少顶层依赖"。对固件来说，这意味着每个OS包、每个共享库、每个bootloader、每个内核模块都得在册。ENISA的漏洞报告义务从2026年9月11日起已经适用，24小时早期预警窗口是硬性的。

没有成分清单的固件厂商，连"这个漏洞要不要上报"都判断不了。这不是合规瑕疵，这是没法做业务。

二、两条路线，先看你在链条的哪一端

固件SBOM的生成路线只有两条，选哪条取决于一个前提：你有没有控制构建。

路线一，构建期生成。Yocto和Buildroot这类构建系统，本来就知道自己编译了什么、链接了什么，让它们顺手输出SBOM，这是精度最高的方案。自己造产品的厂商应该走这条路，几乎没有商量余地。Yocto对CycloneDX有原生支持，配好之后每个构建产物自动带清单。

路线二，事后分析。你拿到的是ODM给的固件包，或者是三年前买的盒子，源码和构建过程都不存在了。这时只能对二进制做事后分析：先用binwalk这类工具解包，再对里面的组件做识别和漏洞匹配。

两条路线不冲突。成熟的做法是：自研部分构建期出清单，外购部分事后分析去验证。

三、商业工具靠什么吃饭

事后二进制分析这个领域，目前牌面最大的是Black Duck Binary Analysis（BDBA）。

它的原理说穿了不复杂：给编译产物算指纹，跟自己的知识库比对，识别出用了哪些组件、什么版本。难的是积累，Intel、ARM、PowerPC、MIPS这些架构的编译产物它都认，编译器优化导致的代码变形也处理过大量案例。

今年5月，Gartner发布了第一届软件供应链安全魔力象限，Black Duck进了领导者象限。评语里有句关键的话：它支持的范围超出云原生开发，包括嵌入式系统、固件和纯二进制软件的扫描。这在SCA厂商里几乎是独一份。

另一张牌是漏洞情报。Black Duck的BDSA advisories由人工团队维护，平均比NVD收录同款漏洞早近三周，另外还有3500多个CVE根本没进NVD的漏洞在它的库里。对固件这种"出了漏洞要等很久才能打补丁"的东西，早三周知道，价值不小。

今年4月14日，BDBA发了一次更新，开始对Docker Hardened Images做签名式检查，并且配合VEX标注"受影响、不受影响、调查中"三种状态。VEX这个格式值得留意，它的作用是把"有漏洞"和"这个漏洞真的能打到你"区分开。容器基础镜像里躺着几百个CVE，真正能被你的应用触发的可能只有几个，VEX就是那把筛子。

BDBA之外，这个市场还有几家具代表性的公司。Finite State专做固件和IoT的binary analysis；NetRise主打无源码的二进制和固件分析；德国的ONEKEY做设备固件分析加CRA合规报告；Karamba VCode走的是"从二进制推导SBOM再加持续CVE监控"的路线，顺带检查DEP/NX、PIE、RELRO、栈保护这些编译防护有没有开，还有没有硬编码凭据。

四、不想花钱，开源方案够用吗

够起步，不够收尾。

先说OpenSSF的cve-bin-tool。这是CNCF之外的另一个OpenSSF项目，当前版本3.4，内置451个组件识别器，覆盖openssl、libpng、libxml2、expat这些二进制里最常见的常客。漏洞数据不只依赖NVD，还接了Red Hat、OSV、GitLab Advisory Database和Curl官方的数据。它能生成CycloneDX和SPDX格式的SBOM，也能输出VEX，支持离线扫描。

一条命令扫一个目录，输出HTML报告，对个人和小团队来说，这已经能干掉八成的"我们用了什么版本"问题。

短板也很明确：对深度strip的二进制识别率有限，版本靠字符串推断，遇到魔改过的库就抓瞎。它自己文档也承认这个局限。

再看EMBA。这是个开源固件分析框架，把整个流程自动化了：binwalk解包、静态文件系统分析、QEMU动态模拟、硬编码密钥发现、SBOM生成，一条龙。安全研究人员做固件评估，EMBA是事实上的起点工具。

但EMBA的定位是研究者的分析框架，不是产品安全平台。它的文档明说：自动发现的问题需要人工分析确认。拿它做一次性评估没问题，拿它管一百个SKU的持续监控，力不从心。

五、供应商给的SBOM，要不要验

这是二进制分析最有意思的用法。

CRA实施后，欧美的采购流程里会越来越多出现这样的要求：供应商随软件交付一份SBOM。问题来了，这份清单是真的吗？

打包环节可能改过内容，编译时可能塞进了清单里没有的组件，清单生成的时间和最终交付的产物可能隔着好几个版本。行业里管这个叫declared与delivered的差距：声明的成分，和实际到你手里的成分，未必是一回事。

验证办法很朴素：拿二进制分析工具扫一遍收到的产物，和供应商的SBOM对比。多出来的组件、更旧的版本、没声明的许可义务，都会现形。

BDBA的三大典型场景，并购尽调、商用软件准入、嵌入式合规，本质都是同一件事：不信任声明，只信验证过的东西。

信任供应商，验证软件。这两句话不矛盾，后面那句是前面那句能成立的前提。

六、我的三点看法

第一，设备安全的真正问题从来不是"有没有漏洞"。任何跑了很多年的固件，翻出来都有旧组件。真正的问题是，漏洞曝光的时候，你能不能在一个小时内回答"我中招了没有"。回答不了，原因几乎只有一个：没有成分清单。

第二，别把二进制分析当成纯安全工具。它在采购、并购、供应链管理里的价值，眼下比在漏洞扫描里更大。给采购流程加一道"交付物二进制扫描"的关卡，成本很低，回报很高。

第三，预算紧的团队别等工具，今天就能动手。binwalk解包，cve-bin-tool扫描，两个都是免费开源的，一个下午就能跑通第一份固件分析报告。等CRA把你的客户逼着来问你要清单时再起步，就晚了。

软件供应链安全这条线，过去两年大家聊的都是云原生、都是容器。但别忘了，这个世界上还有海量的软件跑在你看不见的固件里。它们不会自己站出来说"我有漏洞"。

你得自己拆开看。

· · ·

你手里有多少来路不明的固件和二进制？评论区聊聊。

关注我，每天一篇安全工具深度分析