检测即代码原则
像对待软件一样管理检测规则。
检测即代码原则 是 CoddyKit 上的免费 Cyber Security Academy 课时。 这是第 1 节课，共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。 这是 Cyber Security Academy 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 Cyber Security Academy 课程共包含 4 节课。
为何采用检测即代码
检测即代码（DaC）将软件工程的纪律应用于安全检测。检测规则不再由分析师在 SIEM 控制台中手动编辑，而是以文本文件的形式存储在版本控制系统中，并通过流水线发布。
其优势很具体：
- 通过拉取请求审查变更
- 在不同环境中实现可复现的部署
- 在逻辑进入生产环境前进行测试
- 保留谁在何时为何修改了什么的可审计历史
检测规则会成为一种构件，您可以像处理其他代码一样比较差异、回滚，并对其进行分析。
作为版本化文件的检测规则
每条检测规则都存储为独立文件，通常使用 YAML 或厂商查询语言，并提交到 Git 仓库。仓库布局反映您组织覆盖范围的方式。
一种常见结构是按平台和战术分离规则：
detections/
windows/
credential_access/
lsass_memory_dump.yml
execution/
suspicious_powershell.yml
cloud/
aws/
root_account_usage.yml
tests/
windows/
lsass_memory_dump_test.yml拉取请求审查
每条新建或修改的检测规则都要经过拉取请求流程。另一名工程师会在合并前审查逻辑、误报风险以及 ATT&CK 映射。
审查人员会询问：
- 逻辑是否符合所描述的威胁？
- 哪些合法活动可能触发该规则？
- 严重程度和 ATT&CK 参考是否正确？
- 是否有测试覆盖真实阳性和误报？
这能发现一名分析师凌晨 2 点独自在 SIEM 中编辑规则时可能遗漏的错误。
持续集成验证
每次推送都会自动运行持续集成流水线。它会在规则合并前执行质量门禁。
基于 Sigma 的仓库通常包含以下持续集成阶段：
# .github/workflows/validate.yml (excerpt)
steps:
- name: Lint Sigma syntax
run: sigma check ./detections
- name: Validate against schema
run: sigma check --validators all ./detections
- name: Run unit tests
run: pytest tests/自动化部署
合并后，部署任务会将可移植规则转换为目标查询语言，并通过应用程序编程接口将其推送到 SIEM 或 EDR。
对于 Sigma，通常会运行类似 sigma convert 的转换器，并使用与平台匹配的后端（Splunk、Elastic、Microsoft Sentinel）。随后，流水线会上传生成的已保存搜索或分析规则。
无需人工将查询粘贴到控制台中。已部署状态始终与 main 中的内容一致。
sigma convert -t splunk -p splunk_windows \
detections/windows/execution/suspicious_powershell.yml测试检测规则
没有测试的检测规则只是猜测。检测即代码会为每条规则配套测试数据：应当触发规则的日志样本（真实阳性），以及不应触发规则的良性样本（误报）。
测试会在持续集成中运行，因此任何破坏覆盖范围或重新引入噪声的变更，都会在合并前导致构建失败。在大规模重构规则时，这是最重要的信心来源。
test:
- log: { Image: 'C:\\Windows\\System32\\rundll32.exe', CommandLine: 'rundll32 javascript:...' }
expected: match
- log: { Image: 'C:\\Windows\\System32\\rundll32.exe', CommandLine: 'rundll32 shell32.dll,Control_RunDLL' }
expected: no_match规则元数据与生命周期
请将元数据视为一等信息。每条检测规则都会记录其在生命周期中逐步成熟时的状态：
experimental— 刚编写完成，需要密切监控test— 正在运行，但尚未得到充分信任，不能用于告警stable— 已得到验证，误报率较低deprecated— 已被替代或退役
在文件中跟踪状态，可以有计划地提升、降低或退役规则，而不是让过时的逻辑继续滞留在生产环境中。
跨后端可移植性
检测即代码的核心优势之一，是以与厂商无关的格式一次编写检测逻辑，然后将其编译到多个后端。Sigma 是基于日志的检测规则的事实标准。
通过特定于流水线的字段映射，同一个规则文件可以面向 Splunk SPL、Elastic Lucene/EQL、Microsoft Sentinel KQL 以及其他平台。这样既无需将同一个想法重写五遍，也能避免受制于单一厂商。
sigma convert -t elasticsearch rule.yml
sigma convert -t microsoft365defender rule.yml
sigma convert -t splunk rule.yml字段映射流水线
不同日志来源对同一数据的命名方式不同。Sysmon 的进程创建事件使用 Image；Windows Security 日志可能使用 NewProcessName。处理流水线可以弥合这一差异。
流水线会将通用的 Sigma 字段名称转换为数据实际使用的确切字段，使一条逻辑规则能够清晰地映射到 SIEM 所接收的任何架构。集中维护流水线意味着架构变更只需修复一次，而不必逐条修改规则。
sigma convert -t splunk -p sysmon rule.yml环境与晋级
与应用程序代码一样，检测规则在进入生产环境前也要经过多个环境。典型流程是从开发环境到预发布环境，再到生产环境。
- 开发环境 — 编写规则，并在持续集成中运行单元测试
- 预发布环境 — 以审计模式针对真实遥测数据的副本进行部署
- 生产环境 — 误报率达到可接受水平后再晋级
晋级是一个经过审慎审查的明确步骤，并与规则的生命周期状态关联，而不是合并时偶然发生的结果。这种分阶段发布方式，与内联检测中采用的先告警后阻断规范相呼应。
覆盖范围与指标
由于检测属于代码，您可以通过编程方式衡量覆盖范围。将每条规则关联到 MITRE ATT&CK 技术，并生成热力图，直观看到已覆盖和未覆盖的内容。
值得随时间跟踪的指标：
- 已覆盖的技术数与威胁模型中的技术总数之比
- 每条规则的误报率
- 从提出规则想法到部署到生产环境的平均时间
- 处于每种生命周期状态的规则数量
这些数字能让检测工程从凭经验讲述变成可管理的项目。
快速检查
请检验您对检测即代码基础知识的理解。
总结
检测即代码为检测工作带来了软件工程的严谨性：
- 规则以受版本控制的文件形式存放在版本控制系统中
- 变更需经过拉取请求审查
- 持续集成会自动执行代码检查、验证和测试
- 合并后的规则通过流水线部署，保持生产环境与主分支同步
- 测试可防止误报和回归问题
- 可移植性（西格玛 + 流水线）让一条规则能够面向多个后端
- 元数据、生命周期和指标让检测成为可管理的项目
接下来，您将使用西格玛编写可移植的规则本身。
常见问题解答
「检测即代码原则」课时是免费的吗？
是的 — 「检测即代码原则」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 Cyber Security Academy 课程的其余内容，请升级到 CoddyKit PRO。 Cyber Security Academy 课程共包含 4 节课。
「检测即代码原则」这节课中我会学到什么？
像对待软件一样管理检测规则。 你通过在浏览器中直接运行的动手代码来练习 Cyber Security Academy，全天候 AI 导师会在你学习这节课的过程中回答你的问题。
学习 Cyber Security Academy 需要有经验吗？
无需任何先前经验。CoddyKit 上的 Cyber Security Academy 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。 这是第 1 节课，共 4 节。
「检测即代码原则」课时需要多长时间？
大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。
我能在这节 Cyber Security Academy 课中编写并运行代码吗？
能。每节 Cyber Security Academy 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。