datazen123/network-config-drift-detector

# network-config-drift-detector 确定性代码计算基线与当前 Cisco IOS 风格路由器配置之间的行级差异，并根据真实的 DISA Cisco IOS 路由器 STIG 规则（包含每条规则真实的 CAT I/II/III 严重性评级）检查当前配置，从而计算出加权合规性记分卡。 Claude 负责的实际上是语言任务部分：解释每种差异和 STIG 失效的语义风险，对其进行优先级排序，并起草一份随时可进行修复的报告（包含 POA&M 风格的里程碑）——它从不自行计算差异、分数或决定通过/失败状态。 ## 合规性记分卡与 POA&M 起草 `data/stig_rules.json` 中的每个 STIG 规则现在都带有其真实的 CAT I/II/III 严重性评级，该评级直接对照 [cyber.trackr.live](https://cyber.trackr.live/stig/Cisco_IOS_Router_NDM/2/8) 发布的 Cisco IOS 路由器 NDM STIG 数据进行了验证（在此验证过程中，两个独立的二级来源对某条规则的严重性评级存在分歧——最终以一级来源为准解决，而非任何一种猜测）。`compute_compliance_score()` 使用这些真实的严重性评级将未关闭的发现转化为 0-100 的加权分数。 **准确地说，不夸大其词**：DISA 实际的内部 CCRI 评分方法并未完全公开，因此这*不是*对其的复刻——输入分数的严重性数据是真实且经过验证的；在此基础上的扣分权重（CAT I 比 CAT II 扣分更多）是一个合理、有明确标注的说明性模型，这与本仓库的接口关闭检查所采用的“真实数据，基于其上标注清晰的逻辑”的划分方式相同。 对于每次失败的检查，Claude 还会起草一个简短的 POA&M 风格条目（里程碑 + 优先级层级 - 立即/30天/90天，直接由真实的 CAT 评级映射而来）——这与真实的 RMF/eMASS 行动与里程碑计划 (POA&M) 所使用的产物类别相同，尽管并非严格意义上的 eMASS 格式输出。`verify_findings()` 现在确定性地检查另外两件事：每个失败检查的发现都有非空的里程碑，并且其优先级层级与真实严重性评级的要求相匹配（CAT I → 立即）——弄错这些的发现将以与错误引用相同的方式被标记为 `[NEEDS HUMAN VERIFICATION]`。 ## 为什么会有这个项目 基于真实的联邦拨款数据，通过 USASpending.gov 验证（不仅仅是新闻/网络声明），以及 SecureBine 自己的公开声明，以下有一个方向性真实但尚未在拨款数据中独立确认的信号： - **已确认、经常性、特定于韩国的**：IDIQ `W91QVN17D0038` 涵盖了在汉弗莱斯营和第四区（大邱）的 CCTV/物理安防网络维护任务订单——真实、注明日期的小型企业（SM Global, Cydaptiv Solutions, Image & Information Co., EC Control）任务订单，正好属于本仓库的类别：监控和维护由安全相关基础设施组成的网络。这是本仓库背后已确认的最强有力的单一证据。 - **已报告但未经独立核实**：陆军由 Empower AI 主导的 **Army Transport Edge (ATE)** 现代化项目（约 2700万-4000万美元，跨越韩国 52 个站点的软件定义网络）得到了 Empower AI 自己的新闻稿以及《星条旗报》（2026年2月，“几近完成”，全面旧系统切换目标定于 2026 年 9 月 26 日）的证实——但在 USASpending 上直接搜索无法找到底层的拨款记录，并且截至 2026 年 7 月的一次检查，**SAM.gov 上尚未发布任何后续的运营/监控合同**。本仓库在切换日期之前预见到了这一需求，它并不是指向一个已经获得资金的项目。 - **SecureBine 自己的公开公告**：SecureBine 已公开确认了一项多年期 IDIQ 服务合同，与 GovCIO 合作支持驻扎在汉弗莱斯营的 USACISA-P 需求——这与 GovCIO 自己声明的 USACISA-P 范围（“服务和维护跨联合网络 CENTRIXS-K 的所有 IT 和网络服务”）相符。这尚未出现在 USASpending 的主/子拨款数据中（这是正常的拨款到发布的时间延迟，而不是怀疑一家公司关于其自身合同的公开声明的理由）。（此外在同一项目中已确认：SAIC 和 GDIT 持有/曾经持有实际的 USACISA-P 网络运营任务订单 - 参见 `claude-ops-agent`。） - SecureBine 自己认证的技术合作伙伴具体是 **Cisco 和 Juniper** ——这是本仓库中实际点名的供应商，而不是一个相近的猜测（这是关于 SecureBine 公开网站的一个直接事实，不需要拨款数据验证）。 ## 真实与说明性内容 - `data/stig_rules.json` - **真实的** DISA Cisco IOS 路由器 STIG 规则，从公开的 STIG 参考内容中获取（规则 ID V-215687、V-215669、V-215668、V-215699、V-215704，来自 Cisco IOS Router NDM STIG，V3R8）：确切的规则 ID、标题、要求文本、修复指南、真实的 CAT I/II/III 严重性评级（V-215687 和 V-215699 为 CAT I；其余为 CAT II），以及每个规则真实的 CCI ID 和 NIST SP 800-53 Rev 5 控制映射（例如 V-215687 → CCI-000196 → **IA-5**），已根据 [cyber.trackr.live](https://cyber.trackr.live/stig/Cisco_IOS_Router_NDM/2/8) 验证。 这是真实的 RMF/eMASS 包使用的实际可追溯性链条 —— STIG 发现 → CCI → 800-53 控制 —— 而不是本仓库虚构出来的；现在打印报告中的每个发现都会在 STIG 规则旁边引用真实的控制 ID。 - `data/baseline_config.txt` / `data/current_config.txt` - **说明性的**，为本演示编写的合成 Cisco IOS 语法配置，并非从任何真实设备中捕获。并非每个真实的 STIG 检查都已实现 - `check_inactive_interfaces()` 是一个明确记录的简化项（仅基于配置文本的“接口应处于非活动状态”的代理指标，而不是同样考虑实时运行状态的官方检查程序）。 ## 架构 ``` data/baseline_config.txt data/current_config.txt data/stig_rules.json | | | v v v compute_diff() check_stig_rules() + (real STIG rule IDs (difflib, code-owned) check_inactive_interfaces() and requirements) | | +--- build_payload(): every item gets a stable id (diff:N, ---+ stig:, interface:) ---+ | v Claude explains, prioritizes, drafts remediation commands, and cites a source_id on every finding | v verify_findings() - deterministic, code-owned: does each source_id resolve? does severity contradict a passing check? | +--------+--------+ v v all findings verified any flagged -> ONE bounded correction pass | (Claude fixes only the flagged findings) v v +--- printed report, unverified findings tagged ---+ "[NEEDS HUMAN VERIFICATION]" ``` ## 弥合一个真实的、此前已如实报告的局限性 本仓库早期版本的 README 记录了一种真实的、现场观察到的故障模式：Claude 偶尔会在其文字解释中将两个相近的相关配置变更细节混淆——例如将接口描述的更改归因于错误的接口 ID——即使底层的确定性分类保持正确。这之前是通过人工通读来发现的，这种方式无法扩展，也不是国防部门相关客户会接受的实际保障措施。 `verify_findings()`（纯 Python 编写，经过全面单元测试，无需 LLM 调用）现在对 Claude 编写的每个发现确定性地检查两件事：(1) 它的 `source_id` 是否实际解析为 Claude 所获数据中的真实差异行、STIG 规则或接口——这正是混合错误产生的那类错误，因为混合发现引用了（或未能引用）错误的对象；(2) 所声称的严重性是否与项目的实际状态相矛盾（例如，对实际上已通过的内容引用了 `critical` 严重性）。任何被标记的内容都会获得一次有界修正——仅向 Claude 展示被标记的发现以及原始数据，并要求其仅修复这些内容——然后报告才会定稿。在此修正之后仍然被标记的发现将带有明确的 **`[NEEDS HUMAN VERIFICATION]`** 标记打印出来，而不是作为同等可靠的内容呈现，这样审查者就可以确切地知道哪些行需要二次审查，哪些不需要。 这与 `claude-ops-agent` 的有界工具调用重试中使用的评估器-优化器 / 反思模式相同，只是应用于内容验证而非格式强制执行——基于国防部发布的 **可追溯** AI 伦理原则（完整引用请参见该仓库的 README）：每个发现都可以在代码中追溯到关于它的确切确定性事实，而不是通过要求人工通读整个报告来检验。 - `llm_client.py` - 轻量级提供程序适配器。Anthropic 是本仓库通篇使用的经过测试的后端。包含 OpenAI 和 Ask Sage 适配器以供相同接口使用，但在本仓库中**尚未**使用真实凭据运行过——在验证之前，请将其视为参考代码。 - `drift_detector.py` - 包含差异、STIG/接口检查、payload id 标记（`build_payload`）、Claude 解释调用、确定性验证器（`verify_findings`）以及有界修正过程。 ## 运行说明 ``` pip install -r requirements.txt cp .env.example .env # fill in your own ANTHROPIC_API_KEY export $(grep -v '^#' .env | xargs) python drift_detector.py ``` ## 测试 + CI `test_drift_detector.py` 覆盖了每个确定性函数（差异计算、两种 STIG 检查类型、接口检查、JSON 围栏去除、`build_payload` 的 id 标记、`compute_compliance_score` 的权重和零底限行为，以及 `verify_findings` 的每个分支 - 缺失引用、无法解析的引用、严重性/状态矛盾、缺失 POA&M 里程碑、错误的 POA&M 优先级层级以及通过情况）- 不需要 API 密钥或网络，可在每次推送时安全地进行 CI。`test_drift_detector_properties.py` 增加了 Hypothesis 基于属性的测试——例如，已证明合规分数保持在 [0,100] 范围内，并且当通过的检查翻转为 FAIL 时分数绝不会增加，这是通过数百个生成的严重性混合输入验证的，而不是一个手工挑选的示例： ``` pip install -r requirements-dev.txt pytest -q bandit -r . -x "./.venv" --severity-level medium # security lint, CI runs this too ``` ## 安全说明 - API 密钥仅从环境变量读取，绝不硬编码；`.env` 已被 gitignore 忽略，`.env.example` 仅附带占位符。 - 从一开始就对 Ask Sage 网关的网络调用设置了明确的 30 秒超时（非后来加上去的）。 - 格式错误/非 JSON 的模型响应会引发清晰、可操作的错误（附带原始响应），而不是不透明的 traceback。 - 依赖项已固定版本并具有上限（`>=X,

标签：Cisco IOS, DISA STIG, DLL 劫持, Docker 部署, 大语言模型, 安全规则引擎, 网络运维, 逆向工具, 配置漂移检测