构建漏洞异常跟踪系统风险接受、审批链与补偿控制 API 参考与实践指南【免费下载链接】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导读当组织面临漏洞无法在 SLA 期限内完成修复的现实困境时单纯依靠修复流程已经不够——需要一套结构化的漏洞异常与风险接受Risk Acceptance跟踪系统为每次延期修复提供正式审批、补偿控制记录与自动过期机制。本指南以仓库中 api-reference.md 为核心结合 SKILL.md、workflows.md 与 process.py 等源码系统讲解异常状态机、按严重性设计的审批链、最大有效时长、ServiceNow / Archer GRC API 集成、补偿控制分类与完整运营工作流帮助你在支持 PCI DSS、SOC 2、NIST CSF 合规的环境中立即可用的异常治理体系。一、异常状态机Exception States异常记录从创建到生命周期结束必须经历一组明确的、可审计的状态。api-reference 定义了六个标准状态状态说明draft初始创建尚未提交审批pending_approval已提交等待审批链处理approved全部审批人接受风险被正式接受rejected任一审批人拒绝流程终止expired超过过期日期自动失效revoked被手动撤销如补偿控制失效从源码结构看agent.py 中以EXCEPTION_STATES常量固化了这六种状态并且状态迁移有严格约束只有draft状态的异常可以submit_for_approval()提交只有pending_approval状态才能执行process_approval()。revoked状态则对应 Workflow 4 中补偿控制无法在 48 小时内恢复时的强制撤销动作确保任何接受的风险都有明确的出口路径。二、按严重性分级的审批链Approval Chain by Severity不同严重级别的漏洞异常需要的审批层级不同。api-reference 给出了明确的审批链设计严重性审批链CriticalSecurity Lead → CISO → Risk CommitteeHighSecurity Lead → CISOMediumSecurity LeadLowSecurity Lead这一设计在 agent.py 的APPROVAL_CHAIN字典中得到完整实现且审批必须按链顺序执行。源码中的process_approval()会校验当前审批人是否为链上的下一个审批人if approver ! chain[next_approver_idx]否则返回错误只有当所有审批人均通过all(a[decision] approved ...)时异常状态才升级为approved且risk_acceptedTrue任何一位审批人拒绝异常立即进入rejected状态。这种一票否决 顺序审批的设计保证了高风险异常的决策质量和审计完整性。三、按严重性限制的最大有效时长Maximum Exception Duration异常不能无限期有效api-reference 规定了每级严重性的最长有效天数严重性最大天数Critical30High90Medium180Low365对应地agent.py 中的MAX_EXCEPTION_DAYS在create_exception_request()中直接参与计算创建时即按now timedelta(daysmax_days)生成expiration_date。而在数据库层process.py 的create_exception()还会在写入前校验请求的expires_at是否超出该类别的上限超限则直接拒绝创建并打印Expiration exceeds maximum X days for category。即时长约束在 API 入口和数据持久化两个层面都被强制执行。四、异常类别Exception Categories与请求字段除了按严重性管理异常还需要按原因类别区分SKILL.md 定义了五类类别说明最大时长审批层级Remediation Delay补丁已发布但部署受阻30 天Team Lead SecurityNo Fix Available厂商尚未发布补丁90 天Security DirectorBusiness Critical系统无法停机修补60 天VP Engineering CISOFalse Positive并非真实漏洞永久Security AnalystCompensating Control已有替代性缓解措施180 天Security Architectfalse_positive类在 process.py 中被设为 365 天上限接近永久。一份合格的异常请求必须包含完整字段SKILL.md 给出了标准 schemaexception_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, }agent.py 中的create_exception_request()会自动完成生成唯一exception_idEXC-前缀 8 位大写十六进制、根据严重性计算审批链与过期日期、初始化approvals列表与risk_acceptedFalse。五、数据库 Schema持久化与审计异常数据需要结构化存储。SKILL.md 提供了 PostgreSQL 风格的建表语句process.py 中则用 SQLite 实现了同构的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);三个关键设计点审计日志表每次created、approved、rejected、expired操作都会写入exception_audit_logprocess.py 中每次写操作后都会同步插入审计记录满足 SOC 2 / ISO 27001 对证据链的要求。索引优化对status、expires_at、cve_id建索引支撑每日过期扫描与按状态/漏洞查询的高效执行。compensating_controls以 JSON 序列化存储见 process.py 的json.dumps(...)便于将多条控制措施作为一个整体记录。六、实现Flask API 与 CLI 处理脚本6.1 异常请求与审批 REST APISKILL.md 提供了基于 Flask 的核心 API 骨架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} return jsonify({status: pending, id: exc-12345}) app.route(/api/exceptions/exc_id/approve, methods[POST]) def approve_exception(exc_id): ... app.route(/api/exceptions/exc_id/reject, methods[POST]) def reject_exception(exc_id): ...三个端点的职责边界清晰POST /api/exceptions负责完整性校验 类别时长上限校验approve/reject端点接收审批人邮箱、备注或拒绝原因更新状态并记录审批人与时间戳。前置依赖为 Python 3.9 与flask、sqlalchemy、requests、jinja2见 SKILL.md。6.2 CLI 运维工具 process.py针对日常运维与自动化process.py 提供了一套完整参数的命令行接口# 初始化数据库默认 vulnerability_exceptions.db可用 EXCEPTION_DB_PATH 覆盖 python3 scripts/process.py --db vuln_exc.db # 从 JSON 文件创建异常请求 python3 scripts/process.py --create exception_request.json # 审批 / 拒绝异常--approve/--reject --approver拒绝还需 --reason python3 scripts/process.py --approve 3 --approver security-leadcompany.com --notes Controls adequate python3 scripts/process.py --reject 3 --approver cisocompany.com --reason Missing monitoring evidence # 每日过期检查可选接入 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其中--check-expirations的底层逻辑process.py值得注意查询expires_at在未来 14 天内的approved记录预警查询expires_at已过去的approved记录并批量置为expired同时写入审计日志若有 Slack Webhook自动推送X expired, Y expiring soon告警消息返回统计字典{expired: n, expiring_soon: m}供上层调度使用。generate_report()process.py则按状态分组统计并输出完整 JSON 报告其排序逻辑将expired置顶、pending次之、approved第三方便优先处理失效与待审批记录。6.3 引擎演示agent.py如需快速验证状态机逻辑可直接运行 agent.py脚本演示了从创建一条 Critical 异常 → 提交 →security_lead/ciso/risk_committee依次审批通过 → 生成报告的全过程输出包含异常 ID、审批链、最大时长与最终risk_accepted状态可作为单元测试或集成验证的基线。七、GRC 平台 API 集成在企业环境中异常记录通常需要同步到治理、风险与合规GRC平台归档。api-reference 给出了两个主流平台的调用示例。7.1 ServiceNow GRC API# Create risk exception 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}要点调用 ServiceNow 的sn_grc_exception表 REST API使用 Basic Auth-u user:pass关键字段为short_description异常摘要、risk_score风险评分、state初始为draft与本文状态机一致。7.2 Archer GRC API# Create exception record 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}}}}要点Archer 使用session-token进行认证LevelId指向目标表单层级FieldContents以字段 ID → 值的映射结构提交内容。集成建议将系统内部的异常审批结果approved/rejected状态与审批链作为同步触发器向 GRC 平台推送或更新记录形成技术跟踪 治理归档的双轨闭环。八、补偿控制Compensating Controls文档化当漏洞无法直接修复时补偿控制是风险接受的核心证据。api-reference 定义了四类常见补偿控制类别示例Network网络分段、ACL、微隔离Monitoring增强日志、告警、SIEM 规则ApplicationWAF 规则、输入校验、速率限制AccessMFA、PAM、最小权限执行Process人工复核、变更控制、审计SKILL.md 进一步要求每条异常必须从四个维度回答控制有效性Detection检测利用尝试如何被发现Prevention预防哪些屏障降低被利用的可能性Response响应有哪些应急响应程序Monitoring监控哪些持续监控确保控制持续有效template.md 将这四个维度固化为异常请求表单的固定小节并额外包含残余风险评估残余风险等级、被利用后的业务影响、被利用可能性确保每个异常都做到理由 控制 风险三要素齐备。九、核心运营工作流workflows.md 定义了四条贯穿异常生命周期的运营流程与上述 API 和脚本形成完整闭环。9.1 异常请求与审批流程资产所有者识别无法在 SLA 内修复的漏洞提交包含理由与补偿控制的异常请求系统校验请求完整性与类别专属字段系统按严重性/类别路由到对应审批人审批人审查理由与补偿控制审批人批准、拒绝或要求补充信息批准后记录异常与过期日期更新扫描器 / DefectDojo 中漏洞状态为exception_approved写入含完整审批链的审计日志。9.2 每日过期检查流程Cron 查询所有expires_at 今天 14 天的有效异常14 天内到期 → 向请求人发送续期提醒7 天内到期 → 发送带升级机制的紧急提醒已过期 → 状态更新为expired漏洞状态恢复为open向资产所有人与安全团队发送过期通知重新生成 SLA 跟踪以纳入重新开放的发现项。该流程与process.py --check-expirations的 14 天预警窗口、expired状态回写完全对应。9.3 季度异常审查流程按类别与严重性生成全部有效异常报告逐条验证补偿控制是否仍到位复查no_fix类异常对应的厂商补丁是否已发布基于当前威胁态势重新评估风险等级对风险画像发生变化的异常升级至重新审批更新异常记录的审查备注与新风险等级向安全治理委员会提交季度报告。9.4 补偿控制有效性验证流程提取每条有效异常的补偿控制清单逐项验证控制仍在运行WAF 规则查询 WAF API 状态、网络分段核对防火墙规则、监控告警确认 SIEM 规则生效标记补偿控制已退化的异常通知请求人与安全团队控制失效控制无法在 48 小时内恢复 →撤销异常revoked。这一流程正是revoked状态与补偿控制必须持续有效原则的落地执行。十、合规框架映射异常跟踪不是孤立的运维工具而是合规审计的直接证据来源。standards.md 给出了关键标准映射框架异常要求需记录的文档PCI DSS 4.0补偿控制工作表约束、目标、控制措施、验证SOC 2 Type II风险接受证据审批链、理由、审查节奏HIPAA风险分析文档PHI 影响、保护措施、时间线NIST CSF 2.0风险响应决策接受标准、残余风险ISO 27001适用性声明风险所有者批准、审查计划此外NIST SP 800-53 Rev 5 的RA-5(5)特权访问的漏洞监控与扫描要求组织以记录在案的风险接受方式跟踪与管理漏洞异常PCI DSS v4.0 附录 B 定义了无法按原样满足要求时的补偿控制条件ISO 27001:2022 第 6.1.3 条要求风险接受必须经适当权威正式批准CIS Controls v8 的 7.7 子控制要求在规定时间线内修复已检测漏洞并以补偿控制记录异常。本仓库的 SKILL.md 元数据同时映射了 NIST CSF 的ID.RA-01、ID.RA-02、ID.IM-02、ID.RA-06与 MITRE ATTCK 的T1190、T1068便于 Agent 检索与安全编排。十一、开箱即用的异常请求模板template.md 提供了一份可直接分发给资产所有者的标准表单包含漏洞信息CVE ID、Finding ID、受影响资产、严重性、CVSS 评分、发现日期、原始 SLA 截止日异常详情类别五选一勾选、请求的过期日期、无法在 SLA 内修复的详细理由补偿控制检测 / 预防 / 响应 / 监控四个维度风险评估残余风险等级、被利用的业务影响、被利用可能性请求人信息姓名、邮箱、部门、日期审批区审批人专用批准 / 拒绝 / 需补充信息三选一、批准条件、审查备注、审批人签名。表单字段与exception_schema、数据库列一一对应确保纸面流程与系统数据无缝衔接。总结一个可落地的漏洞异常跟踪系统由五个核心部件构成严格的状态机draft → pending_approval → approved/rejected → expired/revoked、按严重性分级的顺序审批链、按严重性/类别双重限制的最大时长、可验证的补偿控制文档以及贯穿每日过期检查、季度审查、控制验证的运营流程。本文结合仓库中的 api-reference.md、SKILL.md、process.py 与 agent.py 给出了从 API 设计、数据库建模、CLI 自动化到 GRC 平台集成、合规审计证据的完整实现路径。借助这套体系安全团队可以在保持业务连续性的同时将每一个无法修复的漏洞转化为有审批、有控制、有期限、可审计的正式风险决策。【免费下载链接】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），仅供参考 构建漏洞异常跟踪系统：风险接受、审批链与补偿控制 API 参考与实践指南
构建漏洞异常跟踪系统风险接受、审批链与补偿控制 API 参考与实践指南【免费下载链接】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导读当组织面临漏洞无法在 SLA 期限内完成修复的现实困境时单纯依靠修复流程已经不够——需要一套结构化的漏洞异常与风险接受Risk Acceptance跟踪系统为每次延期修复提供正式审批、补偿控制记录与自动过期机制。本指南以仓库中 api-reference.md 为核心结合 SKILL.md、workflows.md 与 process.py 等源码系统讲解异常状态机、按严重性设计的审批链、最大有效时长、ServiceNow / Archer GRC API 集成、补偿控制分类与完整运营工作流帮助你在支持 PCI DSS、SOC 2、NIST CSF 合规的环境中立即可用的异常治理体系。一、异常状态机Exception States异常记录从创建到生命周期结束必须经历一组明确的、可审计的状态。api-reference 定义了六个标准状态状态说明draft初始创建尚未提交审批pending_approval已提交等待审批链处理approved全部审批人接受风险被正式接受rejected任一审批人拒绝流程终止expired超过过期日期自动失效revoked被手动撤销如补偿控制失效从源码结构看agent.py 中以EXCEPTION_STATES常量固化了这六种状态并且状态迁移有严格约束只有draft状态的异常可以submit_for_approval()提交只有pending_approval状态才能执行process_approval()。revoked状态则对应 Workflow 4 中补偿控制无法在 48 小时内恢复时的强制撤销动作确保任何接受的风险都有明确的出口路径。二、按严重性分级的审批链Approval Chain by Severity不同严重级别的漏洞异常需要的审批层级不同。api-reference 给出了明确的审批链设计严重性审批链CriticalSecurity Lead → CISO → Risk CommitteeHighSecurity Lead → CISOMediumSecurity LeadLowSecurity Lead这一设计在 agent.py 的APPROVAL_CHAIN字典中得到完整实现且审批必须按链顺序执行。源码中的process_approval()会校验当前审批人是否为链上的下一个审批人if approver ! chain[next_approver_idx]否则返回错误只有当所有审批人均通过all(a[decision] approved ...)时异常状态才升级为approved且risk_acceptedTrue任何一位审批人拒绝异常立即进入rejected状态。这种一票否决 顺序审批的设计保证了高风险异常的决策质量和审计完整性。三、按严重性限制的最大有效时长Maximum Exception Duration异常不能无限期有效api-reference 规定了每级严重性的最长有效天数严重性最大天数Critical30High90Medium180Low365对应地agent.py 中的MAX_EXCEPTION_DAYS在create_exception_request()中直接参与计算创建时即按now timedelta(daysmax_days)生成expiration_date。而在数据库层process.py 的create_exception()还会在写入前校验请求的expires_at是否超出该类别的上限超限则直接拒绝创建并打印Expiration exceeds maximum X days for category。即时长约束在 API 入口和数据持久化两个层面都被强制执行。四、异常类别Exception Categories与请求字段除了按严重性管理异常还需要按原因类别区分SKILL.md 定义了五类类别说明最大时长审批层级Remediation Delay补丁已发布但部署受阻30 天Team Lead SecurityNo Fix Available厂商尚未发布补丁90 天Security DirectorBusiness Critical系统无法停机修补60 天VP Engineering CISOFalse Positive并非真实漏洞永久Security AnalystCompensating Control已有替代性缓解措施180 天Security Architectfalse_positive类在 process.py 中被设为 365 天上限接近永久。一份合格的异常请求必须包含完整字段SKILL.md 给出了标准 schemaexception_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, }agent.py 中的create_exception_request()会自动完成生成唯一exception_idEXC-前缀 8 位大写十六进制、根据严重性计算审批链与过期日期、初始化approvals列表与risk_acceptedFalse。五、数据库 Schema持久化与审计异常数据需要结构化存储。SKILL.md 提供了 PostgreSQL 风格的建表语句process.py 中则用 SQLite 实现了同构的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);三个关键设计点审计日志表每次created、approved、rejected、expired操作都会写入exception_audit_logprocess.py 中每次写操作后都会同步插入审计记录满足 SOC 2 / ISO 27001 对证据链的要求。索引优化对status、expires_at、cve_id建索引支撑每日过期扫描与按状态/漏洞查询的高效执行。compensating_controls以 JSON 序列化存储见 process.py 的json.dumps(...)便于将多条控制措施作为一个整体记录。六、实现Flask API 与 CLI 处理脚本6.1 异常请求与审批 REST APISKILL.md 提供了基于 Flask 的核心 API 骨架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} return jsonify({status: pending, id: exc-12345}) app.route(/api/exceptions/exc_id/approve, methods[POST]) def approve_exception(exc_id): ... app.route(/api/exceptions/exc_id/reject, methods[POST]) def reject_exception(exc_id): ...三个端点的职责边界清晰POST /api/exceptions负责完整性校验 类别时长上限校验approve/reject端点接收审批人邮箱、备注或拒绝原因更新状态并记录审批人与时间戳。前置依赖为 Python 3.9 与flask、sqlalchemy、requests、jinja2见 SKILL.md。6.2 CLI 运维工具 process.py针对日常运维与自动化process.py 提供了一套完整参数的命令行接口# 初始化数据库默认 vulnerability_exceptions.db可用 EXCEPTION_DB_PATH 覆盖 python3 scripts/process.py --db vuln_exc.db # 从 JSON 文件创建异常请求 python3 scripts/process.py --create exception_request.json # 审批 / 拒绝异常--approve/--reject --approver拒绝还需 --reason python3 scripts/process.py --approve 3 --approver security-leadcompany.com --notes Controls adequate python3 scripts/process.py --reject 3 --approver cisocompany.com --reason Missing monitoring evidence # 每日过期检查可选接入 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其中--check-expirations的底层逻辑process.py值得注意查询expires_at在未来 14 天内的approved记录预警查询expires_at已过去的approved记录并批量置为expired同时写入审计日志若有 Slack Webhook自动推送X expired, Y expiring soon告警消息返回统计字典{expired: n, expiring_soon: m}供上层调度使用。generate_report()process.py则按状态分组统计并输出完整 JSON 报告其排序逻辑将expired置顶、pending次之、approved第三方便优先处理失效与待审批记录。6.3 引擎演示agent.py如需快速验证状态机逻辑可直接运行 agent.py脚本演示了从创建一条 Critical 异常 → 提交 →security_lead/ciso/risk_committee依次审批通过 → 生成报告的全过程输出包含异常 ID、审批链、最大时长与最终risk_accepted状态可作为单元测试或集成验证的基线。七、GRC 平台 API 集成在企业环境中异常记录通常需要同步到治理、风险与合规GRC平台归档。api-reference 给出了两个主流平台的调用示例。7.1 ServiceNow GRC API# Create risk exception 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}要点调用 ServiceNow 的sn_grc_exception表 REST API使用 Basic Auth-u user:pass关键字段为short_description异常摘要、risk_score风险评分、state初始为draft与本文状态机一致。7.2 Archer GRC API# Create exception record 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}}}}要点Archer 使用session-token进行认证LevelId指向目标表单层级FieldContents以字段 ID → 值的映射结构提交内容。集成建议将系统内部的异常审批结果approved/rejected状态与审批链作为同步触发器向 GRC 平台推送或更新记录形成技术跟踪 治理归档的双轨闭环。八、补偿控制Compensating Controls文档化当漏洞无法直接修复时补偿控制是风险接受的核心证据。api-reference 定义了四类常见补偿控制类别示例Network网络分段、ACL、微隔离Monitoring增强日志、告警、SIEM 规则ApplicationWAF 规则、输入校验、速率限制AccessMFA、PAM、最小权限执行Process人工复核、变更控制、审计SKILL.md 进一步要求每条异常必须从四个维度回答控制有效性Detection检测利用尝试如何被发现Prevention预防哪些屏障降低被利用的可能性Response响应有哪些应急响应程序Monitoring监控哪些持续监控确保控制持续有效template.md 将这四个维度固化为异常请求表单的固定小节并额外包含残余风险评估残余风险等级、被利用后的业务影响、被利用可能性确保每个异常都做到理由 控制 风险三要素齐备。九、核心运营工作流workflows.md 定义了四条贯穿异常生命周期的运营流程与上述 API 和脚本形成完整闭环。9.1 异常请求与审批流程资产所有者识别无法在 SLA 内修复的漏洞提交包含理由与补偿控制的异常请求系统校验请求完整性与类别专属字段系统按严重性/类别路由到对应审批人审批人审查理由与补偿控制审批人批准、拒绝或要求补充信息批准后记录异常与过期日期更新扫描器 / DefectDojo 中漏洞状态为exception_approved写入含完整审批链的审计日志。9.2 每日过期检查流程Cron 查询所有expires_at 今天 14 天的有效异常14 天内到期 → 向请求人发送续期提醒7 天内到期 → 发送带升级机制的紧急提醒已过期 → 状态更新为expired漏洞状态恢复为open向资产所有人与安全团队发送过期通知重新生成 SLA 跟踪以纳入重新开放的发现项。该流程与process.py --check-expirations的 14 天预警窗口、expired状态回写完全对应。9.3 季度异常审查流程按类别与严重性生成全部有效异常报告逐条验证补偿控制是否仍到位复查no_fix类异常对应的厂商补丁是否已发布基于当前威胁态势重新评估风险等级对风险画像发生变化的异常升级至重新审批更新异常记录的审查备注与新风险等级向安全治理委员会提交季度报告。9.4 补偿控制有效性验证流程提取每条有效异常的补偿控制清单逐项验证控制仍在运行WAF 规则查询 WAF API 状态、网络分段核对防火墙规则、监控告警确认 SIEM 规则生效标记补偿控制已退化的异常通知请求人与安全团队控制失效控制无法在 48 小时内恢复 →撤销异常revoked。这一流程正是revoked状态与补偿控制必须持续有效原则的落地执行。十、合规框架映射异常跟踪不是孤立的运维工具而是合规审计的直接证据来源。standards.md 给出了关键标准映射框架异常要求需记录的文档PCI DSS 4.0补偿控制工作表约束、目标、控制措施、验证SOC 2 Type II风险接受证据审批链、理由、审查节奏HIPAA风险分析文档PHI 影响、保护措施、时间线NIST CSF 2.0风险响应决策接受标准、残余风险ISO 27001适用性声明风险所有者批准、审查计划此外NIST SP 800-53 Rev 5 的RA-5(5)特权访问的漏洞监控与扫描要求组织以记录在案的风险接受方式跟踪与管理漏洞异常PCI DSS v4.0 附录 B 定义了无法按原样满足要求时的补偿控制条件ISO 27001:2022 第 6.1.3 条要求风险接受必须经适当权威正式批准CIS Controls v8 的 7.7 子控制要求在规定时间线内修复已检测漏洞并以补偿控制记录异常。本仓库的 SKILL.md 元数据同时映射了 NIST CSF 的ID.RA-01、ID.RA-02、ID.IM-02、ID.RA-06与 MITRE ATTCK 的T1190、T1068便于 Agent 检索与安全编排。十一、开箱即用的异常请求模板template.md 提供了一份可直接分发给资产所有者的标准表单包含漏洞信息CVE ID、Finding ID、受影响资产、严重性、CVSS 评分、发现日期、原始 SLA 截止日异常详情类别五选一勾选、请求的过期日期、无法在 SLA 内修复的详细理由补偿控制检测 / 预防 / 响应 / 监控四个维度风险评估残余风险等级、被利用的业务影响、被利用可能性请求人信息姓名、邮箱、部门、日期审批区审批人专用批准 / 拒绝 / 需补充信息三选一、批准条件、审查备注、审批人签名。表单字段与exception_schema、数据库列一一对应确保纸面流程与系统数据无缝衔接。总结一个可落地的漏洞异常跟踪系统由五个核心部件构成严格的状态机draft → pending_approval → approved/rejected → expired/revoked、按严重性分级的顺序审批链、按严重性/类别双重限制的最大时长、可验证的补偿控制文档以及贯穿每日过期检查、季度审查、控制验证的运营流程。本文结合仓库中的 api-reference.md、SKILL.md、process.py 与 agent.py 给出了从 API 设计、数据库建模、CLI 自动化到 GRC 平台集成、合规审计证据的完整实现路径。借助这套体系安全团队可以在保持业务连续性的同时将每一个无法修复的漏洞转化为有审批、有控制、有期限、可审计的正式风险决策。【免费下载链接】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），仅供参考