企业官网建设流程全解析

构建漏洞例外跟踪系统：风险接受审批、补偿性控制与自动过期机制实战指南

【免费下载链接】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 仓库中skills/building-vulnerability-exception-tracking-system技能，系统讲解如何从零搭建一套漏洞例外（Vulnerability Exception）与风险接受（Risk Acceptance）跟踪系统。当漏洞无法在 SLA 时限内完成修复时，这套系统提供结构化的例外申请、补偿性控制（Compensating Controls）记录、分层审批流以及例外到期自动失效机制，帮助组织在保持风险可见性的同时满足 PCI DSS、SOC 2、NIST CSF 等合规框架的要求。读完本文，你将掌握例外类别的建模方法、数据库设计、Flask API 与 CLI 双重实现、审批链状态机、每日过期巡检与合规报告生成等完整落地能力。

何时需要一套漏洞例外跟踪系统

在真实的漏洞治理实践中，"所有漏洞都能在 SLA 内修复"只是理想状态。依赖老旧系统的资产、等待供应商补丁的场景、业务连续性约束都可能让修复延期。此时如果没有正式的例外流程，漏洞要么长期挂着变成"影子风险"，要么被默认接受却无人签字负责。

按本技能的定位，以下场景适合启用例外跟踪系统：

• 部署或配置漏洞例外跟踪能力时；
• 建立与合规要求对齐的安全控制（如 PCI DSS 补偿性控制、SOC 2 风险接受证据）时；
• 构建或改进该领域的整体安全架构时；
• 执行需要此类实现支撑的安全评估时。

技能元数据（SKILL.md 的 frontmatter）将该能力映射到 NIST CSF 的 ID.RA-01（资产漏洞识别）、ID.RA-02（威胁与漏洞信息接收）、ID.IM-02（漏洞管理活动审计）、ID.RA-06（风险响应行动）等控制项，说明它本质上是漏洞管理治理闭环中"接受风险"这一关键决策的落地载体。

前置条件

在动手实现前，需要准备以下环境：

• Python 3.9+，安装flask、sqlalchemy、requests、jinja2依赖；
• PostgreSQL 或 SQLite数据库（仓库脚本默认使用 SQLite，便于快速启动）；
• Email / Slack 集成，用于审批通知与到期告警；
• 漏洞管理平台 API（DefectDojo、Qualys、Tenable 等），用于在审批通过后将漏洞状态回写为exception_approved。

仓库中的 scripts/process.py 提供了一个可直接运行的 CLI 实现，仅依赖标准库加requests，通过环境变量EXCEPTION_DB_PATH指定数据库文件（默认vulnerability_exceptions.db），是快速验证整套流程的最佳起点。

例外申请工作流

例外类别（Exception Categories）

不同例外场景的风险敞口与审批严肃程度不同，系统按类别区分最大有效期与审批层级。SKILL.md 定义了五类：

在 scripts/process.py 的create_exception()中，最大时长被硬编码为{"remediation_delay": 30, "no_fix": 90, "business_critical": 60, "false_positive": 365, "compensating_control": 180}（误报类在实际实现中按 365 天上限处理而非"永久"，避免数据库中出现无限期记录）。系统会校验请求的过期时间是否超出类别上限，超出则拒绝创建——这正是防止"例外永久化"的第一道闸门。

例外申请必填字段

一次完整的例外请求应包含漏洞信息、资产生命周期上下文、风险评分、补偿性控制清单与审批人名单。SKILL.md 给出的请求数据结构如下：

exception_schema = { "cve_id": "CVE-2024-XXXX", "finding_id": "unique-finding-reference", "asset_hostname": "prod-db-01.corp.local", "severity": "high", "cvss_score": 8.1, "category": "remediation_delay", "justification": "Database upgrade required before patch can be applied", "compensating_controls": [ "WAF rule blocking exploit pattern deployed", "Network segmentation restricting access to trusted VLANs only", "Enhanced monitoring via Splunk alert for exploitation indicators" ], "requested_expiration": "2024-06-15", "requestor_email": "dbadmin@company.com", "approver_emails": ["security-lead@company.com", "ciso@company.com"], "risk_rating": "medium", }

其中justification是审批决策的核心证据——必须说明为什么无法在 SLA 内修复、修复的前置依赖是什么。compensating_controls则回答"在修复落地前，风险如何被兜住"。

仓库还提供了可直接用于收集信息的表单模板 assets/template.md，除漏洞信息与例外详情外，还包含：

• 风险评估区：残余风险评级、被利用后的业务影响、利用可能性；
• 请求人区：姓名、邮箱、部门、日期；
• 审批区（供审批人使用）：批准/拒绝/要求补充信息三种决策、附加条件、评审意见、签名或邮件确认引用。

该模板将 SKILL.md 中的 Python 数据结构"翻译"为业务人员可填写的书面表单，两者配合使用可同时满足系统录入与审计留痕需求。

审批链：按严重度路由

在 references/api-reference.md 中，审批链按漏洞严重度分级路由，且审批顺序严格固定（后一位审批人必须在前一位批准后才能审批）：

对应地，最大例外时长也按严重度收紧：Critical 30 天、High 90 天、Medium 180 天、Low 365 天。

这一设计在 scripts/agent.py 中以APPROVAL_CHAIN与MAX_EXCEPTION_DAYS两个字典常量实现，并由process_approval()（见 agent.py）强制校验"下一个审批人必须是链中的下一顺位"，杜绝越权审批。当链上所有审批人都通过后，状态才转为approved且risk_accepted置为True；任一审批人拒绝则整体转为rejected。

数据库设计

例外记录需要完整承载审批轨迹与生命周期状态。SKILL.md 给出的 PostgreSQL 模式包含主表与审计表两张表：

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);

几个关键设计点：

• expires_at为 NOT NULL，配合三个索引中的idx_exception_expires，支撑每日过期巡检的高效查询；
• exception_audit_log通过外键关联主表，记录created/approved/rejected/expired等全部动作与执行者，是审计与合规取证的核心依据；
• status字段驱动整条生命周期：pending→approved/rejected→expired。

scripts/process.py 的init_db()提供了该模式的 SQLite 等价实现（AUTOINCREMENT自增主键、FOREIGN KEY约束），两套实现字段一一对应，便于在开发环境（SQLite）与生产环境（PostgreSQL）间切换。可以推断，若需切换到 PostgreSQL，仅需替换连接驱动与主键方言，表结构无需改动。

生命周期状态机

references/api-reference.md 定义了六个状态，构成完整状态机：

在 scripts/agent.py 中以EXCEPTION_STATES常量列出全部合法状态。submit_for_approval()仅允许draft状态提交（见 agent.py），process_approval()仅允许pending_approval状态被处理，越界操作一律返回错误——这种"非法状态转换即拒绝"的模式保证了审批流程的严肃性与可审计性。

实现：Flask API 与 CLI 双通道

例外申请 API

SKILL.md 提供了基于 Flask 的三端点骨架：

from flask import Flask, request, jsonify from datetime import datetime, timezone import json app = Flask(__name__) @app.route("/api/exceptions", methods=["POST"]) def create_exception(): data = request.json required = ["cve_id", "finding_id", "category", "justification", "expires_at", "requestor_email"] for field in required: if field not in data: return jsonify({"error": f"Missing required field: {field}"}), 400 # Validate expiration does not exceed category maximum max_days = {"remediation_delay": 30, "no_fix": 90, "business_critical": 60, "false_positive": 365, "compensating_control": 180} # Insert into database and notify approvers return jsonify({"status": "pending", "id": "exc-12345"}) @app.route("/api/exceptions/<exc_id>/approve", methods=["POST"]) def approve_exception(exc_id): approver = request.json.get("approver_email") notes = request.json.get("notes", "") # Update status to approved, record approver and timestamp return jsonify({"status": "approved"}) @app.route("/api/exceptions/<exc_id>/reject", methods=["POST"]) def reject_exception(exc_id): reviewer = request.json.get("reviewer_email") reason = request.json.get("reason") # Update status to rejected, record reviewer and reason return jsonify({"status": "rejected"})

设计要点：创建接口在写入前做必填字段校验与类别最大时长校验（复用前文max_days映射），保证脏数据进不了库；批准与拒绝接口要求携带审批人邮箱与意见，为审计日志提供完整actor信息。

CLI 实现（可运行）

与 Flask 骨架对应的可运行实现是 scripts/process.py 的命令行工具，通过argparse暴露全部核心操作：

# 初始化数据库并创建一条例外（从 JSON 文件读取请求） python3 scripts/process.py --create exception_request.json # 批准 / 拒绝指定例外 python3 scripts/process.py --approve 1 --approver security-lead@company.com --notes "compensating controls adequate" python3 scripts/process.py --reject 1 --approver ciso@company.com --reason "insufficient controls" # 检查到期例外（支持 Slack webhook 告警） python3 scripts/process.py --check-expirations --slack-webhook https://hooks.slack.com/services/xxx # 生成例外报告 python3 scripts/process.py --report --output exception_report.json # 指定数据库文件（默认 vulnerability_exceptions.db） python3 scripts/process.py --db /path/to/exceptions.db --check-expirations

从源码看（process.py），main()采用"单一动作模式"：一次执行只处理--create、--approve、--reject、--check-expirations、--report中的一项，参数不足时打印帮助信息。其中：

• create_exception()（process.py）在校验过期时长后将compensating_controls列表 JSON 序列化存储，并写入created审计日志，返回自增 ID；
• approve_exception()/reject_exception()（process.py）更新状态、审批人与审批时间，同时追加对应审计记录。

与 GRC 平台对接

若组织使用 ServiceNow GRC 或 Archer 等治理平台，references/api-reference.md 给出了对接示例：

# ServiceNow GRC：创建风险例外 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：创建例外记录 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"}}}}'

这意味着本系统的例外记录可以双向同步到企业级 GRC 平台，作为审计与治理证据链的一部分。

到期巡检：自动过期与告警

例外最大的治理风险是"批了就忘"。SKILL.md 明确要求每日巡检，命令如下：

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

scripts/process.py 的check_expirations()揭示了完整逻辑：

1. 以 UTC 当前时间为基准，筛选 14 天内到期（含已到期）的approved状态例外；
2. 对已到期例外执行状态翻转：approved→expired，并写入expired审计记录；
3. 若配置了--slack-webhook，向 Slack 推送汇总告警："Vulnerability Exception Alert: N expired, M expiring soon"；
4. 返回{"expired": N, "expiring_soon": M}供上层调用。

配套的 references/workflows.md 定义了更细的巡检节奏：

• 到期前 14 天：向请求人发送续期提醒；
• 到期前 7 天：发送带升级（escalation）的紧急提醒；
• 已到期：状态置为expired，漏洞状态在扫描器/DefectDojo 中回退为open，通知资产负责人与安全团队，并重新生成 SLA 跟踪清单。

这条"提醒→升级→强制过期→状态回写"的链路，确保例外不会悄悄变成无限期接受的风险，同时让扫描器中的漏洞状态与例外状态始终一致。

补偿性控制文档化

补偿性控制是例外请求获得批准的核心前提——你需要在修复落地前，用其他手段把风险压到可接受水平。SKILL.md 要求每个例外的补偿性控制必须覆盖四个维度：

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

assets/template.md 的表单将这四维问题逐一列出，references/api-reference.md 进一步给出可按类别选取的控制类型参考：

控制不是写了就算数。references/workflows.md 的"补偿性控制验证"工作流要求定期核验每个控制仍处于有效状态：WAF 规则查询 WAF API 确认规则状态、网络分段核对防火墙规则、监控告警确认 SIEM 规则激活且能触发。发现控制失效的例外会被标记，若无法在 48 小时内恢复，则应撤销该例外。这套验证机制保证了"纸面上的控制"与"运行中的控制"不脱节。

关键运营工作流

references/workflows.md 定义了四条可操作的运营工作流，构成系统的日常运转节奏：

工作流 1：例外申请与审批资产负责人识别无法在 SLA 内修复的漏洞 → 提交含理由与补偿性控制的申请 → 系统校验完整性 → 按严重度/类别路由给对应审批人 → 审批人批准、拒绝或要求补充信息 → 批准后记录过期日期 → 扫描器/DefectDojo 中漏洞状态更新为exception_approved→ 审计日志记录完整审批链。

工作流 2：每日到期检查Cron 查询expires_at <= 今天 + 14 天的活动例外 → 14 天前发续期提醒 → 7 天前发升级提醒 → 到期则状态置expired并回退漏洞为open→ 通知资产负责人与安全团队 → 重新生成 SLA 跟踪。

工作流 3：季度例外评审按类别与严重度汇总活动例外 → 逐条核验补偿性控制仍在位 → 复查no_fix类是否已有供应商补丁 → 基于当前威胁形势重新评估风险 → 风险画像变化的例外升级重新审批 → 更新评审意见与新风险评级 → 向安全治理委员会提交季度报告。

工作流 4：补偿性控制验证提取每条活动例外的控制清单 → 逐项验证仍可运作 → 标记控制失效的例外 → 通知请求人与安全团队 → 48 小时内无法恢复则撤销例外。

这套工作流把例外管理从"一次性审批"升级为"持续治理"，与 NIST CSF 的 ID.IM-02（持续监控）语义高度一致。

合规映射与审计证据

例外跟踪系统的最终价值体现在合规审计中。本技能通过 frontmatter 映射了 NIST CSF 控制项，references/standards.md 给出了各框架对例外的具体要求：

同时 references/standards.md 列出的底层标准还包括 NIST SP 800-53 Rev 5 的 RA-5(5)（漏洞监控与扫描）、ISO 27001:2022 第 6.1.3 条（风险处置需正式记录并由适当权限批准）以及 CIS Controls v8 第 7 项控制 7.7（在规定时间内修复漏洞，例外需记录补偿性控制）。

从实现上看，scripts/process.py 的generate_report()恰好对应这些审计要求：报告按状态分组统计（summary），并按"过期→待审批→已批准→其他"的优先级排序输出全部例外明细，生成带时间戳的 JSON 报告文件。运行python3 scripts/process.py --report --output exception_report.json即可得到审计人员需要的证据快照。

值得注意的是，scripts/agent.py 的generate_exception_report()提供了另一视角的汇总：按状态与严重度计数、活动例外数、未来 30 天内到期清单（含剩余天数）。两者结合，既能满足治理委员会的宏观视图，也能支撑审计的逐条核验。

落地建议

• 先在 SQLite 上跑通全流程：使用python3 scripts/process.py --check-expirations验证到期巡检，再迁移到 PostgreSQL 生产环境；
• 与扫描器打通状态回写：审批通过后将漏洞状态在 DefectDojo/Qualys/Tenable 中置为exception_approved，到期后回退为open，避免"双份真相"；
• 把四维补偿性控制作为硬性要求：缺少 Detection / Prevention / Response / Monitoring 任一维度的申请应直接退回；
• 将每日巡检与提醒纳入运维排班：14 天/7 天两级提醒配合 Slack webhook，让到期处理不再依赖人工记忆；
• 按季度执行例外评审工作流，并将结果以 assets/template.md 形式的书面记录归档，作为 SOC 2 与 PCI DSS 审计证据。

相关参考文件：SKILL.md（技能主文档）、scripts/process.py（CLI 实现）、scripts/agent.py（审批链状态机）、references/workflows.md（四条运营工作流）、references/api-reference.md（状态/审批链/GRC 对接）、references/standards.md（合规映射）、assets/template.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