安全与合规平台演练

本文演示一个以安全门禁、权限治理、审计证据和放行规则为核心的仓库，如何从风险澄清到 review / release 收口完整跑通。

1. 场景

• 仓库当前主要维护安全扫描、权限基线、例外管理和审计记录
• 团队准备补齐安全门禁与发布放行规则
• 目标不是改业务功能，而是把安全结论治理成可分层解释、可复盘、可放行的状态

2. 推荐链路

1. /team-intake
2. /team-plan
3. /tdd
4. /team-execute
5. /verify
6. /team-review
7. /team-release

3. 第一步：/team-intake

输入示例

/team-intake
目标：补齐安全基线与合规审计仓库的门禁、证据和放行规则
范围：安全扫描、权限基线、例外管理、release 说明、测试计划
不做：无关业务功能改造
约束：必须区分阻塞风险、可接受例外、观察项和最终放行条件

期望输出重点

• 识别这是安全治理任务，而不是普通交付任务
• 明确参与角色至少包括 tech-lead、architect、qa-engineer、devops-engineer
• 风险应聚焦权限边界、审计缺口、放行标准不清和例外项失控

4. 第二步：/team-plan

需要拆清的动作

• 安全门禁与风险分层
• 权限边界与例外管理
• 审计证据和 release 记录
• review / release 中的接受风险位置

5. 第三步：/tdd

重点是先锁风险分层和放行标准：

• 哪些是阻塞项
• 哪些是可接受例外
• 哪些只是观察项
• 哪些证据必须进入 review / release

6. 第四步：/team-execute

执行阶段通常包含：

• 调整扫描与基线规则
• 收敛权限与例外说明
• 更新 review / release 模板与证据位置

7. 第五步：/verify

Verify 阶段要回答：

• 当前阻塞项有哪些
• 例外项是否有正式接受记录
• 审计证据是否可追溯
• 当前是否满足进入 review / release 的条件

8. 第六步：/team-review 与 /team-release

Review 阶段要回答

• 当前是否还存在阻塞发布的安全风险
• 哪些例外暂时接受，谁负责承担

Release 阶段要回答

• 放行条件是什么
• 回退或临时降级路径是什么

9. 常见错误

• 把阻塞项和观察项混成一个结论
• 工具通过了，但没有正式放行说明
• 例外项没有责任人和期限