将新安全厂商数据映射到 Dynatrace…

当需要把新安全厂商的 API 样本或实时事件映射到 Dynatrace security.events 字段，并校验映射完整性与合规性时使用。

适用场景

解决思路

1. 先运行 references/intake-and-constraints.md 中的 intake checklist；若输入不完整，可继续产出部分草稿，但必须显式列出缺失证据与置信度限制。
2. 根据上下文判断工作模式：Workflow A（仅有原始厂商 API payload，建议新映射）、Workflow B1（已有映射 + 厂商 API 样本，静态校验）、Workflow B2（已有映射 + 实时租户访问，运行时校验）。
3. Workflow A：按 references/mapping-workflow.md § Workflow A 执行，先产出 Phase 1 映射表，获得用户批准后再产出 Phase 2 样本 JSON。
4. Workflow B1：按 references/mapping-workflow.md § Workflow B 执行，先分类输入模式（最终已摄取 / 理论值），应用规则，产出带差异高亮的表格。
5. Workflow B2：按 references/runtime-validation.md 执行，先加载 security (AppSec) events 支持技能（必需的 Step 0），再运行 query pack，产出 Validation Summary 表。
6. 确保映射覆盖每个 finding class 对应的正确 event.type 集合；检测类集成是 push-based，不使用 scan cycle，绝不要为检测类要求 scan 事件。
7. 当检测类映射错误地发出 *_SCAN 事件时，按 references/validation-policy-and-reporting.md 中的替代分类路径处理。
8. 按 references/validation-policy-and-reporting.md 应用校验规则：event-type 覆盖、必填字段、scan 引用、namespace 要求、值/类型检查、vendor-namespace 重复。
9. 遵循 references/validation-policy-and-reporting.md 中的可接受偏差策略：对该列表中的字段不要提出 critical/major 问题。
10. 对真正未知的字段（既不在本地引用中，也不在实时 SD 中）按 references/validation-policy-and-reporting.md 提出质疑。
11. 以 references/semantic-reference.md 作为 SD 权威参考，处理本地 vs 实时来源、可查询的 Grail 表、when-to-query 决策矩阵；当出现分歧时以实时 SD 为准。
12. 仅在主要引用（SD、data-model-notes、known-discrepancies、validation-rules、object-type-expectations）无法解决特定问题时，才查阅 samples/ 中的真实集成 payload 作为兜底，不要在每个工作流中例行查阅。
13. 所有工作流都遵循 references/intake-and-constraints.md 的输出契约和 references/validation-policy-and-reporting.md 的报告模板。
14. 产出差异高亮、gap 分析和可执行的映射改进建议。

适用边界 · 注意事项

• 不负责实时摄取管道的部署。
• 不做运行时 DQL 性能基准测试。
• 不处理租户侧的摄取故障排查。