注意： 网站管理员必须先为实例启用 secret scanning，然后你才能使用此功能。 有关详细信息，请参阅“为设备配置密码扫描”。
如果企业所有者在企业级别设置了策略，你可能无法启用或禁用 secret scanning。 有关详细信息，请参阅“强制实施企业的代码安全性和分析策略”。
模式对检测
Secret scanning 将仅检测模式对（例如 AWS 访问密钥和机密），前提是 ID 和机密位于同一文件中，并且两者都被推送到存储库。 对匹配有助于减少误报，因为对的两个元素（ID 和机密）必须一起使用才能访问提供商的资源。
推送到不同文件或未推送到同一存储库的对不会导致警报。 有关受支持模式对的详细信息，请参阅“支持的机密扫描模式”中的表。
关于旧 GitHub 令牌
对于 GitHub 令牌，我们将检查机密的有效性，以确定机密是活动还是非活动的。 这意味着，对于旧令牌，secret scanning 不会检测 GitHub Enterprise Cloud 上的 GitHub Enterprise Server personal access token。 同样，不会在 GitHub Enterprise Server 上找到 GitHub Enterprise Cloud personal access token。
推送保护限制
如果推送保护未检测到你认为应该检测到的机密，你应首先检查推送保护是否支持受支持机密列表中的机密类型。 有关详细信息，请参阅“支持的机密扫描模式”。
如果你的机密位于受支持的列表中，则推送保护可能无法检测到它的原因有多种。
- 推送保护仅阻止最可识别的用户警报模式子集上的已泄漏机密。 当此类机密被阻止时，参与者可以信任安全防御，因为这些模式的误报数最少。
- 机密的版本可能太旧。 推送保护可能不支持某些旧版令牌，因为这些令牌生成的误报数可能高于其最新版本。 推送保护也可能不适用于旧令牌。 对于 Azure 存储密钥等令牌，GitHub 仅支持“最近创建”令牌，不支持与旧模式匹配的令牌。
- 例如，如果尝试推送数千个大文件，则推送可能过大。 如果推送过大，推送保护扫描可能会超时并且不会阻止用户。 GitHub 在推送后仍会根据需要扫描和创建警报。
- 如果推送导致检测到五个以上新机密，我们将仅显示前五个机密（我们将始终一次向你显示最多五个机密）。
- 如果推送包含 1,000 个以上现有机密（即已为其创建了警报的机密），则推送保护不会阻止推送。