ARTICLE · 1292661
无法拿到源码怎么做 SCA、漏洞审计、合规取证
一、痛点：没有源码，供应链安全怎么做？
在工程落地中，大量依赖是二进制形态：
第三方闭源 SDK、静态库.a、动态库 so、dll、lib 设备固件镜像（RTOS、单片机固件、嵌入式 Linux 固件） 第三方编译好的工具链、预编译二进制程序 外购板卡配套闭源驱动、协议栈组件
很多项目在这里卡壳：
没有源码 → 不能跑 SAST；没有 pom/package-lock/go.mod → 常规 SCA 识别不出依赖；测评 / 甲方依据 GJB/Z141、GB/T43698 要求交付 SBOM、风险评估报告，直接卡住验收。
误区：无源码 ≠ 豁免供应链安全评估。标准只区分评估手段，没有豁免条款。只是检测手段从源码分析，切换到二进制层面分析。
二、无源码场景风险和源码场景的差异
源码侧风险：编码漏洞、硬编码密钥、不安全函数、代码后门、许可证文本。二进制侧新增风险：
编译后遗留已知开源组件漏洞（上游开源库编译进固件，不对外声明） 静态链接依赖，依赖树不可见，组件被打包合并 固件内置后门、调试接口、隐藏串口、硬编码密钥 编译器、构建链投毒，编译阶段植入恶意逻辑 许可证风险：二进制分发开源组件，违反 GPL 等强传染许可证
核心难点：二进制没有 AST、没有依赖声明文件，组件识别依赖特征指纹、哈希、符号串、版本特征。
三、无源码二进制供应链安全技术栈拆解
二进制 SCA 原理：提取文件哈希、字符串常量、函数符号、版本标识、特征指纹，和组件指纹库比对，识别内置的开源组件、第三方库。支持对象：so、dll、a、elf、pe、固件镜像、容器镜像。
✅ 能力：识别内置 OpenSSL、zlib、libcurl、sqlite 等常见开源库，输出组件版本、CVE 漏洞、许可证信息，输出 CycloneDX/SPDX SBOM。❌ 局限：
库被裁剪、符号 strip、编译优化、静态合并后，识别率大幅下降； 自研闭源私有组件，没有指纹库，无法识别； 无法精准定位漏洞是否可达，只能判定 “组件存在漏洞”。
工具清单：开源：Trivy、Grype、syft、ossidetect、go-sbom
固件经常是打包后的镜像，需要先拆包，才能拿到里面的二进制文件再送入 SCA。典型流程：固件镜像 → 固件解包（binwalk、unsquashfs）→ 提取 rootfs、elf、驱动库 → 批量二进制 SCA。重点：很多厂商固件会压缩、加密、加壳，加密固件无法直接解析，只能要求供应商提供未加密测评版本或者供应商侧提供 SBOM。
针对高风险核心组件：
IDA/Ghidra：反汇编、查看函数逻辑、硬编码密钥、调试后门、未授权接口； Ghidra 支持批量脚本，提取字符串、导入导出符号，辅助确认组件版本；适用场景：少量关键组件深度审计，不适合大规模批量扫描。
注意：军工项目逆向审计需要在合同、授权范围内开展，避免知识产权纠纷。
二进制 Fuzz 不需要源码，直接对二进制程序、协议解析库、固件服务做 Fuzz，捕获内存越界、溢出、崩溃。工具：AFL++、libFuzzer、honggfuzz。作用：二进制 SCA 只能报 “存在 CVE”，Fuzz 可以验证漏洞是否在当前编译版本、当前配置下可触发，用来支撑 VEX 漏洞声明。
这是无源码场景下非常重要的信任手段：
要求供应商提供每个二进制制品的 SHA256 哈希； 制品签名（Cosign 等）； 交付后比对哈希，防止交付途中被替换、投毒。即使我们看不懂内部代码，至少保证交付物和供应商原始版本一致。
四、一套标准化落地流程
步骤1：资产梳理收集所有闭源制品：固件、SDK、so/dll、静态库、第三方工具，记录供应商、版本、用途。步骤2：获取供应商侧材料（优先，成本最低）优先向供应商索要：该组件的SBOM、VEX、开源评估报告、许可证清单。> GJB/Z141明确要求供应商提供配套安全材料，不要自己上来就逆向。步骤3：二进制SCA批量扫描对所有二进制文件、解包后的固件文件执行二进制SCA，生成SBOM初稿。步骤4：差异研判与指纹识别补充对识别失败、识别模糊的组件，结合版本说明、字符串、供应商文档人工复核。步骤5：高风险组件深度验证高危CVE组件：二进制Fuzz + 逆向抽样审计，判断漏洞可达性。步骤6：编制VEX漏洞声明区分：可利用漏洞（要求供应商整改）、不可达/未启用漏洞（VEX说明，留存证据）。步骤7：制品哈希归档、签名校验所有二进制制品哈希存档，后续版本变更做比对。步骤8：输出交付包二进制SCA报告、SBOM、VEX、固件解包记录、Fuzz测试记录、哈希校验记录。
五、项目中高频踩坑清单
供应商拒绝提供 SBOM，声称是闭源不能给✅ 应对：合同前置约定交付义务；按 GB/T43698，供应商需要提供供应链安全评估材料，不是提供源码。 固件加密、加壳，binwalk 无法解包✅ 应对：要求测评专用明文版本；或者由供应商内部完成分析并提供报告。 静态链接多库合并，二进制 SCA 只识别一部分组件，漏报✅ 应对：结合供应商开发文档、编译脚本交叉核对，不能只依赖工具输出。 直接拿二进制 SCA 报告当成最终验收材料，不做可达性研判✅ 应对：二进制 SCA 是 “发现资产和漏洞清单”，必须配套 VEX，否则甲方会批量质疑漏洞。 逆向审计越界，侵犯第三方知识产权✅ 应对：在采购合同、保密协议中明确允许为安全测评目的做有限逆向。
六、和前面三套体系如何联动
自研源码：SAST + 源码 SCA 开源组件（有源码）：源码 SCA + SBOM 闭源 SDK / 固件：二进制 SCA + 固件解析 + Fuzz + 哈希验签全部资产汇总后，合并成全局统一 SBOM，统一漏洞台账、统一 VEX 管理，满足 GJB/Z141 全软件供应链管控要求。
七、总结
无源码二进制组件，是软件供应链安全里最容易被忽略、也最难落地的一环。它的核心思路不是 “强行拿到源码”，而是换一层检测手段，从源码分析转向二进制指纹、制品校验、黑盒 / 灰盒验证。在军工、嵌入式装备项目中，把二进制 SCA、固件解析、Fuzz、VEX、哈希溯源组合起来，完全可以支撑 GB/T43698、GJB/Z141 的测评取证。在项目前期的采购合同、技术协议里就把 SBOM、安全评估材料交付要求写清楚，远比后期测评阶段再补救成本低得多。
