ARTICLE · 1005319
源码查自己,二进制查别人,软件成分分析为什么必须两条腿走路
软件供应链安全 · 合规实务
源码查自己，二进制查别人，软件成分分析为什么必须两条腿走路
从国家安全预警到欧盟 CRA，SCA 与 BAT 为什么必须一起上
一、从一次国家级预警说起
2026 年 6 月 18 日，国家安全部发布安全提醒。国家网络安全通报中心监测发现，近期集中爆发多起供应链投毒攻击事件，涉及开源软件仓库和商用工具两大核心供应链场景。
通报给出的定性相当直白。这类事件攻击隐蔽性强、影响范围广、危害程度高、传播速度快，可造成凭据被窃取、远程代码执行和敏感数据泄露。攻击模式是典型的"上游污染、下游传导"：攻击者劫持开发者账号、篡改开源仓库源码、污染安装包与发布版本，恶意程序随着软件的发布与更新被输送到海量终端。
针对研发管理环节，通报明确提出要"管住依赖链"：建立软件物料清单管理机制，全面掌握系统中开源组件、第三方库及插件工具的来源、维护与漏洞情况，对长期无人维护、来源不清、版本过旧、权限过高的组件及时替换或降权使用。重点系统上线前，应当开展代码安全检测、依赖项扫描和恶意代码排查。
这段表述值得行业读者逐字读一遍。它把"软件物料清单"从一个工程术语，写进了国家级安全通报的管理要求。
同一条线上，三个月前还有一个更硬的动作。2026 年 3 月 31 日，国务院总理李强签署第 834 号国务院令，公布《国务院关于产业链供应链安全的规定》，自公布之日起施行。这是我国首部专门维护产业链供应链安全的行政法规。
十八条内容里，关键领域清单制度、风险监测预警、风险防范与应急管理构成主干。落到软件行业，这意味着供应链的透明度（用了哪些组件）、可控性（组件是否可信）、韧性（出问题后能否快速响应），第一次被放进国家安全层面的审查视野。
国内强标这条线同样在推进。GB 44495-2024《汽车整车信息安全技术要求》与 GB 44496-2024《汽车软件升级通用技术要求》已于 2026 年 1 月 1 日实施，新申请型式批准的车型先行执行。
《网络安全法》在 2025 年 10 月完成修正，新法同样已于 2026 年 1 月 1 日施行，处罚力度显著加大。GB/T 43698-2024《网络安全技术 软件供应链安全要求》虽属推荐性国家标准，但在监管检查、招标采购与客户准入环节被直接引用，实际约束力已经接近强制。
国际方向的时间点正在逼近。欧盟《网络弹性法案》（CRA）的漏洞与事件上报义务将于 2026 年 9 月 11 日生效，也就是明天。
制造商一旦确认产品存在被实际利用的漏洞，需要在 24 小时内向 ENISA 单一上报平台提交早期预警，72 小时内提交详细通报，修复措施发布后 14 天内提交最终报告。这个节点比 CRA 主体义务全面适用（2027 年 12 月 11 日）早了 15 个月，且覆盖所有仍在支持期内的存量产品。罚款上限为 1500 万欧元或全球年营业额的 2.5%，取两者中的高者。
把这些日期排在一起，指向同一个判断。软件供应链安全已经完成身份转换，从企业内部的工程最佳实践，变成了产品能不能上市、订单能不能交付的前置条件。
问题随之而来。当合规要求落到工具层面，很多团队会问一个具体的问题：到底该用什么样的检测手段，才能既覆盖得住，又拿得出证据。
二、先把两个概念说清楚
软件成分分析在这一领域通常分成两条技术路线。一条面向源代码，一条面向二进制制品。行业内习惯把它们简称为 SCA 与 BAT。
2.1 SCA，回答的是资产的四个基本问题
SCA 即开源软件成分分析，核心工作是识别、分析、追踪软件中所包含的第三方与开源组件。
它要回答的问题很朴素：项目用了哪些开源组件，这些组件从哪来，是什么版本，许可证是否允许当前的用法，有没有已知漏洞。
从这个角度看，SCA 的本质是软件资产的盘点与管理工具。漏洞检测是它的能力之一，不是它的全部定义。很多团队把它当成一个漏洞扫描器来接，结果在 SBOM 交付和许可证合规上反复返工，原因往往就在这里。
它的工作链路是一条清晰的流水线：
资产识别 → 生成 SBOM（软件物料清单）→ 与漏洞库、许可证库比对 → 风险判定与处置建议
检测方式覆盖五种，各自适用于不同的项目形态与合规阶段：
再往下是数据底座。这一层决定了检测结果的可信度。成熟的方案通常自运营一套基因库，覆盖 1100 万以上的项目组件、2.6 亿以上的开源组件版本、2600 多种许可证类型、60 万以上的安全漏洞，并同步维护通用、商业、官网、社区以及定向行业的多源漏洞库，保持实时监测。
为什么强调定向行业漏洞库。因为通用漏洞库对车规芯片、车载中间件、工业协议栈、特定固件平台的覆盖往往是滞后的，而恰恰是这些组件最容易出问题。
SBOM 的字段规范也在全球范围内趋于一致。2026 年 7 月 30 日，美国网络安全和基础设施安全局（CISA）联合多国机构发布 2026 版 SBOM 最小元素，取代 2021 年的旧版。新版增加组件哈希算法、组件许可证、SBOM 工具名称、生成上下文等字段，并补充数字签名要求，让物料清单可以被自动化地校验与流转。
2.2 BAT，解决的是拿不到源码怎么办
BAT 即二进制软件分析工具，面向二进制软件或文件，包括固件、安装包、磁盘镜像，以及 .so、.a、.dll、.exe 等各类制品。
它不需要源代码，通过启发式解析制品格式与特征指纹匹配来识别其中的组件，再与漏洞库、许可证库比对，完成供应链产品的安全风险治理。
能力清单覆盖八个方向：软件资产识别与 SBOM、已知漏洞分析、恶意代码检测、敏感信息分析、配置安全分析、代码缺陷分析、许可合规检测、漏洞告警与开源软件安全管理。
覆盖的格式范围，是它区别于源码工具的核心价值所在：
- 压缩包与安装包
：.rpm、.deb、.apk、.ipa、.msi、.dmg、.exe 等 - 文件系统与磁盘镜像
：Docker 镜像、.iso、.qcow2、.vmdk、.img 等 - 固件
：UEFI、Android OTA、OpenWrt、路由器与 PLC 固件、物联网设备 OTA 等 - 语言与架构
：C/C++、Java、Go、Rust、C#；x86、ARM、MIPS、PowerPC、RISC-V；Linux、Android、macOS、Windows
它的产品定位可以概括为一句话，二进制版的软件成分分析。下游客户用它验证上游供应商的安全与合规状况，上游供应商用它对齐下游客户的检测手段。在横向产品矩阵里，它对应的是二进制漏洞扫描能力，配套 ISO 21434 的信息安全漏洞检测与二进制风险审计。
2.3 两条路线放在一起看
三、为什么源码级检测不能省
有一种常见的误解是，只要能把二进制扫清楚，源码层的检测就可以简化。事实并非如此。以下五点，是源码级检测不可替代的原因。
第一，二进制扫描识别不了 Copyright 版权风险。 受技术原理限制，二进制制品中通常不保留完整的版权声明信息，而版权恰恰是欧美开源许可诉讼的主要切入点。拿不出源码级的版权与许可证证据，在诉讼与合规审查中会非常被动。
第二，二进制扫描缺少编译与优化过程的信息。 编译和优化会丢失变量名、数据结构等类型信息，直接后果是组件识别不到，或者版本判断出错。版本错了，漏洞匹配的结果也就不可信。
第三，二进制扫描识别不了已经通过补丁修复的漏洞。 而 UN R155 与 GB 44495 等信息安全规范明确要求对漏洞进行识别与持续管理。识别不到补丁状态，就无法证明漏洞已被处置，也无法形成可追溯的闭环记录。
第四，溯源证据链的要求是源码到二进制的完整链条。 美国 ICTS 相关合规要求供应商提供从源代码到二进制制品的完整可审计溯源材料，单纯依赖二进制工具无法满足这一要求。
第五，主机厂标准已经写明了双扫描。 以大众为代表的主机厂供应链标准，明确要求供应商在开发阶段和发布阶段同时以源码和二进制两种方式开展开源成分分析。这属于合同与准入层面的硬性条款。
这五点指向同一个结论。源码与二进制解决的是两类不同的问题，缺少任何一条腿，风险都会漏到发布之后，而那时返工的成本已经不在一个量级。
四、SCA 的必要性
把 SCA 针对源码的必要性单独拿出来讲，是因为它承担的是治理体系的底座功能。
法规强制已经形成闭环。 2026 年 3 月施行的《国务院关于产业链供应链安全的规定》，把风险监测预警、风险防范与应急管理确立为关键领域的法定义务，对软件行业而言，组件级的资产台账是履行这些义务的技术前提。GB/T 43698-2024 覆盖开发、交付、运维、废止全流程，包含风险管理、组织管理、供应活动管理三大维度 72 项指标。GB/T 43848-2024《网络安全技术 软件产品开源代码安全评价方法》把软件产品中的开源代码成分纳入评价范围。《网络产品安全漏洞管理规定》明确漏洞发现、上报、处置的义务，与 SCA 扫描出的已知漏洞管理强相关。在汽车行业，GB 44495 与 GB 44496 已经进入强制执行期。在出海方向，欧盟 CRA 的上报义务即将于 9 月 11 日生效，GDPR 按全集团收入处罚。违规的代价是认证不通过、产品无法上市。
供应链投毒已经是国家级风险议题。 2026 年 6 月国家安全部的预警，把攻击面从研发侧扩展到开发终端、代码仓库、制品库和 CI/CD 流水线。这类攻击的关键应对动作是同一件事：知道自己用了什么、什么版本、从哪来。没有组件台账，应急响应连排查范围都圈不出来。
开源风险是真实的业务风险。 开源组件平均占代码库的 80% 以上。恶意组件包已被收录约 44 万个，并且仍在实时增长，依赖混淆与账号劫持型攻击频繁出现。出海企业还额外面对开源许可与版权诉讼，这是欧美市场最主要的法律风险切入点之一。
供应链交付已经形成商业刚需。 约 90% 的企业需要向甲方提供开源安全合规证明，形式包括 SBOM、Notice 文件、不含黑名单组件的声明、无 6 个月以上高危漏洞的证明，以及跨国企业要求的定向合规报告。没有工具出具的可信报告，供应链订单无法完成交付验收。
主动开源治理需要全生命周期管控。 对主动拥抱开源的厂商来说，开源管控要覆盖选型、引入、使用、升级、退出全过程，涉及自研率评估与代码来源溯源。国内已有基础软件厂商与操作系统厂商走在这条路上，把开源合规做成了产品能力的一部分。
研发左移直接影响成本。 在编码阶段发现合规与安全问题，避免选型定型后再回退开发测试的高成本返工。函数级漏洞识别、漏洞可达性检测、自动降噪，能够大幅压缩人工审计的工作量。这部分收益在项目量大的团队里非常可观。
信创与自主可控需要源码级证据。 自主源代码溯源、自主可控认证、软件相似度评估，这些工作都建立在源码级分析能力之上。二进制工具无法提供代码相似度与来源溯源所需的粒度。
漏洞响应需要小时级能力。 在 HVV 或重大 CVE 爆发时，需要快速定位自身受影响范围。小时级的漏洞舆情监控、POC/EXP/RCE 分析、缓解措施建议，只有把资产清单建在源码与 SBOM 层，才能快速回答"我有没有用、我用了哪个版本"。
五、BAT 的必要性
BAT 的必要性来自一个现实约束。很多时候，你拿不到源码。
第三方与外购交付物的核查只能靠二进制。 外购的模组、控制器、网关、传感器，供应商往往只交付制品，不交付源码。要对这些交付物做安全与合规验收，二进制分析是唯一可行的技术路径。
检测与认证机构的业务本身依赖它。 国家级汽车检测机构在承接 GB 44495 等强制性标准的检测业务时，面对的是整车与零部件实物，可能无法获取完整源码。二进制分析能力直接决定检测业务能否承接。
主机厂管理供应商需要统一的验收手段。 一个整车项目涉及数百家供应商，要求所有供应商开放源码并不现实。用二进制分析对交付物做统一验收，是可在供应链规模上落地的方案。
工控和物联网领域的固件检测是刚需。 设备固件通常以镜像形式发布，涉及多种架构与实时操作系统。要做供应链监管检查或出口合规核查，二进制固件分析是主要手段。
ISO 21434 的漏洞检测与渗透测试需要配套工具。 信息安全漏洞检测与二进制风险审计，是这套体系里的配套能力。
存量资产盘点和应急响应需要无源码能力。 当某个广泛使用的开源组件爆出高危漏洞时，企业需要快速确认哪些在售制品、哪些已交付设备受影响。制品与固件层面的快速扫描，是应急响应的第一手数据来源。在供应链投毒事件中，已交付设备的固件往往是最后才被排查到的一环，也是最需要无源码手段的一环。
它让上下游的检测手段对齐。 供应商用二进制工具做自检，主机厂与检测机构用同类工具做复核，双方对同一份交付物可以得到一致结论，减少验收环节的反复沟通。
六、业务场景清单
SCA 的典型场景
BAT 的典型场景
七、适用对象分层
不同角色在这套体系里的位置不同，需求重点也不同。
一句通俗的区分。BAT 侧重拿到对方的东西就能查，服务对象是检测机构、主机厂审供应商、监管取证。SCA 侧重把自己的代码全程管住，服务对象是研发左移、出海合规、信创与主动开源。
八、军工行业，自主可控语境下的软件供应链治理
军工是一个需要单独讨论的行业。原因在于它对软件供应链的要求，同时叠加了合规、保密、自主可控和全生命周期管理四重约束。
装备的信息化与智能化程度持续提升，软件在装备价值构成中的比重越来越大。
与之相伴的是开源组件在军工软件中的广泛存在。基础库、通信中间件、图形界面框架、数据处理组件，工程实践中很难完全绕开开源生态。
这带来三个具体问题：这些组件从哪来，版本是否可控，是否存在已知漏洞以及是否已被修复。
离线与涉密的运行环境，决定了工具形态。 涉密网络不允许连接外部互联网，通用的在线漏洞库查询与云端分析无法使用。军工单位需要的是私有化部署、离线知识库更新、分析全程数据不出内网的方案。这一点在选型阶段如果没考虑清楚，后期几乎无法补救。
源码级溯源是自主可控论证的基础材料。 自主可控、自主创新、进口件替代这类论证，都需要回答代码来源与自研比例的问题。开源成分清单、代码片段级识别、软件相似度评估，这些能力构成论证链条的证据层。二进制工具在这里帮不上忙。
多级配套的供应链，需要统一的可验证手段。 军工产品的供应链层级多、外协环节多，整机单位对下游配套单位的软件交付物往往只能拿到二进制形态。设备到货验收、外购模组的合规核查、进口设备的风险排查，这些环节需要无源码的分析能力。装备软件二进制交付物的成分识别与漏洞核查，是质量与信息安全流程中的可落地动作。
制度与标准的约束是现成的。 GJB 5000B《军用软件研制能力成熟度模型》对研制过程的规范化提出要求，GJB 9001C《质量管理体系要求》覆盖产品实现全过程，GJB 8114《军用软件安全性设计指南》对软件安全性设计给出规范。武器装备科研生产单位保密资格认定、武器装备承制单位资格审查、涉密信息系统分级保护相关技术要求，以及前述行政法规与等保 2.0、GB/T 43698-2024，共同构成军工软件供应链治理的制度框架。《网络安全审查办法》对关键信息基础设施运营者采购网络产品和服务提出审查要求，把供应链来源风险纳入了法定审查范围。
落地路径可以这样拆。 研制阶段，用源码级能力建立组件清单与许可证台账，把开源选型纳入评审节点。测试与定型阶段，对自研代码做代码片段级识别，输出自研率与来源溯源材料。生产与交付阶段，对配套单位交付的制品做二进制成分与漏洞核查。运行维护阶段，建立离线漏洞库的持续更新机制，保证漏洞处置可追溯。
这里的关键判断是，在军工场景下，源码能力与二进制能力分别对应不同的合规证据。前者支撑自主可控论证与过程管控，后者支撑交付验收与外购件核查。两条腿都要有。
九、法规地图
上位法与通用法规
软件供应链专项
汽车行业
出海与海外市场
垂直行业
十、双轮驱动的治理闭环
把上面的内容收束一下，这套体系的形状其实很清楚。
法规层面，软件供应链安全已经是市场准入条件。 国务院 834 号令把产业链供应链安全提升为行政法规层面的制度要求，国内 GB/T 43698 在采购与监管场景中被当作硬要求执行，汽车 GB 44495 与 GB 44496 已进入强制执行期，欧盟 CRA 的上报义务在 9 月 11 日生效、2027 年 12 月全面适用。违规的代价是认证不通过、无法上市、按全球收入罚款。
风险层面，开源已经是业务风险而非技术议题。 八成以上的代码来自开源，恶意组件包以数十万量级存在并持续增长，国家级安全通报已经就供应链投毒连续发出预警。这些风险不会因为不检测而消失，只会推迟到问题爆发的时刻。
商业层面，没有报告就没有交付。 九成左右的企业需要向客户提供开源安全合规证明，供应链验收已经把 SBOM 与漏洞状态证明列为交付物。
技术层面，源码与二进制缺一不可。 源码能力解决精度与合规深度，覆盖版权风险、补丁状态识别、溯源证据链、研发左移。二进制能力解决覆盖广度与不可获取源码的场景，覆盖检测机构业务、供应商验收、固件与存量资产。只做其中一条，风险漏到发布之后，返工成本会高出很多。
国产化层面，自主可控的诉求已经落到工具本身。 信创趋势下，用国产工具替代海外同类产品是明确方向，离线知识库、私有化部署、行业定向漏洞库集成是选型时的关键指标。
成本层面，左移是唯一的降本方式。 编码阶段发现合规与安全问题，代价远低于选型定型后的回退开发测试。函数级漏洞识别、漏洞可达性判断、自动降噪，直接决定人工审计的工作量。
软件供应链治理没有一步到位的方案。它需要把资产盘点、成分分析、漏洞闭环、合规交付串成一条流水线，而源码与二进制就是这条流水线的两只轮子。
如果团队正在准备 SBOM 交付材料、出海合规材料或供应商验收流程，建议先从一件事开始：把现有项目的组件清单真正盘点一遍。清单不清楚，后面的合规动作都无从谈起。
十一、参考法规与标准索引
本文引用的法律、行政法规、部门规章、国家标准与行业标准汇总如下，便于读者按需查阅原文。
法律
《中华人民共和国网络安全法》（2016 年 11 月 7 日通过，2025 年 10 月修正，2026 年 1 月 1 日施行） 《中华人民共和国数据安全法》（2021 年 9 月 1 日施行） 《中华人民共和国个人信息保护法》（2021 年 11 月 1 日施行） 《中华人民共和国国家安全法》 《中华人民共和国反外国制裁法》
行政法规
《国务院关于产业链供应链安全的规定》（国务院令第 834 号，2026 年 3 月 31 日公布并施行） 《网络数据安全管理条例》（2025 年 1 月 1 日施行） 《关键信息基础设施安全保护条例》（2021 年 9 月 1 日施行）
部门规章与规范性文件
《网络产品安全漏洞管理规定》（工信部、国家网信办、公安部，2021 年 9 月 1 日施行） 《网络安全审查办法》（国家网信办等十三部门） 国家安全部软件"供应链投毒"安全提醒（2026 年 6 月 18 日）
国家标准
GB/T 43698-2024《网络安全技术 软件供应链安全要求》 GB/T 43848-2024《网络安全技术 软件产品开源代码安全评价方法》 GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》（等保 2.0） GB 44495-2024《汽车整车信息安全技术要求》 GB 44496-2024《汽车软件升级通用技术要求》 GJB 5000B《军用软件研制能力成熟度模型》 GJB 9001C《质量管理体系要求》 GJB 8114《军用软件安全性设计指南》
国际法规与标准
欧盟《网络弹性法案》Cyber Resilience Act，(EU) 2024/2847 欧盟《通用数据保护条例》GDPR，(EU) 2016/679 欧盟《医疗器械条例》MDR，(EU) 2017/745 联合国 UN R155《关于网络安全与网络安全管理系统》（UN Regulation No. 155） 联合国 UN R156《关于软件更新与软件更新管理系统的统一规定》（UN Regulation No. 156） ISO/SAE 21434《道路车辆 网络安全工程》 ISO 26262《道路车辆 功能安全》 ETSI EN 303 645《消费物联网安全基线要求》 UL 2900-1《软件网络安全可测试性要求》 美国加州 SB327《物联网设备安全法》 美国 FDA 第 524B 条《确保网络设备符合网络安全要求》 美国 ICTS 相关规则（信息和通信技术与服务供应链安全） IMO MSC.1/Circ.1526《海事网络风险管理临时导则》 IACS UR E26 / E27（船舶网络韧性统一要求） CCS《船舶网络安全指南》 CISA《2026 版 SBOM 最小元素》（2026 年 7 月 30 日）
注：法规名称、发布日期与实施时间均以官方公开发布信息为准。不同行业与产品形态的适用范围存在差异，具体合规判断建议结合自身业务与监管要求单独评估。