国务院令第834号已落地：软件供应链安全，企业欠缺的不是工具，是这三件事

 

一、法规已至，窗口期不多了

2026 年 3 月 31 日，国务院公布了《产业链供应链安全规定》（国务院令第 834 号），即日起施行。

第十二条写得很直接：

企业、科研机构等应当完善风险防控体系，实现核心技术及相关信息系统、数据的安全可控。

第九条要求建立”关键领域产业链供应链安全风险监测预警制度”，企业发现安全风险的，须向主管部门报告。这不是行业性规范，是行政法规，效力覆盖所有行业。

在这之前，国家标准 GB/T 43698—2024《网络安全技术 软件供应链安全要求》已于 2024 年 11 月 1 日实施，将企业的供应链安全义务从”推荐”升级为”应当”。标准对需方（即软件的采购者和使用者，也就是绝大多数企业）明确要求：

1. 获取软件前须完整性验证 + 全面安全检测，确保无已公开漏洞未修复（§7.2.3）
2. 运维期间须从安全可控渠道获取安装/升级包，完整性验证后方可部署（§7.2.4(d)）
3. 发现漏洞，立即采取补救措施，并按规定向主管部门报告（§7.2.4(i)）
4. 必须构建并维护软件供应链安全图谱（含 SBOM），重要业务场景须含组件漏洞信息，至少每年更新（§6.2）
5. 开源/第三方组件使用前须完整性验证、安全检测、依赖分析，建立组件库并标明优选/可选/限选/禁选四级（§8.2.2(g)）

两层法规一上一下，正在交汇。软件供应链安全，已经从”安全团队关心的事”变成了”企业合规义务”。

 

二、大多数企业的认知偏差

在跟不同企业的安全团队交流时，我们经常听到这样的话：

“我们有 Nexus，包都走私有仓库。” “我们有 SCA 扫描工具，定期跑一下。” “发生什么事了我们能第一时间知道。”

这三句话，代表了当前企业在软件供应链安全上最典型的认知框架——以”有工具”等同于”有能力”，以”定期扫描”等同于”持续防护”。

问题在哪里？

Nexus 只是传送带，不是安检门。 它的核心功能是缓存和分发，而不是安全审查。一个被攻陷的开发者账号，可以把任意版本的内部包推进 Nexus；多个构建节点共用缓存目录，一个被污染的包可以悄无声息地扩散到所有后续构建任务。这些风险，Nexus 本身毫无感知。

SCA 扫描是快照，不是实时防护。 定期扫描的本质是”事后审计”——攻击已经发生、依赖已经引入，你才知道问题的存在。2026 年 3 月底的 Axios 投毒事件，恶意版本从推送到被官方下架，不到 4 小时。在这 4 小时窗口期内执行了 npm install 的开发者或 CI 流水线，定期扫描救不了。

“能知道”和”能拦住”是两件完全不同的事。 情报告诉你这个包是恶意的，但如果开发者的工作环境可以直接 pip install 访问公网，如果 CI 流水线可以绕过私有仓库直连 PyPI——那情报的价值就只剩下”事后归因”。

GB/T 43698—2024 第 7.2.4(d) 条要求”从安全可控渠道获取安装/升级包”，意思不只是”用 Nexus”，而是整个链路都必须可控——包括谁能发什么版本的包、构建环境有没有绕路、内部包有没有被篡改。

 

三、供应链攻击面的真实形态：三个方向同时扩张

理解为什么”有工具”还不够，需要先看清楚当前企业面临的攻击面结构。

方向一：外部开源包投毒——已成熟且持续升级

PyPI、npm、Maven 每天都有新的恶意包投放。攻击手法从最初的命名仿冒，进化到今天的维护者账号劫持——2026 年 3 月底的 Axios 投毒事件，攻击者用三周时间社工了全球下载量排名第一的 npm 库的首席维护者，拿到账号后在几小时内向全球数百万个正在运行的 CI 流水线推送了带后门的版本，并在代码执行后自我删除、销毁取证痕迹。

方向二：AI 工具链攻击——新兴、增长最快

开发者使用 Claude Code、Cursor 等 AI 编程助手时，会安装各类 Skill 文件扩展助手能力。攻击者已经在向 ClawHub、Anthropic Marketplace 等平台批量投放恶意 Skill——表面是”Python 工具集”，实际会引导 AI 助手读取 ~/.aws/credentials、SSH 私钥，或在生成代码时静默植入后门逻辑。这类攻击完全绕过了传统 SAST/DAST 工具的检测范围，现有的安全扫描体系几乎无覆盖。

方向三：内部制品仓库——最隐蔽、最被忽视

这是讨论最少、实际危害最难评估的方向。企业自己的 Nexus 仓库里，存放着大量内部开发的共用组件——支付模块、认证库、基础工具包。一旦某个发布账号被攻陷，攻击者只需向 Nexus 推送一个带后门的”更新版本”，所有依赖该组件的服务都会在下次构建时静默感染。这种攻击对外部情报库完全不可见——情报库只监控公开包仓库，对企业内部包毫无感知。

三个方向加在一起，构成了今天企业软件供应链攻击面的完整轮廓。没有一套覆盖这三个方向的体系性方法论，任何单点工具都只是在某个方向上有限度地减少风险。

 

四、供应链安全防护方法论：“感知—拦截—盘点—治理”四层闭环体系

真正有效的供应链安全防护，是一套覆盖”感知—拦截—盘点—治理”四层的闭环体系，每一层解决一个不同的核心问题。

第一层：威胁情报实时感知

情报的价值在于精度和时效。必须精确到包名 + 版本号级别——不是”axios 有风险”，而是”axios@1.14.1 是恶意的，axios@1.14.0 是干净的”。两个版本的处置逻辑完全不同，粗粒度的情报在实战中等于没有。

情报来源需要覆盖三类制品：

1. 传统包仓库（npm / PyPI / Maven / Go / NuGet / Docker Hub 等）：多源聚合 + 自研深度分析，覆盖混淆代码、postinstall 钩子、动态模块加载等对抗性技术
2. AI Skills 平台（ClawHub / Anthropic Marketplace / skills.sh / GitHub/skills 等）：这是绝大多数企业当前的防护空白，需要专项情报覆盖
3. 内部包异常变更：监听制品仓库的 ADD/UPDATE 事件，对内部包变更进行旁路扫描——这是外部情报库无法覆盖的盲区

时效决定防护窗口的宽度。2026 年 3 月底的 Axios 事件，在 npm 官方下架恶意包约 41 分钟前，塞讯高级持续威胁情报已完成收录和威胁标注。这 41 分钟，是决定”已保护”还是”已感染”的关键窗口。

第二层：制品下载节点拦截

情报的价值不在于”被告知”，而在于”被保护”。这需要在依赖下载的物理节点上做拦截，而不是在告警邮件里做通知。

三个必须覆盖的拦截卡点：

1. 卡点①——制品仓库代理：在 Nexus / JFrog Artifactory 的上游部署透明反向代理，开发者 npm install 照常执行，所有请求经过情报决策引擎，命中已知恶意即阻断，恶意代码永远不落地
2. 卡点②——VSCode 插件市场代理：VSCode 插件安装请求经过情报核验。恶意插件已有大量实际案例，但几乎没有企业在这个卡点有任何防护
3. 卡点③——AI Skills / MCP 代理：AI 编程工具安装 Skill 的请求经过情报核验。这是当前最新、最难覆盖的攻击面，也是增长最快的风险方向

对于内部包投毒，必须通过监听 Nexus 事件来触发扫描：

1. 新增包（ADD）→ 全量扫描
2. 更新包（UPDATE）→ 仅扫变更差异（Diff 扫描），降低资源消耗，同时提升时效
3. 发现高风险：阻断发布 + 联动 CI/CD 质量门禁 + 自动回滚到上一版本

第三层：存量资产风险盘点（SBOM）

应对突发投毒事件时，很多企业面临的第一个困难是：我根本不知道哪些项目依赖了受影响的包，是哪个版本。

这不是信息系统的缺陷，而是没有建立 SBOM（软件物料清单）的必然结果。GB/T 43698—2024 第 6.2 条已将构建和维护 SBOM 明确为企业义务——重要业务场景须包含组件漏洞信息，至少每年更新。

SBOM 系统需要支持 SPDX / CycloneDX 两种标准格式的导入，导入后自动与情报库比对，输出哪些项目存在受影响依赖、风险版本分布，并与实时拦截告警交叉印证。

有了 SBOM，突发投毒事件的影响面评估，可以从人工小时级排查缩短到系统分钟级查询。

第四层：研发行为治理——最难的，也是最根本的

这是最容易被忽视、也最根本的一层。前三层做得再好，只要”通路”没有被管控，都可以被轻易绕过。

这不是假设性场景：

1. 开发者执行一行 npm config set registry https://registry.npmjs.org，完全绕过企业私有仓库和网关
2. CI/CD 流水线配置疏漏，没有走私有仓库代理，构建时直连公网
3. 开发账号泄露，攻击者直接往 Nexus 推了一个带后门的内部包

治理层需要做到五件具体的事：

① 账号权限严格分层（防内部投毒的第一道闸）

账号类型	权限范围	安全意义
dev 开发账号	只能上传 snapshot（测试/开发版本）	开发者无法单独推 release 进生产
ci 构建账号	只读，不能发布任何版本	CI 账号被攻陷不影响制品库
deploy 发布账号	唯一能发布 release 的账号	严格管控，与研发账号体系隔离

② 流量强制收口（堵死”绕路”可能性）

1. 网络层（ZTNA / 防火墙）封锁所有公网包源的原始域名——npm / Maven / PyPI / Docker Hub 原始地址全部拦截，没有例外
2. Maven settings.xml 的 mirrorOf=* 强制全量请求走 Nexus
3. 未实施结果：一行配置命令，所有防线失效

③ CI/CD 构建环境隔离（防缓存横向传播）

1. 每个构建任务使用独立缓存目录（Maven：-Dmaven.repo.local=/build/.m2/repository；npm：npm config set cache /build/.npm）
2. 禁止多构建节点共享 ~/.m2 / ~/.npm 目录
3. 未实施结果：一个被污染的包通过共享缓存横向扩散至所有后续构建任务，难以定位源头

④ 内部制品完整性记录（发现”院子里的篡改”）

1. 每次发布记录：SHA256 指纹 + 发布人 + 来源 IP + 构建 Pipeline ID + 时间戳
2. 定期重新计算 Nexus 中存储包的 hash 值，与基线比对
3. 禁止 snapshot 版本进入生产：CI 阶段自动检测，违规构建直接失败
4. 未实施结果：内部包被静默替换，无告警、无记录、无法溯源

⑤ AI 工具链 Skill 来源管控（最新攻击面）

1. 将 AI 编程工具（Claude Code / Cursor 等）的 Skill 来源纳入与代码包同等级别的情报核验体系
2. 通过代理网关统一管控，不留例外通路

 

五、先做体检：快速评估当前完成度

结合 GB/T 43698—2024 的要求，五个问题可以快速判断当前状态：

核查项	对应依据	是否完成
是否已构建 SBOM，知道自己用了什么、各项目依赖哪些版本？	GB/T 43698—2024 §6.2
是否能在恶意包被公开披露后 1 小时内完成全量影响面评估？	国务院令第834号 第9条
私有仓库发布账号是否与开发账号严格分离，CI 账号是否只读？	GB/T 43698—2024 §7.1.3(b)
公网包源地址是否已在网络层封锁，研发侧无法绕过私有仓库？	GB/T 43698—2024 §7.2.4(d)
内部包每次发布是否有 SHA256 指纹记录和完整来源追踪？	GB/T 43698—2024 §7.2.4(c)

这五项都不是”高级功能”，而是 GB/T 43698—2024 对企业的基本要求。在实际调研中，能同时完成全部五项的企业，并不多见。

 

六、情报是眼睛，SOP 是骨架

有一个比喻可以概括本文想说的核心：

情报是眼睛，管控是手，治理是骨架。

眼睛告诉你威胁在哪里，手让你能拦住威胁，但骨架决定整个防御体系能不能站立——能不能真正落地。

没有骨架，眼睛再好、手再快，也是在沙地上建高楼。一个没有权限分层的 Nexus、一条没有流量收口的 CI 流水线、一台可以随意直连公网的开发工作站，都可以把前面所有的投入变成无效功。

GB/T 43698—2024 和国务院令第 834 号，用合规的方式强制要求企业去建这个”骨架”——这其实是一件好事。骨架不可能靠单个安全产品建起来，它需要 IT 部门、研发团队、安全团队协力推动，需要管理层支持，需要制度化落地。

法规已经明确了方向，剩下的问题只有一个：你从哪里开始做？

 

参考法规与标准

文件	效力	施行日期
中华人民共和国国务院令第834号《产业链供应链安全规定》	行政法规	2026-03-31
GB/T 43698—2024《网络安全技术 软件供应链安全要求》	国家标准	2024-11-01
GB/T 36637—2018《信息安全技术 ICT供应链安全风险管理指南》	国家标准（被前者规范性引用）		2019-05-01

关注公众号：塞讯安全验证，回复“规定”获取以上法规与标准原文件。