如何将 GitHub 上的变更管理作为 ISMS（ISO/IEC 27001）与 SOC 2 的审计证据

开发团队接受 ISMS（即 ISO/IEC 27001）或 SOC 2 审查时，几乎一定会被问到变更管理。代码都在 GitHub 上，也做了代码评审——可到了“该拿出什么、怎么展示”这一步，很多团队仍会卡住。

本文先梳理审计师在变更管理上想确认的内容，再依次说明 GitHub 侧应做好的设置，以及证据的留存方式。

审计师在变更管理上想确认什么

相关标准条款如下。

两者都没有写“必须在 GitHub 中这样配置”。审查关注的是：能否用记录证明变更是按既定程序进行的。

实际的核查通常按以下流程进行。

1. 要求提供观察期内进入生产环境的变更清单
2. 从清单中抽取若干项变更
3. 针对每项抽取的变更，确认是否由提交者以外的人批准后才进入生产环境
4. 如有紧急变更，确认是否留有事后批准和记录

也就是说，需要的是覆盖整个期间的变更清单，以及每项变更的批准痕迹。缺了任何一项，解释起来都会很吃力。

在 GitHub 中应做好的设置

在谈证据之前，先用 GitHub 的设置把程序本身强制执行起来。不只是把运行规则写进文档，而是让机制上无法违反，这样审查时的说明会简短得多。

对进入生产环境的分支（如 main），通过分支保护或规则集（ruleset）设置以下内容。

• 合并前必须创建拉取请求（Pull Request）：堵住直接 push 就能改动生产代码的路径
• 至少需要 1 个批准：没有提交者以外的人批准就无法合并
• 有新的 push 时撤销已有批准：防止批准后再悄悄追加改动
• 管理员也不例外：如果只有管理员能绕过保护，就无法声称“所有变更都经过了批准”
• 禁止强制改写历史（force push）和删除分支

同时，在变更管理程序文档中写明“哪个分支是生产分支”“紧急情况下由谁、如何批准，事后留下什么记录”。设置与程序文档是否一致，也是审查会关注的一点。

为什么截图不够

常见的做法是截取拉取请求页面或分支保护设置页面，贴进资料里。这种做法存在结构性的弱点。

• 只能证明某一时刻。 设置页面的截图只能证明“截图那一刻是这个设置”。如果在观察期中途曾一度关闭保护后又恢复，这一事实不会出现在截图里
• 难以确认日期和来源。 图片里的日期只是图片的一部分，第三方无法确认它是何时、从何处截取的
• 每次收集都很费事。 针对每项被抽取的变更去找页面、截图，每次审查都要重来一遍

在审计师一侧，相比这类手工证据，要求提供自动带有时间戳、可追溯的记录的趋势也越来越明显。

如何留下覆盖整个期间的记录

要点有两个。

1. 在变更发生的当时就记录。 不是在审查前夕集中收集，而是在 push 或拉取请求合并发生时，就记录何时、何人、做了什么。事后再收集，期间被删除或被修改的内容就无法捕捉。

2. 以被评估方事后无法改写的形式留存。 GitHub 的事件历史和审计日志很方便，但这些记录位于被评估组织自己管理的系统之中。而且保留期有上限，某些套餐可能无法覆盖 6–12 个月的观察期。建议先确认一下自己所用套餐的保留期。

要证明记录事后未被改写，常用的方法是把每条记录的指纹（哈希值）与上一条记录串联起来。一旦改写中间的任何一条，其后的所有链接都会对不上，因此一旦被篡改即可检测出来。

SPHIOR 能做什么、不能做什么

SPHIOR 的 GitHub 集成会自动完成上述两点。

• 在 push、拉取请求的创建与合并等事件发生时即时记录
• 记录包含事件类型、执行人、发生时间，以及 GitHub 发来的完整内容的指纹。内容本身不予保存
• 记录以指纹相互串联的形式封存，一旦被篡改即可检测。也可以导出验证包，自行核验

另一方面，以下几点 SPHIOR 无法弥补。

• 评审的批准操作本身，目前不在记录范围内。 对于批准，请通过上文所述的分支保护设置强制“未经批准无法合并”，并以该设置和程序文档加以说明
• SPHIOR 不判定审计是否通过。 SPHIOR 提供的是向审计师展示用的辅助证据

免费额度下记录保留 90 天。当需要覆盖整个观察期的记录时，可以切换到保留期更长的套餐（价格）。

总结

• 变更管理审查关注的是期间内的变更清单，以及每项变更的批准痕迹
• 在 GitHub 中用分支保护强制批准，且管理员也不例外
• 截图只能证明某一时刻。在事件发生时以无法改写的形式记录，才更可靠

为了不在审查前夕手忙脚乱地截图，最好的办法是在审查之前很早就开始记录。