企业官网建设流程全解析

漏洞例外跟踪系统合规标准指南：基于 NIST、PCI DSS、ISO 27001 与 SOC 2 的风险接受治理

【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills

导读

本文基于 Anthropic-Cybersecurity-Skills 仓库中building-vulnerability-exception-tracking-system技能的 standards.md 文档展开，系统梳理漏洞例外（Vulnerability Exception）与风险接受（Risk Acceptance）治理所依据的五大权威标准框架，并结合该技能目录下的数据库 Schema、API 实现、审批工作流与补偿控制文档化实践，说明"哪些漏洞可以申请例外、需要什么证据、由谁审批、必须留下什么记录"。读者完成本文后将掌握：如何把 NIST SP 800-53、PCI DSS v4.0、ISO 27001:2022、CIS Controls v8 与 SOC 2 的例外管理要求翻译成一套可落地的异常跟踪系统设计。

为什么例外管理是合规审计的硬性要求

在漏洞管理中，并非所有漏洞都能在 SLA 时限内完成修复。补丁未发布、停机窗口受限、业务连续性与修复冲突等情况，要求组织必须有正式的例外（Exception）与风险接受流程。standards.md明确指出，主流合规框架普遍要求组织以文档化风险接受（documented risk acceptance）的方式跟踪和管理漏洞例外。

例如 NIST SP 800-53 Rev 5 的RA-5(5)（漏洞监控与扫描——特权访问）要求组织跟踪并管理漏洞例外，且必须带有文档化的风险接受记录；ISO 27001:2022 的6.1.3 信息安全风险处理要求风险接受必须由具备相应权限的管理者正式批准并记录在案；CIS Controls v8 的Control 7（持续漏洞管理）及其子控制7.7要求在规定的时限内修复已检测漏洞，同时对无法按时修复的漏洞以补偿控制的形式文档化例外。因此，例外跟踪系统不是"法外开恩"的工具，而是把风险决策纳入治理与审计轨道的必要基础设施。

在本技能对应的 SKILL.md 中，这一系统被定义为：为无法在 SLA 时限内修复的漏洞提供请求、审批、补偿控制文档化与自动到期的结构化流程，从而在满足 PCI DSS、SOC 2、NIST CSF 合规要求的同时，让组织对被接受的风险保持持续可见性。

五大核心标准及其例外管理要求

standards.md将例外管理的权威依据归纳为五类框架，每一类都对应不同的审计证据要求：

其中 PCI DSS v4.0 的补偿控制（Compensating Controls）要求最为严格：当组织无法按标准原文满足某项 PCI 要求时，必须填写补偿控制工作表，证明补偿措施达到了与原始要求同等的安全强度。这也解释了为何在技能的数据模型与工作流中，compensating_controls字段是例外记录的强制组成部分（详见后文数据库 Schema 部分）。

各框架的例外合规要求对照表

standards.md进一步以对照表的形式给出了不同框架下例外所需的文档要求，这是设计表单与记录字段的直接依据：

这五行的设计意图非常清晰：例外一旦被批准，就必须能回答审计员的五个问题——为什么接受（justification）、谁批准的（approval chain）、风险还剩多少（residual risk）、有什么补偿（controls）、多久复审一次（review cadence）。技能中的异常状态机、审批链与到期机制，本质上是把这五个问题固化成系统字段与流程约束。

从标准到系统：例外记录的数据模型

要在系统中承载上述合规证据，例外记录必须包含足够的字段。技能目录中的 SKILL.md 给出了完整的数据库 Schema，其核心表vulnerability_exceptions与审计表exception_audit_log一一对应了合规要求：

CREATE TABLE vulnerability_exceptions ( id SERIAL PRIMARY KEY, cve_id VARCHAR(20) NOT NULL, finding_id VARCHAR(100) NOT NULL, asset_hostname VARCHAR(255), severity VARCHAR(20), cvss_score DECIMAL(3,1), category VARCHAR(50) NOT NULL, justification TEXT NOT NULL, compensating_controls TEXT, status VARCHAR(20) DEFAULT 'pending', requested_by VARCHAR(255) NOT NULL, approved_by VARCHAR(255), requested_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, approved_at TIMESTAMP, expires_at TIMESTAMP NOT NULL, expired BOOLEAN DEFAULT FALSE, risk_rating VARCHAR(20), review_notes TEXT, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE exception_audit_log ( id SERIAL PRIMARY KEY, exception_id INTEGER REFERENCES vulnerability_exceptions(id), action VARCHAR(50) NOT NULL, actor VARCHAR(255) NOT NULL, details TEXT, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); CREATE INDEX idx_exception_status ON vulnerability_exceptions(status); CREATE INDEX idx_exception_expires ON vulnerability_exceptions(expires_at); CREATE INDEX idx_exception_cve ON vulnerability_exceptions(cve_id);

对照standards.md的文档要求可以发现：

• justification、risk_rating、review_notes对应 SOC 2 的论证与复审节奏、NIST CSF 2.0 的接受准则与剩余风险；
• approved_by与审计表中的actor字段承载 ISO 27001 要求的"风险负责人批准"证据链；
• expires_at与expired字段将"复审计划"固化为强制到期机制，杜绝无限期接受风险。

仓库中 scripts/process.py 使用 SQLite 提供了同一 Schema 的可运行实现，并通过环境变量EXCEPTION_DB_PATH（默认vulnerability_exceptions.db）指定数据库路径，便于本地验证。

例外分类与补偿控制：PCI DSS 的核心落地

例外能否获批，取决于分类与补偿控制的质量。standards.md中 PCI DSS v4.0 附录 B 要求补偿控制工作表涵盖"约束、目标、控制措施、验证"四要素。技能目录中的例外分类表将例外划分为五类，每类都有最大时长与审批层级约束：

在 scripts/process.py 中，create_exception()会校验请求的到期时间是否超出该分类的最大天数，超限直接拒绝创建，从入口处保证例外时长不越界。

补偿控制的文档化需要覆盖四个维度（见 SKILL.md）：

1. 检测（Detection）：利用尝试如何被发现？
2. 预防（Prevention）：哪些屏障降低利用可能性？
3. 响应（Response）：有哪些事件响应流程？
4. 监控（Monitoring）：哪些持续监控保证控制持续有效？

assets/template.md 提供了可直接使用的例外申请表模板，其中补偿控制部分即按"检测控制、预防控制、响应流程、监控"四项设计，并包含 CVE ID、Finding ID、受影响资产、严重性、CVSS、原始 SLA 截止日期等字段，以及审批人的批准/拒绝/补充信息三分决策区——这套表单与各框架的文档要求完全对齐。

审批链设计：按严重性路由的治理层级

ISO 27001 要求"风险接受须经适当权限方批准"，而standards.md明确 SOC 2 需要可审计的审批链证据。技能中的 api-reference.md 给出了按严重性路由的审批链设计：

同时，按严重性定义了最大例外时长：Critical 30 天、High 90 天、Medium 180 天、Low 365 天。

在 scripts/agent.py 中，APPROVAL_CHAIN与MAX_EXCEPTION_DAYS以字典形式实现这两个映射，而process_approval()（见 scripts/agent.py）强制执行顺序审批：仅允许审批链中的下一位审批人做出决定，任何越权审批都会返回错误；一旦任一人拒绝，异常状态立即转为rejected；全部审批通过后状态才变为approved且risk_accepted=True。这种"顺序链 + 一票否决"的模型，正是合规审计所需的审批链证据来源。

完整的异常状态机在 api-reference.md 中定义为六个状态：draft（草稿，未提交）、pending_approval（等待审批链）、approved（全部审批人接受）、rejected（任一人否决）、expired（已过到期日）、revoked（人工撤销）。

与 GRC 平台集成：ServiceNow 与 Archer

standards.md聚焦标准依据，而 api-reference.md 补充了与主流 GRC 平台的集成方式，让例外记录能够汇入企业级治理平台。创建风险例外可通过 ServiceNow GRC API：

curl -X POST "https://instance.service-now.com/api/now/table/sn_grc_exception" \ -u "user:pass" \ -H "Content-Type: application/json" \ -d '{"short_description":"CVE-2024-1234 exception","risk_score":"8.5","state":"draft"}'

或通过 Archer GRC API 创建例外记录：

curl -X POST "https://archer.example.com/api/core/content" \ -H "Authorization: Archer session-token=$TOKEN" \ -d '{"Content":{"LevelId":42,"FieldContents":{"1001":{"Value":"Exception for CVE-2024-1234"}}}}'

同时，api-reference.md 将补偿控制分为五类，可作为表单设计时的枚举参考：

运行时工作流：从提交到复审

例外治理不仅是建表与审批，还包含持续的运行时流程。workflows.md 定义了四个核心工作流：

工作流 1：例外请求与审批。资产所有者识别无法按 SLA 修复的漏洞 → 提交包含论证与补偿控制的请求 → 系统校验请求完整性与分类专属字段 → 按严重性与分类路由到对应审批人 → 审批人批准/否决/要求补充信息 → 批准后记录例外及到期日 → 漏洞在扫描器/DefectDojo 中更新为exception_approved→ 审计日志记录完整审批链。

工作流 2：每日到期检查。Cron 任务查询所有expires_at <= 今日+14天的活动例外；14 天内到期发送续期提醒；7 天内到期发送升级告急提醒；已过期例外状态更新为expired并把漏洞恢复为open；通知资产所有者与安全团队；重新生成包含重开发现的 SLA 跟踪。

工作流 3：季度例外复审。按分类与严重性生成活动例外报告 → 逐一验证补偿控制仍然生效 → 检查no_fix类例外是否已有厂商补丁 → 依据当前威胁形势重新评估风险等级 → 对风险画像变化的例外升级重新审批 → 更新复审记录与新风险等级 → 向安全治理委员会提交季度报告。

工作流 4：补偿控制验证。对每个活动例外提取所列补偿控制 → 逐一验证仍可运行（WAF 规则查询 WAF API 状态、网络分段验证防火墙规则、监控告警确认 SIEM 规则仍活跃且触发）→ 标记补偿控制退化的例外 → 通知请求人与安全团队 → 48 小时内无法恢复的控制，撤销例外。

这些工作流与standards.md中的 SOC 2"复审节奏"、ISO 27001"复审计划"要求一一对应，并通过 scripts/process.py 的check_expirations()落地为可调度代码——该函数扫描已批准且过期的例外自动置为expired并写入审计日志，同时支持 Slack Webhook 推送告警：

# 每日检查到期例外 python3 scripts/process.py --check-expirations # 生成月度例外报告 python3 scripts/process.py --report --output exception_report.json

scripts/process.py 还提供了--create、--approve、--reject、--approver、--reason、--slack-webhook等 CLI 参数，覆盖从创建到审批、到期检查、报告生成的全生命周期操作。

一套治理能力如何满足多家框架

综合来看，standards.md列出的五套框架虽然各有侧重，但最终收敛到同一套治理能力，技能目录中的实现正是按此设计的：

• NIST SP 800-53 RA-5(5) 与 NIST CSF 2.0要求的是"跟踪 + 文档化接受 + 剩余风险可见"，对应例外表的状态字段、risk_rating与review_notes；
• PCI DSS v4.0 附录 B要求补偿控制工作表四要素，对应compensating_controls字段与模板表单的四维控制设计，并通过 48 小时失效撤销机制保证补偿控制"可验证"；
• ISO 27001:2022 6.1.3要求正式批准与负责人记录，对应approved_by、审批链顺序校验与审计日志；
• CIS Controls v8 7.7要求按时限修复、例外附补偿控制，对应分类最大时长约束与到期自动回退机制；
• SOC 2 CC3.2要求风险接受证据与复审节奏，对应完整审计日志、季度复审工作流与报告生成。

在 Anthropic-Cybersecurity-Skills 仓库中，该技能通过 SKILL.md 的 NIST CSF 映射（ID.RA-01、ID.RA-02、ID.IM-02、ID.RA-06）与 MITRE ATT&CK 映射（T1190、T1068）进一步将治理能力嵌入攻击视角，读者可以结合 ATTACK_COVERAGE.md 与 docs/mitre-f3-mapping.md 了解该技能在整个合规映射体系中的位置。

落地建议与前提

实施本文所述体系前需明确以下前提：

• 运行环境：Python 3.9+，依赖flask、sqlalchemy、requests、jinja2；数据库可选 PostgreSQL 或 SQLite；审批通知依赖 Email/Slack 集成；漏洞平台 API 支持 DefectDojo、Qualys、Tenable 等；
• 分类时长与审批链：本文中的最大时长（如修复延迟 30 天、无补丁 90 天）与审批层级是技能提供的默认治理参数，实际部署时应根据组织的风险偏好、行业监管要求与审计实践调整；
• 合规声明边界：例外跟踪系统提供的是支撑合规的证据基础设施，最终是否满足 PCI DSS、SOC 2 等框架的判定，仍取决于组织的整体控制环境与第三方审计结论；
• 仅本地验证：仓库为只读资源，运行 scripts/process.py 等脚本应在本地环境进行，用于验证流程与生成示例报告，不应直接改动仓库内容。

以 assets/template.md 为起点设计例外表单、以 SKILL.md 中的 Schema 建表、以 workflows.md 编排运行时流程、以 standards.md 对照审计证据——这四份文档构成了一套完整的、可向审计员讲清"为什么接受风险、谁批准、还剩多少风险、如何补偿、何时复审"的漏洞例外治理闭环。

【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills