构建漏洞例外跟踪系统风险接受审批、补偿性控制与自动过期机制实战指南【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATTCK, 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 集成用于审批通知与到期告警漏洞管理平台 APIDefectDojo、Qualys、Tenable 等用于在审批通过后将漏洞状态回写为exception_approved。仓库中的 scripts/process.py 提供了一个可直接运行的 CLI 实现仅依赖标准库加requests通过环境变量EXCEPTION_DB_PATH指定数据库文件默认vulnerability_exceptions.db是快速验证整套流程的最佳起点。例外申请工作流例外类别Exception Categories不同例外场景的风险敞口与审批严肃程度不同系统按类别区分最大有效期与审批层级。SKILL.md 定义了五类类别说明最大时长审批层级Remediation Delay修复延迟补丁已发布但部署受阻30 天团队负责人 安全团队No Fix Available无可用修复供应商尚未发布补丁90 天安全总监Business Critical业务关键系统停机即无法打补丁60 天工程 VP CISOFalse Positive误报该发现并非真实漏洞永久安全分析师Compensating Control补偿性控制已有替代缓解措施180 天安全架构师在 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: dbadmincompany.com, approver_emails: [security-leadcompany.com, cisocompany.com], risk_rating: medium, }其中justification是审批决策的核心证据——必须说明为什么无法在 SLA 内修复、修复的前置依赖是什么。compensating_controls则回答在修复落地前风险如何被兜住。仓库还提供了可直接用于收集信息的表单模板 assets/template.md除漏洞信息与例外详情外还包含风险评估区残余风险评级、被利用后的业务影响、利用可能性请求人区姓名、邮箱、部门、日期审批区供审批人使用批准/拒绝/要求补充信息三种决策、附加条件、评审意见、签名或邮件确认引用。该模板将 SKILL.md 中的 Python 数据结构翻译为业务人员可填写的书面表单两者配合使用可同时满足系统录入与审计留痕需求。审批链按严重度路由在 references/api-reference.md 中审批链按漏洞严重度分级路由且审批顺序严格固定后一位审批人必须在前一位批准后才能审批严重度审批人链CriticalSecurity Lead → CISO → Risk CommitteeHighSecurity Lead → CISOMediumSecurity LeadLowSecurity Lead对应地最大例外时长也按严重度收紧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 定义了六个状态构成完整状态机状态说明draft初始创建尚未提交pending_approval等待审批链处理approved全部审批人接受rejected任一审批人拒绝expired超过过期日期revoked被手动撤销在 scripts/agent.py 中以EXCEPTION_STATES常量列出全部合法状态。submit_for_approval()仅允许draft状态提交见 agent.pyprocess_approval()仅允许pending_approval状态被处理越界操作一律返回错误——这种非法状态转换即拒绝的模式保证了审批流程的严肃性与可审计性。实现Flask API 与 CLI 双通道例外申请 APISKILL.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: fMissing 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-leadcompany.com --notes compensating controls adequate python3 scripts/process.py --reject 1 --approver cisocompany.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.pymain()采用单一动作模式一次执行只处理--create、--approve、--reject、--check-expirations、--report中的一项参数不足时打印帮助信息。其中create_exception()process.py在校验过期时长后将compensating_controls列表 JSON 序列化存储并写入created审计日志返回自增 IDapprove_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.jsonscripts/process.py 的check_expirations()揭示了完整逻辑以 UTC 当前时间为基准筛选 14 天内到期含已到期的approved状态例外对已到期例外执行状态翻转approved→expired并写入expired审计记录若配置了--slack-webhook向 Slack 推送汇总告警Vulnerability Exception Alert: N expired, M expiring soon返回{expired: N, expiring_soon: M}供上层调用。配套的 references/workflows.md 定义了更细的巡检节奏到期前 14 天向请求人发送续期提醒到期前 7 天发送带升级escalation的紧急提醒已到期状态置为expired漏洞状态在扫描器/DefectDojo 中回退为open通知资产负责人与安全团队并重新生成 SLA 跟踪清单。这条提醒→升级→强制过期→状态回写的链路确保例外不会悄悄变成无限期接受的风险同时让扫描器中的漏洞状态与例外状态始终一致。补偿性控制文档化补偿性控制是例外请求获得批准的核心前提——你需要在修复落地前用其他手段把风险压到可接受水平。SKILL.md 要求每个例外的补偿性控制必须覆盖四个维度Detection检测利用尝试如何被发现Prevention预防哪些屏障降低利用可能性Response响应针对该漏洞有哪些应急响应流程Monitoring监控哪些持续监控保证控制持续有效assets/template.md 的表单将这四维问题逐一列出references/api-reference.md 进一步给出可按类别选取的控制类型参考类别示例Network分段、ACL、微隔离Monitoring增强日志、告警、SIEM 规则ApplicationWAF 规则、输入校验、限流AccessMFA、PAM、最小权限强制Process人工评审、变更控制、审计控制不是写了就算数。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 给出了各框架对例外的具体要求框架例外要求需要留存的文档PCI DSS 4.0补偿性控制工作表约束、目标、控制、验证SOC 2 Type II风险接受证据审批链、理由、评审节奏HIPAA风险分析文档PHI 影响、防护措施、时间线NIST CSF 2.0风险响应决策接受标准、残余风险ISO 27001适用性声明SoA风险负责人批准、评审计划同时 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.pyCLI 实现、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 ATTCK, 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考