研发平台安全审计可以按“定范围—建基线—采证据—查异常—出报告—跟踪整改”六步推进。先把账号、权限、代码与制品、配置与密钥、操作日志等对象纳入范围，再把每类对象应满足的规则写成可核验的检查项，用平台日志、权限清单和配置导出采集证据，逐项比对记录偏差，形成带风险等级与责任人的报告，最后按期限复检关闭。本文给出范围表、检查项写法、执行步骤、角色分工与收尾清单，AI使用权限与过程合规证据归档不在本文展开。
要点总览（TL;DR）
- 审计范围以研发平台整体安全为边界，覆盖账号与身份、权限与角色、代码仓库与分支保护、制品与发布、配置与密钥、操作日志六类对象，并用范围表锁定本期覆盖与不覆盖内容。
- 基线要把安全制度拆成含对象、判定条件、证据形式、通过标准、责任人的检查项，区分必查与抽查，高风险项单独标注，基线保留版本记录。
- 执行按定范围、建基线、采证据、查异常、出报告、跟踪整改六步推进，每步明确输入、动作、输出和完成标志，证据记录采集时间与数据时间范围。
- 平台管理员、安全负责人、研发团队负责人、审计执行人、整改责任人分工明确，判定与整改建议分离，审批与发布记录随报告归档。
- 收尾以范围覆盖一致、偏差有责任人与期限、高风险项已处置或批准延期、证据可追溯、报告已审批发布、复检安排明确为关闭条件。
先划清审计范围：哪些对象和边界要纳入
审计范围决定后续证据采集和人力投入。建议以研发平台整体安全为边界，把平台承载的账号、权限、代码、制品、配置、密钥和操作记录全部纳入候选清单，再根据本期审计目标标注覆盖与否。范围一旦确定，就形成本次审计的“覆盖面承诺”，后续报告和收尾都以它为准。
研发平台常见审计对象可分为六类：
- 账号与身份：人员账号、服务账号、机器人账号、外部协作账号，关注账号是否真实对应人员或系统、状态是否有效。
- 权限与角色：角色定义、权限分配、高权限角色持有人、临时授权，关注权限是否与岗位匹配、是否存在过度集中。
- 代码仓库与分支保护：仓库可见性、分支保护规则、合并审批要求、代码评审记录。
- 制品与发布：制品仓库访问控制、发布审批、发布记录与回滚记录。
- 配置与密钥：平台安全配置、集成配置、密钥与凭据的存放和轮换。
- 操作日志：登录日志、权限变更日志、关键操作日志的完整性与留存。
边界划分要写清楚哪些内容本期不审。例如AI使用权限的具体规则归研发AI应用权限与治理主题，研发过程合规证据的组织与归档归研发过程合规与审计主题，渗透测试与漏洞扫描的技术实施细节也不在本文范围。把这些写进范围表，可以避免审计执行中范围反复扩张。
范围表建议包含对象、证据来源、责任角色、是否本期覆盖四列，必要时增加“覆盖理由”列。下表为示例结构，可按组织实际调整：
| 审计对象 | 证据来源 | 责任角色 | 是否本期覆盖 |
|---|---|---|---|
| 人员账号与服务账号 | 账号清单导出、人事在职名单 | 平台管理员 | 是 |
| 角色与权限分配 | 权限清单导出、角色配置截图 | 平台管理员 | 是 |
| 代码仓库与分支保护 | 仓库配置导出、分支保护规则截图 | 研发团队负责人 | 是 |
| 制品与发布 | 发布记录、审批记录 | 研发团队负责人 | 是 |
| 配置与密钥 | 配置快照、密钥管理记录 | 平台管理员 | 抽查 |
| 操作日志 | 日志导出、留存策略说明 | 平台管理员 | 是 |
范围表需要安全负责人确认后才能进入基线设计。确认动作本身也是审计证据的一部分，说明覆盖面经过审批而非执行人自行决定。
建立可核验的审计基线：把规则写成检查项
审计无标准可依，往往是因为安全要求停留在制度条文。基线的作用是把“账号应及时回收”“权限应最小化”这类要求，翻译成能逐项判断通过与否的检查项。检查项写得越具体，证据采集和偏差判定越少争议。
基线来源主要有三类：内部安全制度与账号权限管理要求、变更与发布规范、平台自身的配置与日志要求。把来源条款逐条拆解，一条要求可能对应多个检查项。例如“权限最小化”可拆成“高权限角色持有人数不超过约定上限”“临时授权到期后已回收”“服务账号未授予交互式登录权限”等可判定条目。
一条合格的检查项应包含五个字段：
- 对象：检查哪类账号、配置或记录，指明具体范围。
- 判定条件：用什么规则判断，例如“离职人员账号在离职后约定工作日内停用”。
- 证据形式：需要什么材料证明，例如账号清单、停用操作记录、人事离职日期。
- 通过标准：全部符合为通过，出现例外如何记录。
- 责任人：谁负责提供证据、谁负责判定。
检查项表示例：
| 编号 | 对象 | 判定条件 | 证据形式 | 通过标准 | 类型 |
|---|---|---|---|---|---|
| ACC-01 | 人员账号 | 离职人员账号在离职后约定工作日内停用 | 账号清单、离职名单、停用记录 | 无超期未停用账号 | 必查、高风险 |
| ACC-02 | 高权限角色 | 高权限角色持有人数与岗位需要匹配 | 权限清单、岗位说明 | 持有人均有岗位依据 | 必查、高风险 |
| ACC-03 | 临时授权 | 临时授权到期后已回收 | 授权记录、回收记录 | 无过期未回收授权 | 抽查 |
| REP-01 | 主干分支 | 主干分支开启保护并配置合并审批 | 分支保护规则截图 | 规则存在且审批人生效 | 必查 |
检查项要区分必查项与抽查项，并对高风险项单独标注。必查项覆盖全部对象，抽查项用于验证执行一致性，例如从仓库中随机抽取若干项目核对分支保护是否实际生效。基线需要版本管理：每次修订记录版本号、修订内容、修订原因和生效日期，审计报告引用当次使用的基线版本，便于后续对比和追溯。
采集证据与执行核查：六步操作流程
六步流程把审计从准备推进到关闭，每一步都有明确输入、动作、输出和完成标志。执行人按步骤推进，可以避免证据采集中途返工，也便于向管理层汇报进度。
步骤一：定范围
输入是本期审计目标与平台资产清单，动作是填写范围表并确认覆盖与不覆盖对象，输出是经安全负责人确认的范围表。完成标志是范围表签字或审批通过。
步骤二：建基线
输入是安全制度、权限管理要求和发布规范，动作是拆解为检查项并标注必查、抽查与高风险，输出是带版本号的检查项表。完成标志是检查项经安全负责人评审，判定条件无歧义。
步骤三：采证据
输入是检查项表与范围表，动作包括日志导出、权限清单导出、配置快照、抽样复核。证据要记录采集时间、采集人、数据时间范围，确保可追溯。输出是按检查项编号归档的证据包。完成标志是每条检查项都有对应证据或明确标注“证据缺失”。
步骤四：查异常
输入是证据包与检查项表，动作是逐项比对并记录偏差。异常记录至少包含对象、偏差描述、风险等级、责任人、整改期限五个字段，必要时补充证据引用和影响范围。输出是偏差清单。完成标志是全部检查项完成判定，偏差均有责任人和期限。
步骤五：出报告
输入是偏差清单与范围表，动作是汇总审计结论、按风险等级排序、给出整改建议，输出是审计报告。报告应说明覆盖范围、基线版本、通过项与偏差项数量、高风险项处置建议。完成标志是报告经审批并发布给相关责任人。
步骤六：跟踪整改
输入是报告与偏差清单，动作是跟踪整改执行、收集整改证据、到期复检，输出是整改记录与关闭结论。完成标志是偏差项复检通过或经批准延期，报告状态更新为关闭。
证据采集方式要与对象匹配：账号和权限类以清单导出为主，配置类以快照和截图为主，流程类以审批记录和操作日志为主。抽样复核用于验证导出的清单与实际配置一致，例如抽取若干仓库核对分支保护规则是否与清单描述相符。审计记录和整改跟踪如果依托研发管理平台承载，可以把每条偏差建成工作项，关联证据文档，用状态流转记录“待整改—整改中—待复检—已关闭”，让责任人和期限在系统中可见。ONES 提供文档与工作项协作能力，可作为这类记录流转的承载方式之一；具体日志导出与权限清单能力需结合组织实际部署确认。
角色与交付物分工：谁提供证据、谁判定、谁整改
审计变成单人台账，通常是因为职责没有分开。建议至少区分五类角色：平台管理员、安全负责人、研发团队负责人、审计执行人、整改责任人。小团队可以一人兼多角，但判定与整改建议分离，避免自己审自己。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 平台管理员 | 导出账号、权限、配置与日志，说明平台配置现状 | 账号清单、权限清单、配置快照、日志导出 |
| 安全负责人 | 确认范围与基线，审批报告，裁定高风险项处置方式 | 范围确认、基线评审意见、报告审批 |
| 研发团队负责人 | 确认本团队账号与权限合理性，组织整改 | 权限确认意见、整改计划 |
| 审计执行人 | 执行比对、记录偏差、编写报告、组织复检 | 偏差清单、审计报告、复检记录 |
| 整改责任人 | 按期限完成整改并提交证据 | 整改记录、整改证据 |
角色之间的交接要有确认动作：平台管理员提交证据包后由审计执行人签收；偏差清单发给整改责任人时要求确认期限；整改完成后由审计执行人复检并在记录中签字。审计结论的发布路径建议为审计执行人起草、安全负责人审批、发送给研发团队负责人和整改责任人，高风险项同步报管理层。审批与发布记录本身也是审计证据，应随报告归档。
示例：一次账号权限审计的完整走查
以下为演示情景，用于说明从检查项到整改关闭的记录方式，数据为示例，不代表真实组织情况。
场景：某研发平台在一次季度审计中发现两类问题，离职账号未及时回收，高权限角色过度集中。审计执行人按六步流程走查如下。
范围与基线。范围表将人员账号、高权限角色、临时授权列为本期覆盖对象，证据来源为账号清单、权限清单和人事离职名单。基线引用 ACC-01、ACC-02、ACC-03 三条检查项，ACC-01 与 ACC-02 标注为必查高风险项。
证据采集。平台管理员导出截至审计日的账号清单和权限清单，安全负责人提供同期离职名单。审计执行人记录采集时间与数据时间范围，并对权限清单抽取若干高权限账号核对岗位说明。
偏差判定。比对发现：3 个离职人员账号在离职后超过约定工作日仍未停用；高权限角色持有人共 12 人，其中 4 人岗位说明中无对应职责依据。两条偏差分别记录为：
| 编号 | 对象 | 偏差描述 | 风险等级 | 责任人 | 整改期限 |
|---|---|---|---|---|---|
| DEV-01 | 人员账号 | 3 个离职账号超期未停用 | 高 | 平台管理员 | 5 个工作日 |
| DEV-02 | 高权限角色 | 4 名持有人缺少岗位依据 | 高 | 研发团队负责人 | 10 个工作日 |
报告与整改。审计报告将两条偏差列为高风险项，附证据引用和整改建议。平台管理员停用离职账号并提交停用记录；研发团队负责人复核 4 名持有人，保留 2 人并补充岗位依据，回收 2 人权限并提交权限变更记录。
复检关闭。审计执行人复检账号状态和权限清单，确认偏差消除，在记录中填写复检日期与结论，报告状态更新为关闭。若某条偏差无法按期完成，需由安全负责人批准延期并记录新的期限。
这套记录格式可以迁移到其他对象：代码仓库审计把“对象”换成仓库与分支，“证据”换成分支保护规则截图，“整改”换成规则配置变更；发布流程审计把“证据”换成发布审批记录，“整改”换成审批流程调整。判定条件、风险等级、责任人、期限、复检这几个字段保持不变，审计记录就能横向对比。
完成检查：审计收尾要确认的事项
审计是否达到可交付状态，可以用一份收尾清单逐项核对。清单全部通过后再宣布本次审计关闭。
- 范围覆盖一致：实际审计对象与范围表一致，未覆盖对象有明确说明和确认记录。
- 偏差记录完整：每条偏差都有对象、描述、风险等级、责任人和整改期限，无悬空条目。
- 高风险项已处置：高风险偏差已完成整改并复检通过，或已由安全负责人批准延期并记录新期限。
- 证据可追溯：证据包按检查项编号归档，记录采集时间、采集人和数据时间范围，报告引用的证据可定位。
- 报告已审批发布：报告经安全负责人审批，已发送至相关责任人，审批与发布记录随报告归档。
- 复检安排明确：已关闭偏差有复检记录，未关闭偏差有下次复检日期。
- 下次审计触发条件明确：约定定期审计周期，并说明平台重大变更、组织调整或安全事件后启动专项审计的条件。
收尾时还应回看基线本身：本次审计中反复出现的偏差，可能说明检查项判定条件需要细化，或某项安全要求缺少落地机制。把这类观察写入报告的建议部分，作为下一版基线修订的输入，审计才能从一次性检查转为持续改进的循环。
常见问题
审计过程中发现范围表遗漏了某类对象，应该中途扩大范围吗？
建议先记录遗漏对象，评估其与本期审计目标的关系，再由安全负责人决定是否纳入。若纳入，需要同步补充对应的检查项和证据来源，并在报告中说明范围变更原因和确认人；若不纳入，写入“本期不覆盖”并注明理由，作为下次审计的输入。中途随意扩大范围容易导致证据采集返工和期限失控，范围变更应保留审批记录。
检查项判定条件写得比较笼统，执行时争议很大，怎么处理？
把笼统表述拆成可观察的事实。例如“权限应合理”可以改为“高权限角色持有人均有岗位说明中的对应职责”，并明确证据是权限清单加岗位说明。若某条检查项在评审时仍无法形成一致判断，先降为抽查项或暂不纳入本期基线，在基线修订记录中注明原因，下一版再细化。判定条件有歧义时，不要在执行阶段临时解释，否则不同执行人得出的结论无法横向比较。
高风险偏差到期未整改完成，审计还能关闭吗？
可以关闭本次审计，但该偏差不能直接标记为已整改。需要由安全负责人批准延期，记录新的整改期限、延期理由和临时控制措施，报告状态可更新为关闭并附未关闭偏差清单。下次复检时优先核对延期项。若高风险项涉及正在发生的安全风险，应先采取临时处置措施，再走延期流程。
审计记录和整改跟踪放在文档里还是工作项里更合适？
取决于偏差数量和跟踪周期。偏差较少、一次性审计可以用文档承载，按检查项编号归档证据和结论；偏差多、整改跨多个团队和周期时，把每条偏差建成工作项更便于分配责任人、设置期限和查看状态流转。ONES 提供文档与工作项协作能力，可作为这类记录流转的承载方式之一；具体日志导出与权限清单能力需结合组织实际部署确认。
下次审计什么时候启动，需要重新建基线吗？
建议约定固定审计周期，并在平台重大变更、组织调整或安全事件后启动专项审计。基线不必每次重建，但应回看上一版：反复出现的偏差可能说明判定条件需要细化，制度变化也需要同步更新检查项。每次修订记录版本号、修订内容、原因和生效日期，审计报告引用当次使用的基线版本，便于跨期对比。
