01_新网络安全法下的软件漏洞治理

2026新版《网络安全法》落地：软件企业的代码安全与漏洞治理要怎么改？

关键词：网络安全法、代码安全、漏洞治理、DevSecOps、安全开发、软件供应链

政策状态：已施行

更新时间：2026年9月

2026年做代码安全，不能再只把

SAST、SCA、渗透测试当成"安全团队自己的工具"。

2025年10月28日，全国人大常委会通过关于修改《中华人民共和国网络安全法》的决定，并明确自

2026年1月1日

起施行。对于软件研发团队而言，值得重点关注的并不是"又多了一部合规文件"，而是法律对网络产品、服务提供者在安全缺陷、漏洞处置、用户告知、主管部门报告以及持续安全维护方面提出了清晰要求。

这意味着：代码安全正在进一步从研发质量问题，变成产品全生命周期的治理问题。

一、代码漏洞为什么越来越像"合规事件"？

修正后的《网络安全法》第二十四条明确：网络产品、服务的提供者发现其产品、服务存在安全缺陷、漏洞等风险时，应当立即采取补救措施，按照规定及时告知用户并向有关主管部门报告；同时还应持续提供安全维护，在规定或者约定期限内不得终止。

从研发视角看，这至少对应五个工程问题：

企业能不能及时发现漏洞？
能不能定位漏洞影响了哪些产品和版本？
能不能快速确认漏洞来自自研代码还是第三方组件？
能不能形成修复、验证、发布、通知的闭环？
产品停止维护时，是否存在清晰的安全维护生命周期？

如果企业仍然采用"上线前做一次扫描"的安全模式，很难覆盖这些要求。

二、研发流程需要从"上线前检测"转向持续治理

传统模式通常是：

text 复制代码

需求 -> 开发 -> 测试 -> 安全测试 -> 上线

问题在于，安全被放到了流水线末端。

更适合当前监管与供应链环境的模式是：

text 复制代码

安全需求
   ↓
威胁建模
   ↓
编码规范 + IDE安全检查
   ↓
SAST / SCA / Secret Scan
   ↓
构建与制品完整性校验
   ↓
DAST / IAST / API安全测试
   ↓
上线
   ↓
漏洞监测 -> 影响分析 -> 修复 -> 验证 -> 发布 -> 留痕

核心变化只有一句话：

安全检测不再是发布门禁的一个节点，而是软件生命周期中的持续控制。

三、企业最容易出现的四个断点

1. 扫出了漏洞，却没有责任人

很多平台每天产生大量高危、中危告警，但没有绑定应用负责人、组件负责人和修复

SLA。

最终结果就是"有扫描，没有治理"。

建议至少建立：

yaml 复制代码

severity: critical
owner: application-team
fix_sla: 24h
verification: security-team
exception_approval: security-owner

2. 知道某组件有漏洞，却不知道哪些系统用了它

例如某个 Java 组件突然曝出严重漏洞，如果企业需要让几十个研发群逐个自查：

"谁用了这个版本？"

说明软件资产与依赖治理仍然不成熟。

这也是 SBOM 逐渐重要的原因。

3. 修复完成，但缺少可审计证据

代码安全治理需要的不只是"修了"，还应保留：

漏洞发现时间；
风险评级；
受影响版本；
修复提交；
Code Review 记录；
安全测试结果；
发布版本；
例外审批；
用户通知与相关处置记录。

这些数据最好自动从 Git、CI/CD、安全平台和工单系统采集，而不是年底补

Excel。

4. 产品已经停售，但依然存在安全维护责任

产品生命周期管理必须明确：

text 复制代码

GA（正式发布）
↓
正常维护
↓
仅安全维护
↓
EOL通知
↓
停止支持

安全团队应参与 EOL 策略，而不是产品下线之后才知道。

四、建议建立"漏洞闭环流水线"

企业可以把漏洞治理拆成七个动作：

text 复制代码

发现
 ↓
确认
 ↓
影响分析
 ↓
修复
 ↓
验证
 ↓
发布/通知
 ↓
归档

其中最值得自动化的是"影响分析"。

理想状态下，当新的 CVE 出现时，平台可以自动回答：

text 复制代码

CVE
 ↓
受影响组件
 ↓
SBOM查询
 ↓
受影响应用
 ↓
应用负责人
 ↓
线上版本
 ↓
修复任务

这样，漏洞响应时间才能从"几天人工排查"缩短到分钟级资产定位。

五、代码安全平台应该记录什么？

建议至少建立以下证据链：

阶段安全能力主要证据

编码 SAST/Secret Scan 扫描结果、修复记录

构建 SCA/SBOM 组件清单、许可证、漏洞

测试 DAST/IAST 测试报告

发布制品签名/完整性校验 Hash、签名、构建记录

运行漏洞监测风险告警、影响资产

修复工单/代码提交 Commit、PR、复测结果

运营生命周期管理 EOL、用户通知、安全公告

未来真正有价值的代码安全平台，不只是"发现多少漏洞"，而是能够证明：

漏洞在哪里、影响谁、谁负责、多久修复、如何验证，以及整个过程是否可追溯。

六、DevSecOps团队可以马上做的五件事

第一，把 SAST、SCA、Secret Scan 接入

CI/CD，并设置分级门禁，而不是只生成报告。

第二，建立应用---代码仓库---组件---制品---部署环境之间的资产映射。

第三，把高危漏洞修复 SLA 写入研发安全制度，并支持例外审批和到期复审。

第四，建立 PSIRT

或类似的软件产品漏洞响应机制，明确研发、安全、法务、客服和产品团队的职责。

第五，把扫描、修复、复测、发布、通知等证据自动沉淀到统一平台。

七、结语

2026年的代码安全建设，重点已经不只是"有没有扫描工具"。

真正需要回答的是：

text 复制代码

代码安全吗？
↓
依赖安全吗？
↓
制品可信吗？
↓
漏洞能快速定位吗？
↓
修复过程可追踪吗？
↓
安全维护责任清晰吗？

当这些问题都能够通过研发平台的数据回答时，企业才真正从"漏洞扫描"进入了"软件安全治理"。