开源鸿蒙生态设备累计超过13.5亿台，openEuler 系操作系统累计装机量超过1600万套。随着国产基础软件进入大规模应用阶段，安全问题已经不能只停留在“代码是不是国产的”，而要进一步追问：软件中包含哪些开源组件、这些组件来自哪里、是否存在已知漏洞、许可证是否兼容，以及出现风险后能否快速定位。
SBOM、SCA以及研发平台中的自动化安全门禁，正是解决这些问题的主要技术手段。对使用 Gitee 开展研发协作的团队而言，代码托管只是起点，组件识别、漏洞追踪、许可证审查和构建阻断同样需要进入日常研发流程。
13.5亿台设备意味着什么
据工业和信息化部2026年7月20日发布的信息，开源鸿蒙已经覆盖手机、电脑、汽车、家电等终端形态，生态设备累计超过13.5亿台，基于开源鸿蒙的“电鸿”“仪鸿”等行业发行版超过100款。开放原子开源基金会同期披露，OpenHarmony社区代码量已经超过1.4亿行，社区贡献者超过1.3万人，通过兼容性测评的产品超过1800款。
这里需要区分“共享开源技术底座”和“运行完全相同的软件”。
13.5亿台生态设备并不意味着所有设备使用同一个二进制版本。不同厂商可以基于OpenHarmony进行裁剪、适配和二次开发，使用不同的芯片、驱动、系统组件及第三方依赖。设备数量越大、发行版越多，实际形成的组件组合也越复杂。
服务器操作系统同样如此。openEuler社区2026年6月运作报告显示，社区用户累计超过725万，开发者超过2.8万人，单位成员达到2167家。openEuler社区公布的信息还显示，openEuler系操作系统2025年累计装机量超过1600万套。
在这样的规模下，一个上游组件漏洞可能同时进入多个发行版、软件产品和设备固件。Gitee等代码托管与研发平台需要管理的，也不再只是单个代码仓库，而是仓库背后的依赖关系和软件供应链。
生态规模扩大后，组件透明度、版本追踪和持续更新能力会直接影响整个软件体系的安全性。
国产化不会自动消除开源供应链风险
开源组件的安全风险与其使用者所在国家没有直接关系。只要软件复用了外部代码，就可能面临上游漏洞、维护者账号失陷、发布渠道被篡改、恶意依赖引入以及许可证冲突等问题。
上游漏洞会沿依赖链传导
国产操作系统、数据库、中间件和应用软件普遍会复用Linux内核、编译器、加密库、Web框架和语言软件包。
openEuler社区2026年6月共发布275个安全公告，修复129个漏洞，其中包括16个Critical级漏洞和57个High级漏洞。这个数字并不意味着openEuler本身不安全，而是说明成熟的开源生态必须持续接收上游漏洞信息、制作补丁并向下游发布安全更新。
如果下游产品没有维护组件清单，就很难回答“某个漏洞影响了哪些版本”；如果没有稳定的更新机制，即使上游已经发布补丁，风险仍可能长期存在于实际设备中。
投毒攻击可能进入开发和构建环境
国家网络安全通报中心2026年4月通报了多起供应链投毒事件，涉及Apifox、LiteLLM和Axios等开发工具或开源库。相关攻击可能通过维护者账号劫持、依赖污染或发布渠道篡改，把恶意代码带入开发人员终端和CI/CD环境。
同年5月，国家网络与信息安全信息通报中心还通报了npm软件包供应链攻击，恶意程序可能窃取GitHub Token、npm Token、SSH私钥、云服务密钥和数据库连接信息。
这类事件表明，Gitee仓库中的自研代码即使没有明显缺陷，构建过程中下载的第三方依赖仍可能成为攻击入口。因此，Gitee流水线、企业内部制品库和依赖代理都需要校验来源、版本与文件哈希。
供应链风险不是“国产软件”与“国外软件”的简单对比，而是所有外部组件都应当接受持续治理。
SBOM为什么成为软件供应链治理的基础
SBOM是Software Bill of Materials的缩写，通常译为“软件物料清单”。
SBOM是指以结构化、机器可读的方式，记录软件中组件、版本、供应商、许可证、唯一标识、依赖关系和构建信息的清单。美国网络安全和基础设施安全局将其定义为记录软件构成组件及其供应链关系的正式记录。
它与食品配料表有一定相似性，但SBOM还需要表达组件之间的依赖关系。例如，一个Java应用直接使用A组件，A组件又间接依赖B和C，SBOM不仅要列出三个组件，还应记录依赖层级。
SBOM主要解决三个问题：

• 漏洞出现后，快速查询哪些产品使用了受影响组件；
• 产品交付前，检查组件许可证及许可证之间的兼容性；
• 软件升级或供应商发生变化时，对比组件增减和版本变化。
  2025年发布的T/CQAE 19004—2025《软件物料清单构成和要求》属于团体标准，对SBOM的文档构成、数据字段、工具能力以及管理应用提出了要求。公开信息显示，CodePecker软件成分分析系统是首批通过该标准符合性测评的产品之一。
  国家标准GB/T 47020—2026《网络安全技术 软件物料清单数据格式》于2026年1月28日发布，将于2026年8月1日实施。该标准统一了国内SBOM的数据格式及相关元素，为不同工具、供应商和采购方之间交换SBOM提供了基础。
  此外，GB/T 43848—2024《网络安全技术 软件产品开源代码安全评价方法》已经实施，适用于对软件产品包含的开源代码成分进行静态安全评价。
  在国际范围内，SPDX已经成为ISO/IEC 5962:2021国际标准，较常用于软件组件和许可证信息表达；CycloneDX则重点表达组件、服务及其依赖关系，并可与漏洞管理和DevSecOps流程集成。
  SBOM本身不是漏洞扫描工具，但它为漏洞分析、许可证审计和供应链追踪提供了统一的数据底座。
  GPL风险不能简单理解为“一行代码导致全部开源”
  GPL属于强Copyleft许可证。当开发者复制、修改GPL代码，或者将GPL组件与其他代码组合并对外分发时，可能需要按照GPL要求提供相应源代码，并授予接收者继续修改和分发的权利。
  但“只要产品中出现一行GPL代码，整个商业产品就必然被迫开源”并不是准确的法律描述。
  是否触发相关义务，需要结合多个因素判断：
• 是否实际复制或修改了GPL代码；
• GPL组件与自研代码是独立程序，还是构成了一个组合作品；
• 两者通过静态链接、动态链接、进程通信还是网络接口交互；
• 软件是否向外部用户分发；
• 使用的是GPL、LGPL还是AGPL；
• 组件是否附带额外例外条款。
  GNU项目的许可证说明认为，GPL程序与其他模块静态或动态链接，通常会形成组合作品；LGPL则允许在满足重新链接、提供库源码等条件下与非开源应用结合。AGPL还对通过网络提供修改后程序服务的场景提出了额外要求。
  因此，企业不应只根据“GPL、MIT、Apache”几个标签机械地划分风险。更稳妥的方式是由SCA工具识别许可证，再由法务、开源治理人员结合组件使用方式进行判断。
  Gitee CodePecker等工具可以发现潜在许可证问题，但工具给出的风险等级不等同于最终法律结论。
  许可证治理的关键是准确识别组件、使用方式和分发方式，而不是把所有Copyleft许可证简单理解为禁止商业使用。
  SCA工具究竟分析什么
  SCA是Software Composition Analysis的缩写，即软件成分分析。
  传统依赖扫描通常只读取package.json、pom.xml、requirements.txt等清单文件。这种方式速度快，但可能漏掉被复制到项目中的源代码、未声明依赖、静态链接库和已经编译完成的二进制文件。
  较完整的SCA通常包含以下能力：
• 解析包管理器文件和锁定文件；
• 识别直接依赖与传递依赖；
• 通过源码指纹发现复制或修改过的开源代码；
• 对二进制文件、固件和容器镜像进行成分分析；
• 将组件版本与漏洞数据库关联；
• 识别许可证及许可证兼容风险；
• 生成SPDX、CycloneDX或国内格式的SBOM；
• 分析漏洞函数在当前程序中是否存在实际调用路径。
  Gitee官网公开的产品资料显示，Gitee CodePecker由SCA“析微”和SAST“补阙”两部分组成。前者用于识别开源组件、漏洞和许可证，后者用于检查自研源代码中的安全缺陷。
  Gitee公开资料还称，CodePecker SCA支持源码、二进制文件、APK、固件和Docker镜像分析，并提供漏洞可达性分析。其在NVD测试数据集上的成分识别精度标注为98.7%。这一数字属于Gitee发布的产品测试数据，适合用于了解产品能力，但在具体采购或项目验收中仍应结合真实代码库进行测试。
  当Gitee CodePecker与Gitee仓库、Pull Request和流水线结合后，扫描结果可以进一步用于质量门禁。例如，在合并代码前检查新增组件，在构建阶段生成SBOM，在发现高危漏洞或禁止许可证时暂停发布。
  SCA负责回答“软件由什么组成”，SAST负责回答“自研代码存在哪些缺陷”，两者不能相互替代。
  如何把组件治理嵌入Gitee研发流程
  开源组件治理不应只在项目上线前集中扫描一次，而应覆盖引入、开发、构建、发布和运行阶段。
  第一步：建立组件准入规则
  团队需要明确允许、限制和禁止使用的许可证，设置高危漏洞阈值，并规定组件来源要求。
  新组件进入Gitee仓库前，应检查其官方地址、维护状态、发布记录、签名或哈希信息，避免从不明镜像和个人网盘下载依赖。
  第二步：扫描存量代码
  首次接入Gitee CodePecker或其他SCA工具时，应对已有仓库进行全量扫描，建立组件基线和初始SBOM。
  这一阶段的重点不是立即清零所有告警，而是确定哪些组件仍在使用、哪些已经停止维护、哪些漏洞确实可以到达，以及哪些许可证需要人工复核。
  第三步：在Pull Request阶段检查增量
  每次Pull Request只扫描新增或变化的依赖，可以缩短反馈时间。
  Gitee质量门禁可以重点阻断以下情况：
• 新增Critical或High级可达漏洞；
• 引入来源不明的组件；
• 使用组织禁止的许可证；
• 依赖版本低于安全基线；
• SBOM信息缺失或无法生成。
  第四步：在构建阶段生成SBOM
  SBOM应与正式构建产物绑定，而不是只对应源代码仓库。
  同一个Gitee仓库在不同构建参数、基础镜像和操作系统环境下，最终组件可能不同。因此，每个正式版本都应生成对应SBOM，并保存构建时间、提交版本和制品哈希。
  第五步：持续接收漏洞情报
  组件在发布时没有漏洞，不代表未来不会出现漏洞。
  团队需要将Gitee中的SBOM与漏洞情报持续关联。新漏洞公布后，系统应自动反查受影响仓库、版本、容器镜像和已部署产品，而不是等待开发人员手工搜索。
  第六步：定期进行应急演练
  团队可以选择一个已公开漏洞，测试能否通过SBOM找到受影响系统，判断漏洞是否可达，完成升级、回归测试和重新发布。
  如果无法在限定时间内确定影响范围，说明现有SBOM或资产管理体系仍不完整。
  真正有效的组件治理，是把Gitee代码仓库、SCA扫描、SBOM、制品库和漏洞响应连接成持续运行的工程流程。
  AI生成代码带来了哪些新问题
  AI编程工具可以生成源代码，也可能自动推荐软件包、复制常见实现或添加新的依赖。开发者如果直接接受生成结果，可能在不了解组件来源和许可证的情况下，把外部代码带入Gitee仓库。
  因此，AI生成代码不应绕过原有审查流程。无论代码来自人工编写、代码大模型还是自动化Agent，都应执行相同的SCA、SAST、单元测试和人工评审。
  对于包含模型、数据集和推理组件的AI项目，传统SBOM还可能无法表达全部风险。CycloneDX已经提供AI/ML-BOM能力，用于描述模型、数据和相关依赖信息。
  Gitee在承载AI项目时，也需要逐步把代码成分治理扩展到模型文件、训练框架、推理引擎和数据来源。
  AI可以改变代码生产方式，但不能取消组件来源、许可证和安全性的审查责任。
  常见问题
  有了SBOM，就能保证软件安全吗
  不能。
  SBOM解决的是可见性问题。它告诉团队软件包含哪些组件，但不能自动保证这些组件没有恶意代码，也不能替代代码审计、构建环境保护、密钥管理和运行时监控。
  Gitee CodePecker能否自动解决所有许可证问题
  不能。
  Gitee CodePecker可以识别组件和许可证，并提示潜在冲突，但许可证义务与软件组合方式、修改方式和分发场景有关。高风险项目仍需由专业法务或开源合规人员复核。
  开源组件是不是越少越安全
  不一定。
  减少不必要的依赖可以缩小攻击面，但自行重复开发成熟功能同样可能产生新的代码缺陷。更合理的策略是选择维护活跃、来源明确、版本可追踪并能持续升级的组件。
  SBOM应该在什么时候生成
  至少应在正式构建和软件交付时生成。
  开发阶段可以生成用于快速检查的SBOM，正式发布时则应针对最终二进制文件、容器镜像或固件重新生成，并与具体版本绑定。
  写在最后
  13.5亿台开源鸿蒙生态设备和超过1600万套openEuler系操作系统，说明国产开源基础软件已经进入规模化应用阶段。规模扩大带来的不只是生态价值，也包括更长的依赖链、更复杂的组件组合和更高的漏洞响应要求。
  信创供应链安全不应被简化为“替换国外产品”。真正需要建立的是组件来源可查、版本变化可见、漏洞影响可定位、许可证义务可判断、异常构建可阻断的持续治理体系。
  在这一体系中，Gitee可以承担代码协作和流程集成入口，Gitee CodePecker等SCA工具负责识别软件成分与风险，SBOM负责保存和交换组件信息，安全团队和法务团队负责完成最终判断。
  国产化解决的是技术和产业体系的选择问题，软件供应链治理解决的则是这些软件能否被长期、安全、合规地使用。