Skip to content

roadmap.md

Latest commit

 

History

History
547 lines (428 loc) · 52.2 KB

roadmap.md

File metadata and controls

547 lines (428 loc) · 52.2 KB
Raw

路线图

原则：解决已被证据确认的问题；实现、部署、验收分别记录。代码存在不等于生产已启用， 隔离回放通过不等于自然事件验收完成。历史规划保留在文末，不再作为当前待办。

运行修复补充（2026-10-30）

服务端 be20c7f60 已在两个 HA 节点滚动部署，前端仍为 ee945af54。 以下为本轮现场验收，不替代后文各方向的独立完成条件。

  • 入库改为最多 64 条一批；进程回查只查询缺少名称的有效连接，并使用进程创建事件的部分索引。 同组 8 个 GUID 的生产查询由约 737 ms、127040 缓冲页降至约 22 ms、35 页。 最新连续 120 秒自然负载发布 19362 条、处理 19566 条（含采样前在途事件），无处理失败； 多次队列归零、测试主机事件时间距当前约 1–4 秒。这不是峰值容量或总体 P95 验收。
  • 图谱改用与事件入库同事务登记的持久待办，生产迟到事件与重投验证通过。 针对旧游标遗留遗漏，增加只读核对和维护重建工具，见 资产图谱。
  • 已按 2026-09-30T07:00Z 至 2026-10-30T07:52:09.367102Z 的保留窗口重建： 扫描 1738031 条网络事件、重建 4189 条边，原 3149 条边完整备份；维护期间原始入库持续进行。 后续同窗核对扫描 1738042 条（包含后到事件），缺失边 0、计数低于窗口观测值的边 0。 计数已按保留窗口重设，不代表恢复了过期删除的全部历史，也不把下界核对当作所有累计计数的精确证明。
  • 重建工具的维护锁、超限/应用失败回滚、原图备份、重复执行不重计、快照后迟到事件衔接均有真实 PostgreSQL 集成测试。 be20c7f60 CI 全部通过；生产六路由浏览器检查无 JavaScript/5xx 错误，图谱实际节点与连线正常显示。
  • Linux RPM 软件清单已补齐，并在 UOS 实机核验；漏洞匹配仍不支持该发行版，前端明确显示覆盖限制。 不把软件采集成功当作漏洞扫描完成。

单分片阶梯负载验证已完成：额外 50/100/200 条每秒短轮完整落库； 400 条每秒出现持续积压，停止后追平，不能算持续容量。瓶颈排查指向数据库读 I/O，仍待优化后复测。 重复 GUID 索引清理已部署（e2984aa67），释放约 2.4 GB，查询与页面回归通过。 清理后 400/s 复测因发布异常、NATS 流领导者切换未通过；200/s 完整落库但积压仍偏高。 尚未证明吞吐提升，继续排查存储 I/O、缓存及部署后基线，详见同一容量报告的复测记录。 随后两节点数据库缓存已由 128 MB 调至 1 GB，主库切到 node1；100/s 与 200/s 短时测试完整落库。 200/s 最高待办降至 21，但存在主库与自然流量变化，尚不能证明单项优化收益；400/s 和持续容量仍未完成。

仍需推进：扩大纳管后的持续、多分片峰值容量验收、独立备份与恢复、容量扩展及分区迁移、依赖备份条件的宿主机维护。 两个 abuse.ch 情报源仍缺 Auth-Key，不能报告新鲜情报已接通；硬件问题按人工选择忽略，不等于修复。

前次基线（2026-10-29）

最近一次现场验收：服务端 b02492c，前端 9b90178，两个 HA 节点均已部署。 这是当日版本记录，不代表后来部署状态；发版时应重新核对实际镜像。

方向 已实现 / 已部署 验收边界与剩余工作
纳管与采集 Linux/Windows Agent、配置下发、升级、进程/文件/登录/网络等采集；流量探针和 syslog 接入 多条路径已有实机证据，并非“只有交叉编译”；具体覆盖与未验证项以 实机矩阵 为准。批量异构纳管仍需验证
检测与降噪 Sigma、情报、UEBA、去重/抑制/关联、复核与批量结案；时序引擎已有实现 合成对拍不验证采集可见性；时序规则是否启用、身份来源是否接通须逐环境验收，见 时序检测、身份关联
AI 研判 只读调查工具、记忆来源约束、覆盖/截断提示、DNS 结构化摘要；每次尝试和逐工具耗时持久化、前端展示；单工具 15 秒超时 已部署并完成隔离真实模型回放；自然事件的新版逐工具记录与耗时仍待积累，结论中仍发现绝对化推断
AI 助手与巡检 Pi 会话、按组只读查询、命令名单/审批、运维待办、定时巡检和报告 保持与事件研判分工；不能用会话成功或模型可用代替业务任务验收，见 Pi 后端
响应处置 结束进程、隔离/解除隔离、审批与审计等控制 实机验证按主机与动作留证；具备自动响应代码不代表生产已开启，也不能因研判置信度高就扩大放行或处置范围
HA、存储与运维 JetStream、Patroni/VIP、滚动发布、检索索引优化、指令历史优化、业务日志归档；备份/恢复工具 最近发布后主备和队列健康；已有数据库恢复实测，不等于整站灾难恢复，见 备份恢复、日志归档
欺骗引擎 独立 DYGK 引擎接入已合并、部署；管理器、修订、运行回报与停止状态已接通 已完成单节点生产回环验收；真实业务入口、故障切换、持久化恢复未由此覆盖，见 引擎说明
导出与外部联动 资产导出、集成身份/API、可靠事件投递和外部工单关联代码已有实现 不再列为从零开发；真实厂商工单创建—回写—结案闭环应独立验收，不能把通用 API 可用当作外部接通
控制台 已修复多处窄屏布局、跳转、空值与卡片展示问题；研判历史支持展开和分页 近期相关页面在 1440/390 宽度验收通过，不代表全站移动端覆盖

最近研判测试说明

  • 9df86e2 上线后的一条自然 DNS 事件：排队约 9.9 秒，执行约 222.3 秒； 模型约 35.5 秒，工具约 186.7 秒。该记录证明查询是这一个样本的主要耗时，不能作为总体 P95。
  • b02492c：索引字段值与完整原文搜索明确区分；保留控制台 UUID/哈希检索语义。 生产只读复查同一十六进制域名前缀，索引查询约 130 毫秒返回 10 条。
  • 使用 10 条真实 DNS 记录的独立测试库、当前 deepseek-flash 完整回放：执行约 28.7 秒， 4 次模型调用、9 次工具调用，工具合计约 166 毫秒；判为可疑，未建议白名单或抑制。 小样本库与生产全量库不可直接比较，不能据此宣称整体提速倍数。
  • 数据库锁测试约 15.01 秒返回查询失败；注入模型失败后再次执行成功，失败和成功两条尝试均保留。 这是隔离执行/重试验证，不是生产调度退避和自然失败恢复验收。
  • 真实落库记录暴露零值字段省略导致的 NaN/undefined；9b90178 已修复并部署。
  • 仍发现“无法承载信道”“出现某些特征立即升级恶意并封堵”等过度绝对措辞。 判定方向正确不代表解释和处置建议全部可信；这应进入下一轮回归，而非把测试标成全面通过。

当前优先级与验收条件

P0-1：研判回归集与证据约束（已开工）

本轮进展：已新增六类脱敏回归集、20 项正反校准与独立建议审查， 离线检查纳入 Go 测试。续测报告： 14 个负对照全部识别，6 个正对照通过 4 个；同批 12 次输出复评自动通过 9 次。 工程复核仍发现真实事实扩写及建议/评分歧义，质量验收未通过，候选提示词未部署。

结构化证据首批实现（本地，未部署）：查询工具的状态、返回条数、截断、血缘缺失和查询范围 由服务端写入 query_evidence，前端研判卡片可展开查看。返回条数截断与单条正文裁剪、DNS 字段省略分别记录，避免把“条数未超限”误解为完整证据。有工具证据时必须提交非空 evidence_claims，编号、字段和值 必须与实际工具返回一致，错误引用只允许修正一次，仍无效则拒绝落库。旧结论兼容。 已补事件级证据编号、事件/资产 ID、process GUID 与 parent GUID，直接取归一化事件列， 可在前端展开核对；引用须与该条事件字段一致，不能借用相邻记录的父进程。字段缺失仍为未知。 这证明的是与存储记录一致，不保证采集真实性或自由文本摘要正确；最近一次采集快照已接入 host_alerts，带接收时间、组件状态和路径；缺失为未知，不回推事发时状态。 已新增只读 process_baseline 工具，按资产与完整程序路径查询规范/旧版路径，记录基线 ID 与首次记录时间； 未命中为 unknown、数据库错误为失败。基线首次记录不能等同于程序刚安装或实际首次执行。 结构化回放探针已使用真实模型验证一个样本： 4 项正反对照通过，两次答案的各 4 项引用匹配；一次自动评分失败，另一次自动通过但工程复核发现工具能力误述。 初版消息兼容性失败记录也保留。工具能力说明现已由生产生成器和离线生成/评分共用，并补齐两个错误能力反例与一个正对照，该轮共 23 项校准。 完整六类复测已完成 12 次生成、23 项校准： 自动通过 7/12；工程复核 7 通过、2 失败、3 待核；负对照 14/16、正对照 5/7，共 6 次评分调用错误。 此前可选引用被省略时，仍发生缺失事实扩写和工具能力误述；精确评分诊断已补：区分完整/独立评分、完成原因、校验类别、超时与 HTTP 状态，且不记录敏感错误正文；历史失败不回填原因。 建议结构已收紧为服务端目录中的 action_codes，生成兼容 actions 文案；无效或与结论不匹配的建议拒绝落库，旧存档仍可读。 结构化建议真实模型验证已完成：12/12 一次通过结构校验、标签匹配，建议文案与服务端目录一致；工程复核 11 通过、1 项措辞待核。 本轮未运行评分器或真实调查工具。关键事实和自由文本推断约束、整体语义门禁仍待完成。质量门禁仍未通过。 补齐有工具证据时的非空引用校验；重研判明确上次摘要不是独立证据或人工确认，前端与通知标记模型判断。 引用要求不证明摘要成立，旧模型评测报告不代表本次变更通过真实模型或生产验收。

非空引用真实复测已完成：12/12 最终结构与标签匹配，1 次使用修正；两次带台账答案分别有 4、8 项有效引用。 工程复核 10 通过、2 失败，两次截断样本仍把无工单扩写为无其他人工核实记录，故语义门禁仍失败。 已补离线评测 generation_attempts 存档，保留首次与修正输出及结构校验结果；本次旧探针首次输出缺失，不回填。

另外修复历史结案来源漏洞：resolved_by 缺失的记录不再被标为分析师结论；仅有结案人、时间、独立备注且非系统/AI 采纳的记录可进入人工参考。 上下文改为带事件 ID 和来源字段的 JSON，并区分有界空结果与查询失败；缺字段的旧记录仍保留在库中，但不当作人工确认。 该修复针对生产上下文来源，未证明此前纯文本离线样本的自由摘要扩写已消除。

摘要范围专项校准已复现评分器漏判：原规则 2 次错误放行，并有输出截断和无效引文。 评分器补否定对象/范围检查，语义输入限模型结论字段，避免将服务端派生字段当作模型虚构；最新专项 7/8 符合预期、无错误放行，1 次输出预算耗尽，整轮未通过。 两条实际失败答案及对应正对照已进入常规语料，当前共 27 项（18 负、9 正）；默认思考模式的完整校准与生成复测仍待完成。

显式关闭评分思考的完整回归已完成：27 项校准通过 25 项（16/18 负、9/9 正），12 次生成结构与标签匹配，自动语义通过 10 次；工程复核 10 通过、1 失败、1 待核。 本轮无评分接口/格式错误，但漏掉两条危险反例，且误判了一条保全建议；不改默认评分模式。新增 -judge-no-thinking 仅为显式实验选项，两个评分阶段配置一致并入报告，生成器参数保持生产默认。 摘要仍有无工单扩写与查询缺口原因混淆，语义门禁未通过。

历史人工案例另发现跨组引用缺口：同规则查询原先可带入别组和混合组备注。现已按当前事件完整资产的现有归组限制，并要求整个历史案例都在范围内；未知资产归属不做全局回退。 独立 PostgreSQL 回归已先复现、再验证修复，涵盖组外/混合组/未分组/未知资产、转组刷新及明细截断不缩小完整范围；Go 全量单测、build、vet 通过。此结论仅覆盖历史案例范围，不代替全部调查工具的组隔离审计或摘要语义验收。

四个只读调查工具也已复现并修复全局读取缺口：本轮独立 Engine 绑定内部 incident ID，事件/血缘 SQL 限组，资产告警/基线先检查范围，未绑定或未知归属拒绝全局回退。 PostgreSQL 回归覆盖两种事件搜索、组外祖先/子进程、未分组及无资产记录、组外资产参数、模型伪造范围参数、同组正常基线、逐次调用转组刷新，以及共享 Engine 连续处理不同组事件不串范围。 每轮研判记录事件资产与归组快照，在后续模型调用、工具范围查询及落库前复核；发现变化则本轮失败，不保存旧结论、不触发结果回调。最终落库事务依次锁定事件、既有关联告警及其资产，再核对快照，使这些关联与归组在检查后至提交间保持稳定；模型推理期间不持锁。四个工具实际返回的资产，以及已提供历史案例的相关资产，也记录引用时的归组：转组或删除会中止本轮，最终事务一并锁定；不引用的同组资产不加入锁集合。仍不覆盖两次检查间转组后又转回、历史案例读出后新增或改挂告警，以及成功提交后的历史结论撤销；不能作为整个权限生命周期已闭环的证明。

否定范围与缺口原因修正的完整回归已完成：默认评分思考配置，27 项校准通过 21 项（14/18 负、7/9 正），12 次首次生成结构及标签匹配；自动语义检查与工程复核均为 10 通过、2 失败。两次查询不完整样本未再出现目标扩写；两次多客户端样本暴露固定建议缺少分别核实客户端的要求，已在后续本地代码补齐，待真实复测。评分另有四次输出故障与两次正对照误判，门禁未通过。完整报告已核验，临时进程与远端文件已清理。本轮仍使用旧评分器，失败评分原文不可恢复；新增 judge_attempts 留证仅适用于之后的评测。

客户端核实建议对照按收尾要求中止，保存 4 项校准与 1 次对照，未完成计划的 8 次对照。校准匹配 2/4：一项正对照因未显式声明记录非全量被拒，另一项负对照在 8192 输出预算下以 length 结束、正文为空。原始评分和终止原因已留存；不能把部分结果视为新建议通过验收，也不据此切换生产评分配置。

当前问题：精确引用全部匹配仍不能约束摘要；必须按证据来源拆分可验证事实与模型推断，不能把引用通过作为自由文本真实性保证。 已将匹配的证据引用生成为服务端字段摘录，覆盖返回计数、截断、基线首次记录、采集快照和父进程 GUID 等边界；前端独立展示，摘要与攻击链仍标为模型判断。 此改动只建立可核对的字段展示，不修改自由摘要，不能据此解除语义发布阻断。组件浏览器回归覆盖 390/1440 宽度、多条摘录展开收起、长文本与旧结论/等待/错误态；修复了大量摘录把摘要挤出首屏的问题。验证使用合成数据，不代替完整页面、生产链路或真实模型语义复测。引用存在不等于推断成立。 评分分歧仍单列复核，不通过放宽规则或挑选最好一次来解除发布阻断。

最小交付：

  1. 在仓库中保存脱敏样本、证据覆盖范围和预期边界，至少覆盖：共享 CDN 但应用未知、 AI 记忆唯一依据、查询截断/超时、多个客户端混淆、明确人工授权维护、明确恶意行为。
  2. 每个样本分别评估 verdict、事实引用、未知事项和 actions；断言语义边界，不比较整段固定措辞。 证据不足时不得升级为已证实，也不得扩大到网段/域名族放行或处置。
  3. 修正已发现的绝对化推断，同时保留良性维护对照和恶意对照，避免简单地“全判可疑”。
  4. 分开离线确定性测试与显式启用的真实模型评测；记录模型、版本、调用用量和完整失败结果。 密钥、生产凭据及未脱敏日志不进入仓库；普通 CI 不依赖真实模型密钥。

完成条件：六类样本可重复执行；真实模型运行有明确通过/失败记录，不能只报告最佳一次； 违规放行/处置建议或无依据的事实断言会使对应样本失败。通过不等于已经证明整体准确率。

校准语料复核补充：mixed_clients/weak_branch_investigate 原正对照未完整满足本案例 rubric，不能将旧运行对它的拒绝全部归为评分器误判。已对齐正负对照的记录范围与逐客户端核实建议，仅保留弱线索后补证/隔离的差别；历史报告不变，新语料待真实校准，门禁仍未通过。见语料修正说明。

修订语料后的建议对照完整结束：4 项校准匹配 3 项，仍漏判“没有记录”扩写为“未采集”；8 次固定答案对照中，新建议 3 次通过、1 次评分截断，旧建议 1 次按预期拒绝、2 次未识别缺口、1 次截断。评分理由把必要核实范围不足视为不影响安全性，与案例 rubric 不符。工件完整性已核验，不能据此放行语义门禁；后续本地代码已统一完整评分与建议评分对安全性和必要覆盖的要求，并加入只差一条建议的新旧答案正反对照，当前共 29 项（19 负、10 正）；单测、离线语料检查与相关静态检查通过，新版真实校准未完成，仍须独立复核事实范围。

必要调查覆盖评分修正后的完整回归已结束：29项校准匹配23项（15/19负、8/10正），12次首次生成结构与标签匹配，自动语义7/12；工程复核10通过、1失败、1待核。多客户端必要覆盖对照已按预期区分，但授权维护第2次虚构“精确业务归属”；共8次评分截断，两个正对照另有工具建议歧义。完整性核验通过，不等于语义门禁通过。临时进程与远端文件已清理，尚未提交或部署。

后续本地修正：将精确操作授权支持的单次结案与需要业务归属的长期放行分开，禁止由获批补写业务归属；新增真实失败/仅修正归属短语的正反对照，当前共31项（20负、11正）。同时消除两个正对照及其事实负对照中的工具建议歧义，并将裁剪因果正对照改为字段未提供、原因未知。旧运行工件不变。修复评测 CLI 测试写死旧语料数量的问题，按实际输入核对报告、调用和失败总数；相关单测以 -count=1 重跑通过，离线31项语料、全量构建和 go vet 通过。新版真实复测尚未完成，不作为发布通过依据。

针对完整回归8次评分截断，评测工具新增显式 -judge-max-tokens，完整/建议评分统一使用并记录预算，默认8192不变；生成配置与超时不变，不自动重试。无缓存测试验证默认与16384请求、报告配置一致，以及非法预算无文件或请求副作用；构建、静态检查通过。更高预算尚未真实校准，不能宣称评分截断已解决。

本轮收尾状态（2026-10-29）

实现、回归测试及评测证据一并归档，尚未部署生产，P0-1 语义验收仍未通过。 授权范围修正与16K预算回归 按收尾要求停止：31项计划校准完成27项，其中25项符合预期；12次计划生成保存8次。 报告共36行，无终态 summary；已核对远端与本地摘要，独立评测进程和临时文件已清理。 新增授权范围正负对照均符合预期，但新提示词下的授权维护生成尚未完成，不能据此宣布问题闭环。 两项校准解释争议、通用建议措辞的评分分歧及独立人工复核仍待处理。 提交前全量 Go 单测、build、vet、相关 Go 格式检查和 Web build/lint 通过；lint 有既有警告。 集成测试与浏览器组件验收的范围见回归文档，不将其扩大为生产验收。

2026-11-02 补充：针对 engineering-review.partial.json 暴露的 verify_source 通用角色用语歧义（单主机事件被评分器误读为声称存在“各客户端”或“转发器”），已将服务端建议目录 verify_source 收紧为“核实本事件实际涉及的资产、主机或客户端来源……涉及多个对象或经中间节点转发时，不把单一对象或中间节点的归属结论套用到其他对象”，并在 judgePrompt 中明确防扩写限定语不构成额外实体存在断言；同时补齐前端 VerdictCard.tsx 对全部 10 个服务端 action_codes 的中英文标签与色彩映射，与通知卡片一致。离线 31 项语料及单测通过；完整 6×2 真实模型复测与独立人工复核仍待后续单独完成。

P0-2：生产自然研判验收与失败可见性

问题：执行明细已上线，但尚无足够自然样本说明生产延迟、失败原因与重试行为； 已经具备的队列/基础设施告警不能代替研判失败的运营反馈。

交付与验收：

  • 按首次/新增证据/重开分组，记录样本数、排队、模型、工具和总耗时；先建立基线，再定 SLO， 不用一条回放数据算 P95，也不先提高并发。
  • 逐次核对执行记录、事件状态、前端运行提示与心跳失效；自然失败恢复样本不足时明确留空。
  • 核查现有告警/待办覆盖，补上持续失败、长期无进展的研判提醒；重复提醒要合并，恢复后能解除。 保持组权限，不自动隔离、不自动改写历史结论、不新增未经配置的通知目标。
  • 根据工具明细优化已证实的慢查询。首次观察到的事件时间至 incident 创建约 11 分钟差距另行追踪； 缺少接收入库时间证据，尚不能归因于采集、时钟、队列或关联，更不能计入 AI 排队。

完成条件：生产样本与指标可对账；失败/恢复在受控测试中可见且不重复制造待办； 自然事件缺失的验收项仍标未验证。并发调整必须由排队与资源瓶颈证据驱动。

生产自然样本基线与慢查询修复（2026-11-02）

对生产库（10.1.1.198）累计 461 条自然 triage_runs 与 3,163 次工具调用完成对账基线：

触发类型 (trigger) 状态 (status) 故障分类 (failure_kind) 样本数 排队 P50 / P95 执行 P50 / P95 平均模型耗时 / 调用数 平均工具耗时 / 调用数
initial（首次） succeeded — 112 19.9s / 93.8s 41.9s / 93.6s 28.1s / 3.8 次 19.4s / 7.0 次
initial（首次） failed model_or_verdict 4 54.0s / 365.4s 56.1s / 100.3s 49.0s / 5.0 次 7.1s / 5.5 次
initial（首次） interrupted canceled（滚动重启） 6 17.8s / 24.4s 46.3s / 52.3s 38.8s / 3.2 次 7.5s / 8.7 次
evidence（新增证据） succeeded — 281 14.8s / 47.0s 41.5s / 93.8s 32.6s / 3.2 次 13.2s / 6.7 次
evidence（新增证据） failed model_or_verdict (6) / timeout (1) / persist (1) 8 21.8s / 242.7s 59.3s / 180.0s 57.6s / 4.9 次 9.6s / 7.8 次
evidence（新增证据） interrupted lease_replaced 2 47.6s / 57.8s 64.9s / 71.1s 36.7s / 2.5 次 19.0s / 8.5 次
urgent（高危加急） succeeded — 45 29.9s / 642.9s 56.2s / 101.2s 40.3s / 3.7 次 18.8s / 8.4 次
urgent（高危加急） interrupted canceled（滚动重启） 3 109.9s / 121.0s 43.3s / 62.6s 40.1s / 3.0 次 6.8s / 6.7 次

逐工具调用统计（3,163 次）：

  • host_alerts：成功 469 次（P50 11 ms、P95 29 ms、最大 66 ms），错误 1 次。
  • process_baseline：成功 186 次（P50 10 ms、P95 26 ms、最大 39 ms），错误 1 次。
  • process_lineage：成功 973 次（P50 55 ms、P95 316 ms、最大 2,146 ms），错误 1 次。
  • query_events：成功 1,436 次（P50 2,144 ms、P95 10,011 ms、最大 14,825 ms），错误 96 次（其中近 48 小时 44 次稳定卡在 10,001–10,014 ms 的 eventsearch.Search 三分之二超时预算）。

已证实的慢查询根因与修复：

  1. triage 工具 query_events / process_lineage 与 correlate.findByLateral 的 HasAssetWith 子查询计划退化：
    • 根因：toolQueryEvents 原先通过 entevent.HasAssetWith(scope)（events.asset_id IN (SELECT id FROM assets WHERE group_id = ...)）过滤分区表 events。生产库单日分区达 362 万行时，PostgreSQL 优化器无法穿透子查询估算组内资产基数：在 eventsearch.Search 第 1 步（OFFSET 9999 LIMIT 1）选择 Index Scan Backward using events_p20261101_ts 倒序扫过跨组全部 362 万行（实测耗时 31,268 ms）；在第 2 步（Where(m.scan())）选择 Hash Join + Parallel Seq Scan，对全表 362 万行先算 openxdr_event_search_text(raw) 再关联 assets（实测耗时 221,073 ms）。
    • 修复：新增 Engine.incidentEventScope 先查出本事件允许范围的资产 UUID 列表，再以 entevent.AssetIDIn(ids...) 过滤 events（与 /api/events 的 s.event() 口径一致），并在 correlate.findByLateral 中同样先解析同组对端资产列表 event.AssetIDIn(peers...)（单资产组直接短路返回）。生产库 EXPLAIN (ANALYZE, BUFFERS) 实测验证优化器直接走 events_p20261101_asset_id_ts 复合索引：第 1 步由 31,268 ms 降至 5.2 ms（缓冲页由 3,522,069 页降至 26 页），第 2 步由 221,073 ms 降至 168.5 ms。
  2. 只读视图 ip_infos 与跨节点指令通道回归核验：
    • PR #21（8edc57601）将组只读视图 ip_infos 改为最近 7 天时间界定 + 禁用 JIT 编译并完成老分区冷归档后，生产实测 SELECT count(*) FROM group_<uuid>.ip_infos 由 29,164 ms 降至 74.7 ms，Pi 巡检不再生效 canceling statement due to statement timeout。
    • 部署跨节点旧指令流驱逐（openxdr.evict.<agent_id>）与 gRPC HTTP/2 keepalive（60add936c）后连续观察 26 小时，21 台在线主机累计下发 147 条 exec 指令全部 succeeded，failed = 0、sent 悬挂 = 0。

P1：覆盖、恢复与业务接通

工作 开始条件 完成条件
采集和检测实机补验 从实机矩阵中挑与实际部署相关的未验证格子，使用授权测试主机 原始事件、规则命中、关联/研判各层留证，同时跑良性对照；不把一个系统通过推广到所有系统
批量与异构纳管 明确客户/内部使用的系统与规模 干净安装、升级、断网重连、失败回滚与证书身份验证；失败可定位，不能只统计安装成功数
备份和业务恢复 核实已有备份目的地、保留策略、最近恢复报告；另行安排隔离环境/维护窗口 验证数据、配置、密钥、队列及应用业务恢复，实测恢复时间与数据损失窗口；数据库导入成功不等于整站恢复
欺骗引擎正式接入 明确业务入口和运行策略，先观察后评估处置 入口事实、事件回传、停止、断连补传、版本回退及持久化恢复逐项通过；回环访问不替代外部入口验收
外部工单与身份来源 有真实目标系统、权限和配置 事件投递去重、工单回写、失败恢复及权限边界验证；目录身份只按强证据关联
情报订阅 核实目标源当前接口及所需密钥 同步成功、失败原因、数据有效期和碰撞可核对；无密钥时明确不可用，不以 0 条伪装成功

P1 实机补验与生产状态核对（2026-11-02）

  • 采集和检测实机补验（已完成真 Linux 与 Win10 测试机全项矩阵补验，见 validation/replay/README.md 第七轮）：
    • 真 Linux（openxdr-test-linux，Debian 12，内核 6.1.0-54-cloud-amd64，eBPF + AF_PACKET + fanotify）：实机补齐并留证网络入站（SYN_RECV→ESTABLISHED 归属监听进程）与 UDP 出站（kprobe udp_sendmsg 归属发起进程）、DNS（AF_PACKET 问答配对、NXDOMAIN rcode_id=3、按源端口归属进程、出站 TCP 连接回填 dst_endpoint.hostname）、eBPF exit_group 退出码与运行时长（exit 7 → exit_code=7, duration_ms=2001）、平凡退出抑制（suppressTrivialExit=true：<2s 且 exit 0 抑制 Terminate，<2s 非零退出码 exit 9 与 ≥2s exit 0 照常发 Terminate 并复用启动 GUID），以及生产宿主机群的容器归属（Docker 12 位容器 ID + 容器名，PVE lxc / qemu VMID + 名称）。
    • Windows 10 Pro 22H2 测试机（OPENXDR-TESTWIN，build 19045，ETW）：排查并修复 agent/src/collector/windows.rs 在 EVENT_PROCESS_STOP 分支漏解 ExitCode 的真实缺陷（此前 Windows Terminate 事件 exit_code 恒为空，导致 suppressTrivialExit 在 Windows 上完全不触发，连带每 30 秒上报 persistwatch 的 4 条 <1s powershell.exe / conhost.exe 正常退出事件）；修复并升级至 653999b7af63... 后，实机四组对照（<2s exit /b 0 抑制、<2s exit /b 9 不抑制、3s exit 0 不抑制、2s exit 7 不抑制）全部通过并留证。
  • 批量与异构纳管（已在生产 4 类异构系统与双平台在线升级中验证）：
    • 生产环境当前在线纳管 21 台主机，覆盖 4 类操作系统与内核形态：Debian 12（17 台，含 cloud 6.1 与标准 6.1 内核）、Debian 13 / Proxmox VE 9（2 台，7.0.2-6-pve 内核）、统信 UOS Server 20（1 台，4.19.0-amd64-server 内核，自动选择 netlink + fanotify）、Windows 10 Pro 22H2（1 台，build 19045）。
    • 实机验证 Linux（4bf965743c44...，覆盖 20 台 Linux 资产）与 Windows（653999b7af63...，覆盖 OPENXDR-TESTWIN）经 gRPC 下发分块、SHA-256 校验、--version 自检、退出码 75 原子替换重启及跨节点指令流重连的完整闭环。
  • 外部工单与身份来源（身份来源已在生产验证，外部工单待目标系统接入）：
    • 目录身份来源：生产已接入 Authentik（https://auth.yuzhian.com.cn），累计自动同步成功 1,258 次（failed = 0），物化 584 个目录身份（identities） 与 584 条身份关联边（identity_links）。
    • 外部工单：生产尚未配置外部工单系统（integrations = 0、external_tickets = 0），保持未验证状态，待有真实目标工单系统与凭据时再行接入。
  • 情报订阅（已在生产验证免密钥源同步、碰撞与需密钥源显式边界）：
    • feed:et-compromised（EmergingThreats 失陷 IP）：生产定时同步正常，当前有效指标 542 条 IP（有效期至 2026-11-03），累计在生产流量与连接事件上产生 24 次真实情报碰撞命中。
    • feed:feodo（abuse.ch Feodo Tracker C2 IP）：生产定时同步正常，当前有效指标 5 条 IP。
    • 需 Auth-Key 的 urlhaus 与 threatfox 在未配置密钥时保持明确不可用，不以 0 条伪装成功。
  • 欺骗引擎与整站恢复演练（保持边界，待维护窗口与外部入口条件）：
    • 生产已登记 5 条 decoy_deployments 记录，外部业务入口引流与整站跨机灾难恢复演练需独立隔离环境与维护窗口，不在生产业务实例上直接做破坏性注入。

P2：有需求和条件再启动

  • macOS Agent：先具备开发/CI/实机环境和明确用户需求。
  • 旧 Windows 与更多发行版覆盖：按真实部署需求排序，不承诺未验证兼容性。
  • 新时序规则、身份来源及边界设备接入：以真实数据和误报回测为前提，复用已有引擎。
  • 全站移动端一致性：沿用户常用流程补验，不把近期几个页面通过当作完成。

暂不做

多租户 SaaS 化、按业务包继续拆微服务、全量 PCAP 长期存储、自研检测规则语言。 当前也不推进“因为模型更快就放开自动响应”或“因为已有时序/身份引擎就全面启用所有规则”。 这些选择改变前，须有实际需求、成本和验收依据。

执行顺序

先推进 P0-1 的可验证事实与证据引用，用已有回归集验收；同时只读观察 P0-2 的自然样本。 两者有稳定证据后，按实际风险选择 P1 的恢复演练或采集补验。不会先新增可视化编排器、 重写研判架构或扩大自动处置权限。后续每个条目独立提交、验证，并补充部署与验收日期。

历史规划（仅作背景）

下面保留早期快照、完成记录和当时的已知缺口。旧日期的容量、规则/用例数量、 “未部署”“未验证”和优先级只代表当时状态；与上文或当前实现冲突时，不用它们安排新任务。

展开 2026-10-17 及更早的路线图记录

现状快照（2026-10-17，v0.1.0）

  • 纳管：按组接入令牌一行命令装 agent（主机绑定证书）、agent 自动升级、运维文档导入与 SSH 纳管
  • 采集：Linux 进程启停（eBPF/netlink/轮询三级降级 + username + exe SHA-256）、 敏感文件（fanotify FID 优先 / inotify 递归兜底）、持久化点、登录（wtmp/btmp）、网络出站（eBPF）、 内核模块；Windows 进程启停（ETW）、文件监控（RDCW）、持久化点（注册表/服务/计划任务/ Defender 排除/IFEO/COM/WMI）、Security 与 PowerShell 日志、网络出站（ETW）； 全流量探针（DNS、TLS JA3/JA3S + 证书元数据、HTTP）；syslog
  • 检测：Sigma 引擎（热重载）42 条规则、三类 IOC 情报碰撞与公开订阅、UEBA 首次出现
  • 降噪：去重 → 抑制 → 关联 → AI 研判 → 复核口径 → 低危良性到期自动结案
  • AI 助手与巡检：后台运行的对话、命令高风险名单 + 阻塞审批、按组只读查库、运维待办、 事件与待办「交给 AI」、cron 预设巡检与 HTML/PDF 报告
  • 响应：结束进程、主机隔离（mTLS + 按主机绑定证书）
  • 平台：三角色 RBAC + 组权限、审计、JetStream 集群、Patroni/Keepalived 跨宿主机高可用

v0.1.0 之后的已知缺口

  • Windows 实机验证：采集与 WFP 隔离只在 CI 交叉编译把关，缺系统的实机回放（见 validation/replay/ 矩阵）
  • 新主机接入实测：一行命令接入与 SSH 纳管只在少量主机上跑过，缺批量与异构系统验证
  • 模型能力：弱模型在多对象、长上下文下会跑偏；会话历史未做压缩（较早的工具结果超阈值折叠，见 pi-backend.md）；费用预算已有按组每日 token 限额
  • 复核积压：需人工复核的事件仍靠人逐个结案，缺批量结案与按规则归并的体验（事件页按规则 + 主机归并、整组或多选批量结案，见 detection.md）
2026-08-09 快照（历史）
  • 采集：Linux 进程启停（eBPF/netlink/轮询三级降级 + username + exe SHA-256）、 敏感文件（fanotify FID 优先 / inotify 递归兜底，fanotify 路径带进程上下文）、 持久化点目录（systemd unit / cron / .ssh）、登录（wtmp/btmp）；Windows 进程启停 （ETW + Win7 PEB cmdline 兜底 + exe SHA-256）、文件监控（RDCW）、持久化点 （注册表 Run/Startup/服务/计划任务，删除带旧值）、登录（4624/4625 含失败原因码）； 全流量探针（DNS 含应答与 rcode、TLS、HTTP 元数据 + JA3/JA3S + 证书元数据，仅 TLS ≤1.2）；syslog
  • 检测：Sigma 引擎（热重载）41 条规则、三类 IOC 情报碰撞（IP/域名/哈希； TLS 指纹 JA3/JA3S 走哈希通道）
  • 降噪：去重 → 抑制 → 关联（血缘/时间窗/横向移动）→ AI 研判 → 通知阈值
  • 响应：结束进程、主机隔离（mTLS + 按主机绑定证书）
  • 运营：概览漏斗、事件检索、规则/情报/抑制/资产/审计页、三角色 RBAC

P0 —— 下一步就做

1. Windows 采集对称性 ✅ 已完成。 注册表 Run/RunOnce/Winlogon 与 Startup 目录快照 diff。仍缺：服务与计划任务持久化点 ✅ 已补齐（见附录 P1-6）。

2. 登录事件采集 ✅ 已完成。 Linux：wtmp/btmp 增量读；Windows： Security 日志 4624/4625 订阅（Security-Auditing 的 ETW provider 是受保护 通道，Event Log API 是正路），滤掉机器账号与服务会话。两侧同出 OCSF 3002。 ✅ 爆破得手升级已完成："窗口内 N 次失败后一次成功"在 ingest 侧检测 （成功登录稀少，回查一次库即可，无需引擎状态），合成 critical 告警 xdr:bruteforce-success，按用户维度隔离，Linux/Windows 通用。

3. 事件检索规模化 ✅ 索引已完成（pg_trgm GIN）。 events 表按时间分区 ✅ 已完成：生产到了 78 GB / 7800 万行，改为原生按天范围分区， 保留期清理变成退役日分区，老库用 cmd/eventpartition 在线迁移，见 event-partitioning.md。

4. 检测面对拍验证 —— 合成回放 ✅ 已完成，实机待环境。

validation/ 语料 + cmd/detectcheck：88 个用例取自 Atomic Red Team 的真实 命令行，回放过引擎，判定标准是"命中的规则必须标了该技术"。已进 CI。

第一次跑出 14 个问题，全部修完，其中值得记住的三类：

类别 实例 教训
规则匹配不到真实命令 vssadmin delete shadows 漏了 .exe 变体，一条 critical 勒索规则形同虚设 规则里别写命令名，写动作
完全没有规则 LSASS 内存转储、/etc/shadow 读取 凭据窃取这么核心的手法之前是空的
抓到了但没标 python 反弹 shell 命中却未标 T1059.006 覆盖矩阵会因此少算，与"标了抓不到"同样有害

仍需实机：合成回放绕过了采集层，验证不了"ETW/inotify 是否真的报了这个 动作"。需要 Linux + Windows 各一台可跑攻击模拟的测试机。

P1 —— 看得见的价值

5. MITRE ATT&CK 映射 ✅ 已完成。 引擎解析 Sigma tags，40 条规则 全部打标，/api/attack 出覆盖矩阵（含"有规则但无数据源"的差额）。

矩阵第一次跑出来就暴露了缺口，已补三条（删卷影 T1490、远程执行 T1021.002、 数据打包 T1560.001）。仍然全空的战术：initial-access、reconnaissance、 resource-development、exfiltration（仅间接覆盖）。前两个本质上需要边界设备 日志（邮件网关、WAF、VPN），属于接入面而非规则问题——等有真实环境再说， 不为假想数据源写规则。

6. incident 报告导出 ✅ 已完成。 GET /api/incidents/{id}/report 输出 Markdown，界面一键下载。渲染是纯函数，脱库单测。

7. AI 研判升级为工具调用 ✅ 已完成。 研判可调用 query_events / process_lineage / host_alerts 主动查证；误报反馈已回流进上下文； 曾开放为对话式狩猎（含 AI 起草规则落盘），2026-10-17 删除：与 AI 助手 （Pi 会话，可按组只读查库、按名单执行命令）完全重叠且无人使用。

8. agent 配置下发 ✅ 已完成。 配置存在资产上，随 Register 响应下发， agent 断线重连本就会重新注册，因此不需要热更新通道也不需要新 RPC。 可调：文件监控目录、三个采集开关。坏配置一律退回内置默认—— 让 agent 变瞎比配置不生效严重得多。

P2 —— 时机到了再做

9. UEBA 首次出现 ✅ 已完成。 (资产, 可执行文件) 基线表，首次入表即 首次出现，合成 low 告警 xdr:new-process 进关联管道。学习期按资产从基线 最早记录起算（默认 7 天）——新资产、新部署、重启都先安静学习，无需额外 状态就避开告警风暴。断点存在基线表里，重启不回放历史。 外连基线偏离仍不做：信噪比不够，等首次出现在真实环境里证明自己再说。

10. 自动响应 ✅ 已完成。 研判钩子：verdict 为 malicious 且置信度 达标（默认 90）→ 对 incident 涉事资产下发隔离。保险：显式开启 （AUTO_RESPONSE_ENABLED，仍受 RESPONSE_ENABLED 约束，隔离真执行）、 主机白名单（AUTO_RESPONSE_EXEMPT）、每次决策含跳过都进审计。 同一 incident 同一资产只动一次，重开重判不重复隔离。

11. agent 独立网络采集 ✅ 已完成（eBPF 模式）。 tracepoint sock:inet_sock_set_state 抓 TCP 进 SYN_SENT（本机主动出站，必然在发起 进程上下文里），带 pid → 进程 GUID，网络事件直接挂进血缘。同目标 60s 采样去重，loopback 不报。conn_tuple 与 sensor 同格式，横向移动关联与 现有网络规则零改动复用。仅 eBPF 模式提供；netlink 模式不做—— proc connector 没有网络事件，为它单开轮询不值。

  • macOS agent（Endpoint Security Framework，需 Mac 开发环境）

不做

  • 多租户 / SaaS 化——目标用户是自建 SOC 的团队，租户隔离用"每客户一套"解决。 为不存在的 SaaS 生意把每张表加 tenant_id，是给所有查询上税。
  • 按业务包拆成独立微服务仓库——server 已能作为多节点 gateway/worker 水平扩展；继续把每个包拆成独立部署只会增加版本与网络债，当前没有收益。
  • 存 PCAP 全包——磁盘无底洞，会话元数据 + 按需取证是行业共识。
  • 自研规则 DSL——Sigma 生态就是护城河，兼容它而不是发明方言。

工程债（随手清）

  • sensor 侧尚无 JA3S / 服务端指纹 ✅ 已完成（ServerHello→JA3S，入情报碰撞）
  • Windows ETW 采集无文件哈希 ✅ 已完成（设备路径→Win32 路径转换后哈希生效）
  • 前端无移动端适配（SOC 大屏优先，低优）

附：后续工作详细规划（2026-08 代码核实版）

以下规划基于对采集端与 server 全量代码的逐项核实（结论与证据见 docs/collection.md 与 docs/events.md）， 按"缺口严重度 × 工程成本"排序。P0 与 P1 已全部完成（2026-08-09， 验证：cargo fmt/clippy/test、go build/vet/test、sigmacheck、detectcheck 全过）。

P0 —— 修正确性缺陷 ✅ 全部完成

  1. 补 Linux 进程事件 username ✅ mod.rs:185 username_of：/proc status 读 uid → /etc/passwd 解析（带缓存），eBPF/netlink 路径已接入。
  2. 修 eBPF 降级链 ✅ eBPF 失败 → netlink → 轮询逐级回落 （linux.rs:39-51）；agent/Cargo.toml 错误注释已修正。
  3. Windows ETW 哈希路径转换 ✅ windows.rs:95 to_win32_path （QueryDosDeviceW 映射），exe SHA-256 真正生效。
  4. persistwatch 删除告警 ✅ 注册表值与 Startup 文件删除均上报， 删除事件带旧值内容。
  5. 文档对齐代码 ✅ docs 文档系统重建（见 docs/README.md）。

P1 —— 补采集面缺口 ✅ 全部完成

  1. Windows 服务与计划任务持久化点 ✅ persistwatch.rs:130,179： 服务快照（ImagePath+启动类型）与 Tasks 目录递归快照，增/改/删全报。
  2. 进程退出事件（双平台） ✅ netlink PROC_EVENT_EXIT（含 exit_code）、 ETW Stop（ID 2）、轮询消失 pid、eBPF sched_process_exit；退出事件 复用启动 GUID（mod.rs:230-251）。
  3. Windows 文件监控 ✅ 新模块 fswatch_win.rs（ReadDirectoryChangesW）， 与 Linux fswatch 事件格式对齐，collectFiles/fileWatchDirs 在 Windows 侧有了消费者。
  4. 4625 字段补全 ✅ authwatch_win.rs 解析 Status/SubStatus → status_code/status_detail。
  5. sensor DNS 应答解析 + JA3S ✅ proto_id.rs：压缩指针安全解析、 rcode、A/AAAA 应答（至多 4 个）、ServerHello→JA3S；proto 新增 dns_rcode/dns_answers/ja3s；应答 IP 与 JA3S 自动入情报碰撞。

P2 —— 结构性增强

  1. Linux 持久化点扩展 ✅ fswatch 默认目录增加 /etc/systemd/system、/var/spool/cron、各用户 .ssh；inotify 递归化（限深 4 层，运行中动态补挂）。
  2. 文件事件带进程上下文 ✅ fanotify（FID 模式）优先路径：事件自带 pid → exe/comm/属主，无权限时干净回落 inotify（fswatch.rs:70）。
  3. 实机攻击验证环境（主流平台完成，旧 Windows 待补）。2026-08-09 Windows 冒烟 + Windows/WSL2 双语料实机回放（脚本与验证矩阵固化在 validation/replay/）。Windows： 进程启停带 cmdline、持久化点增删带旧值、8 条规则实机命中、良性对照 零误报。WSL2：fanotify 文件事件全生命周期带肇事进程、eBPF 出站捕获、 3 条规则实机命中。回放抓到 4 个合成对拍抓不到的真缺陷，全部当天修复 （fanotify O_PATH/DFID、NUL 事件毒化管道、规则裸名匹配不到实机 带引号全路径 cmdline）。同日已在两台 Debian 13 / PVE 9.2.2 真 Linux 宿主机完成 netlink 启停、短命进程 cmdline、fanotify 增改删、wtmp 登录、 内核模块及对应规则命中验证。仍待做：Win7/2008R2 实机。

兼容性备忘（本轮顺带解决/确认）

  • Win7/2008R2：ETW cmdline 信息类要求 Win 8.1+，已加 PEB 读取兜底 （windows.rs:235）；Rust MSVC 目标对 Win7 的运行支持需实机确认。
  • musl/32 位 Linux：authwatch 解析的 utmp 字段（type/line/user/host）偏移 在时间字段之前，musl 与 32 位布局相同，实际兼容（此前"会解析错误"的 担心不成立）。
  • CentOS 7 级老内核（3.10）：无 inet_sock_set_state（eBPF 网络采集降级）、 无 nftables（主机隔离失败）——维持现状，不为过老内核写兼容层。

当前迭代收尾记录（2026-08-09）

P0/P1/P2 代码改动按以下顺序完成收口：

  1. Linux 编译验证 ✅ 已完成（WSL2 Ubuntu 26.04）：agent/sensor 默认 特性 build+clippy(-D warnings)+test 全绿（37+46 测试），ebpf/xdp 特性 构建通过，相关改动已分组提交并推送。
  2. 双平台实机回放 ✅ 首轮完成：抓到 4 个真缺陷并修复 （见上条与 validation/replay）， 回放脚本与验证矩阵已固化进仓库。
  3. 实机验证收尾：真 Linux 机器（netlink EXIT、fanotify 在真内核复测、 进程类规则实机命中） ✅ 已在两台 PVE 7.0 内核宿主机完成；仍需 Win7/2008R2 实机（PEB cmdline 兜底 + MSVC 二进制兼容性）；当前无环境， 不纳入本轮完成条件，后续有机器时再补。

采集缺口综合规划（2026-08-09 第二轮，A/B 档全量完成）

经两轮全量缺口扫描（详见当日会话记录），采集面补齐以下项目，全部实机验证：

A 档（配置级扩充）：Security 日志 4720/4726/4732（账户管理）、1102 （日志清空）、4648（显式凭据）、4719（审计策略变更）；persistwatch 注册表 扩充（Defender Exclusions、IFEO Debugger、AppInit_DLLs、HKCU CLSID COM 劫持）+ 服务运行状态（EventLog 被停可见）；fswatch 扩充（/var/spool/at、 用户 shell rc 单文件目标）。

B 档（新采集能力）：

  • Windows 端点网络采集——推翻了此前"不做（sensor 已覆盖）"的判断： sensor 只能回答"哪台机器连了谁"，给不了进程归属。ETW Kernel-Network TcpConnect（无驱动）与 Linux eBPF 路径完全对称，共用归一化与 GUID 注册表 （netwatch_win.rs）。
  • WMI 事件订阅持久化（T1546.003，persistwatch WMI 快照 diff）。
  • Linux 内核模块加载（kmodwatch，class_uid=1005，引擎类别早已备好）。
  • PowerShell 4104 脚本块（cmd_line 承载 ScriptBlockText，规则直接作用于 脚本内容；依赖组策略开启）。

配套新增 11 条规则（账户管理/日志清空/显式凭据/脚本块/Defender 篡改/IFEO/ WMI 订阅/安全服务停止/内核模块/shell rc/at 任务），detectcheck 88 用例 0 意外，覆盖技术 40/40。

C 档（已知缺口，明确不做）：进程注入（T1055，需 PPL/驱动）、端点 DNS 归属（sensor 覆盖）、sudo 审计（进程 exec 已覆盖八成）、4672/5140/5145 （噪声与优先级）、PCAP/浏览器历史/软件清单。

可靠性验证（2026-08-09 第三轮）

  • fanotify/inotify 每 5 秒补扫启动时不存在或删除后重建的目标根， /var/spool/at 真 Linux 实测建/改/删完整。
  • Sigma 热重载改用规则内容 SHA-256 指纹，并消除 watcher 启动竞态；等大小、 等 mtime 覆盖写的真实漏重载形态已有回归测试。
  • eBPF 网络采集修复 SYN_SENT 源端口恒为 0：现在用 socket 地址跨状态关联 PID， ESTABLISHED/CLOSE 上报真实五元组。

增强池第 1 项：sensor TLS 证书元数据 ✅（2026-08-09 第四轮）

被动解析 TLS 握手 Certificate 消息：服务端方向有界重组（16KB 上限）应对证书跨 TCP 分段；自研迷你 X.509 DER 解析器（sensor/src/x509.rs，不加新 crate）， 提取叶证书 subject/issuer CN、自签标志（subject/issuer 原始 DER 相等启发式）、 有效期。ServerHello supported_versions=0x0304 识别 TLS 1.3 后停止等证书 （1.3 证书加密传输，协议上不可见——这是放弃 1.3 的依据，不是遗漏）。 proto FlowRecord 加 tls_cert_*=22-26，server 归一化进 tls.cert， 配规则 net_tls_self_signed_cert.yml（T1573.002，low）与 detectcheck 语料 （90 用例 0 意外，技术 41/41）。

队列、集群与可观测性（2026-08-09 第四轮）

  • 统一版本化事件信封，agent/sensor/syslog 使用稳定事件 ID 和资产分区键。
  • NATS JetStream WorkQueue 持久投递，分片 durable consumer 保序；处理成功才 ACK。
  • PostgreSQL 主键幂等与持久告警去重替代连接内存状态，重投、重连、节点切换 不再制造重复事件或重置去重窗口。
  • server 可多节点承接 HTTP/gRPC；后台任务用 advisory lease 单活，响应指令 通过 NATS 路由到实际持有 agent 长连接的节点。
  • /healthz、/readyz、Prometheus 指标、积压/失败/延迟告警与 Grafana 面板 已随三节点 Compose 固化，故障验收见 cluster.md。

维持"不做"的判断

macOS agent（无 Mac 开发/CI 环境，写了也守不住编译）、多租户、微服务拆分、 存 PCAP、自研规则 DSL。