网络产品漏洞报送时限
网络产品提供者发现或获知所提供产品存在安全漏洞后，应立即验证与评估，并在 2 日内向指定平台报送相关漏洞信息。
01现在要盯的日期与规则
先看哪些时点不能漏
02真实断点
业务现在断在哪
售前承诺和交付基线脱节
销售答应的功能、范围与验收口径没有逐条进入项目基线。
需求变更不先算影响
客户增加需求后先做再说，工期、成本和验收范围同步失控。
客户问题散在群里
工单、群消息和研发缺陷没有同一编号，修复上线后也缺少客户确认。
漏洞、版本与到期事项分开管
漏洞通报、修复版本、客户通知与订阅到期没有统一时间线。
03应用场景
软件与互联网的 4 条业务闭环
页面使用本行业、本岗位的单据和叫法；详情只链接当前已经存在的产品闭环。
- 执行动作
- 标准接入
合同承诺到可执行项目基线
把功能、边界、里程碑、验收条件和客户前置逐条固化，项目组读回确认。
跑完留下：项目基线、责任清单、确认记录
查看对应通用闭环 - 闭环推进
- 标准接入
需求变更到影响评估与书面确认
新增需求先计算范围、工期、资源与商务影响，再由双方确认是否进入基线。
跑完留下：变更单、影响评估、书面确认
查看对应通用闭环 - 闭环推进
- 标准接入
客户工单到修复回读与确认
将客户问题绑定版本、责任人和验证步骤，修复后回读生产状态并请客户确认。
跑完留下：工单时间线、修复版本、客户确认
查看对应通用闭环 - 执行动作
- 标准接入
批准版本发布到客户环境一致
核对发布清单、配置、文档和客户环境版本，避免修复只停在研发分支。
跑完留下：发布基线、环境回读、差异处置记录
查看对应通用闭环 04业务终态
跑完之后，系统里多了什么
不是多一段聊天记录，而是能继续流转、复核和追责的业务对象。
- 合同承诺与验收基线
- 需求变更影响与确认记录
- 客户工单—修复版本—确认链路
- 漏洞与发布版本时间线
05人机边界
Agent 做什么，人在哪拍板
Agent 负责
- 归集合同、工单、版本与漏洞信息
- 生成基线、影响和发布清单
- 跟踪获批发布后的环境回读
必须由人确认
- 范围、报价、上线窗口和客户承诺由负责人确认
- 生产发布与高风险变更由有权人执行
- 安全事件定级与对外通报由安全负责人确认
明确不做
- 不绕过发布审批
- 不直接修改生产环境
- 不替负责人作安全事件或法律结论
相邻分工
上下游还要看哪些页面
用你自己的材料验证
带一份合同和一条工单来试跑
不讲抽象架构，先核一次承诺有没有进入基线、修复有没有回到客户可见状态。
建议带上：一份脱敏合同 / SOW + 一条真实客户工单
工作日 8:30–18:00 在线。
