aegis-vulnerability-management-process

漏洞管理流程（VULN）

适配说明 — 请先阅读

本模块有意偏离红队模板：它不用于漏洞搜寻，而是定义一个循环运行的流程，用于处理其他所有模块产出的内容。各章节的含义重新映射如下：

模板章节	此处的含义
检查内容	对现有 VM 计划进行就绪度／成熟度审计：每个流程阶段是否存在，并有证据支撑？
查找位置	计划产物应存放的位置：跟踪目录、登记表、日历、cron、CI 配置
模式与特征	各类模板：优先级决策树、完整示例、例外情况架构、指标公式、议程
污点追踪指南	单条公告／审计输出如何经过各阶段流转，直至最终状态
漏洞利用与复现	桌面推演：将一项发现按完整流程端到端地演练一遍
修复	按依赖顺序构建缺失阶段
严重性评估	优先级调整区间和 SLA 表本身

cwe 数组为空是有意为之：本模块审计的是流程能力，而非代码级弱点类别。它位于两个编排器——SKILL-CODE.md（代码标识）和 SKILL-SERVER.md（主机标识）——的下游，并借用 IR 中的事件处理词汇（skills/operations/incident-response/SKILL.md）。本模块只对计划本身提出发现。

前提与术语

零基础入门：本模块使用的术语，每条一行。仓库 GUIDE.md 词汇表中对每类术语均有更深入的通俗解释。

• SLA：每个优先级对应的承诺最长修复时间
• 分类：为每项新到的发现确定优先级和计时周期
• MTTR：从发现到验证关闭的平均时间
• 例外登记表：记录有意延后处理的发现，每项均注明负责人和到期日
• 缓解与修复：降低风险的变通方案与实际修复——记录必须始终注明属于哪一种
• 限期接受：在规定期限内正式保留已知问题，之后重新审查
• 污点流／源→汇：不可信数据从入口点流向危险函数的路径（此处重新映射为发现如何经过各流程阶段）
• 发现状态：已确认 > 可能 > 需审查；证据规则见 templates/finding-report.md

范围与目标

两部分，一个闭环：

A 部分 — 程序就绪性审计。 以证据作答：明天出现一项发现（来自审计、扫描器或公告源）时，从发现到验证关闭之间，除了临时应对之外，是否还有其他流程？

B 部分 — 闭环操作系统。 提供各阶段可直接填写的模板：闭环章程、分诊记录、SLA 默认值、例外登记表、指标集、月度评审议程和节奏安排。

使用本模块执行一次审计后，交付成果包括：

1. 闭环记分卡 — 每个阶段标记为 PRESENT / PARTIAL / ABSENT，并附上产物指针。
2. 提交给 Remediation 的差距清单 — 每个 ABSENT 阶段都转化为由负责人承担的构建任务。
3. 已采用的模板 — 在团队文档中填好 SLA 表、例外登记表和议程框架，并补齐方括号中的内容。
4. 回溯分诊的待办清单 — 未解决的发现均记录了优先级决策，而不只是严重性。
5. 指标基线 — 手动计算一次这五个数字，此后每月计算。

操作规则：

• 只使用，不重复。 审计模块判定 SEVERITY（规范性评级）；本模块判定 PRIORITY 和 CLOCKS。禁止在分诊中重新争论评级所判定的严重性——应当明确调整优先级。
• 以文件作为跟踪系统。 在未解决的发现约 50 项之前，发现事项的 .md 文件目录加上一个索引文件就构成了系统。不要先部署工具。
• 如实记录缓解方式。 记录始终要注明实际发生的是哪一种：已修复、已缓解且停止计时，或纸面接受并设定到期时间。把三者含混处理是小团队最常见的失败方式。
• 每个阶段都要产出一项产物。 未记录的分诊、未归档的扫描或没有日期的评审，都视为未发生。

范围之外：执行审计本身（SKILL-CODE.md / SKILL-SERVER.md）、事件响应（IR）、告警阈值（DETECT）、补丁实施（PATCH）、备份演练（DR）。本模块负责串联它们的输出。

心智模型

闭环流程，以及将此技能组映射到每个阶段后的示意：

            ┌─────────────────────────────────────────────────────────┐
            │                                                         │
            ▼                                                         │
   [1 INVENTORY]  repos, hosts, tunnels/hostnames, k8s clusters,      │
    what exists?   DBs, third-party SaaS with data access, DNS names  │
            │                                                         │
            ▼                                                         │
   [2 FIND]       <- SKILL-CODE.md / SKILL-SERVER.md audits on cadence;    │
    hunt for      dependency scanners (commands per SUPPLY module);   │
    weaknesses    sweep-patching.sh host state; distro security       │
                  trackers; pentest/bug-bounty intakes                │
            │                                                         │
            ▼                                                         │
   [3 TRIAGE &    priority = f(base severity, reachability/exposure,  │
    PRIORITIZE]    known-exploitation intel, asset criticality)        │
            │                                                         │
            ▼                                                         │
   [4 REMEDIATE]  batches BY COMPONENT, quick wins first inside the   │
    do the work    batch; fix-vs-mitigate decided explicitly; finding │
                   reports' Remediation sections ARE the work orders  │
            │                                                         │
            ▼                                                         │
   [5 VERIFY]     <- each finding's own Fix Verification Plan;        │
    prove closure  regression tests merged; module greps re-run;      │
                   run-all-sweeps.sh evidence diff where applicable   │
            │                                                         │
            ▼                                                         │
   [6 TRACK &     open-by-severity, MTTR per band, exception count,   │
    METRICS]      audit-coverage freshness, SLA breaches              │
            │                                                         │
            └─────────────────────────────────────────────────────────┘

五条公理：

1. 审计严重性不等于操作优先级。 评级标准给出严重性；闭环再结合暴露程度、可达性、利用情报和资产关键性来确定优先级。不同队列中存在严重性相同、优先级不同的发现，正说明系统运转正常。
2. 只有经过验证，事项才能离开闭环。 templates/finding-report.md 中的 Fix Status 状态转换——Open → Fixed (unverified) → Verified-Fixed（或 Risk-Accepted）——受到门控：最后一步必须执行该发现对应的修复验证计划。这就是模板要求填写该部分的原因。
3. 计时从分诊时开始，而非修复时。 发现被赋予优先级时，SLA 倒计时即开始；分诊前的积压时长属于单独的程序缺陷。
4. 清单是关联键。 公告按软件包发布，影响则按服务计算。只有清单能让你在几分钟内回答“我们是否在运行它？”，而不是花时间翻查历史记录。
5. 稳定节奏胜过临时突击。 按季度重复执行的完整审计、每周定时运行的扫描，以及每月 30 分钟的评审，效果胜过在可怕的博客文章发布后突击投入精力。

默认节奏（完整表格见 Patterns & Signatures）：完整审计按季度执行或在重大变更时执行；定向审计按事件触发；每周扫描；每周关注公告；至少每季度重新确认一次清单；每月评审。

检查内容

审计闭环的每个阶段；标记为 PRESENT / PARTIAL / ABSENT，并记录产物指针（或注明不存在）。定义：PRESENT = 产物存在且为最新状态，并且指定负责人可应要求提供；PARTIAL = 产物存在，但已过时、无人负责或未经演练；ABSENT = 通过临时应对来运作。

V1. 阶段 1 — 清单已建立并经过新鲜度认证

清单涵盖所有表层类别：代码仓库、主机、cloudflare 隧道及其主机名、k8s 集群/命名空间、数据库、可访问数据的第三方 SaaS（支付、邮件、分析、错误跟踪），以及所有 DNS 名称。证据：一个命名的工件，其中每个条目都带有 last-reviewed 日期，并且在 90 天内重新认证（至少每季度一次）。清单即代码原则：尽可能从 IaC/清单派生条目，使其自动保持最新。双向交叉核对：随机抽取两条清单记录，确认其在现实中存在；再选一个线上服务或 DNS 名称，确认其已列入清单——最新服务未列入即判定此项不合格。持续更新的工件：sweep-code-recon.sh 输出归档，以及最新的 TARGET-PROFILE.md / HOST-PROFILE.md（交叉参阅 SKILL-CODE.md 阶段 1 / SKILL-SERVER.md 阶段 1）。

V2. 阶段 2 — FIND 来源已接入，而非仅停留在设想

检查每个来源是否有实际触发机制，而非仅有书面意图：

来源	“已落实”的标准	要求提供的证据
全面审计	在上一季度内执行过，或已记录重大变更触发机制	security-audit/ 下带日期的运行目录、PROGRESS.md 文件
定向审计	已写明事件驱动规则（新增端点/服务/依赖类别 → 在当前冲刺内审计对应 slug）	约定文档 + 近期定向审计记录
依赖扫描	CI 中或按计划运行各生态系统的命令	调用 SUPPLY 模块命令的工作流文件
主机补丁状态	每台主机的 sweep-patching.sh 输出均已归档并经过审查	tools/run-all-sweeps.sh 生成的带日期证据目录
安全公告监控	每周查看发行版安全跟踪信息（Ubuntu Security Notices / Debian tracker / Fedora errata，定性评估），并关注依赖项安全公告订阅源（RustSec、npm/GitHub advisories）	周期性日历条目 + 带日期的记录文件
外部输入	渗透测试报告/漏洞赏金报告有明确的接收途径（即使只是“转交分诊”的占位流程）	记录了如何将报告提交至跟踪系统的流程
动态扫描（DAST）	OWASP ZAP（或同等工具）按计划对可访问环境执行基线扫描；发现项流入同一跟踪系统	扫描配置 + 带日期的报告。注意：动态测试不在本工具包的静态测试范围内——ZAP 类工具是衔接手段，其发现项仍按相同方式进入阶段 3

V3. 阶段 3 — 分诊规则已写明并实际执行

已记录优先级公式（模式与特征）；SLA 表已采用并获签核；每个未关闭的发现项都在 TRIAGE RECORD 中列出基础严重性 + 调整项 + 最终优先级；任何偏差均有书面理由。抽查五个发现项：任何一个缺少 TRIAGE RECORD，此项最高只能评为 PARTIAL。

V4. 阶段 4 — 修复工作流已组织就绪

按组件/服务批次安排修复工作，而非按严重性分散处理；发现报告中的 Remediation 部分原样用作工作单；记录修复与缓解之间的选择及理由；按服务合并停机窗口。

V5. 阶段 5 — 验证关卡已强制执行

没有任何发现项可以在未执行其专属 Fix Verification Plan 的情况下进入 Verified-Fixed：重新运行针对性 PoC 测试、合并回归测试、重新运行扫描范围 grep 并确认无结果，以及在适用时归档扫描证据的前后对比。抽查已关闭的发现项，核实这条证据链。

V6. 阶段 6 — 跟踪与指标已就绪

可通过一个索引在各个运行目录中查找发现项文件；五项指标可在 30 分钟内计算出来；每月都召开评审，并留存带日期的议程文件。无法查询的跟踪系统，无论内容多完整，都只能评为 PARTIAL。

V7. 例外工作流已强制执行

已建立登记表；每一行都包含所有必填字段，包括不超过 180 天的到期时间；到期例外均已按时审查，而非悄悄延期。

V8. 实际安排的节奏

日历／cron／CI 证据应证明：每季度或发生变更时进行全面审计、事件驱动的定向审计、每周扫描、每周查看建议、每月审查、每季度重新确认库存。未安排的节奏按定义属于部分达标——意图不会自动重复。

查看位置

能力会留下产物。应有产物却没有，本身就是一项发现。

项目	应存放位置	典型缺失迹象
计划章程 + SLA 表（V3）	版本控制的文档（docs/vuln-mgmt.md 或 wiki 根目录），并从 CI 和审查议程链接到该文档	只存在于聊天记录或某个人的脑海中
发现跟踪表／索引（V6）	一个 security-audit/TRACKER.md，索引 <run-id>/findings/ 下的每个发现文件；只有未解决项目超过约 50 项时，才升级为电子表格／DefectDojo 类工具	发现散落在旧运行目录中；没有索引
库存产物（V1）	由 TARGET-PROFILE.md/HOST-PROFILE.md 和 sweep-code-recon.sh 档案提供数据的持续更新文档，包含每个条目的审查日期	每次审计时临时重新生成，从未与实际情况核对
例外登记表（V7）	单一的 security-audit/EXCEPTIONS.md	审批散落在私信／工单中
扫描计划（V2/V8）	cron/systemd 定时器或调用 tools/run-all-sweeps.sh 的 CI 作业；证据归档到带日期的目录下	“审计时跑过一次”
依赖项扫描（V2）	CI 工作流文件（.github/workflows/*.yml），按各生态系统运行 SUPPLY 模块命令	只手动运行，最近一次输出已是几个月前的
公告监控记录（V2）	每周重复的日历事件 + 仅追加的记录文件	没人说得清谁在监控公告渠道
审计节奏（V8）	每季度的日历事件 + 定向审计的书面触发条件列表	距上次全面审计已超过 12 个月
分类记录（V3）	每个发现文件内（追加章节），或按发现 ID 引用的集中决策日志	优先级口头决定，未记录
指标 + 议程（V6）	跟踪表旁按日期归档并追加的月度文件	每季度凭记忆重新计算数字

另请检查：章程的 git 历史（每年才编辑一次的文档只是束之高阁的文件）；CI 扫描步骤是否确实通过（被忽略的红色作业比没有作业更糟——它会让忽视问题变得习以为常）。

模式与特征

运行模板。所有代码块均可直接填写；应在发现出现前将其复制到团队文档并填写方括号内容，而非事后补填。

P1. 优先级决策树（第 3 阶段核心）

START: base severity from the finding report (C/H/M/L/Info). The rubric in
       templates/finding-report.md is normative; do NOT re-derive it.
  |
  v
Q1 KNOWN EXPLOITATION: maps to a CISA Known Exploited Vulnerabilities (KEV)
   Catalog entry, or credible active-exploitation reporting for the class?
   YES -> P0 treatment: fix-or-mitigate inside 7d REGARDLESS of base severity.
   Record what maps.
  |
Q2 REACHABILITY: vulnerable surface reachable from public internet WITHOUT
   auth? YES -> bump one band UP (Critical stays Critical; Low -> Medium).
   NO -> keep band; record the gate (auth / internal-only / build-time).
  |
Q3 COMPENSATING CONTROLS: does a named control genuinely cover THIS path?
   (Cloudflare WAF rule blocking the payload class; Cloudflare Access gating
   the admin route; tunnel ingress pinning the hostname; egress firewall
   denying metadata reach) -> MAY hold at band WITH written justification:
   control named, what it blocks, what slips past. Provisional — control
   changing or failing reopens the question automatically.
  |
Q4 EPSS TIE-BREAK: published EPSS score exists for the relevant CVE (FIRST
   Exploit Prediction Scoring System — probability-of-exploitation)? Use it
   to order same-band items, higher first. Never invent or estimate scores;
   "not consulted" is a valid entry.
  |
Q5 ASSET CRITICALITY: payment path > auth plane > prod data stores > internal
   tooling > marketing site. Same-band conflicts resolve toward the more
   critical asset; criticality also justifies tightening SLAs below.
  |
  v
FINAL PRIORITY (P0-P3) -> SLA clock starts today (table in Severity Assessment).

可直接填写的分类记录（追加到每个发现文件或集中日志中）：

TRIAGE RECORD — <SLUG-NNN>
Base severity: [C/H/M/L]        (from finding report — not re-litigated here)
KEV / active exploitation: [no | yes + source named]
Reachability: [internet-unauth | internet-auth | internal-only | build-time]
Band adjustment: [none | bumped +1 band | held-at-band-with-control]
Compensating control: [named control + covers / does-not-cover]
EPSS: [published value + date checked | "not consulted"]
Asset criticality: [payment-path | auth-plane | prod-data | internal | marketing]
FINAL PRIORITY: [P0|P1|P2|P3]   SLA due date: [YYYY-MM-DD]
Decided by / date: [name] / [date]

P2. 优先级判定示例（三项发现）

发现 A — SSRF-003，Webhook URL 获取器中的 SSRF。基础级别：高。 Q1：应用逻辑缺陷，没有 CVE → 无法映射到 KEV。Q2：端点可从互联网访问，但请求已签名（需认证类别）→ 不自动上调，记录门槛。Q3：主机出站防火墙拒绝访问 169.254.169.254／链路本地地址，元数据路径已关闭 → 保持高优先级，并注明依据规则及仍可能绕过的情况（DNS 重绑定类获取请求）。Q5：支付集成路径使紧迫性在同一等级范围内上升。最终：P1，30 天内到期——保持在该等级，未降级；若防火墙规则发生变化，则保持决定失效。

发现 B — SUPPLY-004，生产路径依赖项存在漏洞，属于 DoS 类 CVE。基础级别：中。 Q1：CVE 出现在 KEV Catalog 中 → 立即跳入处理队列。最终：P0，7 天内修复或缓解，尽管基础级别为中——现实中的在野利用优先于理论影响计算。

发现 C — WEB-007，缺少 CSP 标头（反射型 XSS 阻碍类）。基础级别：低。 Q1：无映射。Q2：营销页面可由未认证用户从互联网访问 → 上调一个等级，低 → 中。Q3：未声明任何补偿控制 → 不保持不变。Q5：最低重要性资产仍处于新等级的最低水平。最终：P2，90 天内到期——如实上调，不超过一个等级。

P3. 例外登记表架构

# Exception Register — security-audit/EXCEPTIONS.md
# Every field mandatory. Expiry MANDATORY, max 180 days from approval.

| Exception ID | Finding ID | Reason (why now) | Compensating control | Owner | Approved by | Expiry date | Review trigger |
|---|---|---|---|---|---|---|---|
| EXC-2026-001 | AUTHZ-002  | [refactor lands next sprint] | [Access policy gates admin route] | [name] | [name] | 2026-11-20 | [policy removed / new pentest finding] |

规则：缺少负责人或到期日期的行均为 INVALID — 在修复前，将相关发现视为 OPEN，且保持完整优先级。例外到期后，发现会自动以原优先级重新打开。当补偿控制发生变化时，审查触发条件会提前触发。发现文件中的 Risk-Accepted Fix Status 会链接到此处对应的行。

P4. 频率表 + sweep cron 示意

活动	触发条件	频率
完整审计，涵盖所有适用的 slug（SKILL-CODE.md + SKILL-SERVER.md）	按计划执行或发生重大变更（新服务、身份验证全面改造、迁移）	至少每季度一次
定向审计	事件驱动：引入新的端点 / 服务 / 依赖类别	在引入该项的 sprint 内
主机 sweep（tools/run-all-sweeps.sh）	按计划执行	每周
依赖项扫描	推送到 main 时 + 按计划执行	按 CI 执行，每周至少一次
公告监控（发行版跟踪器 + 依赖项公告）	定期查看	每周，约 30 分钟
库存重新认证	按计划执行	至少每季度一次
每月 VM 审查	日历安排	每月，严格限定 30 分钟
DR 恢复演练	按 DR 模块频率执行	按 DR 模块要求
例外到期 sweep	按计划执行	每月（列入议程）

# /etc/cron.d/vuln-mgmt-sweeps (or systemd timer) — weekly read-only sweeps,
# evidence archived by date; %% escaping so cron passes literal % to date(1).
0 6 * * 1  ubuntu  cd /opt/sec-tools/aegis-skills && ./tools/run-all-sweeps.sh \
  > /var/log/vm-sweeps/"$(date +\%Y\%m\%d)"-sweeps.log 2>&1

CI 变体：每晚定时运行的工作流，执行同一脚本并运行 SUPPLY 模块扫描器命令；禁止 fail-open——扫描作业若被静默禁用，必须通知相关人员（DETECT 接线纪律）。

P5. 指标公式（根据文件计算，重新计数，绝不估算）

指标	公式	事实来源
按严重程度统计未解决项趋势	统计 Fix Status ∈ {Open, Fixed (unverified)} 的发现文件数量，并按严重程度分组；每月快照	<run-id>/findings/*.md 上的跟踪器索引
按严重程度统计平均修复时间（MTTR）	每个等级的 mean（达到 Verified-Fixed 的日期 − 发现文件创建日期）；排除 Risk-Accepted；同时报告 MAX	发现文件中的日期 / 状态
例外数量 + 即将到期数量	登记表行数；其中到期日距离当前日期 ≤30 天的行数	EXCEPTIONS.md
审计覆盖时效	每个 SLUG 距最近一次完整 / 定向审计的天数 = 今天 − 最近一次涵盖该 slug 的运行的 run-id 日期	security-audit/<run-id>/PROGRESS.md 文件
SLA 违约数量	SLA 到期日期 < 今天的未解决发现，按优先级列出，最早的排在前面	分流记录

P6. 每月审查议程框架（30 分钟，严格限时）

MONTHLY VM REVIEW — <YYYY-MM>
1. Numbers first (5m): five metrics vs last month; note trends, not anecdotes.
2. SLA breaches (10m): every breached finding gets a NEW committed date or an
   escalation; "we'll get to it" is not an outcome.
3. Exceptions (5m): expiring ≤30d — renew with fresh justification or lapse to
   open; verify compensating controls still exist.
4. Coverage gaps (5m): slugs stale beyond a quarter → schedule targeted audits.
5. One improvement (5m): smallest automation that shrinks NEXT month's load.
Output: dated agenda file appended beside tracker; actions get owners+dates.

污点追踪指南

映射：一个输入——安全公告、扫描器输出、审计发现、外部报告——如何经过各个阶段传播，直到终态。每个输入都必须到达一个汇点；在流程中途消失的输入就是闭环中的漏洞。

SOURCES (entry points):                SANITIZERS (legal transformations):
 - finding file, any slug of             - dedup merge onto existing finding
   SKILL-CODE.md / SKILL-SERVER.md              (SKILL-CODE.md Phase 4; cross-ref line,
 - dependency-scanner output               not duplicate file)
   (SUPPLY-module commands)              - documented compensating control
 - sweep-patching.sh evidence              (holds band, never deletes)
 - distro security notice / dep          - scope exclusion WITH recorded
   advisory feed                           reason ("vendored fork, patched" + proof)
 - KEV catalog update / EPSS movement    - false-positive disproval w/ evidence
 - pentest / bug-bounty report
 - staff observation                     SINKS (terminal states only):
                                           - Verified-Fixed (evidence chain)
                                           - Risk-Accepted (exception row)
                                           - closed-as-false/disproven (recorded)

传播规则：

1. 一个工作日内进入唯一入口。 每个来源都必须作为新的发现文件（模板原样使用）录入跟踪器，或作为交叉引用行添加到现有文件中。在聊天中讨论过、却未录入跟踪器的安全公告，视为尚未收到。
2. 分诊前先查询资产清单。 先根据资产清单解析针对各软件包的输入——哪些代码仓库导入了该软件包、哪些主机运行着它、哪些隧道会暴露它。同一个 CVE 出现在构建主机和支付路径 API 上时，会成为两个优先级不同的实例。
3. 没有 TRIAGE RECORD，不得开展工作。 先修复再确定优先级，会让嗓门最大的人决定队列。污点必须先到达第 3 阶段，第 4 阶段才能开始。
4. 第 4 阶段必须原样传递工单：即发现条目自身的 Remediation 部分。在执行过程中变更范围，必须返回分诊环节；绝不能暗中修改。
5. 第 5 阶段是通往良性汇点的屏障。 合并差异后，可将 Open → Fixed (unverified)；只有执行 FVP 后，才能标记为 Verified-Fixed：重新测试 PoC、合并回归测试、重新扫描结果干净，并在适用时归档清扫差异。
6. 清洗器只是临时措施。 补偿性控制措施的暂缓状态会在控制措施变更时到期；例外条目会在指定日期到期——任一事件发生，都会以原优先级重新注入该发现。
7. 每个输入都必须通过一个有名称的汇点退出，并附上相应记录。 “决定没问题”却没有佐证材料，不是汇点，而是漏洞。

利用与复现

重新映射：在纸面上端到端走完整个流程，演练一个发现如何走完整个闭环。非破坏性；不发送任何数据包。尽可能使用真实的团队产物；遇到空白项时，将其记录为就绪度发现。限时 60 分钟；参与者：技术负责人 + 一名审计员角色；主持人引导各阶段、注入突发情况并评估产物。

对象： INJ-001 — orders-api 的订单搜索端点因未清理输入而导致的 SQL 注入。状态：已确认，基础严重性：高；发现报告中包含完整的修复验证计划（FVP）。

日	阶段	纸面演练内容	产出物
D0	FIND	季度全面审计派发 INJ slug；编写包含 PoC + FVP 的发现文件	findings/INJ-001-order-search.md；PROGRESS.md 行
D0	INVENTORY	跟踪器索引将发现关联到清单条目：orders-api，经由 cloudflared 隧道面向互联网，Postgres 后端，支付路径	跟踪器索引行
D1	TRIAGE	分流记录：无 KEV 映射（应用逻辑缺陷）；可从互联网未认证访问 → 按高危升级至严重级别处理；未声称存在控制措施（隧道的 Access 策略无法限制此公开产品端点——暂不适用）；资产 = 支付路径	已完成的分流记录块
D1	CLOCK	最终优先级相当于 P0；SLA 截止日期为 D8	已记录截止日期
D2–D7	REMEDIATE	批次 = 在同一维护窗口内处理整个 orders-api 组件：INJ-001 及在同一服务中发现的相关 LOGIC-003 竞态问题；先处理快速修复项（ORDER BY 允许列表，报告显示耗时 <1h）；修复与缓解选项框：拒绝将 WAF 规则作为最终方案，因为载荷中的空格各不相同——已记录决策	引用了发现 ID 的已合并 PR
D7–D8	VERIFY	执行本发现的 FVP：原始 PoC 现在返回 HTTP 400；GIVEN/WHEN/THEN 回归测试已合并到 CI；在变更文件上重新运行注入模块的 grep — 无结果；对于代码修复，差异扫描不适用，已记录定向重扫	发现文件中引用的测试名称 + 输出
D8	TRANSITION	Fix Status：合并时从 Open → Fixed (unverified)；通过门禁后变为 Verified-Fixed	状态已更新
D9	TRACK	更新指标：MTTR 样本（9d，对比 P0 的 7d SLA——是否计为违约？否：D8 已验证，符合要求）；已刷新 INJ 的覆盖率时效标记	月度指标快照
D30	REVIEW	月度回顾引用此案例；经验教训：按组件批处理发现了 LOGIC-003，而按严重性分散处理会推迟该问题	议程文件条目

主持人注入的突发情况（演练过程中任选一项）：

• “Cloudflare Access 策略可以限制此端点的访问——先暂缓修复？要暂缓多久？”（修复与缓解选项框 + 到期纪律）
• “D6 时，回归测试因合法的 Unicode 排序值而失败。”（是否如实阻止 VERIFY 阶段关闭？）
• “第二个仓库的管理工具中也出现了相同模式。”（清单传播 + 重新分流，而非复制粘贴优先级）
• “验证时，修复人员正在休假。”（单点故障：谁可以执行 FVP？）

通过标准：六个阶段均产出了指定产物；两次状态转换均符合模板规则；时限均得到遵守；每项注入的突发情况都记录了决策，而非临场 improvisation。

整改

按顺序补齐缺失阶段，确保每一步都能为下一步铺路。每项都对应一个 V 项发现，并产出一份制品。

B1. 先建立跟踪表（修复 V6）。 创建 security-audit/TRACKER.md，索引各运行目录中的所有发现文件：ID、标题、严重性、修复状态、优先级、截止日期。花 30 分钟对 <run-id>/findings/ 执行 grep——在做其他事情之前完成，因为之后每个阶段都会读取和写入此文件。

B2. 采用分诊标准和 SLA 默认值（V3）。 将严重性评估表复制到 docs/vuln-mgmt.md，标记可由团队调整的行，并取得一位具名负责人的签字确认。按从最早到最新的顺序，对未关闭积压项进行回溯分诊，直到每个未关闭发现都附有分诊记录。在积压项都有处理时限之前，不要进行新的扫描——否则你只会让债务增长得比决策更快。

B3. 将资产清单升级为持续维护的制品（V1）。 将最新的 TARGET-PROFILE.md 和 HOST-PROFILE.md 合并为一份资产清单文档，为涵盖全部七类攻击面类别的每个条目添加 last-reviewed 日期。与实际情况核对一次（DNS 区域列表、隧道入口配置、k8s 命名空间转储）；设置季度重新确认提醒；尽可能从 IaC 派生，确保信息自动保持最新，而不是依赖记忆。

B4. 接入自动化 FIND 来源（V2）。 按成本从低到高排序：(1) 配置 CI 任务，对现有的每种生态系统运行 SUPPLY 模块扫描器命令；(2) 设置每周 cron 运行 tools/run-all-sweeps.sh，并创建带日期的证据目录；(3) 添加日历事件——每季度进行全面审计，每周查看发行版跟踪器和依赖源中的安全公告；(4) 编写事件驱动的定向审计触发列表。

B5. 强制执行验证门禁（V5）。 在 CONTRIBUTING 中约定：修复某项发现的 PR 必须引用该发现 ID，并执行其修复验证计划；回归测试必须加入 CI，而不是写在评论里。审核者应像索要测试一样索要 FVP 证据。

B6. 创建例外登记表（V7）。 将 P3 模式复制到 security-audit/EXCEPTIONS.md。立即迁移口头风险接受记录；任何缺少负责人和到期日的旧版“我们认为没问题”决定，都要以完整优先级重新作为未关闭项处理。

B7. 进行首次月度审查（V6/V8）。 手动计算五项指标一次——速度慢本身就具有诊断价值。安排 30 分钟会议；追加一份带日期的议程文件。后续只需重复执行。

B8. 安排所有周期性工作（V8）。 根据 P4 表添加日历和 cron 条目。只有当陌生人仅凭制品就能预测每项活动下次何时触发时，才算完成。

顺序依据：先有跟踪表，再有分诊标准（这样才能确定真实事项的优先级）；先有分诊标准，再有自动化（扫描器产生大量发现之前，必须先设定处理时限）；尽早建立资产清单，因为所有输入都要依据它进行核实。

小团队的现实考量——时间紧张时的取舍顺序

当人手骤减时，按以下顺序舍弃（从最左侧开始）：

metrics formality < exception formality < monthly review < SLA-table precision
    < triage discipline < inventory accuracy

绝不能跳过分诊规范或资产清单：这两项能把未知风险转化为已知风险，而这正是整个流程的目的。它们左侧的所有事项都只是报告开销，之后可以根据右侧保持准确的文件重新整理。推论——先自动化，再扩充人手：确定性扫描（tools/run-all-sweeps.sh、tools/sweeps/sweep-code-recon.sh、tools/sweeps/sweep-patching.sh）和 CI 扫描器可以直接替代分析师的工作时间；只有在自动化能力达到饱和后，才增加人手。

验证与确认

通过演练而非检查来验证本计划：

能力	验证方法	通过标准
跟踪器完整性（V6）	随机选择一项正在运行的服务；在 ≤5 min 内通过跟踪器找到该服务的所有发现项	无需翻查旧资料即可找到
分诊完整性（V3）	抽查 5 项开放和 5 项已关闭的发现项：均存在 TRIAGE RECORD，且调整严格遵循决策树	≥4/5 项正确；错误项在同一周内修正
验证门槛（V5）	抽查 10 项 Verified-Fixed 发现项：均存在 FVP 证据（重新测试结果、已合并的测试名称、重新扫描的引用）	10/10；否则将违规项重新打开为 Open
例外管理规范（V7）	所有行均有负责人和 ≤180d 的到期时间；逾期行均已及时处理	无未经记录的延期
SLA 统计	手动重新计算违规指标，并与上次报告的数字对比	数字完全一致
时效性（V1/V8）	库存已在 ≤90d 内重新认证；每个已登记的 slug 均在其频率窗口内完成审计	符合时限，或已为缺口创建工单
完整闭环（全部）	每年进行两次桌面演练（利用与复现），轮换作为演练对象的发现项	两次均达到通过标准

验证规则：

1. 每次验证都必须产出记录 — 抽样表、演练记录、重新计算说明。没有记录 = 未验证 = 下次审计时标记为 PARTIAL。
2. 回归问题会以原始严重性和优先级重新打开 — 失效的修复不能沿用此前的关闭日期。
3. 每次真实事件发生后，重新运行本模块的就绪度审计（A 部分）：真实事件是最廉价的就绪度数据来源（参见 IR 事后复盘中的 AUDIT-SKILLSET 部分）。
4. 每年审计默认值本身：SLA 时长、频率表和资产关键性等级均须重新签署或经审慎修改 — 因疏忽造成的偏移会让计划沦为形式。

严重性评估

有意将两个层面分开。SEVERITY 来自发现报告量表（templates/finding-report.md，优先考虑可利用性时的决胜规则），并在报告时定稿。PRIORITY 是操作层面的，由本节指定，可以上调发现项的优先级或维持原级 — 但绝不能在未说明的情况下下调。

优先级调整规则

规则	对级别的影响	限制
无需身份验证即可从互联网访问	上调一个级别（最高为 Critical）	在分诊记录中记录可访问性证据
需通过身份验证／仅限内部／仅限构建时	不作调整	在记录中注明限制条件
与 KEV 目录条目对应，或存在可信的在野利用	跳过队列 → 无论级别如何，均按 P0 处理	注明来源；不得依据传闻
补偿性控制覆盖此路径	可以维持当前级别	提供书面理由；控制措施变更时，维持决定失效
存在已发布的 EPSS 评分	在同一级别内用于排序决胜	绝不捏造数值；允许注明“未查询”
资产关键性（支付 > 身份验证 > 生产数据 > 内部 > 营销）	同级冲突时优先处理关键资产	等级须列于团队章程中

如果确实难以在两个优先级之间抉择，选择较低者，并写明理由 — 与严重性量表的保守决胜规则保持一致。

SLA 表（默认值——标有 TEAM-TUNABLE 的行可由团队调整）

优先级	含义	修复或缓解时限	可调整？
P0	已知遭利用的类别，或严重级别为 Critical	7 天	仅可收紧，不可放宽
P1	严重级别为 High，或由 High 上调	30 天	可以
P2	严重级别为 Medium（包括由 Low 上调）	90 天	可以
P3	Low / Info	下个季度——或在记录中添加一行说明后，无限期搁置也可以	可以

缓解计作进展规则。 如果 WAF 规则、Cloudflare Access 门禁或配置变更确实阻止了漏洞利用，那么只要将其记录为缓解措施，SLA 计时就会如实暂停：注明控制措施、说明残余风险路径，并设置不超过 180 天后的复审日期。绝不能在未记录的情况下悄然将其转为已完成——未记录的缓解措施仍是违反 SLA 的未解决发现，但所有人都误以为它已关闭。

例外工作流。 到期日仍未修复的事项，必须归入以下两种情况之一：(a) 记录例外（P3 架构：finding-id、reason、compensating-control、owner、必须设置且不超过 180 天的 expiry、review trigger），并将 Fix Status: Risk-Accepted 关联到对应行；或 (b) 在月度审查中明确显示 SLA 违约。不存在第三种状态，让发现项悄无声息地过期。

常见误报

会让成熟度看起来已具备的项目审计陷阱：

1. 文档存在 ≠ 项目已落实。 从未应用于实际发现项的 SLA 表，最多只能算部分落实。测试方法：任选一项未解决的发现，追踪其计时过程。
2. 扫描器输出 ≠ 已跟踪的发现项。 粘贴到聊天中的 npm audit 输出，在成为发现文件或交叉引用行之前，都还没有进入闭环。
3. 严重级别 ≠ 优先级。 不同队列中的同等严重级别发现项具有不同到期日，说明调整规则正在发挥作用；将其标记为不一致，是对设计的误读。
4. 仅凭 CVSS 基础分确定优先级。 基础分忽略可达性和利用情报；单独使用基础分会重现 Stage 3 要解决的问题。
5. 已缓解 ≠ 已修复。 WAF 规则悄然被提升为永久修复，没有记录，也没有复审日期——这是小团队中最常见的隐性失误。
6. 例外 ≠ 已关闭。 没有关联到期日期登记行的 Risk-Accepted，只是乔装打扮的未解决发现项。
7. 上次审计的 TARGET-PROFILE ≠ 资产清单。 审计运行后上线的服务不会显示在其中；设置新鲜度日期就是为了发现这一点。
8. 仅开发环境的依赖项噪声导致数量虚高。 统计指标前，按照 SUPPLY 指引将扫描器输出限定在生产路径内——但仍须以 P3 修复开发路径中的项目。
9. 声称已验证修复，却未执行 FVP。 没有合并的回归测试，也没有重新扫描输出 → 重新打开。状态转换规则不是建议。
10. MTTR 平均值掩盖异常值。 除平均值外还要报告 MAX；一项持续 400 天的 Critical 发现项，会轻易隐藏在看似健康的平均值中。
11. 一个平静的季度 ≠ 趋势。 指标需要跨季度才有意义；单次快照只能用于建立基线。
12. 在分流记录中捏造 EPSS/CVSS/利用情况声明。 在整套技能中都严格禁止，尤其在这里，因为这些信息会影响队列；始终可以注明“未查询”。

参考资料

• NIST SP 800-40 补丁管理出版物系列（不同版本的修订编号有所变化——请查阅 CSRC 目录以确认当前版本）：https://csrc.nist.gov
• NIST 网络安全框架——前置内容中说明的 Identify/Respond 功能映射：https://www.nist.gov/cyberframework
• CISA 已知遭利用漏洞（KEV）目录——权威的已知遭利用漏洞列表；请通过 https://www.cisa.gov 查阅当前条目
• FIRST 漏洞利用预测评分系统（EPSS）——已发布的漏洞利用概率评分：https://www.first.org
• FIRST 通用漏洞评分系统（CVSS）规范——发现报告使用的基本严重性术语：https://www.first.org
• 编排器：SKILL-CODE.md 第 4 节注册表（代码 slug、第 4 阶段去重规则、第 6 阶段修复流程）；SKILL-SERVER.md 第 3 节注册表（SRV slug、第 6 阶段加固应用）
• 相关模块：SUPPLY skills/code/supply-chain/SKILL.md（依赖扫描器命令矩阵——仅作引用，此处不重复）；PATCH skills/server/updates-patching/SKILL.md；DETECT skills/operations/blue-team-detection/SKILL.md（P1–P4 分级规则：警报紧急程度，与本模块的修复优先级不同）；IR skills/operations/incident-response/SKILL.md（已跟踪的发现何时成为正在发生的事件）；DR skills/server/backup-dr/SKILL.md（演练频率模型）
• 模板：templates/finding-report.md（严重性分级规则、状态、Fix Verification Plan 要求、Fix Status 状态转换）；templates/target-profile.md（资产清单种子文件）
• 工具：tools/run-all-sweeps.sh、tools/sweeps/sweep-code-recon.sh、tools/sweeps/sweep-patching.sh、tools/README.md 扫描约定