1. 漏洞治理资产台账建立与字段设计
为什么资产台账是漏洞治理的起点
漏洞本身没有优先级，优先级来自它落在什么资产上。同一枚 CVE，落在面向公网的核心交易系统与落在内网测试机上，处置顺序完全不同。因此漏洞治理的第一步不是扫漏洞，而是先把"资产是谁、归谁管、多重要、在哪、跑什么"这五件事固定成结构化字段，让后续每一条漏洞都能挂到具体资产上。
本节从零设计一份可支撑漏洞治理的资产台账，核心是字段设计，并用一份模拟清单验证它能否支撑漏洞关联与优先级排序。
字段设计：五类必填 + 三类扩展
台账字段不是越多越好，而是每个字段都要能回答一个治理问题。下面按"标识—责任—重要性—位置—软件栈"五类必填字段组织，再补三类扩展字段。
| 字段 | 类别 | 回答的治理问题 | 示例值 |
|---|---|---|---|
| asset_id | 标识 | 这条漏洞挂到哪台资产？ | AST-WEB-0012 |
| hostname | 标识 | 人可读的资产名 | pay-web-02 |
| owner | 责任 | 谁负责修复？ | 张伟（支付研发组） |
| business_level | 重要性 | 多快必须修？ | 核心 / 重要 / 一般 |
| network_zone | 位置 | 暴露面多大？ | 互联网DMZ / 内网办公 / 生产内网 |
| software_stack | 软件栈 | 漏洞能不能命中？ | Nginx 1.24 / Spring Boot 3.1 / MySQL 8.0 |
| ip_address | 扩展 | 扫描器如何定位？ | 10.20.3.12 |
| os_version | 扩展 | 系统层漏洞匹配 | Ubuntu 22.04 |
| last_seen | 扩展 | 资产是否还活着？ | 2025-06-01 |
business_level 与 network_zone 是后续优先级排序的两个关键输入：前者决定业务影响，后者决定暴露面。两者组合可以快速给出"先修谁"的初判。
模拟资产清单
下面用 6 台模拟资产验证字段是否够用。这份清单是教学示例，不是真实环境数据。
| asset_id | hostname | owner | business_level | network_zone | software_stack | ip_address |
|---|---|---|---|---|---|---|
| AST-WEB-0012 | pay-web-02 | 张伟 | 核心 | 互联网DMZ | Nginx 1.24 / Spring Boot 3.1 | 10.20.3.12 |
| AST-WEB-0013 | pay-web-03 | 张伟 | 核心 | 互联网DMZ | Nginx 1.24 / Spring Boot 3.1 | 10.20.3.13 |
| AST-DB-0007 | pay-db-01 | 李娜 | 核心 | 生产内网 | MySQL 8.0.34 | 10.20.9.7 |
| AST-APP-0031 | oa-app-01 | 王强 | 重要 | 内网办公 | Tomcat 9.0 / JDK 17 | 10.30.1.31 |
| AST-TEST-0005 | test-box-05 | 陈晨 | 一般 | 测试网段 | Ubuntu 22.04 / OpenSSH 8.9 | 10.40.2.5 |
| AST-WEB-0021 | static-web-01 | 刘洋 | 一般 | 互联网DMZ | Nginx 1.22 | 10.20.3.21 |
用一条模拟漏洞验证台账能否支撑关联与排序
假设采集到一条漏洞：CVE-2024-XXXX，影响 Nginx 1.22–1.24，远程代码执行。用台账做关联：
- 按 software_stack 匹配，命中 AST-WEB-0012、AST-WEB-0013、AST-WEB-0021 三台。
- 按 network_zone 判断暴露面：三台都在互联网DMZ，均可被外部触达。
- 按 business_level 排序：核心（0012、0013）优先于一般（0021）。
- 按 owner 分派：0012、0013 给张伟，0021 给刘洋。
如果台账缺少 software_stack，就无法判断漏洞是否命中；缺少 network_zone，就无法区分暴露面；缺少 business_level，就无法排序。这三个字段是关联与排序的最小充分集。
常见坑：只记录 IP 不记录软件栈，导致漏洞无法按组件匹配；只记录 owner 不记录 business_level，导致所有资产看起来一样重要，优先级排序失效。
台账可用性检查清单
设计完字段后，用下面 5 个问题自检台账是否真的能支撑漏洞治理：
- 给定一条漏洞，能否在 1 分钟内找到所有受影响资产？——依赖 software_stack 与 os_version。
- 能否区分"必须今天修"和"可以排期修"？——依赖 business_level 与 network_zone。
- 能否直接找到修复责任人？——依赖 owner。
- 能否判断资产是否还在线？——依赖 last_seen。
- 能否用扫描器结果自动回填？——依赖 ip_address 与 hostname 作为关联键。
如果以上任一问题无法回答，说明对应字段缺失或粒度不够，需要回到字段设计阶段补齐。