情报接收与初筛是什么
情报接收入口要做三件事：收得进、找得到、判得准。统一接收渠道（邮件组或平台），把公告与情报汇聚到一处；再按「受影响组件与版本区间」与资产台账做匹配初筛，输出一份「可能受影响资产列表」交给分诊。初筛的目标是缩小人工研判范围，不是给出精确结论。
基本信息
| 输入 | 厂商公告、漏洞库、利用态势、上级与行业通报 |
|---|---|
| 输出 | 候选受影响资产列表（含匹配依据与置信度） |
| 匹配依据 | 组件名称 + 版本区间 + 部署位置 |
| 责任分工 | 情报岗初筛、系统责任人确认、管理岗决策排期 |
情报源清单（示例）
情报源清单（示例）
1. 厂商公告：Microsoft Security Update Guide、Oracle CPU、Red Hat/CentOS 安全公告
2. 官方目录：CVE（NVD）、CNVD/CNNVD、GitHub Advisory（开源组件）
3. 利用态势：CISA KEV、EPSS 分数
4. 内部渠道：安全厂商邮件、应急组织通报（CNCERT 等）
# 每个来源指定订阅人与备用订阅人，避免人员变动后断档初筛匹配思路
初筛匹配思路
公告影响范围（组件 + 版本区间）∩ 资产台账中的组件版本
= 候选受影响资产
# 版本模糊或信息不足时标记为『待确认』，不要直接忽略
# 结果要带匹配依据（命中的是组件名还是版本号），便于人工复核典型使用场景
- 日常值班：收到公告后按模板完成初筛并登记处理结论
- 重大漏洞应急：先确认受影响范围再决定是否启动紧急流程与限时上报
- 月度汇报：统计本月情报处理量与命中率，衡量情报工作产出
- 跨团队协同：把候选列表分发到系统责任人确认实际影响
- 复盘：漏洞实际爆发时回查早期情报是否被正确处置
初筛结论分类
| 结论 | 含义 | 下一步 |
|---|---|---|
| 命中 | 组件与版本都在影响范围内 | 直接进入分诊与排期 |
| 待确认 | 组件命中但版本信息缺失 | 登录核实或补台账 |
| 不命中 | 组件或版本不在范围 | 记录依据后归档 |
| 不适用 | 功能未启用或有补偿措施 | 记录理由，纳入观察 |
发行版回移植补丁的情况要在确认环节处理：包版本号可能低于上游修复版，但实际已含修复，直接按版本号判定会产生大量误报。
初筛结论要留下依据（命中哪个字段、由谁确认），否则同一公告被反复讨论，既浪费人力也无法评估情报质量。