夜雨聆风你的软件里到底装了什么？这个"成分表"现在有了国标
你有没有过这种经历：
买了一份外卖，吃完了才发现配料表里有一种你过敏的食材——但问题是，外卖盒上根本没有配料表。
听起来很荒谬？但在软件世界里，这就是日常。
你安装一个APP，它实际上打包了上百个开源组件、第三方库和间接依赖——其中任何一个有漏洞，你的系统就多了一个攻击面。但你作为用户（甚至作为采购这款软件的企业），对这些"配料"几乎一无所知。
软件物料清单（SBOM，Software Bill of Materials）就是软件的"配料表"。它列出了软件产品中所有组成成分——主程序、依赖库、第三方组件、开源许可证信息——以及它们之间的相互关系。
GB/T 47020-2026《网络安全技术 软件物料清单数据格式》的发布，让这份"配料表"有了全国统一的技术格式。
为什么现在需要SBOM的国家标准？
几个趋势叠加，让SBOM从"可选项"变成了"必选项"：
软件供应链攻击激增——SolarWinds、Log4j、CodeCov……近年来重大的网络安全事件，很大一部分根源在软件供应链——攻击者不直接攻击目标系统，而是攻击目标系统所依赖的第三方组件。如果你的SBOM不完整，你甚至不知道自己是否受了影响。
开源依赖的复杂性——今天一个普通的企业级软件，可能依赖上千个开源组件，这些组件彼此之间又有依赖关系，形成一张复杂的依赖网络。没有系统化的SBOM，这张网络就是一团迷雾。
合规要求的升级——美国行政令14028要求联邦政府采购的软件必须提供SBOM，欧盟的CRA（网络弹性法案）也在推进类似要求。中国作为全球最大的软件生产和消费国之一，需要有自己的SBOM标准来对接国际规则、支撑国内监管。
国标里的SBOM长什么样？
GB/T 47020-2026定义了SBOM的六大信息类别，覆盖了软件成分披露所需要的核心数据：
文档信息——这是SBOM文件本身的元数据：谁生成的、什么时候生成的、用什么工具生成的、覆盖哪些软件版本。相当于配料表的"生产日期和制造商"信息。
产品信息——这份SBOM描述的是哪个软件产品？版本号是多少？校验值（hash）是什么？确保SBOM和它描述的软件是一一对应的关系，防止SBOM被篡改或张冠李戴。
组件信息——这是SBOM的核心。每一个软件成分（主程序、依赖库、模块、插件）都作为一个"组件"条目出现，包含名称、版本、供应商、校验值、许可证信息等字段。标准规定了哪些字段是必选的、哪些是可选的，确保不同厂商生成的SBOM具有基本的可比性。
关系信息——组件之间不是孤立的，而是存在"依赖""包含""派生"等关系。标准定义了关系的类型和表达格式，让SBOM不仅能列出成分，还能描述成分之间的结构。
漏洞信息——SBOM可以关联已知漏洞信息（比如CVE编号），让使用方快速判断某个软件成分是否存在已知安全风险。
服务信息——对于包含网络服务调用（API、微服务）的软件，SBOM还可以描述这些外部服务的依赖关系。
数据格式：JSON和XML双轨
标准规定了SBOM的文件格式要求，支持JSON和XML两种格式（都是结构化、机器可读的）。
这个设计考虑了产业现状：JSON格式更轻量，适合现代DevOps流水线中的自动化处理；XML格式更成熟，适合与传统系统集成。
无论用哪种格式，标准都要求SBOM文件必须可验证——接收方能够验证文件的完整性、来源的真实性，防止SBOM本身被篡改。
对各类市场主体的实际意义
软件开发商——需要在软件交付时随附SBOM文件。这会增加一定的开发流程成本（需要在CI/CD流水线中集成SBOM生成工具），但长期看，SBOM是软件"安全可信"的重要证明文件的组成部分。
软件采购方（企业和政府）——可以把"提供符合国标的SBOM"作为软件采购的必要条件。收到SBOM后，可以自动比对漏洞库，快速发现安全风险。
监管部门——在对关键信息基础设施运营者进行安全检查时，可以要求其提供所使用软件的SBOM，以核实软件成分的透明度和安全状态。
开源社区——SBOM的推广会倒逼开源组件的维护者更规范地提供版本信息、许可证信息和漏洞披露渠道，对整个开源生态有正向促进作用。
GB/T 47020-2026将于2026年8月1日正式实施。对于软件企业来说，留出的准备窗口只有一年多一点。
但换个角度看，这份标准的出台本身就是一个信号：软件成分的"不透明"，将越来越难以被接受。就像今天没有人会买没有配料表的外卖一样，未来，没有提供SBOM的软件，可能也会在采购和合规环节遇到实质性的障碍。
你的软件里到底装了什么？这个问题，以后不能再回答"不知道"了。
来源：标准和标准化 | 作者：标准和标准化
