台账是补丁管理的记忆
补丁台账要回答一个很具体的问题：每台资产最后一次补丁是什么时候打的、打了什么、谁执行的、验证结果如何。字段设计要同时服务两类使用者——运维用它查现状，审计用它取证。缺了任何一类字段，台账都会在关键时刻失去作用。
基本信息
| 台账用途 | 运维查询现状与审计取证 |
|---|---|
| 记录粒度 | 一条记录等于一次补丁发布 |
| 必填字段 | 资产标识、组件与版本、补丁编号、执行时间、执行人、结果 |
| 证据要求 | 结果附证据路径（执行日志、截图、复扫报告） |
| 例外管理 | 未修复原因与复审日期，单独列出 |
| 载体选择 | 初期用结构化表格或工单系统承载，平台可以后补 |
台账字段参考
| 字段 | 说明 | 用途 |
|---|---|---|
| 资产标识 | 主机名、IP、所属业务系统 | 查询与覆盖率统计 |
| 组件与版本 | 升级前后版本号 | 判断是否真的升级 |
| 补丁编号 | KB 编号、CVE 或厂商公告号 | 与漏洞清单关联 |
| 执行时间 | 开始与完成时间 | 与变更窗口核对 |
| 执行人 | 操作者与审批号 | 责任追溯 |
| 结果 | 成功、失败或回滚 | 异常项需要单独跟进 |
| 证据路径 | 执行日志、截图、复扫报告位置 | 审计取证 |
| 例外 | 未修复原因与复审日期 | 防止长期挂着无人管 |
| 验证方式 | 复扫、版本核对或功能回归 | 说明如何确认修复有效 |
最小可用载体示例
最小可用载体示例
初期可用结构化表格或工单系统承载：
一条记录 = 一次补丁发布（资产、版本、编号、时间、人、结果、证据）
必填字段先定下来，工具平台可以后补
定期导出与资产台账交叉核对覆盖率
未修复项单独一列，写清原因与复审日期典型使用场景
- 季度审计时提供执行记录
- 漏洞复查时确认某台资产是否已修复
- 新同事接手时的现状查询
- 补丁覆盖率统计与趋势分析
- 例外清单的定期复审
- 事故复盘时确认某个补丁当时是否打过
台账不必一步到位上平台：先把必填字段和更新时机定下来，工具选型可以后补，避免为了选平台把流程本身拖住。
台账靠事后回忆补录等于没有台账。季度审计要求提供原始执行记录时，补录内容既不能自证，也支撑不了覆盖率统计。