源代码防泄密审计体系建设，极狐GitLab审计事件与推送规则

源代码防泄密审计体系：以代码仓库为对象，通过推送规则事前拦截敏感内容、密钥检测事中扫描、审计事件事后追溯三层机制，形成的可验证的代码资产防泄露与合规留痕方案。

代码资产的泄密，很少是黑客攻破防火墙那种大戏，更多是三件「小事」：开发者把云服务密钥随手提交进了仓库；离职员工在最后一个月批量克隆了核心项目；某个外部协作者的权限被悄悄改成了维护者。等安全团队发现时，密钥可能已经在攻击者的字典里跑了很久。

防泄密的正确姿势不是「事后查监控」一条腿走路，而是把拦截、扫描、追溯做成闭环。极狐GitLab 在这一个平台里把三层能力都给了出来：推送规则管事前，密钥检测管事中，审计事件管事后。这篇文章把三层拆开讲清楚，每层都给到可落地的配置。

一、三层防线全景：各管一段，缺一层就漏一截

依据密钥检测官方文档的建议，企业应该「采用多层安全防护方法，并启用所有可用的密钥检测方式」——这个原则对整个防泄密体系同样成立。

只做其中一层的团队，泄密路径往往就绕开了那一层：比如只开流水线扫描，密钥已经进仓库了才发现，还得处理历史；只靠审计事件，能查到「谁干了什么」，但拦不住当下这一次。

二、事前拦截：推送规则是仓库门口的安检门

依据推送规则官方文档，推送规则本质是界面化配置的 pre-receive Git 钩子——每次 git push 到达服务端时执行校验，不合规直接拒绝。与受保护分支管「谁能推哪个分支」不同，推送规则管的是「推送内容本身合不合规」。

防泄密场景下最值得打开的几条规则：

配置入口在项目 > 设置 > 代码仓库 > 推送规则。有两个容易踩坑的机制要提前知道：

1. 推送规则是模板而非继承设置。全局推送规则只对之后新建的项目生效副本，存量项目必须逐个按项目覆盖；删除项目推送规则后，项目不会自动回退到全局或群组规则，而是处于「无规则」状态。

2. 每个正则上限 511 字符，且使用 RE2 语法，不支持先行断言。复杂拦截清单建议按官方正则示例组合，例如阻止 .exe、根目录 config.yml、任意位置 install.exe 可合并为一个表达式。

用项目推送规则 API 可以把配置固化成脚本，批量治理存量项目：

curl --request POST \
  --header "PRIVATE-TOKEN: <your_token>" \
  --url "https://gitlab.example.com/api/v4/projects/<项目ID>/push_rule" \
  --data "deny_delete_tag=true&member_check=true&max_file_size=10&file_name_regex=\\.pem$|\\.key$"

三、事中扫描：密钥检测的三道网，别只开一道

推送规则按文件名拦截，但密钥藏在代码里、变量里、注释里时，文件名看不出来。这就是密钥检测的职责——它扫的是内容。官方明确给出三道网：

1. 密钥推送保护：推送到达时扫描提交中的密钥，检测到即阻止推送（除非显式跳过），把泄露扼杀在到达仓库之前；

2. 流水线密钥检测：作为 CI/CD 流水线一部分运行，扫描推送到默认分支的提交；在合并请求流水线启用后，还能扫描开发分支提交，在密钥进入默认分支之前响应；

3. 客户端密钥检测：在议题和合并请求的描述与评论保存前扫描，防止密钥通过文档渠道溜出去。

三道网已经漏掉的密钥，会进入漏洞报告留档，部分密钥类型甚至支持自动撤销。误报治理方面，购买了极狐GitLab Duo 附加组件的旗舰版客户可以使用 Duo 误报检测，每次扫描后自动运行并为每项评估给出置信度分数和说明——安全团队不必再逐条人肉排查。

一句话概括分工：推送规则拦「文件名」，密钥推送保护拦「内容」，流水线检测兜「历史」。三层全开才是完整的事前事中防线。

四、事后追溯：审计事件无限期保留，泄密调查有据可查

真出了事，调查要回答的问题永远是：谁、什么时候、动了什么权限。依据审计事件官方文档，极狐GitLab 可以跟踪「谁在何时更改了某个项目中特定用户的权限级别」「谁在何时添加或移除了用户」，并且审计事件无限期保留——官方原文明确「由于没有保留期限，所有审计事件都可用」。

对防泄密调查来说，三个细节值得注意：

• 角色边界清晰：查看群组全部事件需所有者角色，项目级需维护者角色，开发者只能看到自身操作产生的记录；审计员访问级别的用户可查看所有用户的群组和项目事件，适合专职合规人员；

• API 单次查询窗口最多 30 天：群组和项目审计事件的 created_after 与 created_before 参数相差不能超过 30 天，批量导出时按月切片即可；

• AI 审计事件：极狐GitLab Duo Agent 会话会生成 AI 审计事件，捕获每个会话的输入、模型上下文、事件时间线和输出——AI 参与研发后的「谁让 AI 干了什么」，同样有据可查。

查询群组审计事件的 API 示例（注意 30 天窗口限制）：

curl --header "PRIVATE-TOKEN: <your_token>" \
  "https://gitlab.example.com/api/v4/groups/<群组ID>/audit_events?created_after=2026-11-01&created_before=2026-11-30"

对于需要把审计日志接入企业统一日志平台（SIEM）做独立留存的团队，可进一步使用审计事件流功能将事件实时发送到外部目标——「删库的人也能删日志」的风险由此被隔断。

五、落地清单：四步把体系立起来

1. 盘点高危项目：按敏感等级给代码仓库分级，核心仓库优先启用全套推送规则与密钥推送保护；

2. 配置事前拦截：打开阻止密钥文件、设置禁止文件名与最大文件大小，外部协作仓库追加「拒绝未签名的提交」；存量项目通过推送规则 API 批量覆盖；

3. 开启事中扫描：在 CI/CD 中引入密钥检测作业，覆盖默认分支与合并请求流水线，配置 Duo 误报检测降低噪音；

4. 验证追溯链路：用审计事件 API 按月导出权限变更记录，演练一次「离职员工权限回收」场景，确认事件可查、可导出、可交付。

FAQ

Q1：推送规则和密钥推送保护都开着，会重复拦截吗？

不冲突，二者拦截对象不同。推送规则按内置的文件名清单（如 id_rsa、.aws/credentials）和自定义正则拦「文件」，密钥推送保护按内容特征拦「密钥值」。同时启用才能覆盖文件名可辨和密钥内嵌两种泄露形态。

Q2：审计日志会被定期清理吗？多久之前的还能查？

不会。官方文档明确审计事件无限期保留，没有清理周期。唯一的时间限制在查询环节：群组和项目审计事件 API 单次查询的起止日期最多相差 30 天，按月分批查询即可覆盖任意历史区间。

Q3：密钥已经提交进仓库了，推送规则还能拦住吗？

拦不住。推送规则只作用于推送时的文件，官方明确「此推送规则不会限制已提交到代码仓库的文件」。已入库的密钥要靠流水线密钥检测在漏洞报告中识别出来，并尽快撤销、替换密钥，必要时重写历史。

如果你的团队正在把代码仓库纳入数据安全与内控审计范围，建议先用免费试用在测试项目里把推送规则和密钥推送保护跑一遍，感受拦截节奏；也可以预约演示，让解决方案团队按你们的仓库分级给出配置基线。完整的官方文档见极狐GitLab 文档中心。