如何在代码进入拉取请求之前捕获安全漏洞
内容提要
本文介绍通过 Git 预提交钩子实现安全左移：用 DevSkim 扫描暂存文件，用 Gitleaks 检测硬编码密钥，快速反馈弱加密、危险 API 等问题。但钩子可被跳过，需在 CI 中重复检查。建议只扫描变更文件、优先阻断高危问题、谨慎处理误报并逐步推广。
延伸解读
预提交钩子的定位与局限
预提交钩子能在代码提交前快速反馈安全问题，但开发者可用 git commit --no-verify 跳过。因此它并非强制关卡，不能替代 CI 扫描或人工审查。文章建议将预提交用于本地快速反馈，同时在 CI 中运行相同或等效检查，形成分层防护。
DevSkim 与专用密钥扫描器的分工
DevSkim 是安全 linter，主要检测危险 API、弱加密等不安全编码模式，其内置的凭证规则基于正则，仅针对长令牌类值。对于硬编码密钥，应搭配 Gitleaks 等专用扫描器，后者利用熵和模式检查，能更可靠地识别真实凭证。两者互补，不可互相替代。
误报处理与规则调优
静态分析难免误报，正确做法是验证可 exploit 性并修复真实风险，对合理例外使用窄范围抑制并记录原因，定期审查。避免直接禁用扫描器或大范围排除目录，否则会形成盲点。初期可只阻断高置信度问题，逐步调优规则。
渐进式推广与效果衡量
建议从一两个仓库开始，先基线化现有问题，再逐步启用新规则。初期只阻断高影响问题，分享修复示例，跟踪重复模式以指导安全培训。衡量指标应关注采用率和修复时间，而非仅统计发现数量，目标是让安全成为默认选择。
Q&A
为什么要在代码提交前进行安全扫描？
在代码提交前扫描可以让开发者在代码还记忆犹新时获得反馈，避免等到拉取请求、CI构建或渗透测试时才发现暴露的凭证和不安全模式，从而减少不必要的返工。
DevSkim是什么？它能检测哪些安全问题？
DevSkim是微软创建的安全linter，提供IDE扩展和跨平台CLI，使用可配置的规则集标记不安全的编码模式。它能检测危险API使用、弱加密、不安全反序列化、弱TLS或证书验证以及潜在的命令注入风险。
如何配置Git预提交钩子来运行DevSkim和Gitleaks？
首先安装pre-commit和DevSkim CLI，然后创建.pre-commit-config.yaml文件，配置本地钩子运行DevSkim（通过包装脚本处理多个文件），并添加Gitleaks钩子。最后运行pre-commit install安装钩子。
DevSkim能检测硬编码的密钥吗？为什么还需要Gitleaks？
DevSkim不是专门的密钥扫描器，它只包含一些针对长令牌类值的通用凭证规则，基于正则表达式。对于可读的占位符字符串或真实形状的密钥，DevSkim可能无法检测。Gitleaks使用熵和模式检查专门针对凭证，因此需要与DevSkim配合使用。
预提交钩子可以被跳过吗？如何确保安全检查在CI中强制执行？
是的，可以使用git commit --no-verify跳过钩子。因此需要在CI中运行相同或等效的安全检查。例如，在GitHub Actions工作流中配置DevSkim和Gitleaks，在拉取请求和推送到主分支时运行。
如何处理预提交安全扫描中的误报？
误报在静态分析中是预期的。不要禁用整个扫描器。应验证发现是否可利用，如果存在真实风险则修复。当例外合理时，使用范围狭窄的抑制，记录原因并定期审查。避免广泛排除整个目录，以免形成盲点。
在团队中推广预提交安全扫描有哪些实用建议？
从一两个仓库开始，在强制执行新规则前对现有发现进行基线评估。最初只阻止高置信度、高影响的问题，然后与开发者分享发现和修复示例。跟踪重复模式以指导安全编码培训，并衡量采用率和修复时间，而不仅仅是发现数量。
