在ci/cd中嵌入日志审计与合规检查，需覆盖代码提交、镜像构建、安全扫描、部署动作、运行时权限五类事件，结构化为带trace_id的json；设置构建、扫描、部署前、上线后四道硬性卡点；日志须只追加、签名、离线存证；报告须明确回答“谁干的、为什么干、有没有错”。
在 CI/CD 流程中嵌入自动化日志审计与合规检查，不是加一道“安检门”，而是把审计能力变成流水线的呼吸节奏——每次构建、每次部署、每次配置变更，都同步生成可验证、可追溯、可归责的操作证据。
日志采集必须覆盖全链路关键节点
仅记录应用日志远远不够。真正的审计日志需贯穿从代码提交到容器运行的完整生命周期，重点捕获以下五类事件：
- 代码提交与分支合并：谁、何时、向哪个分支推送了什么变更（Git hook 或 CI 触发器自动提取 commit author、SHA、PR 关联信息）
- 镜像构建行为：Dockerfile 解析结果、基础镜像来源、构建时使用的 UID/GID、是否启用 --no-cache 等安全参数
- 安全扫描执行过程：Trivy/Kube-bench/OPA 的原始输出、扫描时间戳、策略版本、是否跳过某类检查
- 部署动作本身：Spinnaker pipeline 执行人、目标环境（dev/staging/prod）、所用 manifest 版本、Helm values 差异摘要
- 运行时权限变更：Kubernetes PodSecurity Admission 拒绝事件、ServiceAccount 绑定更新、Secret 挂载行为
这些日志应统一结构化为 JSON，并打上 trace_id 与 pipeline_id 标签，便于跨系统关联分析。
合规检查要嵌入具体卡点，而非泛泛而谈
合规不是“有没有做”，而是“在哪个环节、按什么标准、由谁确认过”。推荐在 CI/CD 中设置以下硬性卡点：
- 构建阶段：Dockerfile 必须声明 USER（非 root），且禁止使用 ADD 指令直接拉取远程脚本；未通过则终止构建
- 镜像扫描阶段：Trivy 扫描结果中，CRITICAL 级漏洞数量必须为 0，HIGH 级不超过 2 个且需附带 Jira 工单链接才允许放行
- 部署前阶段：OPA/Gatekeeper 对 Helm render 后的 YAML 执行策略校验，如发现缺失 securityContext.runAsNonRoot、未设置 resources.requests，立即阻断
- 上线后阶段：通过 Prometheus + LogQL 自动巡检 audit log，确认过去 1 小时内所有 /mutate、/alter 请求均有对应审计日志条目，缺失即触发告警
审计日志本身必须具备防篡改与可验证性
日志若可被随意覆盖或删除，就失去审计价值。需落实三项技术控制：
- 所有审计日志写入只追加（append-only）存储，例如 Loki 的 retention + chunk store 配置，禁用 delete API
- 日志文件级签名：使用私钥对每批次日志哈希值签名，公钥内置在审计服务中，供后续回溯验证完整性
- 定期导出日志摘要至离线介质（如加密 USB 或区块链存证服务），形成不可抵赖的时间锚点
例如 Dgraph 的 audit/audit.go 中 InitAuditor 函数即支持密钥文件加载与 AES-GCM 加密写入，可直接复用其日志初始化逻辑。
报告生成需面向真实使用场景
合规报告不是堆砌数据，而是回答监管或内审最常问的三个问题：
- 谁干的？—— 关联 Git 用户、CI 系统账号、K8s ServiceAccount，还原操作主体身份链
- 为什么干？—— 提取 PR 描述、Jira ticket、pipeline trigger reason，说明业务动因
- 有没有错？—— 显示该次操作触发的所有策略检查结果（通过/失败/忽略），并高亮失败项的修复建议
OneDev 的访问控制审计模块已支持导出含角色变更轨迹的 PDF 报告；Spinnaker 可通过 Kayenta 的 automated-canary.yaml 模板扩展审计元数据字段，实现一键生成符合 ISO 27001 附录 A.9 要求的交付物。
